Slashdot Mirror
Interview: KDE League Chairman Andreas Pour
Frank writes "Here's a good interview with KDE League chairman Andreas Pour. He talks about the K desktop environment (KDE) 2.1, that will be Hitting the streets on Monday, February 26. He reveals info about some significant advantages over the old 1.0 platform, including a full-fledged browser and the upcoming KOffice suite of business applications."
Interesting.
I've always found KDE for 'weenies', those that really do not want to interface with UNIX the way it was meant: through a command-line interface or via a windowmanager like twm, fvwm or a light modern one like afterstep.
KDE with it's Windows look-alikeness is therefore the solution for those who do not want to bother with 'arcane' CLI's and windowmanagers.
But then, when I was at the OSDEM in Bruxelles quite a lot of 'smart' developers were using KDE, to my surprise. This made me think about it again and I'm now considering installing 2.x just to try it.
--Rogier
So what if the browser is integrated with a desktop environment? The issue with MS was that it was integrated with the operating system. There is a big difference.
-- Thrakkerzog
He reveals info about some significant advantages over the old 1.0 platform
Of course, it wouldn't be as good PR to talk about the significant advantages over the old 2.0 platform, like stability. My best explanation for KDE 2.0 was that it was an olive branch after all the insults Gnome developers took over their "1.0" misrelease. I managed to get konqueror to crash within a minute of using it. I tried both compiling from scratch and prebuilt binaries before giving up. To be fair, I didn't try the 2.0.1 release or whatever came next; the bugs I saw may have been pounced on more quickly than I'm giving them credit for.
Most of the problems seem to be gone now; in the 2.1 beta that comes with Red Hat fisher (yes! beta software squared!) I couldn't make any of the main components crash, and even koffice took some time and work to bring down. I hope the RH7.1 final is delayed long enough to slip KDE 2.1 final in; it's really worth a look now.
If you want to work on this, I'm sure no one will object.
.desktop file standard (although gnome can not handle UTF8 in them.. =/), xdnd, and a common window manager specification.
They have already done quite a bit in terms of unification, though. They have a common
What sorts of bridges do you want? Where exactly is the incompatability between the two? With kde's xparts, you should be able to run gnome applets in kicker (the kde panel). It would take a bit of coding, but it could be done.
Anyway, I don't really see too much of an incompatability with the way things are done now. If the two projects were to merge, there would be less progress than there is now.
I don't know about the rest of you, but kde 2.1 doesn't feel at all beta-ish to me. If you get random crashes for no reason, you probably have bad binaries from a poorly packaged rpm. (or deb) I've been compiling kde from source for a long time now, and have hardly any problems with things crashing. It is very stable now.
-- Thrakkerzog
At present KDE and Gnome both have a somewhat beta-ish feel to them, but this would quickly disappear if there was only one desktop environment.
I think experience has shown that, for better or worse, throwing more resources (people etc.) at a project doesn't necessarily solve its problems. Same here. I also had the opinion that two huge projects both pursuing the same goals would be a waste, but I think that the "competition" has helped increase the quality of both Gnome and KDE. They make sure that certain features are available, because the others have them already. They study each other's code to improve their own (not everybody, but some). Variety _is_ good!
I'm not enough into this to know whether the efforts to make both projects more compatible to each other, share certain file formats / configurations etc. really worked out. That would be a step into the right direction.
However, whether a single desktop environment would be good or not, I think there's not a chance in hell that one of the groups will drop development to join the other.
I love the new shell plugin idea. Konqueror has been top-notch stuff, and adding the ability to conveniently execute shell programs and capture them to a terminal just rocks.
I've been using the embedded terminal feature to do this in KDE 2, and having a way to do it without needing to pop open a shell in advance is just nifty. I bit of configuration lets me set up development directories that are extremely convenient to use.
I've been hearing this fiction that KDE is not for serious Unix users, but this is just bull IMHO. Konqueror is easily the most productive programming environment I've ever worked with.
You state your performance with KDE is poor on a 466 Mhz Celeron w/ 64 MB ram.
...
I recommend you upgrade to 128 MB RAM, which is really the standard nowadays and is essential with the nature of UNIX desktop environments -- they require a lot of libraries to be loaded
mwtr / THIS SIG HAS BEEN PRAYED OVER AND MAY BE USED AS A POINT OF CONTACT (ACTS 19:12)
Would merging the two be the most effective cure for the "beta-ish feel"? Realistically, the developers would let their egos get in the way and have this second-circuit battle deciding which incumbent desktop gets to dominate the merge. Diversity is a good thing with desktops. Eventually, one will dominate. Perhaps they will become even more disparate.
Manufacturers of non-clunky desktops have cognitive psychologists, physiologists, and experts in other interface-related fields at their disposal. As the open source movement gathers more momentum, it will have such resources working in symphony. Patience for now--We're living in what the historians will refer to as the end times of closed source dominance.
One of the most popular habits of /. flamers is arguing over KDE/Gnome, vi/emacs, etc... It's amusing, but they have totally missed the point. The best we can ask for in the KDE/Gnome issue is mutual bindings.
If you love God, burn a church!
Ewige Blumenkraft!
Oh no! Background processes. They only reason you're not using KDE is because of background processes and themes (who says Linux users aren't as style obsessed as the rest of us?) Right now, with no programs running, I've got 17 processes running on BeOS, some with over half a dozen threads. Having background processes really doesn't have any relation to system performance, particularly in the case of Linux, where context switching is very fast.
A deep unwavering belief is a sure sign you're missing something...
Does anyone have a way to test this? (Be sure to check that Konqueror *isn't* preloaded by KDE already.)
It isn't going to happen - not for a long time anyway. Both KDE and GNOME are still developing their infrastructures and investing massive resources into their own respective projects. The thought that one project would abandon their work and merge with the other is extremely unlikely, especially considering the past animosity and considerable egos that some nameless core developers have (I won't say which project - I'm no troll).
.NET working with the Linux desktop.
I wouldn't expect to see anything significant until KDE 4.0 / GNOME 3.0. Then we should see two mature component models, a large number of applications that make use of it's respective desktops features and things will have probably settled down a bit. At that point, it might be possible to see some sort of bridge developed between the environments at the object level.
One day we might have a desktop that integrates Mozilla XPCOM, KDE Kparts, GNOME Bonobo, OpenOffice UNO (yeah, I know about the port to Bonobo) and possibly even COM/ActiveX via WINE. Who knows, maybe some people will get
There is obviously a lot of talk here about merging KDE and GNOME. That is not a good idea. There is also a lot of talk to keeping things like it is. Also, not a good idea. The only real way to solve this issue is create a standard desktop API that KDE or GNOME backends can plug in to. I've already espoused the idea dozens of times, and if you want details, look at my back-posts, especially the recent Art of UNIX Programming Thread. If there was an ABI that apps had to follow, then we could open the desktop environment to competition in quality, stability, etc, while still having a consistant desktop, and without fragmenting the application base.
A deep unwavering belief is a sure sign you're missing something...
[...] it is in the interests [...] of Linux as a whole.
In this context, `Linux as a whole' sounds distinctly silly. You remind me of people living in Amsterdam or in Paris who tend to forget that there's more than one city in their country. What you seem to forget here is that Gnome and KDE are not desktops specifically for Linux. To illustrate: I have used both KDE and Gnome, but neither on Linux.
Also (but this has been brought up by other people as well): what on earth is wrong with having more than one desktop to choose from? The same is true for any other piece of software.
The same argument as you're using has been used over the last few years to justify the Windows monopoly. Windows, it's argued, brings much needed compatability, and therefore forcing people to buy computers with Windows is a good thing. After all, all that having multiple operating systems would do would be to generate incompatable platforms all trying to do the "same thing".
I can't agree with that argument. Ten years ago I remember a software industry that was vibrant with innovation, where multiple software houses produced outstanding software on a range of different platforms. We had choice, and even those who selected obscurer computer platforms had a range of tools available to them of decent quality. I remember the days when the adverts in most computer magazines were 70-80% software.
That seemed to stop when people stopped caring about choices. When Windows 95 became dominant, and PC choices from OS/2 to the various Digital Research OS's were dropped from the market. It became rare to find any PC with anything other than Windows, Office, and the occasional shareware utility like WinZip installed on it. Games were perhaps the only honorable exception. And that was the PC industry. Amiga (still my favourate platform) disappeared, Atari faded, first by becoming a games console only company, then by fucking it up. NeXT, well, NeXT screwed up from the start, but it was at least another direction.
You may feel that we're better off having the entire might of the programmers of the world focussing on two or three platforms today, but I kind of feel like I can't find anything I want to use these days. I don't like the way Windows 9X feels, or its design. NT might be better but is overly bloated. Unix has some wonderful ideas, and right now my home is a Linux/OpenBSD only shop, but I'd hesitate to suggest the OS family is close to how I want to work. And while technically there are other PC OS's out there, like QNX, BeOS, and OS/2, none appear to have any momentum. Right now they may as well not exist, thanks to the industry consensus that competition is a bad thing.
*ix, be it BSD, Linux, or whatever, is the closest thing we have at the moment to a platform on which to build new environments to provide choice for users. GNOME and KDE deserve to both exist, both succeed, and both remain independent, for the sake of their users and for the sake of continuing that policy of choice. It would be really nice to see that attitude at some other levels of the OS as well, such as creating a credible alternative to X, but it's great that we have that choice. I don't want to see people reducing them.
Even if shortterm, merging may bring benefits to the quality and completeness of KDE and GNOME might improve more quickly, a single desktop standard will be the death of choice in user environments. We've seen how difficult it is to get a "new" operating system accepted in an environment in which the industry has settled on one standard. If we lose choices at other levels of the system, we may never get them back.
--
You are not alone. This is not normal. None of this is normal.
Windows (95 and 98) require less resources than Konqueror. Period. Windows 95 and 98 also came out 6 and 3 years ago respectively, so this can be taken with a grain of salt.
I have 256 MB of RAM for my Win2000/Linux "box" (actually, it's a laptop) because I'm preparing for the future. RAM is cheap right now. Not everyone has this option though.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Consider your history. Why are there now two desktop environments for Linux? Well, we have reached this state because of liscensing issues. The Gnome project formed purely because people were unhappy with the KDE qt liscense.
The origin of the projects is no longer important. So if MIT suddenly is given the source code for all the printer drivers in use on their campus, should RMS give up the Free Software Foundation? (click here if that didn't make sense to you)
Why continue to divide out labor on two projects which both hope to achieve the same thing?
Because they plan to do this in completely different ways, also once they are mature the differences willbeself evident.
Imagine how much more polished the Linux desktop environment would be if all effort were focused on just one. Twice as much effort would be expended on it every day.
Anyone who has read Frederick Brooke's Mythical Man Month knows that your statements are a big misconception. Doubling the number of developers on a project does not double the amount of time taken to finish the project because new developers have to be brought up to speed and the layers of communication increase which leads to more errorsoccuring due to miscommunication. Basically there is a certain level of complexity where throwing more developers at a product produces little net gain. KDE and GNOME are at that level of complexity.
KDE is mainly C++, GNOME is mainly C (if you do not realize there is a fundamental difference in these languages then go to comp.lang.c or comp.lang.c++ and state this and see the responses you'll get). GNOME uses all sorts of CORBA stuff while KDE does not. GNOME uses OrBit while the few KDE developers who know CORBA used Mico. Both projects are extremely undocumented and very few, if any, have a complete grasp of the entire system in either case.
Quite frankly,if KDE and GNOME merged the efforts involved in adjusting to the merger would slow down development a lot more than any perceived current lack of developers does. In addition, some functionality that was a part of one or the other system would be lost (because stuff always gets trimmed in a merger).
A better suggestion is for KDE and GNOME to start actively pursing interoperability. Unfortunately this is one place were Open Source may fail. It is unlikely that GNOME interoperability is high on the list of any KDE developer's list of itches he/she wants scratched and vice versa. Thus since they are all simply volunteers they can't be made to do it like would happen in a professional development environment, where a manager can just assign a bunch of coders this task.
Finagle's First Law
The biggest memory-sucker in KDE is a misconfigured QT. Many distros compile QT with exceptions enabled, which almost doubles the size of the library. To fix this, get the latest QT from TrollTech and use "-no-g++-exceptions" to the ./configure command. Then run "make symlinks sub-src sub-tools" to compile the stuff that you need and not the examples or tutorials you don't need. The file libqt.so.2.2.4 should be around 5.5 MB. Adjust the symlinks to point to the new QT and start KDE. I personally find KDE nice and zippy.
Another thing that might get in the way is if debug code has been compiled into KDE, and that can only be fixed by recompiling the whole shebang, adding "--disable-debug" to the ./configure command.
Sure, let's add _yet_ another layer. No wait, let's not...
Abstractions of abstractions does not solve problems. I don't know why people are so easily talked into thinking this is a good idea. That would be XML all over again, like, "let's define a wrapper that everyone uses, but let's not consider that everyone still needs to agree on what we're actually sending thru the wrapper"
A common API on which KDE and GNOME could be developed is *already* there - it's X11R6 and POSIX. That's why you can start up GNOME *and* KDE on the same machine - clever, eh ?
I don't know why you mention an ABI, maybe it's a typo and you meant to say API ? The ABI is standard already, and it would be a damn hard thing to re-define, and as I see it wouldn't make much sense to do either..
It seems that their corparate ties with Ximian, Eazel and Sun are causing real trouble. Apparently they have lost nearly all of their voluntary work force after the GNOME Foundation was announced. Couple of quotes I saw in gnome-hackers list. These are core developers, not some random guys:
Alan Cox:
"...there are not enough people working on gnome infrastructure/site admin to keep up with the demands of these because most folks are busy working on their rival Ximian or Eazel projects and so the number of effective actual gnome core contributions has dropped massively rather than risen as might originally have been expected."
link
Matthias Warkus:
"Looking at the CVS logs, no one seems to be really working on the core anymore. Pretty much all of the code commits go into Nautilus, Gnumeric, Evolution and Eazel's and Ximian's supporting and surrounding technology and tools.
I think we're at the point where we should ask ourselves whether the GNOME Project can still be considered a living entity at all. And whether it's a good move to, at this point, tie our next release to Nautilus, which, however cool, is essentially a third-party product with the main purpose of generating revenue for Eazel. If we go on "outsourcing" software that way, we might end up with a "GNOME desktop" which is not much more than lots of commercial free software bundled together haphazardly."
link
Is their situation really this bad?
I think he is talking about a layer underneath the toolkit and DE environments where code could be shared. You know, compartmentalized, modularized tools done in the Unix way instead of a multitide of huge monolithic incompatible systems that you need to keep around to run all of your apps.
Your attitude is sort of disturbing: "AT&T and The Open Group has bequethed to us POSIX and X11, and that is where the standard environment ends, now and forever, so sayth the lord". Well, this ignores the fact that commercial UNIX was a profound failure on the desktop, and the commercial UNIX players that devised this whole mess no longer have much interest in desktop computing at all.
The future of desktop UNIX computing is now in the hands of Open Source projects, and they need to either work around the problems and legacy issues with the ancient 'standard environment' (particularly the gap between X11 services and DE services), or they need to move forward with defining an architecture that can maximize the utility of the system for the next 20 years.
(Not to mention that your XML comment is entirely offbase.)
When I hear the word 'innovation', I reach for my pistol.
It is how X11 is defined. That's why I can use standard X apps with AcceleratedX or XFree without recompiling. If a standard API for the desktop environment was established (maybe pushed into X, maybe not. God knows that the XFree people have more clout than any of the commercial UNIX corps) then you could have all of the implementations and window managers and whatnot, without the incompatibiliy. Before GNOME and KDE, none of my apps cared what window manager I used. Starting with Enlightenment, apps started using DE-specific features, and the freedom to choose your environment went away.
A deep unwavering belief is a sure sign you're missing something...
Right, I'm bitter. That's why I think that Gentoo Linux is the coolest thing since sliced bread, and that XFS is the creation of god. Get over it. I love BeOS, but Linux has so much potential, its just politics and small minds that's holding it back.
A deep unwavering belief is a sure sign you're missing something...
What are you talking about?
A) It's BeOS, not BEOS.
B) Win*dows* is multi-tasking and has better threading than Linux. Next question.
C) BeOS has better use of threads and multiple processes than Linux as well.
D) I have no clue what your point is. I said that background processes providing services don't necessarily degrade system performance. You just used it as an excuse to trash Windows and spread misinformation about BeOS.
E) Do you know that your login-name is the same as the guy who wrote the famous Windows Programming Book (C. Petzold)
A deep unwavering belief is a sure sign you're missing something...
Its all subjective. Does an OS automatically become trash to you the first time you see the cursor jerk during a CPU intensive processes? I want to start and app and have it on my screen *now* no loading cursor, no nothing. KDE2 doesn't do that for me. While X overall is pretty slow, its not THAT slow.
A deep unwavering belief is a sure sign you're missing something...
For instance, take Gnumeric: the best free spreadsheet available, the one with the most confortable user interface, pleasant to use and only surpased in functionality (but not in usability) by OpenOffice. Guess what? Gnumeric is fully written in Gtk+.
Evolution is another good example: it has a great user interface, but some bits of usability are still not there, and we are working actively to do user testing to make sure we provide a better interface, but this has nothing to do with the underlying technologies (as you like to convenientnly present in your interview). It has to do with matching the "User view" with the application, rather than forcing the application model into users.
OpenParts (KDE's CORBA-based component architecture) failed for a number of things, few of which could be traced to CORBA, I will enumerate the ones i remember, for the sake of completeness:
try {
corba_object->method (x);
} catch (...) {
handle corba errors here;
}
Was actually written like this: corba_object->method (x); Of course you get "unreliable" code if you do not handle errors. (btw, notice that most security holes on BugTraq a few years ago were all caused because people did not handle boundary conditions correctly, nor handle errors from Unix system calls correctly.
Pentium II 350, 64MB RAM, KDE 2.1 CVS from 3 days ago..
time konqueror:
real 0m1.898s
user 0m1.360s
sys 0m0.030s
Well, I consider it pretty fast thank you
Hetz (Heunique)
Although I'm not a KDE developers, but at work we have a guy who is running KDE 2.1 on an old Toshiba Notebook - Pentium MMX 233 with 64MB RAM, and it runs pretty fast on it. Heck, he browses while he is compiling the other packages (kdemultimedia, kdenetwork etc)...
Hetz (Heunique)
Good interview - short and to the point, easy to read in 10 minutes.
Anyway, here's my $0.10:
Andreas Pour has got a good point about the development tools for KDE versus those available for GNOME. Have you guys seen KDevelop? As someone who actually develops GNOME programs, i can tell you that KDevelop does look about 10 times better than GEdit - built in dialog construction tools (a la GLADE), a quick start (read: RAD) wizard, and more!
Shit, i'd kill for this tool in GNOME/GTK...
Moderators need an additional choice: "Karma Whore" for people who cut-and-paste articles as their comments!
If you are, good for you, but if not ... If everyone on slashdot who insists on posting "Linux needs such-and-such" would actually start coding (or doing whatever else their skills permit), we'd have all the problems ironed out in no time.
It seems to me that people who spend their time whining about open-source projects are missing the point. The programmers wrote this for themselves (in some manner, whether it's that they want the functionality, or just the prestige.) If you like what they've done, you're welcome to it, but if not, you're the one that should be doing the work.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
There are several reasons for this speed difference. First Windows Explorer doesn't do a tenth of the stuff that Konqueror does. Combine Windows Explorer, Internet Explorer, make sure none of it is in kernel space and not already running in the background somewhere, give it an advanced widget library, and then see. I bet that Konqueror would kick Windows butt all day long.
A Government Is a Body of People, Usually Notably Ungoverned
If you're using binary packages from your distribution, most likely you are getting the lowest common denominator optimization. In other words, nothing.
Recompile X, Qt and KDE optimized for your system. I use "-O2 -mpentium" for all of them, and --no-g++exceptions when configuring Qt. The speed improvements are amazing!
A Government Is a Body of People, Usually Notably Ungoverned
I've been using KDE 2.01 (XF86 4.0.2) combined with kernel 2.4.1 for about a week now, and the combination far surpasses anything I've experienced on Windows or Mac. Its fast and stable (I compiled everything from source...those of you compiling QT 2.2.4, try
I'm really excited about where this project is headed. In my mind, the Windows 'standard' has already been surpassed.
Click here for a DVD on Linux HOWTO
--------------
Is this rock and roll, or a form of state control?
Even if it was integrated into the kernel, so what? I'm sure I'll be labeled as a heretic (what else is new), but the DOJ's emphasis on integrating IExplorer into Windows was absolutely stupid. They could integrate MSOffice right into Windows kernel space and I wouldn't care.
Microsoft's business practices are the problem, not their technology, and especially not their sophmoric attempts to improve it.
A Government Is a Body of People, Usually Notably Ungoverned
How said BeOS is better than Linux? I said "BeOS does threading better than Linux." If you've ever seen BeOS on an 8 proc machine, that's just plain true. BeOS also has quicker system response times, a faster graphics interface, a nicer, more consistant API, and innovative features up the wazoo (attributes, messaging, etc). Still, Linux has better (if not faster ;) desktop environments, a better filesytem (XFS: like BFS, but bigger and faster!), less limitation in the kernel (32MB add-on limit in BeOS, 256MB library limit), better networking, and just plain more *stuff* (features and programs).
A deep unwavering belief is a sure sign you're missing something...
However, if these two projects were merged it would not work. They have many fundamental differences, differences that would nearly require one project to be completely dumped. We all agree that this would not be a good thing.
I am a KDE user, and I am damn proud of it, but many of my friends use gnome, which is thier preference (its too slow for me).
The competition between the two projects has had an effect on each of them, encouraging adoptation of similar ideas, and generation of new ideas, ideas which might not have made it into the source code otherwise.
The competition between kde and gnome is a good thing, even if both groups didn't care about the existence of each other, it is nice to have more than one option.
Those of you calling for a merging of kde and gnome, think about this, what if we merged the linux kernel and a bsd kernel. It probally wouldn't work for a few years. Think about it.
Spring is here. Don't believe me, look outside!
I don't like Ford cars. I don't like General Moters cars. I like Jaguars. Does this mean we should have totally seperate road systems for each type of car? Competing implementations + open, FORCED, standards (kinda like the road system?) is the best way to do things.
A deep unwavering belief is a sure sign you're missing something...
I'm not the original poster, but I want compatibility as in I can erase GTK and GNOME-libs and still use GIMP.
A deep unwavering belief is a sure sign you're missing something...
Ah, but all programs run on all shells. Using csh doesn't preclude me from running XFree86. Using KDE (and ONLY KDE) precludes me from running GIMP.
A deep unwavering belief is a sure sign you're missing something...
Ensure that the kernel was compiled for i686.
Use hdparm to make your hard drive load faster. This is one of the most common problems. hdparm -d 1 turns on dma which is the most important. also fool with the -m parameter. so man hdparm for details
64 megs of ram isn't that wonderful for KDE or GNOME, but i suppose there isn't much to do about that...
"Recursive bipartite matching"- try it!
I do have to install the relevent libraries, but that's not the same as having to install (let alone run) the whole of Gnome.
X is API neutral. They even have the OpenStep API (both Sun/NeXT implementations and GNUstep) running on the damn thing, and that wasn't ever intended for X. Gnome apps can run under KDE and vice versa. The only unfortunate part is that you need to install the API libraries for the other system.
While there's a slight bloat consequence, we're talking 10-20 megs of disk space per system here, for systems that are each too slow and too memory intensive for you to want to run either on a system where 10-20 megs would be a major concern.
--
You are not alone. This is not normal. None of this is normal.
Tell me: what extra functionality do I get when I use Gnome instead of editing files by hand? Mostly I can fetch a certain option faster in a config file than clicking through loads of windows?
You state that the "standard nowadays" requires 128Meg. I think you're wrong.
I'm completely productive, producing my documents in LaTeX or just plain text, editing files with Vim (which has neat syntax highlighting and loads of usefull features), and using Windowmaker as my windowmanager (which works perfectly, can't see any usefull improvements which could make it better).
With all respect, I've been through a lot of horror learning all these tools, but I just know I work a lot more effective using only these tools.
I was wondering: where is the UNIX spirit? You say UNIX desktop environment, but I can't see a use in going for them. And yes: the only thing I needed GNOME for was a divx player (which for some strange reason needed the GNOME libraries, while it would be much more effective when ran with GTK libraries).
I'm using this configuration as my *primary* configuration for around one year (sometimes switched windowmanager, but never to KDE or GNOME).
My daily stuff: mutt for mail, tin for news, ircii for irc, vim for editing, LaTeX for document processing, Gimp for editing, Blender for 3D content, Netscape (bloat) for websites, Windowmaker for keeping my windows apart, mpg123 for some music, apache for hosting our website and this all on 64 MB ram. Ah, did I mention Sendmail?
Are these programs impossible to learn? IMHO, no. It just takes some time, and some programs have quite a high learning curve, but they can be learned. And it's really IMVHO that these tools are more flexible and productive than any KDE or GNOME app I've seen around.
This is my bit of view on this subject, feel free to argue.
This is a replacement signature.
I'm using the RH6.2 binary packages for KDE 2.1beta2 and have experienced the same problems throughout my the kde2 releases. Very likely much of the core components were compiled without sufficient optimization but that can't really explain all of it. I noticed that URL type autodetection appears to be obscenely slow, specifying "kfmclient openURL http://slashdot.org text/html" appears to be faster.
-- Remember: Wherever you go, there you are!
Actually, I think Mozilla's performance is more related to the fact that the browser is actually written in JavaScript. Also, the scope of Mozilla is much, much bigger than Konquerer. Mozilla is its own XML-based development environment. It has its own object model, it's own widget set, etc. Whether this is a good idea or not, I don't know, but that is more of the cause of these problems than language choice. Also, the fact that Mozilla is extremely cross-platform, including its own portability library makes the fact that they've done so much in so little time, absolutely amazing.
Engineering and the Ultimate
I want to erase GTK as well. I want to have a 100% KDE-only system. How can I do that?
A deep unwavering belief is a sure sign you're missing something...
I would complain. Apps shouldn't require a particular toolkit, but should require the services of that toolkit to be available. On Windows, no app depends on having MS-OpenGL available, but having SOME OpenGL implementation available. Qt provides all the services available in GTK+, so GIMP should work transparently on Qt. Whoa, what a concept! Too bad whoever made shared libraries thought it up first...
A deep unwavering belief is a sure sign you're missing something...
It's not the 10-20MB of diskspace that bothers me, its the 10-20MB of memory. All together, a fully loaded system takes up 30+MB (KDE-1, KDE-2, GNOME, and soon GNOME-2!) Even on a 128MB system, that's just too damn much for the OS to use up. The OS shouldn't use anything more than 10% of avaiable memory, after that its just sick. Not to mention the fact that while GNOME apps run on KDE, you don't get the full experience provided by a "desktop environment." While hacks to load KDE components on GNOME or run GNOME applets in KDE are available, they're just hacks, nothing more.
A deep unwavering belief is a sure sign you're missing something...
I was using the Mandrake packages. Plus, why do binaries all optimize for 386, with some exceptions optimized for Pentium? Given that everybody has at least a Pentium-class chip (and P6 chips have been around for five years) shouldn't -mpentiumpro be the standard optimization, with some special distros cataring to the 386 crowd? What moron runs KDE2 on a 486 anyway? Thankfully, distros like Gentoo exist (yea, my obsession of the day ;) that (will) optimize for Pentium Pro. Check them out at this site
A deep unwavering belief is a sure sign you're missing something...
The qt distribution is 506408 lines of c++. The core library is 351371 lines (Qt 2.2.3). You're off by a factor of 25.
Just to compare: kdelibs + kdebase is 593924 lines of code. (week old cvs cnapshot). Qt is a fairly large library. Good thing it's welldesigned.
Sheez. You clearly do not know what you're talking about.
-henrik
I used to run a system with 64MB using Windowmaker capable of all those tasks. I was even using GNOME for awhile on the same system and didn't encounter many memory related problems, except Netscape would occasionally memory-leak (which plagues my current 128 mb system all the same.)
If you can get by with your current setup, fine. I certainly wasn't saying and/or implying it's essential to run something like KDE or GNOME. Also, I agree there are not many useful apps specific to KDE or GNOME, Konquerer being the obvious exception. I do think, though, that people should try to be realistic. No one working with KDE code *can* make much of a change in the memory requirements. It's just the nature of KDE. There is a lot of overhead.
128MB is pretty standard, anyway, and with memory prices what they are I don't think my suggestion was in anyway outrageous even with regards to the most conservative of spender.
mwtr / THIS SIG HAS BEEN PRAYED OVER AND MAY BE USED AS A POINT OF CONTACT (ACTS 19:12)
I really want to know something. How are you posting at +2. I read /. @ +2 and I keep seeing you drivel all the time. I thought the mod system was meant to prevent this... Quit posting 20 times to a thread @ +2 when you have nothing useful to say.
A journey of a thousand miles starts with a brutal anal raping at airport security
See, I don't know. I tried KDE 2.01 and I went back to GNOME. Why? KDE does not look and feel as good.
The following points are only my observations and may only apply to me.
1. All of its default icons are too big. We need *SPACE* between icons. The GNOME ones look right for me.
2. Icons again. They look like they're created using 16 colours and they look too "hard" with all the hard borders and clear-cut colours. I'd like them with soft edges and a slight soften filter applied all over the icons. They're just easier on my eyes.
3. The menu bar. Those menu buttons are too close together. Compare the menu bars on QT apps with those on Motif and GTK+ apps and you'll know what I mean.
4. There are no real way to disable the maximize-minimize animations, which really suck - no, making them really fast doesn't count.
5. Can I be given a windows manager which is more flexible and scriptable, like Sawmill? I do not like being given a set of fixed functionalities. I sometimes make my own to suit my needs. Does the wm in KDE 2 have a window matching feature? Maybe it's just me but I couldn't find anything like it.
I'll use a desktop with more competent artists. GNOME is currently it.
You saw through me 100% it was just an attempt at flaimbait, it wasn't an effort to point something out that had not been mentioned. I didn't realise Ximian is a charity, I hope I haven't offended them.
I am very jealous indeed, as you told me I don't contribute anything (really don't I?) all this time I've not been contributing and I've not got paid a penny for not contributing. No wonder I'm jealous.
Now, sacasm over. I wonder what interests you have here, my post touched a nerve by making two statements that you highlight:
"The biggest difference I can see between Gnome & KDE currently is: One is an open source project that accepts donations of programmers and hardware, the other is an opensource project coded mainly by companies with a large commercial interest."
This is a true statment. Its fact.
"Is Gnome destined to become another Mozilla?" ...just like Gnome is mostly written by Ximian employees, Mozilla is mostly written by Netscape employees but the fruits of their labor is available to all.
Your comments reversed fit well here:
Honestly, there is nothing in my post to warrent such a childish responce, intellgent debate maybe but not that rant and lame and plain incorrect personal attacks. Think for yourself, open your eyes, don't be a slave to your beleifs I must say it was entertaining as I laughed my head off at this "Miguel De Icacza founded GNOME and started a company just so he could afford to give away GNOME", I'm sure that is exactly what he told the venture capatists before they invested in Ximian.
A journey of a thousand miles starts with a brutal anal raping at airport security
BTW. Last time I looked at Bonobo it looked much more like COM than CORBA. Sure it uses CORBA's IDL but all the QueryInterface stuff is a dot for dot clone of M$ COM. How much CORBA is there really in Bonobo?
Your pizza just the way you ought to have it.
From the same thread.
Finagle's First Law
Manufacturers of non-clunky desktops have cognitive psychologists, physiologists, and experts in other interface-related fields at their disposal.
A cognitive psychologist is someone that teaches you to change your thinking about something that you're miserable about. Do Microsoft have a special hotline to them when Windows BSODs for the 5th time that day?
At a certain level of karma you automatically post at +2, like I do, unless you choose not to.
The same is not true of widget libraries, on either platform. A Windows app needing MFC needs MFC installed. A Windows app needing the Borland/Imprise equivalent whose name escapes me needs that installed. There's also all the OLE based OCX stuff that VB apps rely on. For the most part, the toolkit is usually bundled with any program you get, which merely changes when you install it, not whether you install it.
If you hop over to /usr/lib/netscape, chances are you'll (not the rest of us, because we knew from the start) that there are two copies of Netscape, one just called 'netscape', the other 'netscape-dynMotif'. For 4.7x the difference in size is about 3 megs. One is Netscape with Motif's widget library bundled into the executable, the other assumes you've got Motif installed somewhere. You can run the latter with Lesstif if you want, but the point remains that it needs a Motif like widget library.
Widget libraries are ultimately the choice of the programmer. The "right" widget library will depend on a range of factors, from what language you're going to use to the range of features you need. There's nothing you can do to get programmers to standardise on a single library, because no single library, not Qt which is C++ specific or GTK* which has a much more procedural outlook, not the various other ones, will ever be the "perfect" catch all does all library.
If your objection to running GIMP on your Linux box is that it uses GTK, you really have two options. You can install GTK, which isn't that big, or you can rewrite GIMP. Expecting GTK and Qt to share the same API so each others apps can run on both libraries would be missing the point of why both libraries exist.
--
You are not alone. This is not normal. None of this is normal.
That's the biggest bunch of BS in the world. Wasted memory is wasted memory. I have no problem with Linux using 90% of my memory to cache my disk, but when it has to use 30-40% to cache the 30MB of graphics binaries, that's a problem. The problem isn't that Linux is caching those binaries, the problem is that the binaries are 30MB in size!
A deep unwavering belief is a sure sign you're missing something...
Widget libraries are ultimately the choice of the programmer.
>>>>>>>>>
That's the problem. If UNIX were really about empowering the user, developers shouldn't get to make these decisions. If developers were forced to write to a standard API (OpenGL, for example) then the user could use whatever implementation of it THEY wanted.
The "right" widget library will depend on a range of factors, from what language you're going to use to the range of features you need.
>>>>>>>>
Easy to fix. Design the standard API well, and include lots of language bindings. OpenGL does both.
There's nothing you can do to get programmers to standardise on a single library, because no single library, not Qt which is C++ specific or GTK* which has a much more procedural outlook, not the various other ones, will ever be the "perfect" catch all does all library.
>>>>>>>>>>>>
Sure you can. The X people seem to have done a pretty good job of tying everyone to X. You just have to make sure that all the nifty features are available through that toolkit only. If the standard API were added to X, most programmers wouldn't bother to use a seperate toolkit (just like most programmers don't bother to use toolkits like OWL on Windows.)
PS> MFC realy isn't applicable here, it is more or less a "standard" API for Windows in addition to Win32.
A deep unwavering belief is a sure sign you're missing something...
Turning on P6 optimizations (on VisualC++) makes my graphics library run 20% faster. I'd say that's quite significant.
A deep unwavering belief is a sure sign you're missing something...
What makes you think that GQt, or whatever your hybrid interface is to be called, wouldn't suffer the same fate?
2. Saying that programmers should not be allowed to use toolkits other than the one you desire would, even if possible to implement, have a devastating effect on the programming community. You have to produce toolkits that do what programmers want out of them, or else face not having those toolkits available.
3. MFC is relevent here. It's an alternative API. There are several APIs for programming Windows' GUIs, many of which originate from Microsoft themselves, and many of those are optional. MFC is standard only insofar as the creator of the operating system has declared it such. It happens to be, according to most programmers I've talked to who use it, a very good API, and MS's Visual C++ encourages the use of it. It's become popular for that reason.
In conclusion: It seems to me that the demand that programmers be forced to use a particular toolkit for all their GUI programming is unworkable, unreasonable, would contradict standard practice on every other platform (even the Amiga, 10 years ago with very little legacy issues, had vanilla Intuition, Gadtools, and BOOPSI widget libraries, and programmers routinely used other third party toolkits like MUI or their own where it suited them) and would stifle innovation by ensuring programmers could only produce apps that "fit" the toolkit and by the fact that such a toolkit would be build for the issues of 2001, just as Motif, OpenWindows, and Athena addresses the issues of their day.
And to what reward, the ability to save a small number of megs of RAM that, as a percentage of the whole OS, is practically insignificant? Much as I abhor code bloat, I have to say that the price is not worth paying.
--
You are not alone. This is not normal. None of this is normal.
1. There have been three attempts to create standard widget libraries for X, Athena, OpenWindows and Motif. Of the three, the first quickly became obsolete as time wore on.
>>>>>>>>>
I said standard API. Not standard toolkit. Nothing precludes an API from growing and expanding, and having new toolkits implemented under it. OpenGL (and more so, DirectX) is an excellent example of a standard API that has evolved through many revisions and implementations.
What makes you think that GQt, or whatever your hybrid interface is to be called, wouldn't suffer the same fate?
>>>>>>>>>>>>
Because it would be an API, not a toolkit. It would specify a certain set of services, and whatever toolkit the user wanted could supply those services.
2. Saying that programmers should not be allowed to use toolkits other than the one you desire would, even if possible to implement, have a devastating effect on the programming community. You have to produce toolkits that do what programmers want out of them, or else face not having those toolkits available.
>>>>>>>>>>
Doesn't seem to be much of a problem on the Windows platform. Sure, there is MFC, OWL, VB, etc, but all of those wrap around the same set of Win32 services. An MFC app can exchange clipboard data, objects, whatever, transparently with a Win32 app. The same is not the case with the thousands of *NIX toolkits.
3. MFC is relevent here. It's an alternative API. There are several APIs for programming Windows' GUIs, many of which originate from Microsoft themselves, and many of those are optional.
>>>>>>>>
MFC isn't relevant. Its not an alternative toolkit, but a wrapper over the same Win32 services.
MFC is standard only insofar as the creator of the operating system has declared it such.
>>>>>>>>>
Believe it or not, that's a good way to make it "standard."
It happens to be, according to most programmers I've talked to who use it, a very good API, and MS's Visual C++ encourages the use of it. It's become popular for that reason.
>>>>>>>>>>>>
MFC is a bloated piece of crud. Everyone I've talked to agrees, unless of course you're talking to the "wizard" crowd. (If you need something quick, use a quick language, but for god sakes don't use MFC!)
In conclusion: It seems to me that the demand that programmers be forced to use a particular toolkit for all their GUI programming is unworkable, unreasonable, would contradict standard practice on every other platform
>>>>>>>>>
99% of Win32 apps call the same toolkit functions, whether they are wrapped OWL, MFC, etc is irrelevant. They are not incompatible in the way GTK+ and Qt apps are.
And to what reward, the ability to save a small number of megs of RAM that, as a percentage of the whole OS, is practically insignificant? Much as I abhor code bloat, I have to say that the price is not worth paying.
>>>>>>>>>>>>>
A) Given the current situation with GNOME and KDE, your way doesn't seem to be working, does it?
B) It's not just code bloat, its platform fragmentation. KDE/Linux is not the same OS as GNOME/Linux, at least not for a modern (ie. takes advantage of DE features) GUI app. MFC/Windows and OWL/Windows is. I'm not even saying that the Windows way is the best way to do it, though it's better than the UNIX way. The OpenGL way is the best way to do it. Define an ABI. Then, make both sides replacable. With OpenGL, I can use Java to call NVIDIA's implementation, or use Delphi to call ATI's. All while still having access to the same set of services, and all while interoperating perfectly with apps whose developers didn't make the same decisions as me. That's real good design.
A deep unwavering belief is a sure sign you're missing something...
If MFC is "just a wrapper" for Win32, then GTK and Qt are "just wrappers" for X11. MFC is a toolkit, and an API, and is used by some, but not all, Windows apps. You can run a app written using MFC, and it will exchange data happily with a OCX/VB, OWL, or any other normal Windows toolkit program via the clipboard, will appear on the same screen, and will cooperate with your windows shell (Windows Explorer, Internet Explorer, etc.)
Similarly, you can run an app under X written using GTK. It will happily share clipboard data with an app written using Athena. Or Qt. Or OpenWindows. Or whatever other standard widget set and toolkit you care to mention. And no, not any of these toolkits shares an API.
The API of MFC is not the Win32 API. It merely uses Win32 based operating systems to implement its functionality.
The API of MFC is not the same as the VB API.
The API of Qt is not the same as the XLib API. It runs over the top of it, making use of XLib to implement its functionality.
And, as if it needs to be said, Qt's API is not the same as the API of GTK.
I don't see how you can argue that the situation with APIs and widget sets is any worse on X than it is on Windows. It's exactly the same.
As for pulling OpenGL into everything, there are, as I said, standard APIs out there, normally defined as defacto standards, for X11. They include the three I've already mentioned. They are Athena, OpenWindows, and Motif. Of these, I've seen at least three Athena (the original, the 3d one, and the NextStep one) implementations, OpenWindows never really took off so never gained much support (and was open source anyway so there was little point in writing a new version), and Motif has at least two (Official Motif and Lesstif). Trying to play with words and call them toolkits rather than APIs doesn't change the fact that they're as implementation independent, well defined, and open, as OpenGL is.
Finally, what do you mean by "your way doesn't seem to be working, does it?". I can run Qt apps and GTK apps on my machine without having to run GNOME or KDE. Response times are excellent, and this is on a 32 meg laptop. What definition of "working" are you using? Certainly, by most people's definition, being able to run two programs at once without, most of the time, even caring which widget set it uses, would appear to me to be "working". I don't even know who uses what these days.
I do know that you seem to be having some awful problems loading an application absolutely nobody else is having problems with, and your reasons appear to be ideological, namely "I don't want to have two toolkits installed."
Well, that's fine. Do the conversion work yourself, presumably converting all your apps to use Athena's widget set as you're pretty much stuck with that with X11, or don't run the programs. Most of us will continue to install the libraries needed to run the applications we want to run, and be happy that the programmers who developed them put together high quality software with the right tools, rather than giving up with despair or taking twice as long to put together a botch for a toolkit and/or API that tries to be all things to all people (OpenWindows, Motif) and succeeds at nothing, rather than being the best it can be.
--
You are not alone. This is not normal. None of this is normal.
You're trolling aren't you?
.
>>>>>>>>>
Much as you'd like to belive that, I'm not.
If MFC is "just a wrapper" for Win32, then GTK and Qt are "just wrappers" for X11.
>>>>>>>>>>
No, MFC really IS a wrapper. It doesn't do much processing at all. GTK and Qt do their own text drawing, (GNOME and KDE) manage their own clipboard, they have their own printing services, etc. MFC (and presumably OWL) is just a C++ wrapper just makes calls to Win32. It doesn't define any services of its own. The difference is that GTK and Qt implement their own services and define ones not part of standard xlib. MFC doesn't.
Similarly, you can run an app under X written using GTK. It will happily share clipboard data with an app
written using Athena. Or Qt. Or OpenWindows. Or whatever other standard widget set and toolkit you care to
mention. And no, not any of these toolkits shares an API.
>>>>>>>>>>>>>
Let's see. I can implement a component written in VBScript into an application written in MFC. In the next iteration, the application could move to straight Win32, and the component could move to MFC. Everything still works, hell, I don't even have to know *what* language the component is programmed in. Let's see GTK+ and KDE do this (without hacks!)
The API of MFC is not the Win32 API. It merely uses Win32 based operating systems to implement its
functionality.The API of MFC is not the same as the VB API.The API of Qt is not the same as the XLib API. It runs over the top of it, making use of XLib to implement its functionality.
>>>>>>>>>>>>
Qt and GTK (and to a much larger extent GNOME and KDE, what this debate is about) implement their own features independant of XLib. Hence the X-less Qt and GTK ports. MFC doesn't do much of anything except make calls to standard Win32 functions.
And, as if it needs to be said, Qt's API is not the same as the API of GTK. I don't see how you can argue that the situation with APIs and widget sets is any worse on X than it is on Windows. It's exactly the same.
>>>>>>>>>>>>>>>
A) The situation is different. See above cogitation.
B) Even then, how is being the same as Windows remotely near being good?
As for pulling OpenGL into everything, there are, as I said, standard APIs out there, normally defined as defacto standards, for X11. They include the three I've already mentioned. They are Athena, OpenWindows, and Motif. Of these, I've seen at least three Athena (the original, the 3d one, and the NextStep one) implementations, OpenWindows never really took off so never gained much support (and was open source anyway so there was little point in writing a new version), and Motif has at least two (Official Motif and Lesstif).
>>>>>>>>>>
Funny. OpenWindows "never really took off" yet its somehow a "standard"? No matter what, everything you've just mentioned is entirely irrelevant to Linux. None of the interesting apps coming out use Motif, Athena, or OpenWindows. Besides, decreeing "one standard toolkit" is not what I want. I want a binary standard for toolkits. Different APIs can plug into that binary standard and make calls to different implementations supporting that standard and everything just works. That's how OpenGL does it, and it is Good(TM). Maybe I should have made that point clearer.
Trying to play with words and call them toolkits rather than APIs doesn't change the fact that they're as implementation independent, well defined, and open, as OpenGL is.
>>>>>>>>>>>>
But it also doesn't change the fact that people actually USE OpenGL, and (on Linux anyway) nobody *uses* the "standard" APIs. And while the toolkits maybe be implementation independant (theoretically) the one alternative implementation of the three toolkits you mentioned (Lesstif) lies in stark contrast to the dozens of (compatible!) implementations of OpenGL. There is really no comparison beyond the very basic.
Finally, what do you mean by "your way doesn't seem to be working, does it?". I can run Qt apps and GTK apps
on my machine without having to run GNOME or KDE.
>>>>>>>>>>
But do they look the same? Do they interoperate perfectly? Do they respond to the same configuration programs? Do they use the same themes? Do they work with the same applets? If so, please tell me what versions you're using!
Response times are excellent, and this is on a 32 meg
laptop.
>>>>>>>>>>>>
Then your standards are set to low. Nothing, not even QNX or BeOS, has "excellent" response times on a 32MB laptop. On my machine, (300MHz PII 128MB RAM) GNOME runs "decently." KDE-2 runs inexorably slow, NT-4 is snappy, and BeOS runs like a bat-out of hell.
What definition of "working" are you using? Certainly, by most people's definition, being able to run two
programs at once without, most of the time, even caring which widget set it uses, would appear to me to be
"working".
>>>>>>>>>>>>>
Maybe I should have said "working well." Like most people, I make no distinction between the two.
A) Strike "most of the time" from your vocabulary. I *never* have to worry what WRAPPER a Win32 program is written in (hell, I don't even have to worry what LANGUAGE its written in) and I should have to worry on a supposedly superior platform like Linux.
B) I want it to interoperate perfectly. I want it to take zero memory. I want it to predict what I'm going to do. High standards yes, but right now Windows (and some other OSs) are a lot closer to it than GNOME/X/KDE/Tk/Athena/Motif/GTK/Qt/FLTK/GNU/Linux
As for your additional rantings, I get high quality software on Windows without running dozens of libraries. This is mainly because you're "right tool for the job" BS doesn't hold water, not on Linux as it is today. Qt and GTK (and GNOME and KDE), both progmatically and functionally equivilant. One may prefer one or the other, but one will develop appreciably better on one or the other. There is some use for some of the smaller toolkits, but in that case, methinks it would be better do get something like VBScript (isn't Linux supposed to get a Kylix port?) and keep the total toolkit count to an absolute minumum. The number of toolkits on UNIX is currently much larger than necessary to support "right tool for the job" and the inherent uninteroperability of the toolkits just exacerabtes the problem.
A deep unwavering belief is a sure sign you're missing something...