Core Developers Discuss The Future Of GNOME 118
Jon writes: "George Lebl and Maciej Stachowiak, GNOME core developers, recently attended the Australia Linux Hacker's conference, Linux.conf.au. Check out the article LinuxWorld Australia is running based on their talk at the conference. It looks at the future of GNOME and other interesting tidbits. Also, check out this link to see summaries of other talks - including Alan Cox's '
Classified Progress Report and Briefing.'" The GNOME folks indicate that Nautilus could be the default file manager as soon as next month :)
Gnome:forever two years behind (Score:4)
Now the issue is multimedia support - once again, Gnome will come up to speed somewhere in the two year lag range. Its interesting that I note that most uber-smart unix geeks I know are just throwing in the towel and running an SSH client from windows into their BSD boxes. Why? Because they're tired of seeing "plugin not suported" when they try to do anything interesting on the web.
Inti (Score:3)
could be interesting... (Score:1)
Re:Good so far (Score:3)
I am really looking forward to stuff using the X Render extension (anyone have any examples of anyone using it? Docs on how to use them? I so want real transparent terminals...)...
The RENDER extension is definitely being used, by Qt. KDE's CVS version of Qt now includes patches to make it do font rendering. The great thing is that this is all at a very low level, so it's completely transparent to the application programmer. All of my KDE applications have well-kerned, well-hinted, fully anti-aliased proportional fonts. The same is possible with gtk+; in fact I'd heard that someone had it working at one point.
As far as docs, I don't believe there is much right now. There is an incomplete Xft manual page for the library dealing with the font stuff (basically renders fonts in truetype and feeds them to X using the render extension). There is also probably likely to be something at the render mailing list [xfree86.org].
Real transparent terminals...as I understand it, that requires a seperate extension. Render creates the option of alpha blending, but it takes something else to do it on the window level, rather than on top of an opaque window.
Re:how about a total rewrite.. (Score:2)
With a nod to the existing reply, I'll add that if you must use an OO language, use the bindings. I for one use GtkAda [eu.org] all the time, and bindings exist for other OO languages as well.
> And the other thing is speed. Lord good gravy gnome is slow.
Speaking of GTK+ rather than GNOME per se,
- it is counterintuitive: I would expect to have local control over the theme, and
- it is inefficient: performance is horrible when you try to push all that graphics down the pipe.
IMO, the #1 priority for GTK+ (and for GNOME) should be to remodel their system on the way X behaves.--
Re:Gnome:forever two years behind (Score:2)
I hear that. I used to run Linux on my main pc (dual 550mhz), and mac os on my G3. Programing/Email/Admin/etc on the Linux box, Design/Multimedia/etc on the mac. After constantly fighting with linux to get almost anything multimedia running, with almost the same true for the mac os, I decided to make a change. I'm not saying that linux/mac suck, they have their place, just for my needs, I needed something different. I now have debian on my g3 as my masq box, and general linux use machine. Windows (2000 of course) runs on my main machine, with dual monitors. SSH and VNC let me control the mac from one area. I now I can play games, view things like asf movies (without crashing or 3 hours of configuration), while running a bash shell, and whatever x11 apps I can live without on vnc. It's worked out very nicely for me. I miss the ability to configure X11 windows managers, and being able to REALLY fix my computer when it breaks (windows is still like shooting a fish an a barrell when something messes up). But I like it, I suspect others do the same thing I do.
Re:The Future of Gnome, simplified (Score:1)
Re:how about a total rewrite.. (Score:1)
=)
-Andy
Re:When will it end? (Score:2)
Personally i am getting just a little fed up with all of these do-it-all applications. I want a file manager that manages my files, a web browser that browses the web, and an ftp client that sends and recieves files over FTP. I do not want them all in the same damn application!
Have software developers gone nuts? What happened to the Unix pholosophy of lots of small tools that can be pluged together? Why is it that as soon as the developers get hold of a GUI they go mental and start layering IPC protocols on top of each other, integrating everything into one huge application that does it all, and basically forget that these tools are supposed to be there to do a job, and do it well? I don't need and HTML engine in my file manager, I use a web browser for that. All the HTML component does is add bloat (Even if it's not loaded, the application still needs code to support it), and uses my memory. This seems to apply more to Open Source software than it does to commercial, although Microsoft is also guilty of this in many ways too.
Please, for Jebus' sake, can we get back to small, lightweight tools, and stop integrating everything?
The Biggest Problem with Gnome and KDE (Score:5)
Its that they both ignore each other. Half my apps don't work properly. The standardized drag and drop doesn't work across in any distribution with the latest GNOME and KDE, dragging from Konqueror to the GNOME desktop doesn't work. Neither does any other cross app drag and drop.
* Drag and drop is broken
* I have 2 sets of mime types
* My KDE panel applets won't launch in the GNOME panel, and vice versa
* When I add an application the the kpanel, it doesn't appear on the foot menu, and vice versa
* KDE and GNOME don't even include apps from each other on their panels
* Childish KDE developers write a GNOME theme importer which calls GNOME `legacy' and childish Eazel developers make Eazel services showcase any app for any toolkit, as long as it isn't KDE and QT.
* QT and GTK are themed using different engines, with no reason why.
Thisn isn't competition. This is insanity, artifically partitioning all my apps. Neither desktop will win. No OS uses a single partition.
Imagine a Windows user clicking Start to reveal `MFC applications' `VCL applications' etc. End users don't give a fuck about toolkits and never have. Why is the KDE team writing KPhotoSuite? Why shouldn't KWord work really well with the GIMP?
Windows uses more than one toolkit. It just does it well. For God's sake, stop partitioning my desktop. Write a combined style guide for GTK and QT based apps. Make sure both toolkits use the same theming engine, and have a similar range of widgets aviable.
And for God's sake, stop using your brilliant minds to hurt each other and combine them to actually make Linux a useable desktop.
I'll have hope the first time a Linux developer actually writes a software installer and doesn't call it `gnorpm'.
Re:Gnome:forever two years behind (Score:1)
Re:One Gnome annoyance for you developers (Score:1)
-- Eat your greens or I'll hit you!
The right UI with the wrong code (Score:2)
As much as I like GNOME, it needs a fresh code-base that is simple and elegant. First get the panel working, then the icons, then the backgound, filemanager (a small.simple,easy filemanager like MacOS7's) and just some minor things! GNOME should be small tight code, it really doesn't need to do a tiny fraction of what it does. Everything is about having one program you want to run and needing 20 libraries to run it.
Mod me down for ranting if you must, but any desktop should feel like GNOME to a user, but it's code should do only what it needs to. A new GTK which has only what it needs, and everything should go right on top of that, no other middlemen, no other libraries should go into it. Small tight simple code... themes should be an afterthough, as should be everything else that is a nicety not a necessary feature. The GNOME trash can is a great example of how simple their desktop should work. There's an easy and simple way to do everything.
Re:The Biggest Problem with Gnome and KDE (Score:1)
Sorry. I meant to say `No OS uses a single toolkit'
Re:Excuse me but ... (Score:1)
Sure thing, I doubt I'll ever run Nautilus on my Pentium 150 Laptop ( which I hope to keep for the next four years ). This is why if some Gnome developer would come out with a light-weight Gnome-compliant file manager (heck, also a slightly improved version of GMC would do it) it will have my grazie forever ( well, maybe until I change the Laptop ).
Re:Gnome:forever two years behind (Score:2)
miguel.
Re:The Biggest Problem with Gnome and KDE (Score:3)
- Could you tell us what makes you think that DnD is broken? I am sure that the developers would like to know this, and I would love to fix things that are annoying users.
- The 2 sets of mime types is indeed annoying.
- KDE docklets work in GNOME just fine.
- In general GNOME integrates the KDE menu into its own menu. Ideally we should be sharing the same menu.
- I agree with you about the themes. I have suggested in the past to the KDE people to write together an cross-theme API that would allow theme engines to be written once, and used everywhere, but there was not too much enthusiast on Matthias part. He has since stalled saying that `he has an idea for this, and that he will post later', but the idea has yet to happen. The approach of having a unified subset of the API calls required to have a theme engine is not only doable but simple.
(On the other hand, Helix software installer is called "Red Carpet"Miguel.
Why not speed it up?? (Score:2)
Many of the improvements are the result of user experiences with GNOME. "The application launch feedback program is designed to indicate that a program is in the process of being loaded," said Stachowiak. "We've had complaints about people clicking on the Netscape launcher 10 to 15 times before the program appears on the screen."
Well, if that's not taking user feedback to heart, I don't know what is. It takes a long time to load apps and users get impatient, so lets make a loading box to sooth them (instead of putting some work into making apps load faster).
Why does it take so damn long to load? What's going on that could possibly need 10-15 seconds? Come on, on a modern PC, that's enough time to transfer about 100 megs from a modern disk drive (or over 100 Mbit/sec ethernet), enough time to do an unimaginable number of computations, even in floating point. Only two types of things take time in the modern computing world:
- network latency, usually 20ms to 300ms
- software bloat, anywhere from 100ms to well beyond anyone's patience for software
It's refreshing to see that the gnome developers are keeping a keen eye on being lean-and-mean, NOT!Ok, maybe this message was a bit of a troll, but I'm still a bit pissed about having to upgrade the RAM on a machine where I installed Redhat 6.2. 64 megs of RAM and I was getting quite a bit of swapping running gnome with netscape, xmms, ssh, and several terminals. With this sort of attitude towards bloat and slowness, it sounds like gnome will continue the trend of software getting slower more rapidly than hardware getting faster, just like another OS & windowing environment vendor that we're all familiar with...
Re:could be interesting... (Score:1)
rm -rf
R and everything would be gone save home directory settings etc.
He who knows not, and knows he knows not is a wise man
Re:Gnome:forever two years behind (Score:1)
Re:Good so far (Score:1)
Re:The Biggest Problem with Gnome and KDE (Score:1)
You mean Ximian software installer don't you? ;-)
Tell me something... (Score:1)
Linux is a kernel, not an OS nor a religion - me
Re:The Future of Gnome, simplified (Score:1)
Re:Gnome:forever two years behind (Score:1)
Re:The Biggest Problem with Gnome and KDE (Score:1)
Look at BSD and Mac OS X - that's a great example of starting with something free and making something innovative on top.
I was thinking this way myself, regarding bootstrapping a QoS media OS. I started writing one 5 years ago, on top of RISC OS. That turned out to be a little pointless, as RISC OS plummeted from "almost no users" to "actually no users" a little later ;)
The great thing about RISC OS, compared with Linux, is that it's a single-tasking modular OS. That's bad for a production-quality OS, but if you want to bootstrap your own OS on top, it's actually the best thing you could have. You can run your own IRQ code for scheduling and device access, while the rest of the system happily continues.
I'm currently looking at bootstrapping my stuff onto OpenBSD (preferable license terms to Linux). The difficulty here is that the OpenBSD kernel is damned complex and it's not easy to just patch in a new "idea" without becoming involved in fixing a lot of other code. I know the Linux kernel is equally complex; possibly more so. So whereas it looks like OpenBSD or Linux should be a good starting point for creating truly novel OS architectures, the line is effectively drawn at the user-kernel interface. I know some people have added RTOS support to both OSes, though, so it's obviously possible to do some groovy things. [Incidentally, which free OS would you say has the best kernel docs? I can't find *anything* on the OpenBSD kernel architecture, other than the source code ;) How's Linux for that?]
So although you've got an interesting perspective, I don't think the original designers intended this at all. If Linus wanted Linux to be just a stop-gap on the way to designing future OSs, he would have used a more easily extensible design, especially in the low-level kernel stuff. But, instead, he chose the design which gave maximum system performance at the expense of easily trying out new ideas. *BSD is the same.
But I do take your point. Linux is moving faster than Windows, so maybe someday soon it'll overtake it.
Overtaking Windows would be cool.
Re: Troll? (Score:1)
Embedding panel applets in each others panels would require using the same component model. I don't think either the GNOME or KDE people are going to switch anytime soon. And furthermore, who cares? Who actually has both panels running at the same time? And which applets exist for one but not the other (and if you want it, write, don't bitch at other people to write software for you).
The menues and mime parts are a pain.
For the themeing stuff, again, GNOME uses GTK, KDE uses QT. Why don't motif apps use GTK or QT themes? Cause they are different widget sets. This is life. And if you ever really used different widget sets under windows, you would know that there isn't a perfect blend. You're examples don't cut it either. MFC and VCL are basically the same things
I won't disagree what working together isn't a good thing, but when you different people who want different things, it isn't always possible. And 95% of end users aren't ever going to switch anyways. I personally use GNOME over KDE and I don't think there is one KDE app installed on my system. So I don't worry about it. And I think you'll find that gonna be the case more often then not.
Re:Good so far (Score:1)
Good so far (Score:3)
The only thing I can think, is that the reader here prefers over aggrandized marketing lingo to what is generally self-effacing programmer attitude (in which we learn that programmers always say it is broken even if it isn't 'broken' so as to avoid expectations. as opposed to marketers who never say anything is broken but call bugs features.)
I personally have enjoyed gnome lately. The apps are functional and the toolkit seems to be making it easier for developers to produce some pretty professional looking apps. In combination with Debian (using apt-get) I have been able to keep up to date with gnome and easily added new apps as I heard of them. There is alot of work to go but there seems to be a lot of action. I have been continuously running Helix (Ximian) Gnome desktop for over a month and it is far more stable than any other gui I have ever used. Gimp-print outputs without flaw... And Gimp itself is a rock of stability. The Sawfish desktop is quick and very flexible. Infact running recent Gnome with nightly builds of mozilla, xemacs, eterm, gimp, gpilot, gphoto and xmms has been a pleasure.
Yes there are bugs, and I am an expert user (and thus can pretty much figure out just how I mangled everything, but given a month or two at this rate, and I think ya'll will be suprised.
I am really looking forward to stuff using the X Render extension (anyone have any examples of anyone using it? Docs on how to use them? I so want real transparent terminals...)...
As to Nautilus, well I am still a strong advocate of the command line where file management comes in. Still occasionally I call up the file manager... Certainly not the worst I have seen. Nautilus seems nice looking, and I guess it will appease folks who don't understand cp and mv, but bash with filename completion means I move damned fast when I want a file.
Anyhow,
I am not a 'normal' user with experience since Linux
d
Re:The Future of Gnome, simplified (Score:1)
Re: Troll? (Score:2)
KDE and GNOME are voluntary projects. The people who work on them are volunteers. You can't fire them. And you are not their boss to tell them what the can or cannot do. The last thing freenix needs is a UI Police, arbitrarily setting standards and confiscating noncompliant CVS trees. That kind of thinking is antithetical to Free Software. This is a Free Market of Software. It's Laissez Faire. It's radical libertarianism that takes great pride in tar and feathering any who would set down rules. There are standards in this world, many standards,. And quite a few of them compete with each other. Just like in the real world. If you don't like this chaotic situation, and would prefer a regimented world where everyone does what they're told, then stick with Windows.
That said, the solution to your problem is easy, as long as you keep the fundamental volunteerism of Free Source in mind. If you want the KDE menu to be a part of the GNOME menu, and vice versa, go do it yourself! Or find someone who can and convince them to do it for you.
This isn't Windows. Don't expect it to be.
All I see is a standardized drag and drop that's been bandied about for a couple of years and doesn't work consistently. And symlinks in the menus.
Huh? What about standardization of
Re:how about a total rewrite.. (Score:2)
Has anyone pointed out that Disuss is not a word? (Score:1)
Re:how about a total rewrite.. (Score:2)
Re:how about a total rewrite.. (Score:3)
This is not true. A remote app is running on the remote computer. It has no access to your system for security reasons. Instead of being a client to the LOCAL X server, it is a client of the REMOTE X server. It does not have any access to your filesystem, and doesn't even know what your username is on your local box. It certainly would look nice, but its just not possible.
At my work, we use NFS-shared home directories, so when I run apps on other boxen, they do show up with my theme. Obviously, this is not the case with root, which is local to each machine.
---
More like KDE, not windows (Score:1)
IMO gnome just doesn't have all the 'drag and drop goodness' of KDE. It just doesn't seem as integrated.
With Nautilus (and withOUT gmc, blech), I believe gnome will stand out even over Windows- If they integrate it well enough.
My vision is of Nautilus becoming the desktop environment, so that image/document viewing is seamlessly a part of the OS. And since mozilla is already loaded with Nautilus, opening a web page will be as rapid as with m$ (since gnome would be "cheating" in the same way).
how about a total rewrite.. (Score:3)
Last I looked and tried GTK with Drag and Drop, it was nightmare. Unless you are a gtk/gnome monger, forget it.
And the other thing is speed. Lord good gravy gnome is slow. Its bloat with fudge added in. Waiting for hardware to get faster is not a way to make your software improve, efficiency wise.
---
Re:"Linux currently satisfies..." (Score:1)
Newer LILO versions are pretty good with this, so yes, even my / is on
Setting the partition type to 0xfd and letting the kernel figure out the rest is just too easy.
So, what's the problem exactly?
Re:The Biggest Problem with Gnome and KDE (Score:2)
Maybe representatives from both sides need to start some kind of X desktop environment standards group to decide on these things, so they don't continue their spiral towards madness.
KDE and Gnome are both excellent, but it really bugs me that if I try to run a QT or KDE-based app on a Gnome desktop, it feels like it's being treated as a second class citizen, and vice versa with GTK or Gnome apps on KDE. QT and GTK both have their advantages and disadvantages when programming apps, particularily in terms of language support (GTK is more at home on C and other proceedural languages, whereas QT was designed for C++, etc)
It was this same kind of bickering back and forth that severely crippled UNIX in the past, and allowed Microsoft to make large gains in the server markets because Microsoft could dictate the standards and everyone else had to follow or be replaced by those who would.
If the teams can't come up with agreements between them about standards by themselves, maybe they should appoint a team of people to do it for them. Component and drag and drop should be the primary concern for interoperability, followed by unifying the end user experience (user interface, theming, etc) based on his or her selected desktop environment.
Re:how about a total rewrite.. (Score:2)
Wonderful. Which OOPL do you mean? Notice that you can't "do it in OOP", you have to write it in an OOPL. Objective C? C++? Ada95? Object-oriented C?
Yes, C is an object-oriented programming language, when in the hands of a competent programmer.
I'm sorry, but easy development and expandibility aren't done well in C for graphical programs.
Motif is written in object-oriented C. The kernel is written in object-oriented C. Heck, even C++ is isomorphic to object-oriented C. Back in the early days of C++, we had to run our C++ through AT&T's cfront precompiler. It would take our C++ code and spit out valid object-oriented C code.
People who think that C isn't an object-oriented programming language are correct--but neither is C++. Both are object capable programming languages.
Is THIS insightful? (Score:1)
And slow? Gnome using a proper theme engine instead of Pixmap, is pretty snappy, and it definitely not worth using sentences like "Lord good gravy gnome is slow" over.
While the "Drag and Drop" argument might be valid (not all Gnome applications are created with enough concern over D&D), the rest of this comment is a troll. It does not deserve "insightful".
Re:how about a total rewrite.. (Score:1)
It appears in a distinct theme, because GTK and Gnome apps read thier local
--
Re:The Biggest Problem with Gnome and KDE (Score:2)
GNOME rules! (Score:1)
The foot menu is way cooler than the K menu
I am testing nautilus, and it's great, except when you remotely access the computer. Over my school's network (from engineering building to dorm), it is soooooo slooooow.
Something really funny happened today. I was using Netscape 6 under GNOME (like I still am) to play Yahoo Chess (java). One of the five people I played wanted to talk. I announced that I was using Linux. I said, are you using windows? It was pretty obvious. He said yes, why? Then I talked about the advantages of Linux. I distracted him! After the very next move I got his queen. Ha ha freaknasty!!!!
Linux is cooler than sliced bread.
Re:The Future of Gnome, simplified (Score:1)
When, oh when is this little piece of received wisdom/ FUD/ whatever going to die?! Joe User doesn't give a flying hoot what his desktop looks like, so long as he gets his job done. Remember, 99% of office workers don't choose the OS and UI they work on; that decision is made by fuck-knuckled IT middle management types who believe everything they read in Microsoftie ZD rags and whose only criteria for buying software is how many tick marks are under that product's column in the executive summary feature matrix chartjunk that inevitably appears in these publications.
IMHO, the developers of KDE and GNOME are rip-off merchants too freakin' lazy to do their own usability and whenever they're taken to task on it, they respond with lame excuses like `the market wants it to look like Windows' or `Microsoft spent a gazillion dollars last year on usability testing, so flat toolbars/ office assistants/ Outlook bars/ HTML filemanagers/ Dumb UI Idiom of the Month must be The Right Thing'.
As to what `the market' wants, just what is your market these days, Mr. GNOME, Mr. KDE? The very real and very visible Linux community who have renounced Windows and all its works and pomps or some imaginary `Joe User' market segment that you plan to steal out of Microsoft's clutches with a product that looks exactly what they have already and spend copious amounts of time bitching about? Get real.
Re:how about a total rewrite.. (Score:1)
In what sense is Gnome object-oriented?
How do you get OO features such as inheritance and function overloading without an OO language?
Does Gnome manage to do this?
Or is Gnome OO only in the UI sense, not the programming sense, in which case it would be completely beside the point made by the post to which it is a reply?
Re: Troll? (Score:2)
I have 2 sets of mime types
My KDE panel applets won't launch in the GNOME panel, and vice versa
This sort of interoperability is being worked on even now as we speak. Don't expect overnight perfection. If you look at the history of KDE and GNOME, you'll find that the developers desire this compatibility and have been slowly but surely implementing it.
When I add an application the the kpanel, it doesn't appear on the foot menu, and vice versa
It's one thing for the main root menus of the respective desktops to recognize the menus of the other, and display them. I expect this interoperability very soon. But you're talking about *panels* here. Switching between panels is going to be a rare occurance. And the process of adding an item to a panel takes approximately 8.5 seconds.
QT and GTK are themed using different engines, with no reason why.
Plenty of reason why, if you would just use your head. Both of these toolkits are distinct from each other. They are developed by distinct groups of people. And their theming engines have distinct goals. QT themes are more powerful than GTK themes in some ways, and GTK themes are more powerful than Qt themes in others. I for one do not want a theme engine based on the lowest common denominator.
Imagine a Windows user clicking Start to reveal `MFC applications' `VCL applications' etc.
Apples and oranges. My KDE menu most certainly does NOT distinguish between Motif, Qt, Fox, FLTK and GTK applications. KDE and GNOME are desktops, they are not widget toolkits. To make the proper analogy, imagine a Windows user clicking the main menu to reveal "Windows applications", "DOS applications", "BeOS applications", "Mac applications",
Re:Gnome:forever two years behind (Score:2)
But linux support for the media devices themselves is still non-intuitive, and most of the plugins you describe have very weak support. The Flash and Real plugins are very poor, and I believe at least one major version behind.
I'm not saying it won't get there, but I'm sticking by my estimate that linux support for multimedia will continue to be at least two years behind.
Re:"Linux currently satisfies all the needs of the (Score:1)
If Linux could do this, it truly would be a world-class OS. But it might require the kernel coders to get out of their 70s system designers' rut and start thinking about some tough new problems whose solution isn't immediately apparent.
Re:Why not speed it up?? (Score:2)
It takes a long time to load apps and users get impatient, so lets make a loading box to sooth them (instead of putting some work into making apps load faster).
To be fair, they can't really be expected to speed up the loading of Netscape 4.x when you have a massive mailbox or loads of bookmarks. An app can take a long time to load for lots of reasons, none of which are GNOME's fault.
Re:The Future of Gnome, simplified (Score:1)
Re:disuss? (Score:1)
example: I disuss your mom because she was a ho.
Thank-You!
Re:how about a total rewrite.. (Score:2)
(2) GOB was built for this purpose
(3) Doing this makes code a _lot_ clearer
(4) It took me about 5 minutes to understand. Other people's times may differ, but I've never seen anyone have trouble with it. The you don't have to spend time debugging the macros if you use GOB.
(5) Different people like different langauges.
(6) I have read Havoc's book - it is very good. I'm not terribly up to speed on Gtk+ 2, except that they will finally have moved the OO stuff into glib - YAY!
Re:The Future of Gnome, simplified (Score:1)
Personally, I don't think most people like a Windows environment; I don't think they're bothered either way about their OS or UI or whatever, so long as it doesn't interfere egregiously with their real work. I don't think your average office worker engages at that sort of level with their computer. They don't "like" Windows any more than they "like" Xerox photocopiers or they "like" Canon fax machines.
My point is: there are a lot of ease-of-use issues with modern UIs that companies are either unwilling or unable to do anything about, issues that are more or less "invisible" to people who use computers a lot because, hey, "that's the way computers work". But these issues cause new and casual users no end of confusion. Take the distinction between a document in memory vs. a document on disk and the whole business of "saving" things as an example. This is totally non-intuitive to a casual user and is really a relic from the days when RAM and disk space were scarce. "Saving" a document is the interface equivalent of having to do your own memory allocation in C; there are times when you need that kind of power, but there's awk and Perl and a score of other languages for the times when you don't need or want to think about low-level shit like that.
What about so-called "common dialogs" like File Open? I've seen plenty of holy wars on the "best" design for such beasts. But common dialogs are a hack that go back to the first MacOS when the Mac was single-tasking and apps therefore had to have a miniature version of the shell hacked into them. Common file dialogs are a throwback of the GUI Stone Age. If the GNOME and KDE developers took one second out to really look at them, they'd see them for the vestigial growths that they are. Instead they've got one eye on Redmond and the other eye on Cupertino and these anachronisms persist to plague users.
Or how about hierarchical filesystems? Casual users find them very confusing, especially if some rogue program warps them from their accustomed area into some ill-explored cranny of the directory tree. Hackers and scientific types find it easy to move around hierarchical classification systems; mere mortals are apt to have trouble with them. Nor is a tree structure the ideal way of representing all types of information. Why do you think the Web took off and gopher died? Partly because the Web is hyperlinked but gopher was strictly hierarchical.
What I'm saying is, there's plenty of avenues of exploration out there that could make some for truly user-friendly interfaces. We could really wipe the floor with Windows and MacOS if we just broke out of the imitative mindset.
Re:"Linux currently satisfies all the needs of the (Score:1)
OTOH, I thought I'd mention it, since the Linux community has so much more bandwidth than me, but so few new ideas.
Re:Moderator Quality (Score:1)
--
Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.
Eh? (Score:1)
Linux dies through lack of direction (Score:1)
That's it, guys. No more.
It is now up to the Linux masses to change the real world so that we have new kernels to compile.
Is it a co-incidence that there is a new president in USA, renewed fighting in Mid-east? Seems a good time to launch a new world. All we need now is a catchy slogan...
Brave GNU World?
Re:Why not speed it up?? (Score:1)
The solution?
WindowMaker + ROX:
http://www.windowmaker.org/ http://rox.sourceforge.net/
Runs quite nicely on my old P233, 96MB RAM, slow old 2GB hard-drive.
Rasterman's New Toy (Score:2)
Congrats Aussies, who knew we could put on such a great conference?
Re:The Future of Gnome, simplified (Score:1)
Um, why do you say that?
"A foolish consistency is the hobgoblin of tiny minds" -- Ralph Waldo Emerson
Read it. A seminal work. Absolutely indispensible if you're designing a 128K monochrome single-tasking computer with 400K floppy disk storage. Things have moved on.
[grits teeth, tears hair] Listen to yourself for a moment. The Linux filesystem is flat! It's just long chains of bits encoded in the magnetic domains on the surface of a ferrite-coated disc. It all depends on your representation. A dinky tree control with cute folder icons is no more "real" than any other representation of your filesystem. We could make the filesystem look like a level out of Quake if we wanted to.
See, you're exhibiting precisely the sort of behaviour I complained about in my previous post. You're folding your arms and saying, `we can't do that because no-one has ever done it that way before'. It's a good thing that there are people out there who don't listen to people like you or I'd be sending this by smoke signal...
Re:how about a total rewrite.. (Score:2)
Re: Troll? (Score:2)
Ah, the typical Slashdot `DIY' response. I can't do it myself. Nor do I have any intention of doing so. If Linux is to ever be accepted by mom and pop, which Eazel, Ximian, the GNOME and KDE foudnations / leugues, The Kompany, etc. all set out to to do, they will have to accept the plain reality of life that mom and pop don't know C and never will.
Being a little more educated than mom and pop, I still contribute by doing documentation for various projects. But no, I won't be helping GNOME or KDE beyond giving feedback in the near future, as I don't gave the time.
Or find someone who can and convince them to do it for you
Um, what do do you think this is?
Re:Good so far (Score:1)
Re:The Future of Gnome, simplified (Score:1)
Re: Troll? (Score:2)
The last thing freenix needs is a UI Police, arbitrarily setting standards and confiscating noncompliant CVS trees.
Um, no. This is what destroyed closed source Unix, and pretty much everyone acknowledges this is what will destroy just about everything else. Chaos is not a part of Free software development. We have CVS bringing order to revisioning, we have the LSB bringing standards to distriobutions, and we have the FHS bringing standards to file locations.
That kind of thinking is antithetical to Free Software. This is a Free Market of Software. It's Laissez Faire. It's radical libertarianism that
takes great pride in tar and feathering any who would set down rules.
No, they don't. They get on ther mailing list for the standard amnd flame away, giving their input into the standard, so we can settle on something.
There are standards in this world, many standards,. And quite a few of them compete with each other. Just like in the real world.
Sorry, but its plaionly clear lack of consistent UIs hurt the free desktops more than their competition with each other enhances it. Both KDE and GNOME, and QT / GTK, will both exist. If anything, I'm encouraging the competition - for both players to realize they won't win out over each other, and the must accept the fact people won't always use their respective widget sets. I'm not saying the competition must stop, I'm sayign the current way of competing, which hard the UI experience and halves a users avliable apps, is hurting Linux as a desktop.
If you don't like this chaotic situation, and would prefer a regimented world where everyone does what they're told, then stick with Windows.
Er, no. I wouldn't prefer a regimented world. I'd prefer standards theres a difference. And as for sticking with Windows? Fuck you.
Re:Eh? (Score:1)
Re:More like KDE, not windows (Score:1)
Excuse me but ... (Score:1)
Nautilus could be the default file manager
Doesn't Nautilus require Mozilla libs?
More bloat, yea.
Not any closer to pulling me away from WindowMaker [windowmaker.org].
Re:how often do we need to know gnome's future? (Score:2)
Re:Inti (Score:2)
If you want to use C++ now GTK-- is what you want. Or maybe the Python, OCaml, Perl, Ada, or Guile bindings are of interest.
Re:Is THIS insightful? (Score:1)
Re:Eh? (Score:1)
Re:Gnome:forever two years behind (Score:3)
Linux supports Java, Flash, MP3, and MPEG. RealNetworks also has a client for Linux.
The only significant content that is not easily supported on Linux is stuff for Windows Media Player and Quicktime. And there is nothing that "unix geeks" can do about it: that's proprietary content in proprietary formats, and you are at the mercy of a couple of big companies.
The solution to that problem is to "just say no" and complain to web masters. Tell CDNOW and Amazon that you aren't going to buy if they don't provide all samples in MP3 or some other open format. It is stupid for them to put content in proprietary formats, and it is stupid for you as a user to support those formats, whether you are using UNIX, Windows, or MacOS.
Gnome supports drag and drop just fine. As for actual levels of functionality, there is very little difference between Windows 95 and Windows 2000, so if Gnome is close to one, it's close to the other.
Re:Good so far (Score:1)
I want a file manager that inserts the file I click on into the command line. I want a file manager that opens a command line in the directory I'm working in. Is this too much to ask? Probably, I'm stuck on windows with some morons that nest directories to 10 levels and give files 25 character names.
Re:how about a total rewrite.. (Score:2)
The problem with toolkits like Gtk and Qt is not in their object orientation, it is with other aspects of the underlying C/C++ languages, foremost lack of reflection and runtime safety.
Gtk (and Qt, for that matter) gets somewhat easier and safer to use if you use a language binding to something like Python. That doesn't make the toolkit itself any easier to extend, but it helps with application programming.
Re:More like KDE, not windows (Score:1)
Ah no, GNOME/ Nautilus is not cheating in that way. The Mozilla component is not preloaded, it is only loaded when you are viewing a webpage and unloaded when you are not.
Re:When will it end? (Score:2)
1) The HTML engine isn't in your file manager - it calls out to mozilla
2) Most of the components are separated
3) Yes, most developers went nuts a long time ago
4) Nautilus looks like it will do a great job of managing files. I especially like the "tag" concept - you can tag files with various markings, and then search by those markings - very nice.
Integration is good and bad. We'll see how well it works.
Re:"Linux currently satisfies..." (Score:1)
Yeah, right. And you'll never need more than 640K.
Re:how about a total rewrite.. (Score:2)
I don't remember exactly, but it is something like this:
Each object is a pointer to data. The first data item is a pointer to the virtual method table. The virtual method table has the entries for the functions. So, when I do
gtk_object_show(myobject);
it is a macro for
(*myobject->methods->showMethod)();
Or something like that. This is basically the way C++ handles it internally, too. Anyway, you get full inheritance. However, it does not currently support multiple inheritance or interfaces. However, for GUI programming, those aren't terrible deficiencies.
It is _much_ easier to code it in C and then bind it to other languages, than to code it in an OO language first, and then try to do language bindings to other OO languages.
Re:When will it end? (Score:1)
I really don't know why open source developers get caught in this trap. For corporations, the reason seems clear to me. Most major software houses seem to have long term plan of making a profit by conquering the world ;), but I don't know why open source developers do it.
I'm happy that the company I work for is only trying to take over managing your geographic data, and not your whole desktop.
Re:The Biggest Problem with Gnome and KDE (Score:2)
Re:how about a total rewrite.. (Score:2)
Re:The Biggest Problem with Gnome and KDE (Score:2)
Could you tell us what makes you think that DnD is broken? I am sure that the developers would like to know this, and I would love to fix things that are annoying users.
Okay. In Mandrake 7.2, Red Hat 6.2 with the relevant updates, or SuSE 7.0, one cannot drag an FTP link out of a KDE 2.01 Konqueror onto a GNOME 1.2+ desktop.
The 2 sets of mime types is indeed annoying.
KDE docklets work in GNOME just fine.
Perhaps its just that no user interface seems to provide them - when I right click on the gnome panel, I can't see them listed there as possibilities to add [latest versions of both]. Oddly enough, I attended Linux.conf.au and asked Marceij and his companion [apologies about the spelling] about this personally and he said it was something which *might* be in GNOME 2.0.
In general GNOME integrates the KDE menu into its own menu. Ideally we should be sharing the same menu.
I don't think that's a case of ideal. I think its a case of basic logic. Look at Red Hat 7's GNOME 1.2. You need to find an Internet app...will it be under Foot -> Internet ? Foot -> Red Hat -> Internet (even though Red Hat didn't write it)? Or Foot -> KDE Menus -> Internet? There's no reason for end users to distinguish between applications based on toolkits and their preferred desktop. Just like there's currently no reason to theme the artwork around windows differently from the other aspects of my system.
I agree with you about the themes. I have suggested in the past to the KDE people to write together an cross-theme API that would allow theme engines to be written once, and used everywhere, but there was not too much enthusiast on Matthias part. He has since stalled saying that `he has an idea for this, and that he will post later', but the idea has yet to happen. The approach of having a unified subset of the API calls required to have a theme engine is not only doable but simple.
That's excellent - but you don't really need Matthias' permission to start hacking on KDE. Just put an announcement out you're starting work and that anyone interested might like to give you a hand.
More importantly, feel is the more important aspect of `look and feel'. Is there anything done about having a unified style guide for both projects (and possible others)?
Re:The Biggest Problem with Gnome and KDE (Score:1)
Linux Kernel was made from (supports) many standards: Posix, ISO, RFCs, ANSI ... It has very good filesystem, code tables, and probably the best network support. But they had standards.
X Consortium wrote standards for X Windows. And they work great. I run about twenty computers from one server with X Windows and it works great. I couldn't do that so simple with Microsoft's systems.
But X Consortium didn't tell us much what to do with desktops. They haven't written any standards for it. They just showed us an example of a desktop that was very poor.
I think this is the reason why there are two desktops and they can't decide what will be with them. One must die. But the best way would be to cooperate, if it was still possible.
There are no standards for X Windows Desktops. Microsoft is here ahead of Linux, because they can write their own standards. Their systems have for example common protocol for sharing objects with drag and drop, cut and paste, and for intercontroling applications and also for tray applets (OLE,COM,DCOM,...).
This is what those desktops need for the start. Somebody has to write standards, a third person, so that both desktops will support it. Corba is probably a standard, that could do the job here.
Offtopic: One of the desktops simply mustn't die. Because if dies, then the other would start to write standars and make a monopol. Monopol - look what happened with Microsoft.
Developers of KDE and Gnome are doing a great job. But they sometimes just run out of material, how to do something, and they have to make up something new. That is not good. They need standards.
Re: Troll? (Score:2)
Sorry. I've spent a week talking with Eazel employees and KDE developers at the conference and the outlook so far seems pretty bleak.
"I have 2 sets of mime types
My KDE panel applets won't launch in the GNOME panel, and vice versa"
This sort of interoperability is being worked on even now as we speak. Don't expect overnight perfection.
Really? According to Marciej and George, who I asked personally about this item at their talk at Linux.conf.au, while the mime types issue *may* be being worked on some time in the future, the Panel applet interoperability is something we *might* expect for GNOME 2, but not something the GNOME team are really working on.
If you look at the history of KDE and GNOME, you'll find that the developers desire this compatibility and have been slowly but surely implementing it.
Really? All I see is a standardized drag and drop that's been bandied about for a couple of years and doesn't work consistently. And symlinks in the menus.
"When I add an application the the kpanel, it doesn't appear on the foot menu, and vice versa
It's one thing for the main root menus of the respective desktops to recognize the menus of the other, and display them. I expect this interoperability very soon.
Again, the KDE and GNOME developers I asked about these things generally put it on the very bottom of their things to do list.
But you're talking about *panels* here. Switching between panels is going to be a rare occurance. And the process of adding an item to a panel takes approximately 8.5 seconds.
I meant menus. Sorry.
"QT and GTK are themed using different engines, with no reason why."
Plenty of reason why, if you would just use your head.
But I won't `use my head', I refuse to, because neither will any end user. End users don't give a damn about toolkits. They just want to know why they have to learn to save files in Gimp and how to save files in Kword, because they're `different'.
Both of these toolkits are distinct from each other. They are developed by distinct groups of people.
Really? So are MFC and VCL. They just work together seamlessly...
And their theming engines have distinct goals. QT themes are more powerful than GTK themes in some ways, and GTK themes are more powerful than Qt themes in others.
Then take the best bits and combine them. Sorry, any inherent powerfulness in themes [not the biggest demand from most end users] should be much less on a UI developers list of priorities than consistency of user interface. AFAIK all non-Unix based User Interface engineers acknowledge this, with guides to UI consistency available for MacOS, Windows, and Be.
I for one do not want a theme engine based on the lowest common denominator.
Well, I'm sorrry, every other UI designer does, and useability testing reveals consistency works.
"Imagine a Windows user clicking Start to reveal `MFC applications' `VCL applications' etc."
Apples and oranges. My KDE menu most certainly does NOT distinguish between Motif, Qt, Fox, FLTK and GTK applications. KDE and GNOME are desktops , they are not widget toolkits.
There are KDE and GNOME specific widgets, but I was talking about QT and GTK [without stating it, I thought it would be obvious].
To make the proper analogy, imagine a Windows user clicking the main menu to reveal "Windows applications", "DOS applications", "BeOS applications", "Mac applications",
Um, no. If I was a troll, I would say something a little more blunt here. But I won't. Those QT, GTK, and Motif apps are alll native Linux binaries. I think it is you who is comparing apples and oranges. I love Linux, and use it as my primary platform. But if we never acknowledge its deficiencies, it won't improve.
I think you have your heart in the right place by defending a good OS against criticism. But it is due criticism based on widely accepted wisdom of UI design which if heeded will improve the platform, IMHO.
Re:The Biggest Problem with Gnome and KDE (Score:2)
The problem with Open Source, is that it is manifestly all just re-inventing the wheel. GNOME/KDE are re-inventing the GUI wheel (with few new ideas thrown in). The kernels are re-inventing the inode/process/threads wheel.
There is absolutely no new research [I'll make an exception for those brilliant Ogg Vorbis coders]. And it is new research which is going to free programmers from re-inventing the wheel, because current language idioms fail spectacularly in re-use. [And GNU/Linux is based on old language idioms from C - it isn't even up-to-date with advances like C++ which improve code re-use somewhat, but still don't solve the problem. Still, the coders can sit back and pretend that OOP can be done effectively in C].
Unfortunately, the only way for research to happen is by funding, and the only way to fund research is to make a profit on your development. Microsoft knows this.
So expect Microsoft to come out with a bunch of new ideas in the next 10 years, and expect Linux to re-invent them (with a few extra bells and whistles) in the next 15. I submitted a story a year ago about one of Microsoft's initiatives - Intentional Programming. This shows real possibilities for write-once, compile-anywhere coding.
The story was rejected, naturally.
how often do we need to know gnome's future? (Score:5)
Re:Excuse me but ... (Score:1)
Funnily enough, sharing object code between applications actually reduces bloat.
RE: Congrats Aussies! (Score:1)
I DID!
Also, a (possible) new control centre for Gnome 2.0? Sounds interesting, anybody got anymore information on this?
When will it end? (Score:4)
A file manager that plays mp3's, browses the web, zooms in, displays the actual text of files within the icon, contains the nuclear launch codes, has support for themes, is very configurable....
HEY!!! Did that just say what I think I said? Yup, I guess these open source blokes have finaly gone a bit too far with this "World Domination" thing.
47.5% Slashdot Pure(52.5% Corrupt)
"Linux currently satisfies..." (Score:2)
I guess those people expect a working raid subsystem (one that actually works after rebooting) must be living in some kind of alternate reality
Re:how about a total rewrite.. (Score:4)
--Ben
Re:Has anyone pointed out that Disuss is not a wor (Score:2)
On behalf of desideria's family, I would like to announce some sad news. It appears that several minutes ago he had a stroke; the result of something the doctors called an "oxymoronic inquiry stack overflow failure". We aren't entirely sure what that means, but they said shock therapy might help. We'll keep you posted.
In the Slashdot Trenches - Funny (Score:4)
Narrator: "In their ongoing battle to slashdot sites out of existance, CmdrTaco and his minions, Jamie and Timothy find themselves in a dire predicament."
CT: "That linux.com.au site seems to be holding up very well. Any ideas men?" Jamie: "This business is getting harder and harder. How can we see our power manifested unless we can slashdot some sites. Don't they know who they are dealing with?"
CT: "Obviously not. Our only solution is to post the link again." Timothy: "Wait commander, won't the hordes of lemmings who read the page more than once a day realize that you posted the same story twice? They won't beleive it."
CT: "You're right, a bit too obvious. Why don't YOU post the story."
Jamie: "Excellent idea, then, when they are slashdoted, I can post a story claiming they were CENSORED."
Narrator: "Meanwhile, far from the geek compound in homes and NOC's across the world, geeks and wannabe geeks experience a strong sense of deja-vu, and wonder at the effects gallons of Jolt has injested while sitting a climate controlled room. The ones who realize what is going on on the other hand are a bit quicker in the future to minimize slashdot when their PHB's walk by."
I guess if the good discussion has already happened, we should just have some fun.
One Gnome annoyance for you developers (Score:2)
Re:The right UI with the wrong code (Score:3)
You see, the problem is consistency. The fewer libraries, the less consistent everything is, and programmers have to code their own everything. Why not put it all in ONE BIG LIB? Because not everyone needs everything. If I'm not embedding other objects, I surely don't need Bonobo. If I don't print, why link with gnome-print? Anyway, if you like life on the bleeding edge, download all the libraries and play. I personally prefer to wait until it all comes in a nice package. And then you don't have to worry about any of that.
Re:The Future of Gnome, simplified (Score:2)
Re:how about a total rewrite.. (Score:2)
Re:how about a total rewrite.. (Score:2)
It's possible to code badly in any language. It's not really fair to blame the language for badly-written code.