Both KDE and GNOME follow the same basic cycle: large dramatic changes in infrastructure and layout are followed by years of relatively small, incrememental changes. How many years did KDE go between 2.0 and 4.0? (KDE 3.0 was a break in ABI but the infrastructure and layout were largely the same.) And how many years have there between GNOME 2.0 and the planned GNOME 3.0 next year?
The big difference right now is that KDE made their big change last year and are now incrementally fixing, improving things. GNOME, on the other hand, are working on their big change, which will land next year. The cycle is the same, but the two projects are on different parts of this cycle right now.
There are a couple smaller differences, as well. First, as I understand it, KDE developed many parts of their new infrastructure for a couple years, and this infrastructure landed for use at KDE 4.0. GNOME seems to be inserting many pieces of its new infrastructure in the GNOME 2.x cycle before putting all the new pieces together in GNOME 3.0. On the one hand, this means that the various pieces will (hopefully) get more testing, and thus more bugfixing, before 3.0. On the other hand, 3.0 becomes a little bit less exciting because piece x and piece y are not exactly new. The second difference is that Qt underwent a big overhaul for its 4.x series, which forms the basis of KDE 4.0, whereas GTK 3.0 will be cleaned up, rather than radically changed.
This does not mean that big new technologies are not going to be in GNOME 3.0. Clutter, gjs, seed, and gnome introspection, to take a few examples, are separate libraries that will form the backbone of GNOME 3.0. It seems to me that tech journalists hear the news about GTK+ 3.0 and decide that GNOME 3.0 will have no changes. That should not be the case at all: next generation GNOME shell.
Well, it sounds like you don't really want to give Gnome much of a chance. If it varies at all from your experience, you slam it-- even if Gnome provides other ways to do what you want it to do.
Pressing '/' or control + L is an extra step? How so? If you open up a file chooser with a location bar present, you must first click on the location bar or tab your way until it is selected. Either way will need at least one keystroke or, worse, taking your hands off the keyboard to click the mouse. On the other hand, if you press '/', then you have already started entering in the location without any preliminary keystrokes. This is actually *more* efficient. (If, for the sake of argument, the location bar is the first thing selected in the filechooser, it is simply as efficient as typing '/' to begin with. There is still no extra step.)
As you acknowledge, there is filename completion available: just start entering the name. What is so hard about that?
Gnome didn't swap the Ok and Cancel buttons. They placed the button most likely to be pushed to the edge of the window, where it is easier to be accessed. This has to do with Fitts Law. The Gnome HIG also recommends that the buttons have descriptive terms, such as "Don't Save" and "Save" rather than "Ok" and "Cancel." This isn't such a crazy idea, you know. Apple does it too, and everyone and their brother seem to think that Apple gets everything right.
The changes Gnome made were meant to make things better. You may agree or disagree whether the changes actually made things better, but if you read the mailing list archives, it becomes clear the intent was certainly good. Gnome did not make changes "just to be different."
The location bar is still available. Without taking your hands off the keyboard, press control+ L and start typing the location you want. Or, (again without taking your hands off the keyboard), type the location starting with the root '/'. In both cases, the address bar magically pops up and is highlighted for text entry.
In the newest GTK+, there will also be a button next to the path bar, which, when pushed, will open up a location bar. This new button will make the whole location bar a bit more discoverable, fortunately.
In any case, to address your complaint: in Nautilus (and in any GTK+ application using the standard file dialogues), you can get to the location bar without clicking on the mouse.
When in the open or save dialog, type control l (that's the letter, not the number one). Voila. You have your address box.
This feature has been around for ages, and people keep pointing it out everytime someone like the parent poster complains. The problem is how to make the feature discoverable, and no one has been interested enough to step forward and code a good solution.
Re:Why I won't use GTK.
on
Why Use GTK+?
·
· Score: 1
(1) a GUI toolkit must be object-oriented: ok, as you mostly concede, GTK+ is object-oriented. Point (1) is moot.
That is not what I said. What I said was the people like you claim it is. Its not, anymore then it is possible to write high level code in a macro assembler.
Well, then how do you define "object oriented"? GTK+ allows for subclassing, for instance. see here, which references subclassing. See also the GTK+ tutorial at gtk.org, which states, "GTK is essentially an object oriented application programmers interface (API). Although written completely in C, it is implemented using the idea of classes and callback functions (pointers to functions)." I believe GTK+ also allows for encapsulation.
GTK+ *is* object-oriented. You just want an object-oriented language as well. That's fine. Pick one of these. Good luck.
Re:Why I won't use GTK.
on
Why Use GTK+?
·
· Score: 1
To dissect your comment:
(1) a GUI toolkit must be object-oriented: ok, as you mostly concede, GTK+ is object-oriented. Point (1) is moot.
(2) a GUI toolkit must be written in an object-oriented language. Ok, why is that so? Sure, a language with built-in object-oriented features makes things easier for you. On the other hand, C has the advantages of (a) relatively easy to compile everywhere, (b) ABI compatible, and (c) relatively easy to bind with other languages.
(3) language wrappers just get in your way, and for Gnome, are poorly maintained. I can see how debugging a program can be more difficult in deciphering whether the bug originates in the wrapper code or the underlying C code. In practice, does this happen very often? More pointedly, what evidence do you have that GTKmm is poorly maintained? Murray Cumming will be very interested to hear why you think that, especially as he puts out new releases with the Gnome release schedule, every six months.
It sounds like your criticism is mainly that you don't like C for GUI programming and are therefore damning all of GTK+, even though many programs written in other languages use GTK+ happily. GTK+ is a very nice toolkit used by people who like C, C++, Perl, Python, Ruby, and other languages. Some of the most active GTK+ projects these days are written in C++, C#, and Python. As Owen Taylor, a principal GTK+ developer, has said, one of GTK+'s goals is to help people write GUI code in whatever language they like best. It was designed with that goal in mind. So, feel free to write your code in whatever OOP language you like. GTK+ will likely be there to help you. Cheers!
Summary of your thought: a Gnome developer was misinformed about the reason for the UI of a Gnome module. The Gnome developer who *was* responsible for the UI corrected the mininformation. Gnome, however, is still guilty.
You may be correct that KDE bundles more software in its release, thus making it harder to achieve the 80% "supported" category for each language. I'm not familiar enough with KDE to say one way or another.
I will point out, however, that the release notes for Gnome 2.12.0 says that Gnome has 43 supported languages. That is, 2.12.0 has 43 supported languages, whereas 3.5.0 has 23. So, in some sense, I am still comparing apples to apples.
All of that is besides the point, though. The point is that *both* desktops have very good internationalization. The claim that KDE's internationalization is vastly superior to Gnome's just seems very suspect, unless that poster can come up with more than a blanket statement without any evidence.
So, currently Gnome supports* 43 languages, and KDE supports 23 languages.**
It is not at all obvious to me how KDE's internationalization is so superior. If you could explain your rather blanket statement, I would appreciate it. Otherwise, it seems to me that both desktops have excellent internationalization. Kudos to both KDE and Gnome.
* "supports" defined as at least 80% of strings translated. ** Note: I'm sure KDE will support more languages as their 3.5.1 release comes out: the x.y.1 usually has a lot of attention devoted to translations.
It's strange how the underlying article mentions GNOME accessibility over and over again as being even superior to Microsoft ones to date, and yet all the comments completely ignore GNOME's framework.
Robert Love is from the Ximian division (see here). He is also a kernel hacker. (See, e.g., here; see also here.)
So, the comment may not have been sarcastic at all. Ximian actually does have at least one very accomplished Linux kernel hacker.
One of the main goals of the Evolution 5.x/2.0 release is to better separate the different modules, so that separate mail, calendar, task, and contact programs will be much, much easier. The frontend/backend split (i.e. Evolution and evolution-data-server) and simplified APIs will help in this regard, as will the deprecation of the tree-view side-panel. The Evolution hackers are also toying with making stand-alone shells for the calendar, task, contact, and email programs. With the new structure, such separation should be much simpler.
*The first link (Criawips): http://savannah.nongnu.org/projects/c riawips/
*The second link (Martin's comment): http://www.gnomedesktop.com/comments.ph p?op=showre ply&tid=17276&sid=1353&pid=17268&mode=thread&order =0&thold=#17276
An astute observation. No, there is no GNOME Office PPT equivalent as yet. However, there is good news on the horizon: the Abiword folks are working with Sven Herzberg in creating just such an application, using the Abiword and GNOME libraries. See Criawips. Yes, the name is a bit odd, but some prominent hackers, including Martin Sevior of Abiword fame, are keen to work on this program to round out the core of GNOME office (see the Footnotes story, comment by Martin, for example).
Re:GDK vs. GTK
on
Qt On DirectFB
·
· Score: 5, Informative
Not exactly. GDK is an *abstraction* layer with multiple backends, the X11 one being the most prominent. To quote from the GTK/GNOME developers' website: "Instead of directly building on top of the X Window System, GTK+ introduces an intermediate layer, GDK, which isolates GTK+ from the details of the windowing system. This simplifies things for the programmer and increases portability." See the webpage. Through GDK backends, GTK has been ported to MSWindows as well as DirectFB(see also here).
I hope that helps.
Re:I was hoping they would wait.
on
New Red Hat Beta
·
· Score: 1
Yes, this is *definitely* a conspiracy against KDE by Red Hat!!! Damn them!!!
P.S. Gnome 2.2, which will be VERY nice and will be another big step forward for Gnome, is due to be released on January 29th. Please see the Gnome release schedule. *sarcasm* You would think that Red Hat, as a big supporter of Gnome, would delay the release of 8.1 to get in the newest, greatest Gnome, wouldn't you? *end sarcasm*
FreeLinux said:
KDE 3.1 has been delayed until early/mid January for a security audit. KDE 3.1 is VERY nice and is another big step forward for KDE. I had hoped that Red Hat would delay their 8.1? release until KDE 3.1 could be included. Unfortunately it looks like we will still have the "crippled" KDE 3.0.5 in Red Hat 8.1.
I definitely understand that Red Hat has an affinity for Gnome, and that's fine for them, but for full compatibility you really need to install both Gnome and KDE so why not have the best KDE?
With Mandrake's newly returned cash crunch, Suse is looking like a strong contender on the distro front. However, don't forget Knoppix, the newest "distro".
Most reports are to the contrary: GNOME2 is considered much faster than GNOME 1.4, especially with regard to Nautilus. You should try out GNOME 2.02 parallel installed through one of the new distributions or through GARNOME, for example.
Slashdot Mirror
You might say that his conviction went down the tubes.
Both KDE and GNOME follow the same basic cycle: large dramatic changes in infrastructure and layout are followed by years of relatively small, incrememental changes. How many years did KDE go between 2.0 and 4.0? (KDE 3.0 was a break in ABI but the infrastructure and layout were largely the same.) And how many years have there between GNOME 2.0 and the planned GNOME 3.0 next year?
The big difference right now is that KDE made their big change last year and are now incrementally fixing, improving things. GNOME, on the other hand, are working on their big change, which will land next year. The cycle is the same, but the two projects are on different parts of this cycle right now.
There are a couple smaller differences, as well. First, as I understand it, KDE developed many parts of their new infrastructure for a couple years, and this infrastructure landed for use at KDE 4.0. GNOME seems to be inserting many pieces of its new infrastructure in the GNOME 2.x cycle before putting all the new pieces together in GNOME 3.0. On the one hand, this means that the various pieces will (hopefully) get more testing, and thus more bugfixing, before 3.0. On the other hand, 3.0 becomes a little bit less exciting because piece x and piece y are not exactly new. The second difference is that Qt underwent a big overhaul for its 4.x series, which forms the basis of KDE 4.0, whereas GTK 3.0 will be cleaned up, rather than radically changed.
This does not mean that big new technologies are not going to be in GNOME 3.0. Clutter, gjs, seed, and gnome introspection, to take a few examples, are separate libraries that will form the backbone of GNOME 3.0. It seems to me that tech journalists hear the news about GTK+ 3.0 and decide that GNOME 3.0 will have no changes. That should not be the case at all: next generation GNOME shell.
He who bombs a thing to find out what is in it has left the path of wisdom.
That's just loonie.
Well, it sounds like you don't really want to give Gnome much of a chance. If it varies at all from your experience, you slam it-- even if Gnome provides other ways to do what you want it to do.
Pressing '/' or control + L is an extra step? How so? If you open up a file chooser with a location bar present, you must first click on the location bar or tab your way until it is selected. Either way will need at least one keystroke or, worse, taking your hands off the keyboard to click the mouse. On the other hand, if you press '/', then you have already started entering in the location without any preliminary keystrokes. This is actually *more* efficient. (If, for the sake of argument, the location bar is the first thing selected in the filechooser, it is simply as efficient as typing '/' to begin with. There is still no extra step.)
As you acknowledge, there is filename completion available: just start entering the name. What is so hard about that?
Gnome didn't swap the Ok and Cancel buttons. They placed the button most likely to be pushed to the edge of the window, where it is easier to be accessed. This has to do with Fitts Law. The Gnome HIG also recommends that the buttons have descriptive terms, such as "Don't Save" and "Save" rather than "Ok" and "Cancel." This isn't such a crazy idea, you know. Apple does it too, and everyone and their brother seem to think that Apple gets everything right.
The changes Gnome made were meant to make things better. You may agree or disagree whether the changes actually made things better, but if you read the mailing list archives, it becomes clear the intent was certainly good. Gnome did not make changes "just to be different."
That problem is being rectified in the newest GTK+. See screenshots of the visible button which will pop up the location bar:
http://home.arcor.de/famscheffler/gfc/gfc.png
http://home.arcor.de/famscheffler/gfc/gfc-loc.png
The location bar is still available. Without taking your hands off the keyboard, press control+ L and start typing the location you want. Or, (again without taking your hands off the keyboard), type the location starting with the root '/'. In both cases, the address bar magically pops up and is highlighted for text entry.
In the newest GTK+, there will also be a button next to the path bar, which, when pushed, will open up a location bar. This new button will make the whole location bar a bit more discoverable, fortunately.
In any case, to address your complaint: in Nautilus (and in any GTK+ application using the standard file dialogues), you can get to the location bar without clicking on the mouse.
Cheers!
When in the open or save dialog, type control l (that's the letter, not the number one). Voila. You have your address box.
This feature has been around for ages, and people keep pointing it out everytime someone like the parent poster complains. The problem is how to make the feature discoverable, and no one has been interested enough to step forward and code a good solution.
(1) a GUI toolkit must be object-oriented: ok, as you mostly concede, GTK+ is object-oriented. Point (1) is moot.
That is not what I said. What I said was the people like you claim it is. Its not, anymore then it is possible to write high level code in a macro assembler.
Well, then how do you define "object oriented"? GTK+ allows for subclassing, for instance. see here, which references subclassing. See also the GTK+ tutorial at gtk.org, which states, "GTK is essentially an object oriented application programmers interface (API). Although written completely in C, it is implemented using the idea of classes and callback functions (pointers to functions)." I believe GTK+ also allows for encapsulation.
GTK+ *is* object-oriented. You just want an object-oriented language as well. That's fine. Pick one of these. Good luck.
To dissect your comment:
(1) a GUI toolkit must be object-oriented: ok, as you mostly concede, GTK+ is object-oriented. Point (1) is moot.
(2) a GUI toolkit must be written in an object-oriented language. Ok, why is that so? Sure, a language with built-in object-oriented features makes things easier for you. On the other hand, C has the advantages of (a) relatively easy to compile everywhere, (b) ABI compatible, and (c) relatively easy to bind with other languages.
(3) language wrappers just get in your way, and for Gnome, are poorly maintained. I can see how debugging a program can be more difficult in deciphering whether the bug originates in the wrapper code or the underlying C code. In practice, does this happen very often? More pointedly, what evidence do you have that GTKmm is poorly maintained? Murray Cumming will be very interested to hear why you think that, especially as he puts out new releases with the Gnome release schedule, every six months.
It sounds like your criticism is mainly that you don't like C for GUI programming and are therefore damning all of GTK+, even though many programs written in other languages use GTK+ happily. GTK+ is a very nice toolkit used by people who like C, C++, Perl, Python, Ruby, and other languages. Some of the most active GTK+ projects these days are written in C++, C#, and Python. As Owen Taylor, a principal GTK+ developer, has said, one of GTK+'s goals is to help people write GUI code in whatever language they like best. It was designed with that goal in mind. So, feel free to write your code in whatever OOP language you like. GTK+ will likely be there to help you. Cheers!
Summary of your thought: a Gnome developer was misinformed about the reason for the UI of a Gnome module. The Gnome developer who *was* responsible for the UI corrected the mininformation. Gnome, however, is still guilty.
Nice.
You may be correct that KDE bundles more software in its release, thus making it harder to achieve the 80% "supported" category for each language. I'm not familiar enough with KDE to say one way or another.
I will point out, however, that the release notes for Gnome 2.12.0 says that Gnome has 43 supported languages. That is, 2.12.0 has 43 supported languages, whereas 3.5.0 has 23. So, in some sense, I am still comparing apples to apples.
All of that is besides the point, though. The point is that *both* desktops have very good internationalization. The claim that KDE's internationalization is vastly superior to Gnome's just seems very suspect, unless that poster can come up with more than a blanket statement without any evidence.
Both desktop environments appear to have very good internationalization.
m l and http://www.gnome.org/i18n/
For Gnome: http://www.gnome.org/start/2.12/notes/en/rni18.ht
For KDE: http://i18n.kde.org/stats/gui/stable/toplist.php
So, currently Gnome supports* 43 languages, and KDE supports 23 languages.**
It is not at all obvious to me how KDE's internationalization is so superior. If you could explain your rather blanket statement, I would appreciate it. Otherwise, it seems to me that both desktops have excellent internationalization. Kudos to both KDE and Gnome.
* "supports" defined as at least 80% of strings translated.
** Note: I'm sure KDE will support more languages as their 3.5.1 release comes out: the x.y.1 usually has a lot of attention devoted to translations.
Regarding your comment that accessibility should be built into the toolkit by default, you're described the GNOME accessibility architecture:
h tml
/ at-spi-docs/book1.html
See, e.g., http://developer.gnome.org/doc/API/2.0/atk/index.
See also http://developer.gnome.org/projects/gap/tech-docs
Here's the home page for the GNOME accessibility project (GAP): http://developer.gnome.org/projects/gap/
It's strange how the underlying article mentions GNOME accessibility over and over again as being even superior to Microsoft ones to date, and yet all the comments completely ignore GNOME's framework.
Robert Love is from the Ximian division (see here). He is also a kernel hacker. (See, e.g., here; see also here.) So, the comment may not have been sarcastic at all. Ximian actually does have at least one very accomplished Linux kernel hacker.
One small correction:
GNOME *does* have the navagational paradigm, which is readily available within Nautilus menus. Navagational Nautilus is simply not the default mode.
While the spatial Nautilus decision was certainly controversial, it hardly seems worth the continuing flamewars over it.
Ok, but first a couple questions:
1) what license will the Dirac codec be released under? (GPL, GPL w/ linking exception, LGPL, MPL, BSD, MIT X11 license, non-open source license?)
2) where is the code repository?
(The Register link froze on me; so, I apologize if these questions are answered in the linked article.)
Microsoft owns the code to Windows
SCO owns the code to Linux
Microsoft is financing SCO.
Therefore, Microsoft effectively owns SCO.
Thus, Microsoft owns the code to Linux.
Result: there is no difference between Windows and Linux!
One of the main goals of the Evolution 5.x/2.0 release is to better separate the different modules, so that separate mail, calendar, task, and contact programs will be much, much easier. The frontend/backend split (i.e. Evolution and evolution-data-server) and simplified APIs will help in this regard, as will the deprecation of the tree-view side-panel. The Evolution hackers are also toying with making stand-alone shells for the calendar, task, contact, and email programs. With the new structure, such separation should be much simpler.
Cheers!
See here:
http://gnome-de.org/criawips/about.php#name
Hey, what happened to my hyperlinks?
c riawips/
h p?op=showre ply&tid=17276&sid=1353&pid=17268&mode=thread&order =0&thold=#17276
Fine, here it is in plain text:
*The first link (Criawips):
http://savannah.nongnu.org/projects/
*The second link (Martin's comment):
http://www.gnomedesktop.com/comments.p
Cheers!
An astute observation. No, there is no GNOME Office PPT equivalent as yet. However, there is good news on the horizon: the Abiword folks are working with Sven Herzberg in creating just such an application, using the Abiword and GNOME libraries. See Criawips. Yes, the name is a bit odd, but some prominent hackers, including Martin Sevior of Abiword fame, are keen to work on this program to round out the core of GNOME office (see the Footnotes story, comment by Martin, for example).
Not exactly. GDK is an *abstraction* layer with multiple backends, the X11 one being the most prominent. To quote from the GTK/GNOME developers' website: "Instead of directly building on top of the X Window System, GTK+ introduces an intermediate layer, GDK, which isolates GTK+ from the details of the windowing system. This simplifies things for the programmer and increases portability." See the webpage. Through GDK backends, GTK has been ported to MSWindows as well as DirectFB(see also here).
I hope that helps.
P.S. Gnome 2.2, which will be VERY nice and will be another big step forward for Gnome, is due to be released on January 29th. Please see the Gnome release schedule. *sarcasm* You would think that Red Hat, as a big supporter of Gnome, would delay the release of 8.1 to get in the newest, greatest Gnome, wouldn't you? *end sarcasm*
FreeLinux said:
Most reports are to the contrary: GNOME2 is considered much faster than GNOME 1.4, especially with regard to Nautilus. You should try out GNOME 2.02 parallel installed through one of the new distributions or through GARNOME, for example.