Especially since, in most areas, GNOME's technology lags behind KDE's.
That's basically irrelevant - almost all the apps that I use on a day to day basis and actually matter to me are neither KDE nor GNOME, they are things like emacs, bash, irssi, gaim, firebird and so on.
The only non-desktop neutral app I use and would think twice about replacing is Evolution.
KDE has this problem where they spend all their time making shining pearls of API perfection, and then wonder why there are so few third party apps using them. The fact is that dragging in the KDE or GNOME frameworks does carry a cost for the users and typically the benefits of the additional functionality offered doesn't outweigh the cost.
The GNOME guys have the right idea imho - work on making a great desktop first, and let that drive the infrastructure, rather than the other way around. In time most of the real functionality should be pushed down into either the toolkit (GTK/Qt) or highly modular desktop neutral 3rd party libraries.
No, NSIS should work on an out-of-the-box wine install. I fixed the bug, no problems, it'll be applied to CVS after AJ gets back from vacation in Switzerland (~2 weeks).
People were talking about XFree forking for so long and nothing ever happened. Now within the space of a few months, we have two!
It seems at least to me that the freedesktop.org x server (kdrive) is where the interesting stuff is happening, but we'll see how the Xouvert guys get on.
I fail to see how a pre-beta release of a non-native app lacking a minor area of system integration has anything to do with Linux.
I mean, there are lots of programs on Windows that don't pay any attention to your default requested browser and always open IE. What exactly is your point?
Clear, reasonably informative, posted to community websites and more importantly it sounds like it was written by a real person who just wants to do the right thing.
That's a very rare thing in corporates. I really hope that as Red Hat expands, they keep it up. So far they have, and even with the new splits between their community work and enterprise stuff, I feel pretty confident they won't slip.
I wish all companies were like this. It's too easy for them to slip behind the mask of anonymity.
Actually NTFS has been fully reverse engineered for some years now. The problem is simply one of manpower - all the people working on the linux-ntfs project are volunteers, and they have the same problem we have in Wine: there are simply not that many people who can do it.
Despite the high level of interest in the projects success very few people are willing/able to setup zillions of test partitions and then take a low-level hex editor to them when it goes wrong.
This is an interesting hack for sure, but long term there's no reason why we can't have native write support. We know how, it's just a case of doing it.
How would you be able to tell a Qt app from any other Windows app? They both use the same visual elements.
Careful. They use the same theme, but so does GTK+ on Win32. The widgets are still different. The Qt widgets are deliberately designed to be close to the Windows native widgets but they are not the same, and there are plenty of subtle differences that you'd only notice if you worked with it day in and day out.
It seems you were using GTK+ 1, which has been obsoleted for some time now. For instance, the CList is deprecated, replaced by a much more powerful (perhaps overpowerful) treeview.
The combo box has been rewritten for GTK 2.4, which should be coming out in a few minutes.
I can't comment on the entry box.
The documentation is still weak in places, I agree. It is however a lot better than it once was, and no new APIs are added without proper documentation to back them up.
Are you kidding? $2000 is nothing when you include costs of running a commercial outfit.
It's the principle that worries most outfits. Sure, $2000 for a widget toolkit perhaps isn't much on its own, but now assume you're paying for the OS, the compiler, the IDE... it all adds up. Just imagine if there was not one but many libraries that followed this policy - quickly the cost of support code and tools would cause serious problems.
Furthermore, Qt is such an easy-to-use, high quality toolkit compared with anything GNOME has to offer that you are bound to be ahead on the development costs in time savings alone.
This is a fairly common troll, yet it's never been adequately backed up as far as I know. In fact I know a few developers who have used both GTK and Qt enough to know the differences, and don't think Qt is all it's hyped up to be (for instance, the qpe-gaim developer). The Qt API contains its fair share of wierdness, for instance, why does QVBox inherit from QHBox? Where is the equivalent to gdk-pixbuf?
Qt also works on the Mac and Windows - GNOME toolkits don't - this is very important for most commercial developers.
Qt works on Mac and Windows if you pay the fees, which are hefty. The problem is, so does GTK+ - there is a port which tracks the native XP theme in use, and as MacOS X has X11 support built in, they work there too. In most commercial developments cross platform portability is sadly not a concern anyway.
Come now, you're missing out some important details.
The Mozilla project don't want to build SVG by default because it's not a full implementation of any current spec. It's missing a lot of features. They have been burned before by half supporting standards, and it's generally agreed that it's a bad thing. Either you support it, or you don't. You can't just support the easy bits, or the bits that sounded coolest.
While the KSVG team have been storming and may well have a full implementation, the same is not true of the Gecko implementation. If people cared enough about it, they'd work on Geckos version, but it seems they don't.
Perhaps. It'd certainly be worth doing. I'm far from an advanced C++ coder but last time I looked the GTKmm APIs were pretty good, using the STL throughout (except for strings, because std::string isn't utf-8 or something like that). GTKmm has two sets of APIs that have been optimized, the c++ binding and the underlying generic API, it'd be interesting to analyse the effects of having two teams do that.
Erm, you're comparing two entirely different languages? The Qt example is written in c++, and the GTK widget is written in C. There's no need to do that, you can use GTKmm if you wish. It's also different code - in the C version you have some (apparently unused) getters/setters, which aren't present in the C++ version.
I don't recall where I last posted one, I think OSNews but it's pretty hard to find individual posts there.
Basically:
* OpenOffice really (ab)uses shared libraries heavily. It has over a hundred of them, all internal. Worse they are all C++ so there are lots of symbols. On a typical OpenOffice Writer startup, over 1.7 million string comparisons are performed in the dynamic linker alone.
* MS Word has been heavily optimized so that the minimum number of page faults necessary are used to get the user to the first screen. This involves some clever analysis tools, support from the toolchain etc - MS Visual C++ produces very compact and tight code, so fewer disk accesses are needed for the same amount of code. Modern application startup time is mostly a matter of disk IO once other factors (such as synchronous waits on servers starting up) have been removed.
* OpenOffice drags in an entire framework and object model, whereas MS Office reuses at least COM and the registry (though not the widget toolkit to some extent). Dragging the entire VCL and SAL into memory takes time.
* Microsofts employees have the issues related to startup time drummed into them, free software developers do not. They understand techniques like rearranging the layout of your code so commonly used objects and functions are grouped together, how to optimize the CPU working set and so on.
For OpenOffice the biggest issue is still fixup time. Red Hat and Ximian are looking into that, there are techniques you can use (symbol hiding in particular) that can speed up the time taken to load large C++ shared libraries like that. Prelink will also help.
import gtkhtml
browser = GtkHtml()
# that's it, you're done
Let's ignore the fact that you're somewhat biasing the test by asking about a component that was written from the start for KDE.
Comparing LOC by the way is normally a silly way to measure "elegance". And I asked you to compare Qt and GTK+, not the entire KDE framework. You were talking about Qt, so talk about it now.
If I double-click on MS Word 2002 at work, it loads instantly, because it's already in memory starting at bootup
No, that's wrong. I've already posted analyses of why Word starts so much faster than OpenOffice, use Google power. If people want I can do so again, but Word is not preloaded. End of story.
If I run KWord from Gnome, it takes about over 10 seconds for the KDE backend theme/DB libraries and QT toolkit libraries to load and all the widgets to be arranged properly
This is entirely a problem with KDE (and yes, Gnome is bad too). If KDE didn't insist on loading arts, dcop, and a zillion C++ shared libraries on the startup of every app then KDE apps would not take ages to load. Somebody could sit down and profile and optimize and sort it out, but nobody does - why? I don't know. Maybe people rarely use KDE apps outside of the KDE environment so there's no incentive to do so.
Basically it's possible to make startup time really good, and it's not necessary to abstract an entire platform in order to do so.
The bottom line is that Linux on the desktop won't be embraced until it's more responsive.
Modern desktops are pretty responsive, even more so with the 2.6 kernel. There can always be improvements of course, but to claim this is a huge issue is misleading IMHO.
Maybe QT is the way to go (even though it's currently both slow AND ugly) because of better API design and we should port Gnome to it somehow.
What part of its API is better designed? I get tired of people claiming this like it's just obvious - so far when called on it, I haven't seen any good answers.
Qt won't adopt GTK+ because Qt developers are in love with the well-designed elegance/ease of development in the Qt toolkit, and they see all other toolkits as inferior from a development perspective (and I have to say they have a point).
Do you realise how bigoted that sounds? Can you really back it up with concrete API examples? Can you seriously defend that point of view?
FWIW, I work on Wine and have some experience with both Win32 and POSIX/Linux native APIs. I agree completely. DirectX 8/9 is actually pretty good. The rest of Win32, not so much. POSIX is rather spiffy.
There's one good thing about MS Windows GUI; it's very responsive. That's because everything uses the same widget set that is kept in memory with little extra overhead.
Bzzzt, wrong. Whether something is held in memory or not effects startup time more than responsiveness. The Win32 widget toolkit renders ridiculously fast because:
a) It's primitive and crude. For instance, it has NO layout management at all. Supporting internationalization is a pain in the arse. It uses UTF-16 rather than the somewhat more convenient (but more CPU intensive) UTF-8. Typically Windows desktops are not fully anti-aliased (yes yes, cleartype, not on by default) and when it is, Windows has better HW accel anyway.
b) Microsoft have a lot of people working on performance issues, and entire teams dedicated to optimization. We don't.
Only one GUI library would need to be loaded and everyone could use their favorite. It would certainly help for Windows ports as well. Thoughts?
No offence, but I think that's a bad idea. The thing to understand here is that wxWindows is a toolkit abstraction, and when you abstract things the differences between the underlying implementations are at the same time blurred but they also leak out. A wxWindows app doesn't feel integrated anywhere, and it struggles to hide the underlying differences between the real widget toolkits. Subtle details like focus semantics can break and cause wierd bugs in applications.
When you abstract something, you lose something. Unfortunately the quirks of history have meant we have lots of widget toolkits sitting on our desktop today. The real killer issues from this are integration, consistency and interoperability. Memory overhead is certainly not a big issue compared to these lot - I think you should perhaps do some profiling of applications and then you'd see that having 3/4 toolkits loaded at once is not the real problem, it's the performance quirks of those toolkits that are the issue.
Also note that/. is munging the code; it insists on inserting a "&nbs p;" that shouldn't be in there. I can't seem to get rid of it. Gotta love buggy software.
That's intentional, and is part of the anti-page-widening-post code. It prevents really long lines causing the page to overflow.
I've been wondering about menus in Linux/*BSD - not so much the format of menu storage, although that is an issue, but the applications themselves. We have a very large number of applications out there, but that is a problem for end users because installing them does not result in an update of the graphical menus by which they tend to access them. I think this is one of those little things that makes people think Linux isn't desktop ready.
The shared menu spec has been adopted by GNOME, KDE (in 3.2), XFCE and there are plugins for many other window managers/desktops. SuSE and Red Hat both use it.
Apps that don't register themselves with the current shared menu system are buggy, plain and simple. Yes, at the moment they may get away with this because KDE as shipping is behind, but when 3.2 is finally released that should become less of an issue over time.
You're right, the menus have been a total mess lately, but I think this is well on its way to being a solved problem.
I might also add that autopackage deals with this for the developer - we automatically register in every menu system we can find, though to be honest I might rip this code out at some point. By the time we go stable, the menu system should be working smoothly.
Slashdot Mirror
That's basically irrelevant - almost all the apps that I use on a day to day basis and actually matter to me are neither KDE nor GNOME, they are things like emacs, bash, irssi, gaim, firebird and so on.
The only non-desktop neutral app I use and would think twice about replacing is Evolution.
KDE has this problem where they spend all their time making shining pearls of API perfection, and then wonder why there are so few third party apps using them. The fact is that dragging in the KDE or GNOME frameworks does carry a cost for the users and typically the benefits of the additional functionality offered doesn't outweigh the cost.
The GNOME guys have the right idea imho - work on making a great desktop first, and let that drive the infrastructure, rather than the other way around. In time most of the real functionality should be pushed down into either the toolkit (GTK/Qt) or highly modular desktop neutral 3rd party libraries.
Um, you realise you can do this is Fedora Core 1 right? I have the applet right here - you could do it in red hat 9 too if you used the command line ;)
No, NSIS should work on an out-of-the-box wine install. I fixed the bug, no problems, it'll be applied to CVS after AJ gets back from vacation in Switzerland (~2 weeks).
http://bylands.dur.ac.uk/~mh/file.c.patch
Apply it in the root of the Wine source tree, like so:
patch -p0 </tmp/file.c.path
then do a make and make install in dlls/kernel. Run the installer - it should install fine apart from complaining about "Sonic Pro" or something.
Be warned. The "modern" skin does some funky stuff with window classes we don't yet support. Use the classic skin.
I'm going to take a look at the subclassing stuff now. As an aside, the NSIS code is awful. Great product, nasty as hell code :/
FWIW I can't get WinAmp installing on a clean CVS build and setup - it looks like we have a regression in NSIS :(
It seems at least to me that the freedesktop.org x server (kdrive) is where the interesting stuff is happening, but we'll see how the Xouvert guys get on.
I mean, there are lots of programs on Windows that don't pay any attention to your default requested browser and always open IE. What exactly is your point?
That's a very rare thing in corporates. I really hope that as Red Hat expands, they keep it up. So far they have, and even with the new splits between their community work and enterprise stuff, I feel pretty confident they won't slip.
I wish all companies were like this. It's too easy for them to slip behind the mask of anonymity.
Despite the high level of interest in the projects success very few people are willing/able to setup zillions of test partitions and then take a low-level hex editor to them when it goes wrong.
This is an interesting hack for sure, but long term there's no reason why we can't have native write support. We know how, it's just a case of doing it.
Careful. They use the same theme, but so does GTK+ on Win32. The widgets are still different. The Qt widgets are deliberately designed to be close to the Windows native widgets but they are not the same, and there are plenty of subtle differences that you'd only notice if you worked with it day in and day out.
The combo box has been rewritten for GTK 2.4, which should be coming out in a few minutes.
I can't comment on the entry box.
The documentation is still weak in places, I agree. It is however a lot better than it once was, and no new APIs are added without proper documentation to back them up.
It's the principle that worries most outfits. Sure, $2000 for a widget toolkit perhaps isn't much on its own, but now assume you're paying for the OS, the compiler, the IDE ... it all adds up. Just imagine if there was not one but many libraries that followed this policy - quickly the cost of support code and tools would cause serious problems.
Furthermore, Qt is such an easy-to-use, high quality toolkit compared with anything GNOME has to offer that you are bound to be ahead on the development costs in time savings alone.
This is a fairly common troll, yet it's never been adequately backed up as far as I know. In fact I know a few developers who have used both GTK and Qt enough to know the differences, and don't think Qt is all it's hyped up to be (for instance, the qpe-gaim developer). The Qt API contains its fair share of wierdness, for instance, why does QVBox inherit from QHBox? Where is the equivalent to gdk-pixbuf?
Qt also works on the Mac and Windows - GNOME toolkits don't - this is very important for most commercial developers.
Qt works on Mac and Windows if you pay the fees, which are hefty. The problem is, so does GTK+ - there is a port which tracks the native XP theme in use, and as MacOS X has X11 support built in, they work there too. In most commercial developments cross platform portability is sadly not a concern anyway.
The Mozilla project don't want to build SVG by default because it's not a full implementation of any current spec. It's missing a lot of features. They have been burned before by half supporting standards, and it's generally agreed that it's a bad thing. Either you support it, or you don't. You can't just support the easy bits, or the bits that sounded coolest.
While the KSVG team have been storming and may well have a full implementation, the same is not true of the Gecko implementation. If people cared enough about it, they'd work on Geckos version, but it seems they don't.
Perhaps. It'd certainly be worth doing. I'm far from an advanced C++ coder but last time I looked the GTKmm APIs were pretty good, using the STL throughout (except for strings, because std::string isn't utf-8 or something like that). GTKmm has two sets of APIs that have been optimized, the c++ binding and the underlying generic API, it'd be interesting to analyse the effects of having two teams do that.
In other words, apples and oranges.
Fascinating....
Basically:
* OpenOffice really (ab)uses shared libraries heavily. It has over a hundred of them, all internal. Worse they are all C++ so there are lots of symbols. On a typical OpenOffice Writer startup, over 1.7 million string comparisons are performed in the dynamic linker alone.
* MS Word has been heavily optimized so that the minimum number of page faults necessary are used to get the user to the first screen. This involves some clever analysis tools, support from the toolchain etc - MS Visual C++ produces very compact and tight code, so fewer disk accesses are needed for the same amount of code. Modern application startup time is mostly a matter of disk IO once other factors (such as synchronous waits on servers starting up) have been removed.
* OpenOffice drags in an entire framework and object model, whereas MS Office reuses at least COM and the registry (though not the widget toolkit to some extent). Dragging the entire VCL and SAL into memory takes time.
* Microsofts employees have the issues related to startup time drummed into them, free software developers do not. They understand techniques like rearranging the layout of your code so commonly used objects and functions are grouped together, how to optimize the CPU working set and so on.
For OpenOffice the biggest issue is still fixup time. Red Hat and Ximian are looking into that, there are techniques you can use (symbol hiding in particular) that can speed up the time taken to load large C++ shared libraries like that. Prelink will also help.
Of course some whitespace would have been handy there.
import gtkhtml
browser = GtkHtml
As to Mozilla/Gecko, I'm not sure but I know there is a GtkMozEmbed and I doubt the API is significantly different to GtkHtml.
Comparing LOC by the way is normally a silly way to measure "elegance". And I asked you to compare Qt and GTK+, not the entire KDE framework. You were talking about Qt, so talk about it now.
No, that's wrong. I've already posted analyses of why Word starts so much faster than OpenOffice, use Google power. If people want I can do so again, but Word is not preloaded. End of story.
If I run KWord from Gnome, it takes about over 10 seconds for the KDE backend theme/DB libraries and QT toolkit libraries to load and all the widgets to be arranged properly
This is entirely a problem with KDE (and yes, Gnome is bad too). If KDE didn't insist on loading arts, dcop, and a zillion C++ shared libraries on the startup of every app then KDE apps would not take ages to load. Somebody could sit down and profile and optimize and sort it out, but nobody does - why? I don't know. Maybe people rarely use KDE apps outside of the KDE environment so there's no incentive to do so.
Basically it's possible to make startup time really good, and it's not necessary to abstract an entire platform in order to do so.
The bottom line is that Linux on the desktop won't be embraced until it's more responsive.
Modern desktops are pretty responsive, even more so with the 2.6 kernel. There can always be improvements of course, but to claim this is a huge issue is misleading IMHO. Maybe QT is the way to go (even though it's currently both slow AND ugly) because of better API design and we should port Gnome to it somehow.
What part of its API is better designed? I get tired of people claiming this like it's just obvious - so far when called on it, I haven't seen any good answers.
Do you realise how bigoted that sounds? Can you really back it up with concrete API examples? Can you seriously defend that point of view?
FWIW, I work on Wine and have some experience with both Win32 and POSIX/Linux native APIs. I agree completely. DirectX 8/9 is actually pretty good. The rest of Win32, not so much. POSIX is rather spiffy.
Bzzzt, wrong. Whether something is held in memory or not effects startup time more than responsiveness. The Win32 widget toolkit renders ridiculously fast because:
a) It's primitive and crude. For instance, it has NO layout management at all. Supporting internationalization is a pain in the arse. It uses UTF-16 rather than the somewhat more convenient (but more CPU intensive) UTF-8. Typically Windows desktops are not fully anti-aliased (yes yes, cleartype, not on by default) and when it is, Windows has better HW accel anyway.
b) Microsoft have a lot of people working on performance issues, and entire teams dedicated to optimization. We don't.
Only one GUI library would need to be loaded and everyone could use their favorite. It would certainly help for Windows ports as well. Thoughts?
No offence, but I think that's a bad idea. The thing to understand here is that wxWindows is a toolkit abstraction, and when you abstract things the differences between the underlying implementations are at the same time blurred but they also leak out. A wxWindows app doesn't feel integrated anywhere, and it struggles to hide the underlying differences between the real widget toolkits. Subtle details like focus semantics can break and cause wierd bugs in applications.
When you abstract something, you lose something. Unfortunately the quirks of history have meant we have lots of widget toolkits sitting on our desktop today. The real killer issues from this are integration, consistency and interoperability. Memory overhead is certainly not a big issue compared to these lot - I think you should perhaps do some profiling of applications and then you'd see that having 3/4 toolkits loaded at once is not the real problem, it's the performance quirks of those toolkits that are the issue.
That's intentional, and is part of the anti-page-widening-post code. It prevents really long lines causing the page to overflow.
The shared menu spec has been adopted by GNOME, KDE (in 3.2), XFCE and there are plugins for many other window managers/desktops. SuSE and Red Hat both use it.
Apps that don't register themselves with the current shared menu system are buggy, plain and simple. Yes, at the moment they may get away with this because KDE as shipping is behind, but when 3.2 is finally released that should become less of an issue over time.
You're right, the menus have been a total mess lately, but I think this is well on its way to being a solved problem.
I might also add that autopackage deals with this for the developer - we automatically register in every menu system we can find, though to be honest I might rip this code out at some point. By the time we go stable, the menu system should be working smoothly.