| Sections | |
| |
| Andover.Net | |
|
| Trolltech Developing Qt That Doesn't Need X |
According to Trolltech's release, "Qt/Embedded will also provide functionality not found in the X Window System, such as anti-aliased text rendering and alpha-blending of images. For increased performance, Qt/Embedded can utilize hardware graphics acceleration and it is well suited for multimedia and Web applications."
Flashy graphics without the overhead of X looks like a winner for all the companies providing embedded Linux devices and sofware.
< Is "coke.ch" A Violation of Coca-Cola's (tm)? | Cracking Military Devices >
| Slashdot Login |
| Don't have an account yet? Go Create One. A user account will allow you to customize all these nutty little boxes, tailor the stories you see, as well as remember your comment viewing preferences. |
| Related Links |
|
|
| This discussion has been archived. No new comments can be posted. |
|
Trollin' for Trolltech (Score:0, Interesting) by Anonymous Coward on Tuesday March 21, @03:10PM EST (#2) |
|
Stuff like this is why Linux is going to take awhile (a few decades) to become a serious threat to other OS's. There is no centralized authority and people keep coming out with more and more crap to throw to the pile. |
|
Re:Trollin' for Trolltech (Score:0) by Anonymous Coward on Tuesday March 21, @05:36PM EST (#108) |
|
one word options |
|
It's all about KOffice. ( Nice sarcsim ) (Score:3, Insightful) by Forge (forge @ myrealbox.com?Subject=Slashdot) on Tuesday March 21, @09:48PM EST (#209) (User Info) http://www.netcraft.com |
|
I wonder how many slashdot readers figured out that this poster is being sarcastic? Anyway here is my take on this new embeded QT. I read through the comments looking for someone who gets the real significance of this and came up with a blank. So here is my take on this baby. When WinCE was 1st released oneof MSs major promises was that it would let you run the same apps and exchange files in the same format on both desktop and palmtop. Basically they promised MSWord in a pocket sized version. It never happened and the reason is simple. MS office is over 200 megs of bloat. If they could have made it smaller they probably would but frankly that's tough to do. a 16 meg office suite and OS combination just isn't going to happen. fast forward to the present. portable Linux has a compressed file system almost dubbing the capacity of a flash card so all you really need is a 32 meg office suite to fit in 16 megs of flash. KOffice is normally under 30 megs with the kdelibs. add on 2 megs of QT and 400 K kernel with all the drivers for that device plus frame buffer and you are running in 16 megs of cache with an OS and an OFfice suite. add another 16 or 32 megs of RAM to run everything in and you can get decent performance plus a desktop. THAT is the significance of this thing. Linus plus Transmeta plus Troll Tech and the KDE team are about to deliver on Bill's promise. Frankly I would hate to be a microsofty right now. As for little issues like "dose this interface match the small size device?". They don't matter. Interfaces can be hacked and adjusted and with tidy modular code like this it doesn't really take much for good GUI designers to "fix" it. Isn't it surprizing how badly I spell ? |
|
Flamebuffer? (Score:0, Offtopic) by Kent Berglund (kb@rri.zzn.com) on Tuesday March 21, @03:12PM EST (#4) (User Info) http://www.bloomington.in.us/~kentb |
|
Is it possible that Qt can use this technology to create some underwear using linux flamebuffers to increase the safety of firemen everywhere? Thanks Kent |
|
X (Score:1, Insightful) by Signal 11 (signal11@mediaone.net?Subject=Slashdot comment) on Tuesday March 21, @03:13PM EST (#6) (User Info) http://www.malign.net/~bojay/ |
|
You know, with so many developers trying to bypass the X APIs and write directly to the screen, one would think that X is out of date.
There seems to be a big push to get the X protocol away from network protocols and into direct API calls. Any thoughts (maybe we could interview an X developer next week?) people? -o Question authority! Yeah, says who? o- |
|
Re:X (Score:2, Funny) by redhog (redhogNOSPAM@lysator.liu.se) on Tuesday March 21, @03:17PM EST (#10) (User Info) http://mini.dhs.org |
|
I think we should bypass all of the OS and program the hardware directly, as done in windows to get better single user acceleration. --The knowledge that you are an idiot, is what distinguishes you from one. The above text is covered by the GNU General Public License. |
|
Re:X (Score:1) by not Bruce Perens on Tuesday March 21, @03:26PM EST (#20) (User Info) |
|
>--The knowledge that you are an idiot, is what >distinguishes you from one. After a comment like that, I know it; do you? |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @09:18PM EST (#196) |
|
it was his sig. might I suggest a sig for you: "the difference between me and a fuckwit is that most fuckwits have a sense of humor." |
|
Re:X (Score:1) by penguinboy (comphelper AT yahoo DOT com) on Tuesday March 21, @03:53PM EST (#50) (User Info) http://home.earthlink.net/~rmedico/ |
|
You are joking, right? This is what made NT4 so ridiculously unstable (3.51 wasn't too bad when the graphics stuff wasn't in the kernel) |
|
Re:X (Score:1) by Grimlord on Tuesday March 21, @05:13PM EST (#99) (User Info) |
|
you idiot we are not talking about ms doing it. The code is only as stable as the guy that wrote it. |
|
Re:X (Score:1) by penguinboy (comphelper AT yahoo DOT com) on Friday March 24, @08:26PM EST (#262) (User Info) http://home.earthlink.net/~rmedico/ |
|
It'ss a bad idea none the less. Although it doesn't guarantee it, more low-level stuff certainly increases the chances for problems. |
|
Yes (Score:2) by redhog (redhogNOSPAM@lysator.liu.se) on Tuesday March 21, @06:22PM EST (#126) (User Info) http://mini.dhs.org |
|
Of course I was joking! I thought that was obvious! Perheaps I should have put a ;) there to guide you... --The knowledge that you are an idiot, is what distinguishes you from one. The above text is covered by the GNU General Public License. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @04:20PM EST (#61) |
|
I think we should open the windows and throw you out (to get better single user acceleration). |
|
Re:X (Score:2, Interesting) by ceswiedler on Tuesday March 21, @03:23PM EST (#16) (User Info) |
|
The design of the X Server sticks to the original multiuser-server philosophy that everything runs on the server, and the client is practically nonexistent. At the time "GUI" (tm) came out, people were used to telnetting and running processes on central boxen. The X Server design maintained the status quo. But jesus, are we still in the days of VAX? Big servers are great and it's useful for people to share them, but everyone ALSO has a decent desktop box. Why on earth do we need our computer to talk to itself through networking calls just to render a window? If we're going to keep up the desktop-user push, we have to make the windowing environment better. Does anyone have any figures for how much slower the X server system is than a direct windowing API? If it's a signifigant speed issue (and I imagine it is), we're going to have to do something about it. How difficult would it be to abstract communication layer of the X server so that if it were running locally, it used direct calls, and if remotely, then by networking like it does now? Best of Both Worlds. HELP STOP PLATE TECTONICS |
|
Re:X (Score:1) by not Bruce Perens on Tuesday March 21, @03:32PM EST (#26) (User Info) |
|
You're living in the days of VAX as well, apparently... Believe it or not, someone (actually, quite a lot of people) already noticed that little problem! And that's why modern X implementations (go XFree86!) are hacked to take as much advantage of locality as possible without breaking the abstraction too badly. Even if there were a significant hit, though, abstraction would be sufficient generalization. |
|
Been done (Score:2, Interesting) by Sloppy (sloppy@spam^H^H^H^Hrt66.com) on Tuesday March 21, @03:35PM EST (#31) (User Info) |
|
How difficult would it be to abstract communication layer of the X server so that if it were running locally, it used direct calls, and if remotely, then by networking like it does now? Isn't that pretty much what AmiWin does, when you link it with the proper libraries?
Why on earth do we need our computer to talk to itself through networking calls just to render a window? Because it's cool, and occasionally useful. Ever taken a look at the size of the market for Windoze products like Symantic PCAnyWhere or Citrix WinFrame? If your windowing system doesn't have that capability built-in, then someone's just going to have to tack it on later, anyway. It actually makes sense for X to have this feature. It's a good feature. --- Have a Sloppy night! |
|
Re:Been done (Score:1) by ceswiedler on Tuesday March 21, @04:12PM EST (#58) (User Info) |
|
I didn't say that we should remove the capability for X clients to run from X servers on other hosts, I said that we should also include the ability to run completely on one host without wasting any time with talking back and forth to itself. I don't have any complaints, personally, about how fast my Xfree86 system runs, but then I don't stress it very much. This is one of those "it shouldn't work that way!" sort of optimization-thoughts, and I'm glad to know people are already working on it. HELP STOP PLATE TECTONICS |
|
Re:Been done (Score:0) by Anonymous Coward on Tuesday March 21, @06:35PM EST (#136) |
|
Argh! haven't any of you heard of the shared memory stuff in X? What on earth do you think MIT-SHM stands for? |
|
Re:Been done (Score:2) by Ralph Wiggam (barry@no-meat-in-a-can.summex.com) on Tuesday March 21, @04:36PM EST (#73) (User Info) http://www.redmeat.com |
|
This week the company I work for is cutting a 6 figure check to Citrix for the privledge of a capability that X has for free. Nice. -B 10 PRINT "THIS IS MY SIG" 20 GOTO 10 |
|
Re:Been done (Score:0) by Anonymous Coward on Wednesday March 22, @11:00AM EST (#255) |
|
X has the capability to export Win32 applications for free? Cool! I bet everybody will be excited to hear the news! |
|
Re:Been done (Score:2) by Samrobb on Tuesday March 21, @05:24PM EST (#103) (User Info) http://www.pghgeeks.org |
Ever taken a look at the size of the market for Windoze products like Symantic PCAnyWhere or Citrix WinFrame? If your windowing system doesn't have that capability built-in, then someone's just going to have to tack it on later, anyway. I think the point is that X was designed to operate over a network, period; in hindsight, it probably would have been better to define a local display protocol that could be modified to work in a more peer-to-peer or client-server fashion as the need for that arose. There's nothing particularly wrong with "tacking on" functionality later, as long as the original specification was designed with that sort extensibility in mind. If that had been the case, then this discussion wouldn't be happening, because I could run X the way I want to, and you could run it the way you wanted, and we'd both be happy. As it stands right now, you get what you want, and when I try and get what I want, I get a shrug and a "Live with it - it's a good feature" reply. |
|
reminds me of C++ (Score:1) by kaisyain on Thursday March 23, @08:26AM EST (#261) (User Info) |
|
Wasn't that designed so you were only penalized for the features you actually used? I wonder how many people who are saying "live with it - it's a good feature most of the time" praise that effort in C++ and fight tooth and claw to the bitter end against mandatory inclusion of things like garbage collection, of which pretty much the same thing can be said: "live with it - it's a good feature most of the time". |
|
X !=> networking (Score:2, Informative) by john@iastate.edu on Tuesday March 21, @04:14PM EST (#59) (User Info) |
|
X servers can communicate with clients over a variety of communications channels including network streams, shared memory, and unix domain sockets, etc...
|
|
Re:X !=> networking (Score:0) by Anonymous Coward on Tuesday March 21, @06:23PM EST (#128) |
|
Thank you for clearing that up, it should be apparent to everyone now that the reason X is so slow is the prevalence and perdurability of cosmic radiation. Networking, sockets, and the like have nothing to do with it. |
|
Re:X !=> networking (Score:0) by Anonymous Coward on Tuesday March 21, @09:20PM EST (#197) |
|
some cards have excellent support for their acceleration in Xfree. others do not. might I suggest a reasonably modern Matrox card. I've heard good things about voodoo3's X server also. |
|
Re:X !=> networking (Score:0) by Anonymous Coward on Wednesday March 22, @09:54AM EST (#251) |
|
I have a g400 card, and i am horrified to see that win2k is MUCH faster than X in linux, running mozilla in win2k is a totaly different application than running it in linux. The same goes for netscape and wordperfect. But sure, the matrox cards are among the faster cards with xfree86. It would be fun to know how much of the lack of speed in X depends on its design, and how much is just because of unomptimized X server |
|
Isn't this what Direct Rendering does? (Score:1) by gharikumar (gharikumar@my-dejanews.com) on Tuesday March 21, @04:49PM EST (#83) (User Info) |
|
I thought this was exactly what Direct Rendering (included in Xfree4.0) does. Hari. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @06:35PM EST (#135) |
|
I don't know about you, but its hella great to have an X server on my NT workstation at work and administer my beefy DEC box in the basement. I feel damn sorry for all the NT guys that have to stand directly in front of their servers for hours on end, messing up their necks in the process. X might add overhead, but its damn nice to have that capability. |
|
Re:X (Score:1) by Anonymous._.Coward (print reverse split(/ */,"moc.buprenroc\@demmahom") on Wednesday March 22, @05:57AM EST (#238) (User Info) |
|
Huh? But NT workstations and servers can be remote configured.
|
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @08:04PM EST (#161) |
|
the sad thing is, its probably a lot more efficient to push bitmaps around the network than download, trees, lists, images, button text, grids etc. In these days of server generated forms, X rules. |
|
Re:X (Score:1) by Rakarra (rakNarraO@SpacbPellA.Mnet) on Tuesday March 21, @08:50PM EST (#184) (User Info) |
But jesus, are we still in the days of VAX? Big servers are great and it's useful for people to share them, but everyone ALSO has a decent desktop box. Again, the problem is that you're assuming everyone wants to run the X client applications FROM their desktop. To demand that would be pretty limiting.
Why on earth do we need our computer to talk to itself through networking calls just to render a window? Why? Portability for one. Second, why not? Since on the local machine you don't have to use actual TCP ports to get it done, I've seen XFree86 use domain sockets instead. Is there really a huge drawback other than a "networking! *shudder*" response? You don't have to limit the server to only one method of contact.
|
|
Re:X (Score:1) by twixel on Wednesday March 22, @06:13AM EST (#239) (User Info) |
But jesus, are we still in the days of VAX? Big servers are great and it's useful for people to share them, but everyone ALSO has a decent desktop box.Why on earth do we need our computer to talk to itself through networking calls just to render a window?Rest assured, it doesn't use networking calls if it is not necessary. It uses IPC (unix domain sockets ,shared memory) where possible. Does anyone have any figures for how much slower the X server system is than a direct windowing API? If it's a signifigant speed issue (and I imagine it is), we're going to have to do something about it.And how are you going to measure that? How are you going to factor out driver optimisations? BTW, what you call a direct windowing API means moving the graphics subsystem into the kernel. It would save context switches. Any other design where a separate process handles the windowing and the display, has been done: it's called X. How difficult would it be to abstract communication layer of the X server so that if it were running locally, it used direct calls, and if remotely, then by networking like it does now? Best of Both Worlds.Depends on what you mean with "direct calls". A "direct call" into a shared library to draw a window can be handled in two ways:
So there you have it: A = WinXX and B=XWindow. Take your pick. I guess moving the display subsystem into the kernel won't be very popular. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @03:24PM EST (#18) |
|
> There seems to be a big push to get the X > protocol away from network protocols and into > direct API calls. Any thoughts (maybe we could > interview an X developer next week?) people? Have a look at NanoGUI (a mini X server) or it's twin MicroWindows (a mini Win32 API). http://microwindows.censoft.com/ There was talk about porting Gtk+ to it, but I have no information as to whether anyone is actually working on it (Anyone know?). There's no reason why Qt couldn't also be ported. IMO, TrollTech would be foolish not to go this route. X is pretty well thought out. It's been ported to the Itsy. There's little reason to bypass it's API. You simply need a leaner server with fewer features for embedded systems. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @05:31PM EST (#105) |
|
moderate one this up |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @08:31PM EST (#175) |
|
My name Shane Nay, (sorry too lazy to log in) and Greg Haerr of Microwindows and I are working on porting FLTK right now, it's almost done. The next target in my scopes is GTK/GLIB. I already downloaded the Win32 based source, and setup the headers. Haven't made a function list yet, but it's "in process". I'd say we're a couple months away from a usable GTK on microwindows. You can take a look at some screen shots of FLTK on microwindows at ftp://esdev.net/pub/fltk/scrshots/ There is a history type section, and some new stuff in fontpass2 directory. |
|
Re:X (Score:3, Interesting) by bluGill (hank@black-hole.com) on Tuesday March 21, @03:49PM EST (#47) (User Info) http://www.black-hole.com/users/henrymiller/ |
|
I find that the majority of my time in X is spent with something onscreen not running on the local machine. Even if we call the programs running on the same machine as my window manager this is true. Maybe your desktop machine is fast enough, but not mine. I used to have an ultra sparc on my desktop. I hated it, genuine noisy fan, poor keyboard (You think Sun would know the controll key belongs next to the A. xmodmap is for more difficult tasks than that) And when I kicked the power cord all my compiles stoped. Now the server is in a back room, I have a NCD (A dumb terminal that can run X) on my desk. As a devolper I find that my programs have to run on a machine in the lab. Pop an X window from the lab machine to my desktop and its like working in the lab. THen I can go home and pop an X window from the lab to my home FreeBSD machine. (I don't normally work from home, but if I can check my compile over night and fix the one typo after supper I save time at work the next day)
I used to have a sun3 in one room, and my main machine in anouther. In theory I could run programs on the sun3, but since the main machine is 400 mhz, and the sun is 16 (20? doesn't matter as m68k and x86 of different generations don't compare well by looking at mhz, but you can get the idea) who wants to? X still has life. Xfree86 is very fast on a local machine, and works just fine on a remote one. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @04:26PM EST (#69) |
|
I find that the majority of my time in X is spent with something onscreen not running on the local machine. Then you're in the wrong cubicle. Contact your system administrator to correct your position in the seating chart. You guys rail on about MS Wurd having bloated rarely used features, but you refuse to look at your own case with the same critical eye. |
|
Re:X (Score:1) by mulderlr (mulderlr @ netscape . net) on Tuesday March 21, @04:44PM EST (#77) (User Info) |
|
the problem isn't the overbloat by itself in any application that is the problem. The problem is the market share dominance that forces people to use something which is overbloated like in the case of Microsoft "Wurd"... Last time I looked nobody told you that you have to use X (and if they did you can modify the source to streamline it down to what you want), but my company sure as shit rails on me about having to use Microsoft "productivity" apps (if that isn't an oxymoron in and of itself). |
|
Re:X (Score:1) by 51M02 on Tuesday March 21, @05:35PM EST (#107) (User Info) |
|
Actually this is a very often used feature. The ability to use a GUI interface using two computers instead of one and even to share this environnements in network is wonderful. Also this method does not require much more memory or speed than any other concept In this case this new Qt version is for device that does not offer a lot of memory or CPU speed like the kind of computers we were using 4 years earlier or for Palm like devices (Internet Appliance) where every kb of memory footprint is important.
In this kind of new device it's not very useful to be able to log on it from/to another computer to use a GUI. It just need to be able to access Yahoo(tm) and emails. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @06:17PM EST (#123) |
|
Popular? Yes--among developers. You need to remember your needs and conveniences are radically different from the (millions) people who use your work. If it were up to developers, monitors would probably be twice as tall as wide. 99% of computer users really don't care about networked displays...(trying not to say something nasty here)...infact they probably would want that port 6000 firewalled off. Who is being forced to use the boated--yes BLOATED, cranky, creaky narcotecture of grampa X? Well everyone who wwants to use Unix or Linux is pretty well forced to live with what's convenient but crappy for people who's idea of exciting desktop applications are transparent virtual terminals. A more appropriate question (or at least a more Utilitarian one) would be: how many people are turned off of linux and unix and forced to live with MacroShaft because X doesn't do the basic job of displaying to a monitor in acceptable fashion? (X4.0 just barely gets there now, and still, if anything is in motion--it's back to paleolithic era performance) And convinces them that everything else about the "alternative platform" must also suck?
Why is it that when anyone says, "wouldn't it be awesome to have desktop speed and capabilities like well other desktops--by cutting out the deadwood of X" a thousand crustiphores poke their heads out and screech NEVER! YOU'll never take my network display capability away--as if the first logically necessitates the second. Non Sequiturs are the infallible sign of neurossification. Let's not condemn ourselves mutually to that evil end. |
|
This X server has been running for 3 months ... (Score:0) by Anonymous Coward on Tuesday March 21, @09:15PM EST (#194) |
|
and there's a lot of apps open (a dozen actually - including Netscape, Emacs, applix, staroffice). It currently takes up 30 megs of RAM but about half of that is swapped out (I only have 64 megs). The main source of RAM usage is the Netscape process. How is this "bloat"? MS-Windows is 10 years old. X is about 17 at the most. The reason X is still around is that it works. |
|
Re:This X server has been running for 3 months ... (Score:0) by Anonymous Coward on Tuesday March 21, @11:31PM EST (#222) |
|
It's running with a feature(s) most people don't need which noticeably hampers its basic performance with one or more windows open--and the feature can't be turned off. Bloated spec, sluggish performance.
Why do you think people carp and bitch about the performance of XFree86? Because they see that it's fast, sleek and elegant ?? and seeing that makes them envious? |
|
Re:This X server has been running for 3 months ... (Score:0) by Anonymous Coward on Wednesday March 22, @03:22AM EST (#229) |
|
This notion that the network transparency of X hampers it's functionality is urban legend. People carp and bitch about the performance of Xfree because it's a small group of volunteers trying to replicate the efforts of an entire industry of hardware vendors, oftentimes working without proper information. Furthermore, one implementation of X is not enough base a condemnation of X servers in general. Nevermind that in my own experience I have yet to suffer from this 'slow X' problem. Infact, I find myself running beefier NT machines during the day and being rather glad that I am 'subjecte' to 'sluggish X servers' when I compute at home. WinFoo may push pixels better, but Unix handles concurrence much better. In that end, that gives Unix or Linux the edge. |
|
Fast sleek and elegant? (Score:2, Insightful) by Arker on Wednesday March 22, @05:09AM EST (#234) (User Info) |
|
X isn't designed to be fast sleek or elegant. It's designed to be stable flexible and powerful. It is that. How much of a performance hit the flexibility costs seems to be a subject of great debate. Not being an X hacker all I can offer is subjective, anecdotal evidence - on my box, certain things are noticeably slower, but other things are noticeably faster, I don't see any significant overall speed advantage to win32 over X on my hardware, just some fairly minor trade-offs going both ways. Of course X itself is flexible enough to adapt to a lot of situations - if I stuck a larger window manager on X I could make it slower than win32, and if I stuck a smaller one on I could speed it up a bit too. There are downsides to flexibility, to be sure, but there are advantages too. If you really don't like X, why not make something you like better? X isn't a part of linux, remember that. It's one of many open source programs that you can run if you choose. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @09:17PM EST (#195) |
|
Uhmm the two aren't mutually exclusive: you could run your "Qt in the framebuffer" thing and just run an X server that displays in the framebuffer too to run X apps.
There already are a few framebuffer X servers out there. |
|
There's nothing wrong with X11. (Score:2) by jetson123 (br_9801 at hotmail dot com) on Tuesday March 21, @04:39PM EST (#75) (User Info) |
|
X11 is still a great protocol for network transparent windowing: it's efficient, conceptually simple, and mature. In those areas where it really matters (bulk image and geometry transfer, 3D graphics) X11 already gives applications memory mapped access. X11 does lack a few features, like antialiased drawing and fonts. Those can be added easily with X11's well-defined and widely used extension mechanism, and without breaking backwards compatibility. If you type "xdpyinfo", you'll see that you are already running a dozen or so extensions.
Using libraries that access the frame buffer directly does make sense for embedded systems, but for general usage, they would represent a big step backwards. |
|
~/There's something wrong with make world today/~ (Score:5, Interesting) by MenTaLguY (mental@rydia.net.nospam) on Tuesday March 21, @06:17PM EST (#122) (User Info) http://lunar8.rydia.net/mental |
X11 is still a great protocol for network transparent windowing Really? it's efficient Only if you consider marshalling/unmarshalling individual drawing primitives across some sort of IPC (network or local) efficient. No, I'm not advocating direct application hardware access. Think outside the box, and maybe go back and look at how systems like NeWS, Display Postscript and Berlin are designed. conceptually simple No, not really. Try writing a window manager sometime. The original idea was (is) pretty simple, but once you start adding the various standard extensions that accumulated over the years, if you're writing something major, it's a real mind-bending mess. You're fortunate nowadays that GTK+ and Qt hide a lot of the evil from you. mature No argument there; X is tried, true, and it works. In those areas where it really matters (bulk image and geometry transfer, 3D graphics) X11 already gives applications memory mapped access. That doesn't help you if you're remote ... and yes those are nice sometimes if you're remote. X11 does lack a few features, like antialiased drawing and fonts. Those can be added easily with X11's well-defined and widely used extension mechanism, and without breaking backwards compatibility. Ever wonder why that hasn't been done yet? It's because most people who thought about it decided it wasn't worth the trouble: existing applications might run, but they wouldn't get the new functionality (i.e. antialiased characters). They would still still require a rewrite (yes, a rewrite, not just recompiling). The APIs and necessary backend code are just necessarily that different, because the original X ones were designed so badly. [To be fair, the situation is a little better now, just because modern toolkits abstract the stuff enough that you could get by with only minor changes to the library APIs ... in most cases you'd just have to recompile the apps that didn't use the changed APIs, and only make minor changes to the ones that did, or that bypassed the library in some way] If the antialiased font server was backwards compatible, it would only be because it kept the entire old (now redundant) architecture and API, in addition to implementing the new one. The necessity of taking this approach to extend other aspects of X is one of the contributing factors to its bloat over the years.
Agreed, for the most part. However, arbitrated (i.e. not totally unsupervised) hardware access is still good for certain classes of specialized applications, and of course games. That's the need that ultimately spawned fbcon and KGI (the GGI kernel layer). Something to ponder in parting... if someone wants to experiment with a windowing system that is not X, they either need to rewrite all the drivers themselves, run under X (...then what's the point?) or they need to have some kind of non-X driver infrastructure availible. i.e. has the reliance on X to drive graphics hardware directly strangled the development of alternatives on Unix? |
|
Re:~/There's something wrong with make world today (Score:1) by spitzak (spitzak at d two dot com) on Tuesday March 21, @07:20PM EST (#148) (User Info) http://www.cinenet.net/users/spitzak |
|
has the reliance on X to drive graphics hardware directly strangled the development of alternatives on Unix? YES! All the stuff going into XFree86 has killed development of fb or gdi or other simpler protocols. It does not matter how well they are designed, if you want your fancy card to run at full resolution, you have to use X, because all the hardware control is hidden in the X server.
One plausible solution: could new replacements interface with the binary plug-in interface that the new XFree86 4.0 has? Then they could get all the hardware. I'm sure the interface will be painful because it will make X assumptions, but not impossible to program for. Once an acceptable replacement for X has been made, a new low-level interface can be designed, and instructions on how to change the drivers. |
|
Re:~/There's something wrong with make world today (Score:2) by jetson123 (br_9801 at hotmail dot com) on Tuesday March 21, @08:42PM EST (#181) (User Info) |
|
DPS and NeWS never worked as well or as efficiently as X11. In particular, for what really mattered--getting lots of data from the client to the display server--they are a lot worse than X11. X11 gives you memory mapped bulk data transfer on the local machine, and efficiently packed bulk data transfer to remote machines. That's really the best you can hope for.
As for writing window managers, if you think writing them under X11 is hard, try doing it sometimes under Windows or MacOS. X11 at least delineates and defines responsibilities and puts the window manager in control. The fact that the protocol is complex is a result of the fact that there are a lot of complex interactions that can happen between different applications from different machines. |
|
Thank you! (Score:1) by uradu (spamspamspam.uradu@cdc.net) on Tuesday March 21, @09:49PM EST (#210) (User Info) |
|
The fact that marshalling has barely come up in the whole discussion about X shows that most people are talking out of a hole in their head, and it's not the mouth! You simply cannot say high perfomance and RPC in the same breath, period. X is simply a specialized RPC mechanism, including all the marshalling/demarshalling of parameters that goes with it. As soon as you want to draw a line, X packages up the parameters into a packet, zips it across the network to the server, which then extracts the line parameters, figures out that you want a line, and then does the drawing. The amount of overhead involved is mind boggling. The same basic process is going on even if the server is local, except that you save the network transfer. If X were really smart, it could first check if the server is local, and if so, dispense with the entire marshalling/demarshalling process and resolve the drawing to a simple local API call. Even so, the extra steps involved in this checking would be a significant slowdown. Consider that in comparison the original Windows drawing mechanism is much more straighforward. Drawing requests always resolve to API calls which then delegate drawing to the driver. Much more straightforward than X. Except that even that was too slow for high performance games, which led to DirectX. And even DirectX isn't the fastest thing around, according to some die-hard gamers. And yet compared to X it's orders of magnitude faster. It would be intersting to see a breakdown of the number of machine instructions required for some given drawing primitives, first under plain X, then using memory mapped X, the plain Windows, then DirectX (maybe also NT 3.5, 4.0 and 5.0, as they've moved more of the display stuff into the kernel). It's amusing to see hardcore Xers always defend X mainly by virtue of its remote display capabilities. And they're vocal enough that it would seem that they're the majority. But if Linux should really take off and become a popular desktop OS, remote display will hardly be used at all, by percentage of users. The great unwashed masses had a hard enough time understanding the concept of a Web page, remote data displayed locally. Getting them used to the notion of a remote program displayed locally will be a shift I wouldn't want to walk them through. Besides, I remotely administer NT machines daily quite nicely, courtesy of a little utility called VNC. Brute force maybe, but who cares? It works well enough, doesn't bring the network to its knees (something that couldn't be said about X in the 80s), and is completely free. Uwe Wolfgang Radu Chattanooga, TN |
|
Re:Thank you! (Score:0) by Anonymous Coward on Tuesday March 21, @10:41PM EST (#218) |
|
Damn you people act as if there is no alternative, and seem completely naive to DRI, and GLX. I mean seriously people, I get 40fps at 800x600 in Quake III with my Matrox G400... seriously fellows, learn before you blabber. The G400 is NOT a good 3d card either... in fact it's 3d engine is supposed to suck hardcore. Not only that, but there are alternatives. Microwindows is one, but they don't have as many developers as they need. So instead you people bitch about there not being an alternative when there is an alternative that needs more programmers. Get off your ass and do something about it. X isn't going to kill Linux... lazy people that just sit on the fence whining will kill linux. Get off your ass and help Microwindows, or GLX. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @04:46PM EST (#79) |
|
I recently had the idea of some kind of 'remote framebuffer', when the SUN people showed off with their 'Ray 1' Terminal, which basically implements a really dumb protocol to access a graphical desktop. What at first sound redundant (because we already have X) makes sense when you see how it can handle compression, encryption and authentication/session management, which can all be some kind of problem in X. I guess we could implement something like that using a system like the network block device with a kernel and a user space part. Apart from running XF86_FBdev, this could then also be used to provide a rather lean application server _and_ thin clients as terminals using QT for the framebuffer. |
|
Re:X (Score:2) by MenTaLguY (mental@rydia.net.nospam) on Tuesday March 21, @06:22PM EST (#125) (User Info) http://lunar8.rydia.net/mental |
compression, encryption and authentication/session management What about tunneling X over ssh? |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @06:41PM EST (#138) |
|
While using dxpc at the same time. |
|
Re:X (Score:0) by Anonymous Coward on Tuesday March 21, @06:38PM EST (#137) |
|
X can tunnel over ssh (in fact, ssh usually sets this up automatically for you), providing compression, encryption and authentication. Session management is normally handled by xsm, which has been around for years. |
|
Re:X (Score:2) by jetson123 (br_9801 at hotmail dot com) on Tuesday March 21, @08:55PM EST (#186) (User Info) |
|
It's been done, and it's widely used: VNC. It's free, it's very useful, and there are some vendors now offering thin clients based on it. |
|
Re:X (Score:1) by Wesley Felter (wesf@cs.utexas.edu) on Tuesday March 21, @09:31PM EST (#205) (User Info) http://www.cs.utexas.edu/users/wesf/ |
|
There was a paper (at SOSP, I think) about SLIM, which is the protocol that the Sun Ray uses. In their benchmarks, SLIM beats VNC by a wide margin. |
|
Re:X (Score:0) by Anonymous Coward on Wednesday March 22, @06:45AM EST (#241) |
|
There are lots of protocols that are more efficient than VNC. Let's hope Sun makes a open source clients and servers available like VNC. Until then, VNC is pretty much the only game in town for most people. |
|
S (Score:1) by levl289 (levl289@ check out www.sonous.com) on Tuesday March 21, @04:47PM EST (#81) (User Info) http://www.sonous.com |
|
You know, with so many trolls bypassing /. moderators by moderatring their own posts, trying to write directly to the top of the screen, one would think that /. moderation is out of date. There seems to be a big push to get the /. moderation protocol away from trolls and into the hands of insightful posters. Any thoughts (maybe we could have an insightful post next week?) people? [sorry, couldn't resist] Q: What do you think about American Culture? A: I think it's a good idea.
(adapted from Ghandi) |
|
Whoa! Looks SOMEBODY forgot our slogan 'round here (Score:1, Insightful) by Anonymous Coward on Tuesday March 21, @06:33PM EST (#133) |
|
You know it--you love it--you can repeat it after 12 beers and a bong hit standing on your head ('cause you've heard it all your life...) Xwindows today, Xwindows tomorrow, Xwindows forever! After all, if it was good enough for Dad why change ?!?
seriously people, when do you think maybe it might be time to move on? Are there any plans for that day or do we just wing it here? |
|
Re:Whoa! Looks SOMEBODY forgot our slogan 'round h (Score:2) by jetson123 (br_9801 at hotmail dot com) on Tuesday March 21, @09:23PM EST (#199) (User Info) |
|
Yes, I completely agree that there isn't enough innovation in GUIs on Linux. And I completely agree that it is time to move on. But X11/Xlib isn't the culprit. X11 clearly is not the best thing since sliced bread. It's an old design, a bit clunky in places, and lacks antialiasing for low resolution screens. But the would-be X11 competitors for desktop applications don't aim much higher. And the clunkiness of the low-level X11 API is of little concern to programmers, since it's mostly hidden by the various toolkits. The really important areas where Linux GUIs ought to innovate (but don't) are at the toolkit level. Well executed as they are, Qt and GTK+ are still MFC/toolbox-style, event driven, decades old technology. There are a lot more interesting and innovative ways of writing GUIs out there. Whether it's X11, GDI, Java, Berlin, SVGAlib, GGI, or anything else under the covers doesn't matter much.
While for embedded systems, getting rid of X11 makes some sense because of space constraints, trying to replace X11 on the desktop to me is just barking up the wrong tree. I'd much rather see some of that effort go into something like a desktop based on scalable UIs, notebook interfaces, transcript-based interfaces, or any of a large number of other interesting, innovative approaches to GUIs. |
|
Re:Whoa! Looks SOMEBODY forgot our slogan 'round h (Score:1) by Arker on Wednesday March 22, @05:12AM EST (#235) (User Info) |
|
Got an idea? Develop it. If people find it useful it will grow. This ain't MS, no one decides where "we" are going to go, we each do that ourselves. |
|
Re:X (Score:1, Insightful) by spitzak (spitzak at d two dot com) on Tuesday March 21, @07:43PM EST (#152) (User Info) http://www.cinenet.net/users/spitzak |
|
I seem to be in the minority here, but I don't think the "network protocol" is the problem. The problem is in the horrid design of the Xlib calls themselves! Implementing Xlib as local calls will just remove the only advantage of X and would be totally wrong. There is nothing wrong with buffered network protocols. In fact they use less context switches than api's. If this were not true, why do we have interfaces that write more than one character (or one bit) to a device? Isn't the overhead of copying those characters to a buffer from where they originally were inefficient? NO! Another way to look at it: if Xlib puts 10,000 requests in a buffer and sends it, we get TWO context switches (one to the kernel, one to the server). Win32 gets 10,000 context switches (each one to the kernel for each call). And X, despite being 5000 times more efficient in context switches, does not have the risks of putting complex code in the kernel! (PS: yea I know Win32 ain't that bad, but their solution is exactly equivalent to buffering multiple requests!) What does lose in network protocols is synchronous communication. When Xlib has to wait for an answer from the server, we get at least 4 context switches, plus the network overhead, and we lose. But we don't need so much synchronous communication! The solution is to chuck out most of the Xlib design except for the fact that it is a network protocol. A program that displays a non-interactive display should be writable with a *single* "write" to the server (plus it may have to wait for redraw events and send that write again). Get rid of colormaps! Trash the horrid font system and put in something so that if I ask for "Times" and 12 points, I get something (even if it is not Times at 12 points, if it has letters in it it would be an improvement over Xlib!). Either get rid of window managers, or make it sequential so I can create a window and send drawing to it in one block, without waiting for a stupid expose event to indicate syncrhonization with the window manager. Get rid of atoms, or make it so I can define thousands of atoms in a single round trip.
While we are at it, put some non-primitive graphics in. It is inexcusable that we don't have anti-aliased fonts, or anti-aliased polygons (even though Win32 does not have these), or a call that draws a color image without me having to figure out how to dither it to the hardware! |
|
Network transparency... (Score:1) by Rakarra (rakNarraO@SpacbPellA.Mnet) on Tuesday March 21, @08:44PM EST (#182) (User Info) |
|
... along with OS transparency (display one OS's graphical applications on the screen driven by another OS) are X's greatest strengths. There are many people for whom direct/hardware calls would be useless. My setup: Two computers, one running Windows, the other running Linux. Linux is my "big server," it's where most of my files are stored (served by samba) and where I get much of my "real work" done. The monitor is connected to the Windows machine, and when Exceed runs in full-screen mode, there's pretty much no difference between that and running X from the Linux console. That kind of flexibily is what I love about X, and removing or dumbing down the network aspects would just kill the whole point of it. It'd be ok for running the few games available, but you'd be sacrificing much more to gain that. Assuming "get the X protocol away from network protocols" is even necessary for that, a statement I wouldn't agree with.
|
|
eliminating X from embedded systems bad idea (Score:1) by CurtisLeeFulton (echo O0otisf@bl0o.Ox|sed y/Oo0/cru/) on Tuesday March 21, @11:10PM EST (#221) (User Info) http://blur.cx |
|
Taking the asumption that many apps will fade from the desktop and reincarnate themselves as single devices, keeping X from these products would seriously limit their functionality. A consumer's office suite/browser module and gaming/multimedia module should be able to output to a wide variety of display servers and be controled by a wide variety of input servers. Only X makes this possible. The analog RGB or VGA jack on your computer or gaming machine is going to be replaced by a jack for IEEE1394 or giga ethernet. Both are fast enough even for DV, which is 960x540 pixels at 30fps.
Because X has been around for so long makes X look old fashioned, but I think it's the future. |
|
Project EverBlue (Score:2) by Pseudonymus Bosch on Wednesday March 22, @05:51AM EST (#237) (User Info) http://www.dmoz.org/ |
|
The project EverBlue is a port in progress of Xlib to OS/2 Presentation Manager, so that you can compile X applications to run in a OS/2 framebuffer, using your normal OS/2 drivers and integrated with the rest of your OS/2 apps. -- "Free" as in "free 'undred quid". |
|
Now how about GTK+? (Score:1, Interesting) by NRLax27 on Tuesday March 21, @03:18PM EST (#12) (User Info) |
|
I think this is a great idea, does anybody know if it would be possible to re-work the GTK+ backend to also let it use the Linux Framebuffer device without X? I personally prefer programming in GTK+ over QT, and would be interested in any developments along this line.
./configure |
|
Re:Now how about GTK+? (Score:0) by Anonymous Coward on Tuesday March 21, @03:38PM EST (#37) |
|
No. Unfortunately that would be absolutely impossible. The reason is that GTK+ is lacking the real-time direct API that Qt has. That and I think the newest version of Qt includes a gigabit flux capacitor. Seriously though, what are you smoking? |
|
Re:Now how about GTK+? (Score:0) by Anonymous Coward on Tuesday March 21, @03:51PM EST (#48) |
|
Considering that a Win32 port of GTK+ exists, it certainly sounds possible: all you'd really need to replace are the Xlib calls. |
|
Re:Now how about GTK+? (Score:1) by PiMan (piman.spambegone@sacredchao.net) on Tuesday March 21, @05:22PM EST (#101) (User Info) http://www.sacredchao.net/piman |
|
Note: I'm not a GTK+ hacker My understanding is that GTK sits above the Gdk layer, which does all the actual work, and porting Gdk means (pretty much) a port of GTK. This is why the Win32 port was (relatively) easy, and why you have both Gdk/X11 and Gdk/Imlib to choose from in X. So a port of Gdk to the framebuffer would do it. Windows 2000: Designed for the Internet. The Internet: Designed for UNIX. |
|
A way for QT to take over? (Score:3, Interesting) by molog on Tuesday March 21, @03:19PM EST (#14) (User Info) |
|
With QT now being a good solution for embeded Linux, it would make good sense to use QT for application portability. I like QT. It is object oriented and easy to program with. On the other hand, I'm not too keen on the way that it is marketed. With QT you can use it in open source software with no charge. If you are making propriatery software there is a big charge for it(well some people could compare it to other componets that cost more but I'm speaking from my point of view). I know it would be a nice world if everyone would write open source apps, but a lot of cool apps that would get written for Linux would only be brought over if there was a good open frame work. I think that the best way to go as far as development libraries go is to sell a development environment. Trolltech sells the library only AFAIK. It is for this reason that I support and use the GTK becuase it feels more open to me that everyone can use it. I'm sure I'll get flamed but I think that a development library should not have a cost becuase you are trying to make a standard. Just an opinion. Molog
So Linus, what are we doing tonight? |
|
Re:A way for QT to take over? (Score:1) by Taxing Bastard (lhilATihugDOTcoDOTnz) on Tuesday March 21, @03:33PM EST (#27) (User Info) http://www.memepool.com |
|
It is a bit of a pain not being able to develop any proprietary stuff without paying heaps. You have to think seriously about learning Qt, if you can only use it for open stuff, when at work, you are told to develop closed source. It makes you think - is this the best thing for me to spend time on learning? Do I really want to learn another way of doing things? And you are right that there would probably be more cool apps come across. We cannot expect everything to be open source, if we want to achieve "World domination - and fast" "Oh, I got me a helmet - I got a beauty!" Jack Nicholson, Easy Rider |
|
Re:A way for QT to take over? (Score:1) by hypergeek (cat > /dev/null) on Tuesday March 21, @06:34PM EST (#134) (User Info) |
Do I really want to learn another way of doing things? Even if you only plan on solving a particular problem a certain way, it almost always pays to know "another way of doing things". Otherwise, you could go through life without realizing that you've been tackling a given problem in a suboptimal manner. Suppose one day you decided to write your own library similar to GTK or Qt? I don't know about you, but I would certainly be interested in knowing the different ways that each one solved various problems, and I'd also rather have experience programming in both so I know which solutions work best in practice, and which ones need to be replaced by something completely new.
(Sigh... if I only had the time...)
-- |
|
Re:A way for QT to take over? (Score:1, Insightful) by not Bruce Perens on Tuesday March 21, @03:39PM EST (#38) (User Info) |
|
Wow, that got moderated up really fast...goes to show how most moderators are really just pattern-matchers. (Try it sometime: write a comment with no content but in the form of the ones that tend to get moderated up, and watch...) The point is to bring big non-free apps over to Linux, right? And why aren't they here already? Because companies tend not to feel comfortable without having a reliable vendor who you can yell at if something goes wrong. Troll Tech provides that, and they even give their stuff away for open-source projects. So we've got a company that's helping to bring heavy hitters over while allowing current open-source projects to develop, and making a buck in the process. Why are you complaining again? |
|
Re:A way for QT to take over? (Score:1) by Peter La Casse (peter_lacasse@bigfoot.com) on Tuesday March 21, @03:43PM EST (#41) (User Info) http://www.execpc.com/~tlacasse/ |
|
With QT you can use it in open source software with no charge.
It's not as simple as that. You cannot use it for making open source windows software without shelling out big bucks (relatively speaking) for the professional version (unless you port the linux version to Windows yourself, if I read the license correctly.) This is what prevented me from using QT for an open source project I was considering - I wanted to have cross-platform capability. When I asked them about it, they used the "we have to eat somehow" line. So much for believing in open source. |
|
Re:A way for QT to take over? (Score:1, Funny) by Anonymous Coward on Tuesday March 21, @04:22PM EST (#63) |
|
So much for believing in nutritional needs. |
|
Re:A way for QT to take over? (Score:3, Interesting) by Arandir (arandir-at-usermode-dot-org) on Tuesday March 21, @08:01PM EST (#158) (User Info) http://www.usermode.org/ |
|
When I asked them about it, they used the "we have to eat somehow" line. Do you have a problem with them eating? The levels of intolerance here at Slashdot have reached an all time low. |
|
Re:A way for QT to take over? (Score:2) by divec on Tuesday March 21, @08:19PM EST (#166) (User Info) http://3334130452/ |
Do you have a problem with them eating? The levels of intolerance here at Slashdot have reached an all time low. I don't think the original poster was objecting to them eating, merely to their use of proprietory licensing. Most people in the world get paid without creating proprietory software. Even software developers (most of them write in-house software, which is not licensed *at all* - and hence does not have the same socially divisive effects that non-free packaged software does). In any case, this claim that people will `starve' if they don't write proprietory software is completely false, especially in Norway. [Sig obliterated ;-) ] |
|
Re:A way for QT to take over? (Score:1) by divec on Tuesday March 21, @08:21PM EST (#170) (User Info) http://3334130452/ |
|
I can never remember how to spell "proprietary". Oh well. [Sig obliterated ;-) ] |
|
Re:A way for QT to take over? (Score:3, Insightful) by Arandir (arandir-at-usermode-dot-org) on Tuesday March 21, @09:28PM EST (#203) (User Info) http://www.usermode.org/ |
|
I don't think the original poster was objecting to them eating, merely to their use of proprietory licensing. Then he should have stuck to that objection, instead of bringing food into it :-) Seriously, it is unrealistic to expect commercial developers to give up their jobs and become waiters as suggested by RMS. But we are not talking about developers here, we are talking about the companies that employ developers. Before these companies can pay their employees, they need revenue. If Troll Tech open sourced their professional version, they would end up with ZERO revenue, and be forced to lay off their employees. If they can get complementary products to support Qt with in the future, then that may be an option at that time. But it is not an option now. Qt is not the type of product that you can shrink wrap, put on store shelves, and hope enough users buy it to subsidize those that download it instead. And it's unrealistic to expect them to convert to a support company, particularly since their customers are in the profession least likely to need support. The unfortunate fact is that Troll Tech has only one product. They don't sell other proprietary software like Redhat does. They don't sell hardware like VA Linux. All they have is Qt, and if they don't sell it they have to lay off their employees. Their current situation is in my mind nearly ideal. The software is free if you write free software, but it's proprietary if you write proprietary software (I only wish that the Windows version were the same). But one who is of the opinion that all software must be free takes a strange stand by insisting that proprietary software get the benefit of a free library. |
|
Re:A way for QT to take over? (Score:1) by Peter La Casse (peter_lacasse@bigfoot.com) on Wednesday March 22, @09:11AM EST (#248) (User Info) http://www.execpc.com/~tlacasse/ |
|
I don't think the original poster was objecting to them eating, merely to their use of proprietory licensing. Then he should have stuck to that objection, instead of bringing food into it :-) I made the (apparently false) assumption that slashdot readers would know that the "we have to eat somehow" line is a false argument. As the post you replied to stated, whether or not Troll Tech developers are able to eat has nothing whatsoever to do with whether or not they allow QT to be used for free in open source windows applications.
To be more explicit: in refusing to allow this, Troll Tech essentially states that they don't believe that the model they pay lip service to (free for open source, not free for closed source) is a viable one. If they did believe this, there would be no operating system restrictions on the QT license. |
|
Great expectations. (Score:1) by Roberto (ralsina@unl.edu.ar) on Wednesday March 22, @10:46AM EST (#254) (User Info) http://www.kde.org |
|
One would also expect that someone that writes about the Qt license would actually have read it. There is no OS restriction in the Qt license. For example, I am doing a microwindows port. Microwindows runs just fine on DOS. You could use Qt on win32(with some effort) using it. |
|
Re:A way for QT to take over? (Score:2) by Arandir (arandir-at-usermode-dot-org) on Wednesday March 22, @02:33PM EST (#258) (User Info) http://www.usermode.org/ |
|
I asked VA Linux why they don't give their hardware systems away. They replied "we have to eat somehow." But that's not a true statement. Their employees may lose their jobs and the company may fold, but they can always get other jobs. |
|
Re:A way for QT to take over? (Score:2) by Arandir (arandir-at-usermode-dot-org) on Tuesday March 21, @03:51PM EST (#49) (User Info) http://www.usermode.org/ |
|
I'm sure I'll get flamed but I think that a development library should not have a cost becuase you are trying to make a standard. Don't worry, I won't flame :-) The reason Qt has a cost is because Troll Tech is a business. Hmmm, was that a tautology? I actually think their marketing makes a whole lot of sense. Free for Free Software, proprietary for proprietary software. I wish the would do the same for their Windows product as well. Troll Tech is still largely a one product company. They would be foolish to give away their only source of revenue. But this embedded Qt, coupled with some other new products coming out the same time as Qt 2.1, means that there will be more of an incentive to opensource their professional version as well. If they can make more profits by giving Qt away and selling the complementary products, then they will do so. |
|
Re:A way for QT to take over? (Score:1) by molog on Tuesday March 21, @04:46PM EST (#80) (User Info) |
|
Yeah, I understand that Qt is their only product. I was sorta saying that I would have liked it better if they sold a development environment instead of just a library. On a side note, unless you are going for strick portability using Qt on Windows doesn't make since to me. It seems that it would serve only to port *nix apps over that used Qt. If I was developing an app for the Windows world, I would probably just use the Win32 API. It is native (buggy I know) and consistant with the M$ way of doing things. Is the Qt for Windows targeted at Unix developers who want a port? I don't see Windows developers using it. Molog
So Linus, what are we doing tonight? |
|
Re:A way for QT to take over? (Score:2) by Arandir (arandir-at-usermode-dot-org) on Tuesday March 21, @05:41PM EST (#111) (User Info) http://www.usermode.org/ |
|
I see a lot of Windows developers on the Qt mailing lists. Probably just as many as there are Unix developers. From the questions they've posted and the comments they've made, I can surmise that at least a quarter of the Win/Qt developers are not doing porting. And this is despite the fact that Qt is not even close to the MS paradigm. The reason for this is that Qt is better, easier and more robust than MFC or Win32. |
|
Re:A way for QT to take over? (Score:1) by HarpMan (smolitor@erac.com) on Tuesday March 21, @06:56PM EST (#145) (User Info) |
|
Yes. I do wonder, though, if Qt would attract more Windows developers with a lower license fee. Of course Qt has the right to charge whatever they want, and if you know that you're going to be selling something commercially, the price is not that much. But I'm thinking of the Windows hackers who shell out their own money for a copy of Visual C++, VB, Delphi, etc. (I used to be one of them, before I converted to Linux/Open Source). Troll Tech might make up in volume what they lose in price. Also, a lot of Qt/Kde developers might release free as in beer versions of their apps for Windows, if the Qt license didn't cost that much. Stephen Molitor steve_molitor@yahoo.com |
|
Re:A way for QT to take over? (Score:2) by Arandir (arandir-at-usermode-dot-org) on Tuesday March 21, @08:18PM EST (#165) (User Info) http://www.usermode.org/ |
|
Yeah, it would be great if the Trolls treated Windows like Unix: free for free and proprietary for proprietary. I suspect that this has crossed their minds more than once. I sense some signals that something like this may happen in the future. |
|
Re:A way for QT to take over? (Score:1) by GeZ117 on Wednesday March 22, @03:39AM EST (#231) (User Info) |
|
Also, a lot of Qt/KDE developers might release free as in beer versions of their apps for Windows Maybe right for QApplications, but not for KApplications. I remember reading Matthias Ettrich's letter for launching the KDE project, something like "Qt is portable to Windows, but don't matter, we can use enough Unix-specific things to make a windows port of KDE impossible". Most peoples involved in the KDE project want to see more apps for unices (particularly free ones), and not more apps for Windows (particularly proprietary ones, as they're the only ones ;) ).
Most Qt-hater blame Qt for making money out of people wanting to work in an universe were everyone is making money (MS OS). They compare with GTK but the comparison is unreceivable: GTK don't allow proprietary development, and don't allow cross-platform development. As long as you stick with free development for unices, you use them the same way: costless, with a look on the source. Oh yes, for the Qt 1.X branch you weren't granted the right to distibute modified version of Qt. This was mainly to enforce Troll Tech's right as developers and maintainer of this toolkit, something which is tacitly agreed on for GPL software (the creator is the owner). Can you imagine John Doe Programmer modifying three function in the Linux kernel and then saying "Hey, I've got the new official Linux kernel!" No way. |
|
Re:A way for QT to take over? (Score:1) by hattig (SpinningNucleon FATBAT yahoo.com) on Wednesday March 22, @08:56AM EST (#245) (User Info) http://evil.cones.org.uk/ |
|
QT should release a book "Programming QT for Windows" and include QT free of charge with the book, and make money from book sales :-) [ Discuss new TLDs ] |
|
Re:A way for QT to take over? (Score:2) by bero-rh (bero@redhat.com) on Tuesday March 21, @04:51PM EST (#85) (User Info) http://people.redhat.com/bero |
|
What's wrong with the Qt license? Someone writing proprietary software does it for the money. It's fair that all the developers (including the ones working on the widget set etc.) would profit from that if the programmers don't give back anything else (their code). It's not much unlike the GPL in that respect (the difference being that you can write proprietary software with Qt if you pay, and you can't do it at all with the GPL). |
|
Re:A way for QT to take over? (Score:2, Informative) by molog on Tuesday March 21, @07:05PM EST (#147) (User Info) |
|
It's not much unlike the GPL in that respect (the difference being that you can write proprietary software with Qt if you pay, and you can't do it at all with the GPL).
This is one of the reasons that I like the LGPL more then I like the GPL. My point was that if they want to make Qt a standard then it should be free for "everyone" to use. The BSD license is also good in this regard. I'm not really critizing them for charging money for it but it isn't what I would do. That's it basically.
So Linus, what are we doing tonight? |
|
Re:A way for QT to take over? (Score:2) by Ian Bicking (bickiia@earlham.edu) on Tuesday March 21, @07:48PM EST (#154) (User Info) http://www.cs.earlham.edu/~bickiia |
It's not much unlike the GPL in that respect (the difference being that you can write proprietary software with Qt if you pay, and you can't do it at all with the GPL).This isn't really true. Caldera uses the GPL extensively in just this way. They own the copyright for a lot of the stuff they produce, and if you want it under a non-GPL license, you have to pay them. This is nearly identical to the QPL. The difference is that what Caldera does provides much more benefit to the community. You cannot use portions of Qt in a GPLed program because of the incompatible licenses. And you cannot make a purely free fork of Qt -- any extensions to Qt have to be distributed under some sort of license that allows proprietary use by Troll Tech (I don't remember the exact terms). Caldera uses a symmetrical license -- it obeys the GPL, you obey the GPL, everyone has equal rights. But Troll is more equal than everyone else with Qt -- it can do whatever it wants with your patches to Qt, but you don't have the same rights. You can't say "this extension I wrote is only available to free software programs" -- and you probably don't want to, but they don't even give you the choice.
This could be more important if/when Qt moves to embedded or otherwise Abnormal environments. In an embedded environment, things are often statically linked and integrated. But if you want to integrate Qt into general graphical interface, you will have to give up a lot of the control of your code to Troll Tech. The same is true with the GPL, but in that case you are giving up a lot of control to the community, not a company. That's what Open Source/Free Software is all about: community. The QPL is one-way, centralized on Troll Tech. |
|
Re:A way for QT to take over? (Score:2) by Arandir (arandir-at-usermode-dot-org) on Tuesday March 21, @08:50PM EST (#185) (User Info) http://www.usermode.org/ |
|
...any extensions to Qt have to be distributed under some sort of license that allows proprietary use by Troll Tech (I don't remember the exact terms). You don't remember them because they aren't there. Troll Tech only gets rights to Qt derivatives (in the sense of copyright law), not to extensions. But actually, they might not be able to proprietarize you derivations either! IANAL, but look at the clause in question: ...a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms... To my non-legal mind, this means that they can only use your derivatives in the Qt version you derived from. If you derived from the Free X version, they can't use it in the Win32 version without your permission. They could of course put it in the proprietary X version, but they would still have to include it in the free version as well. Again, IANAL. |
|
Re:A way for QT to take over? (Score:2) by Ian Bicking (bickiia@earlham.edu) on Wednesday March 22, @10:10AM EST (#252) (User Info) http://www.cs.earlham.edu/~bickiia |
Troll Tech only gets rights to Qt derivatives (in the sense of copyright law), not to extensions.I don't see the distinction. The relavent clause is this (from the QPL):
3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications:
b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer.
This also clearly means that the initial developer has the right to distribute your free modifications under their proprietary license ("right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer."). This is a confusing notion, as each piece of the software has an initial developer, so I don't know why Troll Tech takes precedence... |
|
Re:A way for QT to take over? (Score:2) by Arandir (arandir-at-usermode-dot-org) on Wednesday March 22, @02:28PM EST (#257) (User Info) http://www.usermode.org/ |
|
It doesn't seem to make any definition of "modified Software" or derivative work...extension is not well defined either It doesn't have to define "modify" or "derivative" as they are already defined under copyright law. If you only link to Qt, then at most your code is an extension. But the only way you can be derived from Qt is to take parts of their actual code and modify them. The latter is what clause 3 refers to. But I assume you want to modify Qt itself... This also clearly means that the initial developer has the right to distribute your free modifications under their proprietary license That is true, but they also have the obligation to keep it in their free version as well. In short, they cannot close source it. The only way they can use it as proprietary code is to simultaneously issue it as open source code. |
|
Qt Public License incompatible with itself (Score:2) by divec on Tuesday March 21, @08:10PM EST (#164) (User Info) http://3334130452/ |
What's wrong with the QT license? It's an asymmetric license - Troll can use your derivatives in a non-free product, but you can't use theirs in a non-free product. This means that you can't combine code from both QT and a QPLed product from someone else. You'd have to give both original authors rights over each other's code which the QPL doesn't let you give. Compared to standard proprietory licenses, the QPL is a good deal. But don't mistake it for a license which allows the community-style code reuse which has made OSS mushroom so fast. [Sig obliterated ;-) ] |
|
Re:Qt Public License incompatible with itself (Score:2) by Arandir (arandir-at-usermode-dot-org) on Tuesday March 21, @08:32PM EST (#176) (User Info) http://www.usermode.org/ |
|
You are only half right. Yes, it is asymmetrical. But there's nothing wrong with that per se. As with any copyrightable product, the authors have some rights to derivative works. However, you claim about the QPL being incompatible with itself is totally off base. Troll Tech has zero rights to the code of third parties. Just because the QPL makes you open up your source code, it does not follow that Troll gets any rights to patch it into their proprietary version. |
|
Re:Qt Public License incompatible with itself (Score:2) by divec on Tuesday March 21, @08:41PM EST (#180) (User Info) http://3334130452/ |
Just because the QPL makes you open up your source code, it does not follow that Troll gets any rights to patch it into their proprietary version. The QPL insists you give the initial developer these rights in your derivative works. In the case of QT, that means Troll. The relevant paragraph is 3c: When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. [emphasis added] This means exactly that they get the right to patch it into their proprietary version. [Sig obliterated ;-) ] |
|
Re:Qt Public License incompatible with itself (Score:2) by Arandir (arandir-at-usermode-dot-org) on Tuesday March 21, @08:59PM EST (#188) (User Info) http://www.usermode.org/ |
|
Clause 3c refers to the Software, ei. the Qt Widget Library. You would be correct if I incorporated a third party's QPLd code into my own version of Qt, but that was not your scenario at all. You were talking about linking an application to both the QPLd Qt and another QPLd code base. The Trolls get zero rights to any of your code that merely links to Qt (beyond the demand that you open source it). They can't proprietarize your code unless it is a modification to their code. |
|
Re:Qt Public License incompatible with itself (Score:1) by divec on Tuesday March 21, @09:26PM EST (#202) (User Info) http://3334130452/ |
They can't proprietarize your code unless it is a modification to their code I was indeed talking about this scenario; if I gave the impression that I meant merely linking to libraries then that's my mistake. Here's a relevant example of this being a problem. I want to do away with X. I want to modify QT to work without X, but in my modified version I want to support other toolkits such as Athena. I find a QPLed implementation of Athena. I want to merge these two codebases and create my own derivative codebase. I can't, because the QPL won't let me. If the toolkits were GPLed, this wouldn't be a problem. [Sig obliterated ;-) ] |
|
Re:Qt Public License incompatible with itself (Score:2) by Arandir (arandir-at-usermode-dot-org) on Wednesday March 22, @01:52PM EST (#256) (User Info) http://www.usermode.org/ |
|
I've been thinking this over since yesterday, and there is still a problem with your scenario. The problem is copyright law. It doesn't matter what the any license says, it can't give any rights to the copyright holder that he or she did not already possess. The rights of party "A" do not transfer to party "B" just because party "C" combined their two code bases into one. In such a case, Troll could incorporate all of your modifications, including the third party stuff, into their free version of Qt, but they couldn't put any of the third party stuff into their professional version. That section of their license would be voided for that section of code. At the worst, you would be disallowed from combining the two. But in that case it's a very simple matter of making a distinct library that links to the original Qt and QPLd athena widgets. |
|
Re:Qt Public License incompatible with itself (Score:2) by divec on Thursday March 23, @06:16AM EST (#260) (User Info) http://3334130452/ |
At the worst, you would be disallowed from combining the two. Assuming that copyleft-style licenses are capable of standing up in court, that's what would happen. But in that case it's a very simple matter of making a distinct library that links to the original Qt and QPLed athena widgets. On a desktop machine it would be. A random palmtop platform might not have any facility to do dynamic linking. But I think the QPL is much more dangerous for applications than for libraries. As you say, generally you use a library by linking to it. Troll say that "We feel [the QPL] is particularly well suited for anyone who wants to run an Open Source project and still have the possibility to earn some money to eat from sales to closed source commercial developers." Other people on the net are starting to take that opinion. If two equivalent programs were both QPLed it would be very annoying, because there are many times when you'd want to share the code. E.g. you might want to rip xemacs's context highlighting code, modify it and then stick it into Abiword or KWord. If these were QPLed you couldn't. As a result, it becomes very hard to share new features without a complete rewrite, which is one of OSS's principal technical advantages. [Sig obliterated ;-) ] |
|
good (Score:1, Interesting) by Anonymous Coward on Tuesday March 21, @03:20PM EST (#15) |
|
Remember the old adage of "More choices is a good thing!" If this means KDE/Qt is more widespread, various open source OS's must be too. More uses for Linux/*BSD/open source is a Good Thing =) like grits? who doesn't! |
|
Acceleration API .... (Score:3, Redundant) by taniwha on Tuesday March 21, @03:24PM EST (#17) (User Info) http://www.taniwha.com/nospam.jpg |
|
So will there be an API for 2d drivers for common cards? (embedded systems seem to be using all the same chipsets ...) will they use an existing one so that existing drivers can be used? what about 3d drivers? |
|
Re:Acceleration API .... (Score:2, Informative) by Majix on Tuesday March 21, @03:44PM EST (#44) (User Info) |
|
Since this new Qt is built on top of the linux framebuffer infrastructure it will most likely use the standard frambebuffer drivers too. Currently there's at least drivers available for the Matrox cards, some TGA cards and a generic VESA 2.0 one. BTW, if you haven't checked out the frambuffer stuff yet, you really should, it's quite cool. You get a Tux logo while Linux boots up and you can have hi-resolution text consoles. Framebuffer support seems to be tagged experimental in the 2.2 kernels at the moment, but I've found that it works pretty well. |
|
Re:Acceleration API .... (Score:1) by zilym (zilym@SPAMNOT.asu.edu) on Tuesday March 21, @08:28PM EST (#174) (User Info) |
|
I tend to disagree with the framebuffer comments. From my experience with it, it's a lot slower than the traditional text only console and using Shift-PgUp/PgDn to scroll back and forth doesn't work quite right (pieces of text from previously displayed pages remain on screen). Yeah, the Tux penguins on boot are a nice gimmick to show off to your friends, but that's all they're really good for. I only place I use the framebuffer support is on my laptop with its fixed pixel LCD. The text console looks terrible with uneven stretching of pixels to match the LCD resolution -- very annoying to read. With a frame buffer, I set the console to use a mode that matches the LCD resolution, making things more readable. Ed Schlunder |
|
Re:Acceleration API .... (Score:1) by Wesley Felter (wesf@cs.utexas.edu) on Tuesday March 21, @08:57PM EST (#187) (User Info) http://www.cs.utexas.edu/users/wesf/ |
|
Since fbcon doesn't provide acceleration AFAIK, it might be interesting if they used the same loadable modules as XFree86. But I admit that I don't know anything about the X driver APIs, so maybe that is a terrible idea and someone in Norway is spewing COke through his nostrils right now... Or maybe they use more BeOS-style loadable accelerant modules. |
|
Qt...NT... (Score:0, Flamebait) by not Bruce Perens on Tuesday March 21, @03:25PM EST (#19) (User Info) |
|
At first glance, the name bears a striking similarity to NT Embedded...but then I realized it was Qt. If you want a real clone of NT, go for embedded GNOME: comparatively as large and just as buggy. Yes, I want to run KDE on Embedded Linux on my fridge. Go Qt! |
|
Bypassing X, good and bad (Score:1, Interesting) by crow on Tuesday March 21, @03:29PM EST (#24) (User Info) http://www.cs.dartmouth.edu/~crow/ |
|
What we lose from bypassing X is the network transparency and multi-application windowing. Sure, you could create a non-X window manager, but I don't think that's what they're talking about here. The network transparency of X is very useful if you're in an environment with multiple machines; I use it all the time. Of course, starting with the shared memory extensions, there has been an increasing push to go directly to the hardware, which improves performance, but breaks remote execution. On the other hand, they're marketing this for embeded systems. Think of "embeded" as meaning "single application." In this case, you only want one thing on the screen, and you probably don't need remote execution, so X is just a big waste of memory. This could be really cool for a dedicated web browser (WebTV) or such. |
|
Re:Bypassing X, good and bad (Score:1) by srichter (strichter@yahoo.com) on Tuesday March 21, @05:03PM EST (#90) (User Info) http://www.linuxactivist.org |
|
It is interesting. I read the QT article last night (since KDE's site quoted it already) and me and my friend talked about the Network transparency. Maybe they will support that. The article does not mention it. My personal opinion is that for most users at home network transparency is not a big deal, since most users will only use the standard office stuff and a web browser. Remember, the goal is to bring Linux to the Desktop! Furthermore, I love the idea that Qt will bypass X. X is big and ugly (and a horror to code in). If the X standard does not wake up and include antialiasing and alpha-channeling, then someone must come up with a solution. The market asks for it, so someone supplies it. And that a commercial company is behind all of that, is actually good, since it will be better supported. Anyway, this comment I reply to was the first sane idea I read, other than "This is dumb" or "That's fucked up!" People, we should communicate smarter than that. Regards, Stephan -- Stephan Richter - The Linux Activist |
|
Eyecandy (Score:1) by Majix on Tuesday March 21, @03:32PM EST (#25) (User Info) |
|
It will have support for anti-aliased text and alpha-blending, two basic features missing in X11R6. It would take about a complete rewrite of the way X11 handles fonts to get anti-aliasing support, so don't expect it anytime soon :( I know the technical reason why we can't have anti-aliased fonts (only 1 color/font allowed etc.), but why don't we have true alpha-blending yet (either provided by X or the windowmanager)? |
|
Re:Eyecandy (Score:1) by abram_fettig (afettig@avxtantalum.STOPSENDINGMESPAM.com) on Tuesday March 21, @04:23PM EST (#66) (User Info) http://fettig.net/ |
|
I believe that both Enlightenment 0.17 and Gnome 1.2 will support alpha-blending, and I believe that Enlightenment will support anti-aliased fonts. For some enlightenment screenshots, see http://www.enlightenment.org/efm.html. I couldn't find any good shots of the development version of gnome, but I've seen the anti-aliased icons in action and they look pretty good.
More importantly, I'd like to celebrate the fact that I got my first blue screen of death on Windows 2000 today at work! I went to open a .doc file in Word, and it said that to install the necessary converter I needed the CD. So I pressed the eject button on the CD-ROM drive, and BANG! BSOD. So much for stablility... |
|
Re:Eyecandy (Score:0) by Anonymous Coward on Tuesday March 21, @05:48PM EST (#114) |
|
GEE you think it might have been the CDROM hardware or driver that was at fault and not Windows 2000 itself? I do! You spankmaster. |
|
Re:Eyecandy (Score:0) by Anonymous Coward on Tuesday March 21, @06:48PM EST (#140) |
|
Recreate that beautiful moment on your 95 or 98 box...
Click here |
|
Re:Eyecandy (Score:1) by homoted (homoted@hotmail.com) on Wednesday March 22, @04:32AM EST (#232) (User Info) http://members.xoom.com/homoted |
|
No kidding, that URL gives this win98 box a bluescreen and a reboot. Is it a IE problem? If you paint your butt blue and glue your bunghole shut you just "themed" your butt, but lost the functionality. |
|
Re:Eyecandy (Score:1) by spitzak (spitzak at d two dot com) on Tuesday March 21, @07:48PM EST (#153) (User Info) http://www.cinenet.net/users/spitzak |
|
Enligtenment and Gnome "support" does not cut it, because it is on the client end. If this was sufficient X could have one graphics call (putpixel) and we could quit working because all the work is done! Hey, I wrote a program that did radiosity and drew the result on the screen, but I don't think anybody would claim that because of that Linux graphics now supports radiosity!
We need advanced graphics in the server. And we need to stop making excuses. |
|
Re:Eyecandy (Score:0) by Anonymous Coward on Wednesday March 22, @03:31AM EST (#230) |
|
As long as your major drawing/widget API's support it, there's really not much of a difference. |
|
Re:Eyecandy (Score:2) by jetson123 (br_9801 at hotmail dot com) on Tuesday March 21, @04:54PM EST (#87) (User Info) |
|
No, it wouldn't take a complete rewriting of the font code in X11 to get antialiased fonts. In fact, the existing font code should probably not get touched at all. Antialiased fonts and drawing could simply be added as a separate extension, with a separate set of requests. That way, for example, the antialiased FreeType code could probably be dropped in without a lot of changes. Whether to use antialiased operations probably should be left to high level toolkit libraries and/or applications, since it affects performance, color allocation, and color maps.
For the common cases, of course, low-level client libraries could try to map non-antialiased calls onto antialiased calls. |
|
The open source alternative (Score:3, Informative) by geirt on Tuesday March 21, @03:35PM EST (#32) (User Info) |
|
Microwindows/NanoGUI is an Open Source project aimed at bringing the features of modern graphical windowing environments to smaller devices and platforms. NanoGUI allows applications to be built and tested on the Linux desktop, as well as cross-compiled for the target device. Both share a common graphics engine. Nano-GUI is based on an X-like protocol called Nano-X. Microwindows sports an interface similar to the ECMA APIW spec with some advancements.
|
|
Re:The open source alternative (Score:2, Insightful) by Thrakkerzog on Tuesday March 21, @03:44PM EST (#42) (User Info) http://tick.dhs.org |
|
Yes, but most QT applications will be source compatable. You can't say that about any of the gui toolkits you mentioned. -- Thrakkerzog Monkey Cloning at Bucknell! |
|
Re:The open source alternative (Score:1) by HoovrBass on Tuesday March 21, @05:08PM EST (#94) (User Info) |
|
Microwindows is on it's way to supporting Fltk, IIRC. Fltk is really lightweight and supports X and Windows with source compatibility. In that case you should be able to develop on the desktop for an embedded target just like Qt is proposing. |
|
Re:The open source alternative (Score:1) by HoovrBass on Tuesday March 21, @05:13PM EST (#98) (User Info) |
|
bah, errors. Anyway, Fltk is LGPL'd too, so I would think that embedded leaning companies would be quick to jump on it, all OSS issues aside. |
|
Re:The open source alternative (Score:1) by Thrakkerzog on Tuesday March 21, @09:52PM EST (#211) (User Info) http://tick.dhs.org |
|
I think there are a lot more apps which use QT than apps which use fltk. If you want to talk about licensing issues, remember what happend with fltk about a year ago. -- Thrakkerzog Monkey Cloning at Bucknell! |
|
Re:The open source alternative (Score:1) by HoovrBass on Tuesday March 21, @10:24PM EST (#215) (User Info) |
|
Which ones would you use on an embedded system, though? I can see your point for set-tops and net type devices but I've built custom defense-oriented embedded systems using Fltk that would have benefited from not needing X, which Microwindows should take care of. No Qt app would have helped there. You'll have to remind me about Fltk. Are you talking the issue with Bill Spitzak(?). Yeah, it was close, but his company made the right decision (TM) and we all benefited. Or are you talking about something else. It's just another choice--one I find particularly suitable for custom, single app type systems--and it's really easy to use. Regards. |
|
Re:The open source alternative (Score:1) by Thrakkerzog on Tuesday March 21, @11:43PM EST (#224) (User Info) http://tick.dhs.org |
|
Here is what I am talking about. Either way, I'm sure some good will come out of both. :) I have quite a bit of faith in Troll Tech, so I think they will come up with something nice. -- Thrakkerzog Monkey Cloning at Bucknell! |
|
Nice for set-top boxes (Score:4, Insightful) by tjwhaynes on Tuesday March 21, @03:36PM EST (#33) (User Info) |
|
This version of QT without X looks very nice for running on Set-top boxes - anti-aliased text and all. In this sort of environment, the 'display anywhere' X protocol is just excess baggage and a more direct route to the screen makes a lot of sense, especially if you are a company intent on providing a cheap device for general home use and want to get maximum speed out of the hardware. This does of course assume that the license for QT/Embedded is reasonably set... On the flip side, just how much software are you cutting yourself off from if you don't provide X libraries? Quite a lot I suspect unless QT/Embedded is providing some extra coverage. Cheers,
Toby Haynes |
|
Re:Nice for set-top boxes (Score:2) by stripes (stripes at eng dot us dot uu dot net) on Tuesday March 21, @06:30PM EST (#131) (User Info) http://www.eng.us.uu.net/staff/stripes/ |
[...]Set-top boxes[...] In this sort of environment, the 'display anywhere' X protocol is just excess baggage and a more direct route to the screen makes a lot of sense, especially if you are a company intent on providing a cheap device for general home use and want to get maximum speed out of the hardware. Actually that is where I most wish they would use X so I can have my non-embeded program display on my TV, or wrist watch, or car stereo's display, or PDA (assuming some sort of net connection). Witness the vast horde of folks wanting to do little more with the i-opener then turn it into an X terminal :-)
Of corse I can see where the company that wants to sell a dirt cheap box would rather have a cheaper device... or want to lock me into their application. |
|
No mention of the license (Score:2) by dsplat on Tuesday March 21, @03:38PM EST (#35) (User Info) |
|
I certainly hope that the license terms are the same as for the original Qt, but I wasn't able to verify that either from the announcement or from Trolltech's own web site. I would imagine that they wouldn't intend to change course, but it would be nice to see that confirmed. If there's anyone from Trolltech reading this, an official statement on your web site would be a good thing. [This space intentionally left blank] |
|
Qt w/o X? Now this changes everything. (Score:2, Interesting) by truefluke (truefluke@yahoo.com) on Tuesday March 21, @03:38PM EST (#36) (User Info) |
|
This is something that I am so interested in its not even funny. X is good for sharing / pumping apps up and down a network / remote login etc. but is too much cruft for something as simple as a desktop GUI. The topic de rigeur is targeting Linux as a replacement for Windows (which I think is moronic: Linux is *really* a server but everyone will disagree and follow the trend and call me an asshole anyway. oh well!). Well, not in its present state. I mean, if Caldera's WebSpyder browser can run in DOS mode, there's no reason why Linux can't have a better GUI system that doesnt require so much twisted legacy-based logic and overhead. |
|
Re:Qt w/o X? Now this changes everything. (Score:0) by Anonymous Coward on Tuesday March 21, @06:51PM EST (#143) |
|
I have the feeling that the people that don't like X never utilize it. What could be better than bringing up my desktop from one server on my local machine exactly like it would look on the server -- without any third party hacks? I'm willing to accept a little bloat for that capability. |
|
Down with X (Score:1) by theants on Tuesday March 21, @03:53PM EST (#51) (User Info) |
|
This could be a big step forward, not just for embedded applications, but for "Linux on the Desktop" in general. I feel that one of the biggest problems for inexperienced users of Linux is XFree86. There is nothing particularly wrong with X for people who are technically inclined and have time to monkey with, but someone who has little or no computing experience has little hope of using it without someone to hold their hand through it. (No matter how easy Redhat makes it to install.) I hope that GTK will eventually try this too. (Maybe Berlin will be helpful here.) |
|
Re:Down with X (Score:1) by CdotZinger on Tuesday March 21, @04:22PM EST (#65) (User Info) |
|
Absolutely. I don't have much trouble with the technical blizzblazz of X, but I'd like to have a disencruftified X (or a feature-slim replacement) to use in RAM-shortage and/or who-needs-it-anyway (ie: desktop) situations. The only reason I keep it around is for compatibility. Anyone out there working on a mini-X that provides basic application compatibility w/o all the cool stuff? I'd be working on it myself, but I know I'd screw it up and piss everyone off. This (what the article is about) looks very, very useful—moreso than its makers realize, I think. Your mouth is like Columbus Day. |
|
Re:Down with X (Score:0) by Anonymous Coward on Tuesday March 21, @06:09PM EST (#121) |
|
I want linux to have a 90 degree learning curve. It's what seperates linux users from winblow lamers and script kiddies. I don't want linux to be easy! |
|
Re:Down with X (Score:1) by karzan on Tuesday March 21, @06:25PM EST (#129) (User Info) |
|
Write this 100 times on a chalkboard, and maybe then you will understand: XFREE86 IS X, BUT X IS NOT XFREE86. X11 is a protocol. X11R6 is the standard distribution of an implementation of that protocol and the surrounding libraries and utilities. XFree86 is based on X11R6. It is not X that is hard to set up, install, or use. It is XFree86. Do you have any idea how many X servers there are out there? XFree86 is hardly the only one. If you want an X server that's easy to use, set up, etc, I'm sure there are some, and if you're not satisfied with the ones available, make a new one.
X as a protocol is excellent. X11R6.4 is an excellent implementation of that and an excellent set of libraries. Maybe XFree is hard to set up. You can change that without using some shit protocol like Berlin that was designed by people who just want their name on something. Use X... X is good... X is great. |
|
Confused about details (Score:3, Insightful) by Pike (jdueck[at]crosswinds.net) on Tuesday March 21, @03:55PM EST (#52) (User Info) http://www.jdueck.org |
|
It sounds nice at first, but don't get the idea that Qt is replacing X on the desktop anytime soon. Is Qt becoming its own windowing system as well? Will you be able to run more than one Qt app and have them windowed? Where are the video card drivers coming from without X?? Sure it's nice for embedded stuff, but a lot of people seem to have the idea that they're getting a small, fast, free X11 replacement for their desktops. -JD |
|
Re:Confused about details (Score:0) by Anonymous Coward on Tuesday March 21, @04:22PM EST (#64) |
Where are the video card drivers coming from without X??Linux framebuffer driver. |
|
Re:Confused about details (Score:3, Interesting) by bmetzler (bmetzler@linuxfast.org) on Tuesday March 21, @04:45PM EST (#78) (User Info) http://www.geeky.org |
|
Howdy Joel! It sounds nice at first, but don't get the idea that Qt is replacing X on the desktop anytime soon. As others have mentioned in here, it is likely that as a consumer desktop graphical system, an X-less QT/KDE interface could fill a big need. Consumers who just want to run graphical applications locally, don't ever need the overhead that X provides. Is Qt becoming its own windowing system as well? Seeing that KDE runs on Qt, if Qt/Embedded is source compatible, then the problem is solved. KDE on non-X displays. Will you be able to run more than one Qt app and have them windowed?There are 2 answers to this. 1, with embedded devices, such as webtops, PDA's, and refrigerators, only one app is running, and therefore windowing isn't needed. For set top boxes, and consumer Linux installations, windowing can be provided by KDE, or any other Window Manager that is ported to Qt. Where are the video card drivers coming from without X??Frame-buffer devices. This is what gives you the graphical penguin on most distributions bootup now. Sure it's nice for embedded stuff, but a lot of people seem to have the idea that they're getting a small, fast, free X11 replacement for their desktops.And for those who are looking to run their Qt/KDE applications, they are. -Brent-- Are you a geek? |
|
OK for 2-D, perhaps, not for 3-D/games (Score:1) by SpinyNorman (spiny_norman@mad.scientist.com) on Tuesday March 21, @05:40PM EST (#110) (User Info) |
|
The matroxfb driver is slightly accelerated for 2-D, but bottom line is that the framebuffer API is too low level to really allow for much acceleration anyway. What's really going to limit this to embedded use though is the lack of accelerated 3-D (forget GL Quake!). OpenGL via DRI in XFree 4.0 should rock! What would be really nice would be if the accelerated drivers for XFree could also be used for Qt or other graphical subsystems, rather than having to rely on a poor common denomenator like the framebuffer. |
|
Re:Confused about details (Score:2, Interesting) by drew (cattand at charlie.cns.iit.edu) on Tuesday March 21, @07:58PM EST (#156) (User Info) http://www.iit.edu/~cattand |
|
Seeing that KDE runs on Qt, if Qt/Embedded is source compatible, then the problem is solved. KDE on non-X displays. whoa... hold on a second here. i haven't looked at the kde code enough to prove this, but i kinda doubt that kde uses only qt. im pretty sure kde uses a lot of X calls as well. so if you have this new qt which doesn't use X, kde will not automatically compile for you. i may be wrong about this, and i would appreciate if someone would verify this for me, but i don't think kde can do all of the things it does based solely on the qt libs. but that's actually my secondary point. the more important part is this: For set top boxes, and consumer Linux installations, windowing can be provided by KDE, or any other Window Manager that is ported to Qt. now this i do know enough about to comment on, because i have worked with window manager code before. just porting a window manager to qt will do squat for you. in the most basic sense, the window manager does very little really. all it does is give you the means to move your windows around and resize them, and maybe close/shade/iconify them. X is what actually does the work of creating and displaying the windows. the wondow manager uses X library calls to modify the windows state, and do the other things it does. take away x, and oops! our wondow manager is now useless. want proof? run x without starting a windowmanager. see, you still get all of your windows, you just can't move them around. and you lose al of the little control options your window manager gives you. now try starting your window manager without x? what's that? you cant? ohhh.... ok, this isn't really proof, but it does illustrate my point. with this qt, the best you could do is a sort of MDI thing. you would write one big qt app that swallows smaller ones, kinda like the gnome control center. but this doesn't completely work, because all of your pre written qt apps wouldn't run inside this monster app. you'd need to rewrite them at least a little bit to make them compatible with an MDI scheme. > Sure it's nice for embedded stuff, but a lot of people seem to have the idea that they're getting a small, fast, free X11 replacement for their desktops. And for those who are looking to run their Qt/KDE applications, they are. nope, sorry. you are right about the framebuffer thing providing the video drivers, but it doesn't provide the windowing system for you, and kde, while it is an excellent desktop, is not a windowing system. so at best, you'd be able to run one app fullscreen on each of your 6 or so consoles, or run screen and switch between n different fullscreen apps, just like you would use it now to switch between a bunch of curses programs running on the console. (or the previously mentioned MDI app, with it's custom "applets") |
|
Re:Confused about details (Score:1) by Hawke (kilpatds at erols dot com) on Tuesday March 21, @08:37PM EST (#179) (User Info) http://www.erols.com/kilpatds |
Brent wrote:For set top boxes, and consumer Linux installations, windowing can be provided by KDE, or any other Window Manager that is ported to QT.That's a little harder than it seems. kwm (the KDE window manager) has communicate fairly tightly with the X server. You can't write a window manager purely in terms of the functionality QT provides, you have to speak Xlib.
For there to be an Embedded QT window manager, QT would have to add a significant chunk of functionality beyond what would be required to draw widgets into a framebuffer. |
|
Brilliant idea. (Score:0) by Anonymous Coward on Tuesday March 21, @03:59PM EST (#54) |
|
This is an excellent idea and I'm surprised no one else has thought of it before. I wish the Trolls the best of luck with this venture. |
|
what niche does this fulfill? (Score:0) by Anonymous Coward on Tuesday March 21, @04:08PM EST (#55) |
|
What kind of device would use QT/framebuffer? It'd have a decent graphics display and chipset (relatively expensive) but also have very low cost hardware behind it that would be bogged by even the leanest X. But the computing hardware can't be so low cost that the CPU/memory can't support QT and the C++ QT ap |