Slashdot Mirror
Trolltech Developing Qt That Doesn't Need X
Thrakkerzog writes: "Here is an article about Qt/Embedded, a version of Qt which is source-compatable with Qt/X11 and Qt/Windows. It doesn't use X11, and just uses the Linux framebuffer. This is very ideal for embedded systems. Check the link for more info."
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.
Oh for pity's sake. The shared memory stuff (MIT-SHM) has been in X for years. Everyone sane uses it. XFree86 doesn't convert everything local to UDP and back again, hasn't done for a long, long time.
X is designed to be an extensible framework, like OpenGL. This is a GOOD THING, and is why both the OpenGL and X APIs remain clean, while Win32 and Direct3D are horrible kludges.
X is actually relatively memory efficient comapred to citrix winframe or the like. A common problem is that people think that the X process memory size quoted in ps or top is correct - actually, since the whole video card is mapped into X's process space, the process size includes the entire gfx mem on the card, as well as it's control registers. This can be in excess of 16Mbyte - but this is not subtracted from the total main RAM in use on the system.
So much for believing in nutritional needs.
But Linux is an OS, not a company... how can it give it up? Seriously, though, BeOS is much more advanced & better designed in a number of areas... A program/game can write directly to the graphic buffer (full screen or in a window), a window's contents can change while the window is being moved, resized, etc. I don't want to say "innovation" (MS has given it a bad name, and it isn't an innovation), but someday people will recognize that it's a better solution
BTW BeOS now runs on crusoe
BeOS has run on crusoe since day 1 (of the announcement :-)
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!
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?
X11 runs in the userspace, so misconfiguration (or just switching your video card or screen) doesn't lock up the system
X11 can crash the system just as bad as if it was kernel space, i.e. on NT. The actual X server, which controls the hardware, runs setuid root. Indeed, with the new Direct Rendering Architecture it is not possible to use the direct access modes without being root.
If this was a microkernel and the X server used a kernel interface for controlling the hardware, it would be one thing - but XFree is directly banging on the hardware, and has the ability to bang anywhere in memory. A bad pointer can still lock the machine, as can a bad PCI setup.
XFree 4.0 has many highend features which framebuffer-based GUIs will lack: multihead support, truetype support, modular drivers, 3D/OpenGL etc.etc.
Windows CE has truetype font support, some have video output - and they are framebuffer devices.
Some even have DirectX support
X11 is GUI toolkit agnostic. You can run KDE, Gnome, GNUstep, Tk, Motif... apps under one X11 desktop, which you can't on a framebuffer-based desktop
You can too! There is absolutely no reason why you wouldn't be able to do this - try it out with the X framebuffer server!
The reason you would not be able to do this is because having the same application loaded in memory three times and using three different functionally equivelant library sets is dumb. The only reason this happens is because X is toolkit agnostic, and spent twenty years without ever having a decent toolkit. So you have a native X protocol version of biff, a xaw version, an xaw3d version, an openwindows enhanced version, a version packaged with enlightenment, gnomebiff, kbuff, etc etc.
Berlin might be implimented in terms of Embedded QT, which might be implimented on top of GCI. Well, not really, but I hope that got the idea across.
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.
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.
Jim Gettys is a name that should be familiar to all old-time X developers, as his name is on a whole lot of the code from way back when
Anyone with some free moderation points might want to bump up his post.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Berlin Home Page
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Do you have any evidence for these assertions? I can believe that BeOS's deeply multithreaded kernel and display logic is more efficient than X, and I believe that MacOS X's Quartz API provides some fancy operations that would be expensive to emulate in X, but you're really making a lot of sweeping statements here.
I happen to use X Windows over a network all the time, both at work on my X terminal to several machines in our computer center, and at home when I'm doing work there. If having X able to support those uses were a terribly heavy burden for the desktop, I could see moving away from it, but I don't believe that it is.
I'd love to be educated as to the precise technical factors that you believe make an X desktop so painfully slow, but I haven't heard any yet.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Just thought I'd offer a tidbit on X performance from the XFree86 FAQ. They recommend that you run the X server on Linux at nice priority -10 so the X server gets first priority for interactive use.
It would be interesting to see if doing this would make any impact on your feelings on X.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
A) The whole X server over network paradigm isn't really needed for a local desktop (most of the time) by utilizing the framebuffer and hardware acceleration, this is provide an increadible peformance and memory usage boost. One reason I use BeOS that its GUI is so ridiculously responsive. Meanwhile KDE on a PII300 and TNT chugs along. Ever open up SysV init editor and resize the window? Talk 'bout major redraw. I really hope they put in support for writing directly to the framebuffer. That way OpenGL could be put on it and we'd be in desktop heaven.
I don't think XFree86 really has any significant overhead due to the X server network support, anymore. As others have pointed out whenever this topic comes up, local clients talk to the server through UNIX domain sockets (i.e., no TCP/IP involved), pipes, and shared memory. XFree86 is about as efficient as you can get while still having a separate process responsible for actually managing the display.
For embedded applications, it might make sense to have support for a system in which one process can serve as both application and as framebuffer driver, to reduce overhead, but in general this cost of the context switch is overwhelmingly outweighed by the convenience of having multiple applications able to put forth windows on the same screen, and by the convenience of not allowing everyone's code to have a chance at trashing registers on the video card, etc.
As far as DirectX-style API's, isn't DRI on XFree86 4.0 working quite well?
What I wish X had was an API for creating and switching between multiple video contexts, at different resolutions and color depths, the way Windows does. I'd love to be able to configure Wine to create an 8bit 640x400 video display context for playing StarCraft, rather than having to kill the X server, edit XFree86.conf and restart the whole thing in low-res/color mode.
There's plenty that's wrong with X and could use fixing, but the basic decision to use a separate server that can be communicated with over a network is not one of them.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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.
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.
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.
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.
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.
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!
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.
The problem is HORRIBLE Xlib design.
Lets see how you draw a red dot on the screen in Xlib:
1. fill in an XColor structure with the r,g,b and call XAllocColor (1 round trip to server). (this could fail, in which case you have to do hundreds of round trips to find the closest color or make a new colormap, but I'll ingore that to be fair).
2. Create a "gc" (probably 0 round trips in modern Xlib? But info is sent to the server).
3. Set the foreground color in that gc (probably done locally).
4. Do XPutPixel, passing that gc and the window over the wire. (more info sent to server)
Now lets see what the calls would be in an interface designed by a semi-talented monkey:
1. "set_color(r,g,b)": info sent to server. Size of info: 3 bytes.
2. "draw_pixel(x,y)": info sent to server, size of info: 2 numbers.
3. DONE! Total number of round trips: ZERO. And I suspect the amount of info is about 1/4 as much sent over the wire, so the buffer fills up only 1/4 as often. Overall improvement in efficiency: perhaps 10,000 or more, depending on the overhead of a round trip.
Main changes I would make to the NeWS:
1. Add 3d (openGL) and antialiasing
2. Do alpha correctly by making alpha part of the current color, rather than having the "compositing modes".
3. Get rid of "layer numbers" in the server. This was the only bit of GUI in the server, and there was absolutely no reason for it, as the toolkit could emulate it easily.
Document and support the postscript interface, rather than trying to force everybody to use NeXTStep (ie same complaint I have about Qt or MFC being the interface).
A perhaps better example is NeWS. In this the windowing was much better integrated into the PostScript. They did depend too much on executing the GUI on the server, though, but otherwise was a much cleaner design.
In both cases lots of operations were noticably faster than X, despite the "overhead" of the buffering and the PostScript interpreter. And NeWS allowed me to rotate and scale an application and it still worked! Nobody is even trying that now...
I love X. But this would be great for the embedded solutions. The small footprint is ideal for some projects that I would like to start we just have to see about the licensing issues and time.
http://theotherside.com/dvd/
Most of the requirements for switching depths are because most low-end PC graphics cards do not support multiple pixel formats at once.
:-)
If they did this (like SGIs have done for years), then the only reason for swithing would be to change resolutions...and that's less interesting.
Since the screen size and depth are encoded in the X protocol there would be real problems in changing this...
So you want to spend years of resouce across all the major X vendors becuase you don't have a decent monitor ? I'd be cheaper for me to just by you one
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
That's the license for FreeQt version 2.0.
They don't mention the license of Qt/Embedded.
-- Thrakkerzog
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
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?
Calling X an extensible framework is a bad excuse for holding on to a design that is too limited from the beginning (if it's so extensible, where's the antialiased truetype font support that has been available for so many other GUI frameworks for such a long time? Perhaps no applications would support an extension?).
X required in excess of 16MB on 1MB video cards and it wastes a lot of memory in case programs try to use pointless "optimizations" like loading pixmaps into server memory because it's the fastest way to move them on your *local* display (pointless, because a better protocol could have avoided this waste).
"I love my job, but I hate talking to people like you" (Freddie Mercury)
The essential questions are:
- Is the built-in network transparency of X necessary? Answer: no, it can be added later, basing the whole design on network transparency makes sense only for environments where network transparency is actually used most of the time (and that excludes most PCs/workstations these days), in all other cases it isn't worth the performance degradation and design complexity.
- Is X flexible enough to support modern hardware's capabilities without a messy heap of extensions that aren't accessible to existing programs? No, it isn't - e.g. I can't even switch the bitmap depth of the display without restarting all applications (this could have been fixed a long time ago, but for various reasons it hasn't been considered worth it, I suppose - the visuals would have to be "emulated" using quantization, dithering etc., since older applications can't be told that the depth has changed).
If X was stable and efficient, the disadvantages could be tolerated, but unfortunately it is neither. It's one of the major causes for the slow adoption of Unix/Linux in the desktop market. It's time to think about a new design, it can't be too difficult (look at BeOS) and X servers for other display systems are easy to write, so you could still use your favourite X programs, like xfontsel (blergh)."I love my job, but I hate talking to people like you" (Freddie Mercury)
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
My point is, KDE is not a Troll Tech project, and Qt/Embedded is not a sign that the Troll developers are megalomaniacs.
Mostly WM code, since this requires X specific code, everything else should port very easily.
So many people on here are bitching about Qt. Qt (I find personally) is much better than GTK. I this this move by Trolltech is a very good idea. Removing Qt's dependancy on X would make it MUCH easier to port. It would be nice to be able to port *nix apps directly to other OSes GUI and all. I would also think it would be a boon to people wanting to put together embedded systems running Linux but don't have the cash to build their own GUI engine along with a graphics library. I don't like X anyways, why the heck does my display need to be networked? I don't ever use a remote client because my connection isn't nearly fast enough.
I'm a loner Dottie, a Rebel.
Another acronym you should ponder is URI, U R an Idiot.
I'm a loner Dottie, a Rebel.
Amen to that. The one thing I miss about Windows is the ability to switch resolutions without stopping everything else that's going on. With the old 14" monitor that I have, in order to get enough screen real estate I have to run at a ridiculously low refresh rate. This doesn't bother me too much, but my wife notices the waviness/jumpiness a lot more. If we could swap video modes as easily as in Windows, X on Linux would be about perfect for our needs.
Your right to not believe: Americans United for Separation of Church and
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".
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.
I would hope that programmers would go byond just compiling QT apps.
While WinCE and the lesser known PenWindows were miserable failures in moving Windows to the PDA PenGeos made the move quite nicely and continued to move into cell phones where it lives today.
The key diffrence (byond Zoomer dying and nearly taking Geoworks with them) is that as Geos moves from platform to platform it changes to take advantage of that platform. The apps also changed.
I would hope thats the plan with QT. It's not binary compatable but sorce compatable. I suspect we are expected to modify existing programs for the imbeded system and not run them as is. Anything in binary form for the PDA should be a full port.
The use of the framebuffer suggests to me that porting is left up to the Linux kernel and taken out of the hands of QT. A rather smart move.
I don't actually exist.
Correct me if I'm wrong, but if Embedded Qt doesn't require X, then Qt apps should work on MacOS X without having to also run an X server. Of course you still wouldn't get all of the nifty features of Quartz, but on the other hand you wouldn't have to run an X server to use Koffice either.
Did Qt ever amend their differences with the Free Software movement? I've never really gotten a clear answer on this issue.
-Scott scott@surrealistic.org
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.
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.
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.
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.
Why X is nicked X11?
Was there X2, X3 etc.?
QT should release a book "Programming QT for Windows" and include QT free of charge with the book, and make money from book sales :-)
I can never remember how to spell "proprietary". Oh well.
perl -e 'fork||print for split//,"hahahaha"'
Any idea if this is true using xfree on GNU/HURD?
perl -e 'fork||print for split//,"hahahaha"'
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.
perl -e 'fork||print for split//,"hahahaha"'
He's not alone; the Debian project, with some legal advice, agreed. See their statement about the issue. Section 2 of the GPL and section 3 of the QPL are mutually exclusive.
If you link *your own* GPLed app to QT, that's perfectly legal. If you give others permission, then they can do it too.
perl -e 'fork||print for split//,"hahahaha"'
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
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.
/. moderation protocol away from trolls and into the hands of insightful posters. Any thoughts (maybe we could have an insightful post next week?) people?
There seems to be a big push to get the
[sorry, couldn't resist]
Q: What do you think about American Culture?
A: I think it's a good idea.
(adapted from Gandhi)
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!"
"Oh, I got me a helmet - I got a beauty!"
Jack Nicholson, Easy Rider
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.
I thought this was exactly what
Direct Rendering (included in Xfree4.0)
does.
Hari.
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...
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Linux might as well give up in the embedded market because BeIA is much farther ahead technologically. Linux should stay in the server/workstation market where it belongs. BTW BeOS now runs on crusoe so it is only a matter of time before BeIA internet appliances start appearing in big numbers
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
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.
Just when you upgrade to the long awaited version 4.0 than it's time to delete it and re-write all the apps again for a different one.
.oO0Oo.
Anyone written a Farenhieght to Celcius converter for it yet?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
make comment
make post
This is exactly what linux needs to push it to the desktop. I have been saying this all along. X is crap in a single user mode environment. If you wish to have fast graphics which is required by games you have to get at the hardware.
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...)
--
Stay up hacking each weekend. Sleep is for the week.
Considering that in the upcomming years we probably WON'T see broadband internet connections capable of handling a decent speed X session, this may have some value. Because thin clients don't have as many resources as workstations, desktop machines, or even the standard X terminal, this may provide a new solution.
Also we have to realize that one of the things that keeps Windows popular on the desktop is that it is in one way or another easy to develop for. I know I am going to get hit by lots of experienced programmers telling me that I am wrong and that the Win32 API's suck and all that, but with VB and the whole MS Dev studio together, its pretty simple creating apps.
One aspect of Windows development that I see could be easier than standard Linux/OS Unix development is the UI output. If programmers can save resources by not having to utilize network protocols then maybe the apps that they develop could be either more stable or more feature filled.
All of us complain about having too little memory, or bandwith, or processor speed. If there was one less process going on in our standard desktop apps then maybe we may find other features to use those resources with, or even, *gasp*, just have apps that run more stably and consume less resources?
Any thoughts?
I dont have a
Having an install disk with qt and the framebuffer device would make graphical installs one step easier. Correct me if I'm wrong but this seems like a good thing =)
Now we just need gtk to do the same thing
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.
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.
No kidding, that URL gives this win98 box a bluescreen and a reboot. Is it a IE problem?
Ahhh, but my mini-notebook only has a (tiny) 640x480 screen. I won't be able to fit an 80x25 xterm in that at 22 points. Anyway, I *like* the console fonts.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
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.
But X runs as root, while framebuffer apps don't have to. Likewise, X bangs the hardware directly, while framebuffer apps don't. So I think framebuffer apps should be safer than X (unless you are running the fbcon driver for X, of course).
I've been thinking about this, too. It seems like there are two ways to go:
Smart: Put as much of the logic and work as possible in the server. NeWS was an example of this; Berlin is possibly an extreme example.
Stupid: Put as little in the server as possible (events, region management) and let all the apps draw directly to the framebuffer. Y seemed to be taking this approach, and I hear MacOS X is also.
(Note that I don't mean "stupid" in a bad way. The Internet is a really stupid network, and that's why it's the best one around.)
Which way should we go?
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)?
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.)
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?
You mean someone is trying to bypass the standard bloatware(X)? How dare them.
Getting rid of X is a good start. Next, we have to get rid of Qt, and then there's only Linux left to get rid of. Let's do it!
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.
sigmentation fault
No more, as for KDE2 there is a OLE-like protocol (DCOP) which require X for ICE. Without X, no DCOP, so KOffice, for example, won't work. Except if Qt/embed include a remplacement for ICE (I doubt).
sigmentation fault
Ok, I can sympathize with not wanting the overhead of X, but if you can afford the overhead of Qt, single chip capacities arent that far off supporting X too...
And, hey, while we are at it, sure, a webbrowser on a toaster must make sense in someones mind, but what _I_ want is my toaster, fridge and oven consoles on my DESKTOP! Which means X!
This article is about Trolltech creating a new environment (not been X) that will be able to use Qt applications. Correct me if I am wrong but KDE is not only developed using Qt, KDE need some X functions. Without X most part of KDE has to be rewritten.
--- Bouh !!! ---
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.
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.
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:
It is, altogether, a rather short license. It doesn't seem to make any definition of "modified Software" or derivative work. I would thus assume that anything that used a portion of QPLed code would fall under this clause, and that would include many forms of extensions (though again, extension is not well defined either).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...
I figured this would happen once I saw what KDE and gnome were trying to do, namely isolate applications from X completely. Older apps communicate with graphics hardware via X. This meant that graphics hardware could be swapped in and out (and even across the network!). But now both KDE and gnome (with the help of GTK and QT, respecively) have become a complete layer between apps and X. This means it should be possible for KDE and gnome to completely skip X, and go straight to the hardware. The advent of the Linux frame buffer makes this even easier.
There were hints of this already in projects like the now defunct Harmony (FreeQT) in how it handled TrueType fonts.
As others have said, choice is great. It isn't (yet) time for X to die completely, being able to skip the rather large and complex called Xwindows will often be a great boon.
I hope that at some point, all gnome and KDE apps will be run-time (or maybe shared-link time, which amounts to the same thing) switchable between framebuffer and X. Run the app, and if the DISPLAY is local, skip X, otherwise be an X client. ...or something like that, but now I'm just rambling.
--Chouser
--Chouser
"To stay young requires unceasing cultivation of the ability to unlearn old falsehoods." -LL
"Embedded QT" represents an abstract API for constructing GUI apps. That does parallel Berlin.
GGI represents a physical API that abstracts away only the lowest level of "talking to hardware."
The net result is that you might want to run "Embedded QT" on top of GGI, much as you have to run Berlin on top of GGI.
In the process, it's pretty evident that you'll lose the ability to have remotable network applications with "Embedded QT." (Berlin has no such loss, as it runs atop CORBA...)
The thing that I don't see any information on is what they're doing about font rendering. That's one of the major things that X does which a framebuffer doesn't do...
If you're not part of the solution, you're part of the precipitate.
Berlin depends on there being some lower-level display substrate like GGI.
It would make sense to implement Berlin atop X; implementing it atop QT, of whatever form, would not make sense.
What could make sense would be to implement Berlin (or, by the same token, X or Display Postscript) atop whatever low level framebuffer scheme lies underneath Embedded QT. But I suspect that this layer will more closely resemble GGI than anything else...
If you're not part of the solution, you're part of the precipitate.
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")
If I don't put anything here, will anyone recognize me anymore?
- X11 has network transparency
- X11 runs in the userspace, so misconfiguration (or just switching your video card or screen) doesn't lock up the system
- XFree 4.0 has many highend features which framebuffer-based GUIs will lack: multihead support, truetype support, modular drivers, 3D/OpenGL etc.etc.
- X11 is GUI toolkit agnostic. You can run KDE, Gnome, GNUstep, Tk, Motif... apps under one X11 desktop, which you can't on a framebuffer-based desktop
That said, I find Qt/embedded an excellent idea, moreover in the light of the recent progress in the efforts to port Linux to Psion PDAs and WinCE palmtops. For such devices, X11 is bloated. It will be nice to have Qt/KDE applications such as KLyX available on PDAs in the not-so-distant future. I hope the GTK/Gnome folks take up the idea and do the same with GTK/GDK, hopefully in a way that makes it possible to run both Qt- and GTK-based software under the same framebuffer-based GUI.These developments are important in a time where companies like Samsung are working on Linux-based PDAs with proprietary user interfaces and proprietary applications on top of the kernel. Although it's good that Linux becomes popular for settop boxes, PDA and other embedded devices, it would be a substantial drawback for the cause of Free Software if proprietary GUIs and userspaces would prevail on such systems. So Trolltech's move deserves applause from our community.
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
I believe it is now time for a fully free (GPL, perhaps) windowing system that fixes the major problems with X. Such a beast would:
A lot of the infrastructure that we need already exists. Libart provides the imaging model. FreeType can take care of the fonts. I've seen some early results from FreeType 2, and I have reason to believe it will be juicy. We can certainly make use of all the wisdom learned from mature systems such as X, as well as newer systems such as Berlin and Microwindows.
This idea, I think, is gathering momentum. If you're interested in contributing to the project, let me know and I can hook you up with some of the other people who are working in a similar direction.
LILO boot: linux init=/usr/bin/emacs
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.
--
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
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.
Yes, but most QT applications will be source compatable. You can't say that about any of the gui toolkits you mentioned.
-- Thrakkerzog
"I love my job, but I hate talking to people like you" (Freddie Mercury)
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.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
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.
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.
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.
Qt is just a application development toolkit, with a healthy dose of GUI.
KDE uses Qt, but Qt is not a desktop environment. It is just a library.
KDE will continue to use Qt/X11, as it always has.
Isn't that pretty much what AmiWin does, when you link it with the proper libraries?
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.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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 knowledge that you are an idiot, is what distinguishes you from one.
A few factoids to add to the discussion.
The size of the X server on Itsy is under 700K, courtesy of Keith Packard's new frame buffer code; contrast this with your current X server weighing in at 2 megabytes. This is due to the changes in machine speeds over the last decade. (Note that Keith did the previous frame buffer code: but on 10 mip machines, you had to do things differently to drive a frame buffer flat out).
DDX's are beginning to cut over to this code, so expect your X servers to get smaller over the next year or two.
Keith is also working on an anti-aliased text and graphics with alpha blending extension: come hear his paper this summer at Usenix.
Oh, and someone said X is 20 years old: incorrect, the first thing called X was created less than 16 years ago, and X11's design is about 12 years old.
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.
A Government Is a Body of People, Usually Notably Ungoverned
Why don't you guys run a separate X session? Then you can have two resolutions and desktops at the same time (something Windows can't do).
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
The first thing I thought of was "this would make a better GUI installer for Linux". So far, only the Mandrake GUI installer has worked on my system. And only SuSE worked on my friend's system. Everything else completely bombs. The reason for this is X. My card cannot be probed, thus, not detected automatically. My friend's card doesn't have a VGA mode, so it can't use the default.
An embedded Qt would allow distributions to use their own video detection routines. I don't know about frame buffers, but it seems that having two ways of making a GUI installer covers more bases than just the X way. Just load the library that's appropriate and use the same installer.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
...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).
...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.
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 Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
For the first time Im relly happy about QT, I still doesn't like it and will never ever in hell use it but it will hopfully inspire GTK hackers to imitate ;). Linux doesn't need one way to do it but more ways, long live QT,GTK, Berlin, X,Dinx,Framebuffers and GGI !
De lyckliga slavarna är frihetens bittraste fiender, legalisera!!!
You mean like xterm -fn '-bitstream-courier-bold-r-normal-*-*-220-*-*-m-*- iso8859-1' &?
James
XFree already provides DGA to remove the X protocol and network overhead for local apps, so why not combine this with Qt/fb for a seamless "do the right thing" Qt-based desktop...
A Qt/KDE based app. can determine if it's X display is local or not, and act accordingly: If the display is remote (i.e. over the network), then the normal Qt/X is used, but if the display is local, then the new "embedded" Qt/fb is used "on top of X" via DGA to provide a seamless display.
What would really make this solution would be if XFree accelerated drivers could be used by Qt for direct screen access rather than using the framebuffer which has very limited 2D acceleration only.
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.
perl -e 'fork||print for split//,"hahahaha"'
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.
perl -e 'fork||print for split//,"hahahaha"'
This is not only great for embedded systems, but for desktops.
A) The whole X server over network paradigm isn't really needed for a local desktop (most of the time) by utilizing the framebuffer and hardware acceleration, this is provide an increadible peformance and memory usage boost. One reason I use BeOS that its GUI is so ridiculously responsive. Meanwhile KDE on a PII300 and TNT chugs along. Ever open up SysV init editor and resize the window? Talk 'bout major redraw.
I really hope they put in support for writing directly to the framebuffer. That way OpenGL could be put on it and we'd be in desktop heaven.
B) Its X compatible so no re-writing apps to support a next Gen interface!
C) It dumps all the X stuff that is in qt and is redundant anyway on a Qt system.
I think they seriously have the right idea with this release. Finaly, a great kernel like Linux gets a good windowing system to go along. If this is GPLed, it will not make its biggest splash in the embedded market. It will make a splash in the desktop market, because even if Trolltech doesn't have the right focus for this product, I'm sure lots of media obsessed users pissed of by poor interactive performance do. This is seriously cool. This also bodes well for a DirectX type API on Linux. Think about it! It support hardware acceleration, so SDL could be put on it and have a very direct route to the graphics hardware. If basic SDL-style input services are put in, and OpenAL plays nice with it, you have a Direct, low-overhead API that is cross platform to boot!
A deep unwavering belief is a sure sign you're missing something...
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.
The net will not be what we demand, but what we make it. Build it well.
Or to some other frame-buffer based GUI. I want to use Mozilla/XUL/XPCom as the basis for a whole set of applications. And it would help if I could use it embedded.
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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.
spam, spam, spam, spam, e-mail, news and spam.
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).
This message is provided under the terms outlined at http://www.bero.org/terms.html
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.
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
'spose you write closed source...for whatever reason.
TrollTech: A set of libraries; $1550 per developer.
Microsoft: Visual C++ Pro AND W2K. About $500 per developer, for both.
My sources: The trolltech webpage and pricewatch.com
I think the price for Qt is ridiculous. Borland sold their stuff to anyone, for $49.99, at a time when the cheapest alternatives were over a thousand. Phillipe Kahn is still a very rich man. The way they (Troll and KDE) keep yapping about the "QPL" is sickening. The Qt libs do not even have a value of a Borland product, let alone MSHAFT.
Really, I know a lot of people don't like to hear it, but far too many Linux OS and add-on companies are guaging their price structures off of Microsoft, Borland and Apple.
Here's some news for you: your product only runs on a few percent of the world's machines, if that. Stop staring at your P&L and get the products out for low cost so developers can use them.
You are killing Linux, which wouldn't exist without people like RMS and Linus, who were selfless and knew they would have to give for a long time before the rewards came back.
Wake up, Trolls.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
I'm not sure if this is what Trolltech is talking about, but I want a display server that doesn't take over the whole screen. I want full screen text mode consoles to use with mutt. I don't want an Xterm that uses a hard to read font and useless crap on the screen to click on with a mouse that takes my hands off the keyboard. And I want to be able to launch a graphical browser from an email using the framebuffer without all the overhead of X and either Gnome or KDE. It's just way too much stuff.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
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.
- They must convert KDE (that require X) or create a new desktop (one more
:-). - No GTK applications will work with it (Unless support developped by the GTK project group, which is unlikely)
- No X application support (Netscape Communicator
...) until a port is done.
This is a M$-like method to create standard: pressing the developers to adopt Qt as the standard application model capable to be used in all environnement (X and non-X) inside Linux.And if Gnome release such environnement it will only create more fragmentation. I don't really like this idea.
--- Bouh !!! ---
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 surprising how badly I spell ?
But I don't want to see a "toolkit" interface as the low-level API. This will completely freeze all gui devlopment. It will also make Linux much harder to "hacker" program and will make it less fun. If I am forced to use Qt, I might as well use MFC and Direct X.
What we need is a true replacement for X that keeps the (few) good ideas of X:
A networked, buffered protocol. Despite claims above, this is more efficient than a call-based API. There has to be context switches, unless we want to allow the programs to write and peek at each other's windows and to be able to clobber the video registers. The way to keep the context switches down is to buffer requests. Nice simple buffering at a low level, and we get an efficient interface, and we get networked transparency for "free" (rather than having to add it on, as MicroSoft is feverishly trying to do right now...)
The server does not have to do any "GUI" things. X design is 20 years old, yet it is obvious that it can draw all the GUI components ever invented (like we can copy Windoze quite exactly, and that was not a design criteria when X was made). I do not want a server that has any concept of a "menu" or "button". That is bloat. Put it in the user-level library (much like Qt and GTK are now). I really really fear Qt becoming the standard interface, even MicroSoft was smart enough to not cram MFC down everybody.
The server does need advanced graphics capabilities. Here the opposite is obvious: X obviously cannot duplicate new ideas. We have seen antialiasing for years now and X cannot do it. 3D requires a whole new interface (OpenGL) that does not interact well with the rest (it does not use X gc's or colors, for instance). And way too many programs "work" by creating a local image buffer, doing all the work there (thus losing all hardware acceleration), and drawing the image.
I envision a server much like X, but with graphics capabilities like a combination of PostScript and OpenGL (plus antialiased everything, like Flash, and 4-channel images, and transparent paint, and UTF-8 text).
It seperates programs into arbitrary-shaped "windows" (perhaps with transparency) and does not allow one program to draw in another's "window" or intercept events to another's "window". But except for that it is "GUI stupid". It must deliver raw events to the clients and make absolutely no assumptions about anything, for instance a "window" does not mean it has a border.
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.
-BrentWhen 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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
A Government Is a Body of People, Usually Notably Ungoverned
In a similar vein, the YAX (YAX Ain't X) project aims eventually to build a windowing system on top of svgalib/GGI/fbcon/Mesa/whatever that will support Gnome and GTK apps. There hasn't been a lot of traffic on the list, but the code is progressing, albeit somewhat slowly.
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
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.
RFC1925
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?
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
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
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Really?
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.
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.
No argument there; X is tried, true, and it works.
That doesn't help you if you're remote ... and yes those are nice sometimes if you're remote.
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?
DNA just wants to be free...
I'm wondering how this would compare to the Berlin windowing system or GGI? With the goal of running embedded, I'd guess QT's new system is simpler, and less cross-platform. Basically a way to get QT apps ported to handhelds really quickly, rather than a general replacement for X. I'll freely admit, though, that I don't know much about GUI framework design. Anyone out there in the know and willing to comment?
I have to wonder, though, how many X apps will really work well on a handheld? It's a different environment, after all, with somewhat different inputs and uses. Just dumping X apps to a PDA would be like the approach MS used for WinCE, and it didn't really work.
Jon
All opinions expressed herein are my own, and not those of my employers, who are appalled.