Linked by Thom Holwerda on Sat 5th Nov 2005 17:51 UTC, submitted by AdriAn Avila
Novell and Ximian Rumors circulating that Novell is going to kill off its popular Linux desktop lines are completely false. [However,] Novell is making one large strategic change. The GNOME interface is going to become the default interface on both the SLES and Novell Linux Desktop line. KDE libraries will be supplied on both, but the bulk of Novell's interface moving forward will be on GNOME. "The entire KDE graphical interface and product family will continue to be supported and delivered on OpenSuSE."
Permalink for comment 56765
To read all comments associated with this story, please click here.
RE[6]: Developer's POV
by Anonymous on Sun 6th Nov 2005 10:25 UTC in reply to "RE[5]: Developer's POV"
Member since:

> The toolbar is an object/class in GTK+. Developers are
> at liberty to set it up however they like. As usual,
> spouting bullocks you know nothing about.

Lateef, you are wrong. First of all you need to distinguish between a class and an object. A class is some sort of abstraction to define an object. And if developers "set it up differently" they simply create different objects out of it.

The Evince toolbar offers a toolbar editor so it's basicly a different object than the initial object as found inside GTK+. If we build up using the GTK+ object then we usually call it subclassing. That is adding or overwriting existing class definitions and attributes. The result is a new object as in this case it's an Evince toolbar object.

But now imagine this, it would have been better to move the toolbar editor object code inside GTK+ to make this a default behavior of the internal GTK+ toolbar object and as soon as we inherit that object in our applications we instantly would allow all our apps to use that toolbar editor.

Since this is not happening we deal with even more toolbar objects than the basic ones we already have (GTK+, GNOMEUI, BONOBOUI, the ones through bindings).

If the GTK+ toolbar object was designed correctly then it would allow us to do this (out of the object itself)

a) describe whether we want handles or not (to drag the toolbar out of the app or align it horizontally, vertically, at the bottom or the top or inside other toolbar elements)

b) allows us to globally set the icon size (as KDE offers this possibility by right clicking on the toolbar object)

c) allows us to globally edit the toolbar and save the results in a configuration file so it stays permanent.

d) react on global changes set through control center.

But within this screenshot:

You see all the toolbars to be different. Some toolbars already come with drag handles, others come without one, other toolbars are essentially bigger (higher even if its just 1-2 pixels) than others, other toolbars already come with text below icons while others come as icons only on default.

For me these are all "new objects" or different humans such as an indian, an afro american, a chinese, a japan, a turk and so on.

KDE offers one toolbar object which already is defined with many methods and attributes. This object is inherit in all applications as object (and not via functioncall). The objects do look the same while providing an interface to define own toolbar actions (such as a new button, save button, forward and backward button, help button, zoom in zoom out zoom 100% button and so on.

Also the bindings that exist for GNOME are quite incomplete or broken I don't know how valid this is for pythong (since I assume that python bindings are quite good) but there are other bindings who'se toolbars look differently because the maintainers are bone headed to inherit the default objects correctly.

Now GNOMEUI and BONOBOUI as far as their maintainers told me inherit their toolbar code from GTK+ but yet the GNOMEUI and BONOBOUI toolbars are new objects since they react and do basic things totally differently than others.

Now it's a known fact for over one year and longer that GNOMEUI and BONOBOUI are going to be deprecated and disappear (for me this process is not going on fast enough) but there are still people who "style their own toolbar objects" and this is not acceptable. At least not for a corporate desktop that wants to be coherent and clean.

The abiword toolbar for example is nearly 4 bixels bigger than the other toolbars - why ? All this mess with different "toolbar art" only says that there is something dramatically wrong with GTK+ otherwise I can't see the point for applications to create new objects.

Besides said that, I don't see the point for Evince providing a toolbar editor. I say this because there are far other issues with Evince (even basic tasks) that it can not accomplish correctly due to crashes, due to not implemented (like printing correctly) so I wonder where the priorities are set.

Wouldn't it have been better to provide the toolbar editor code towards GTK+ for global acceptance and global effect ?

> As usual, spouting bullocks you know nothing about.

I think the guy who spouts out bollocks and who know nothing about is you otherwise you would have been agreeing with me as everyone else whom I have shown the problem agreed with me. The reason why I come up with the toolbar issue is, that the toolbar issues is pretty easy to explain. It's so easy that even non-technical people get an idea of what I am trying to explain them.

There are dozens of other issues that I could easily throw up here but I avoid indepth enmeshment with developers and people.

Having different toolbars is not an advantage, it only leads to irritation.

Say you get a new user for GNOME and that user starts using GNOME for the first time, he first starts Evince and changes the toolbar by adding the zoom in and zoom out buttons, then he starts Gedit and wants to remove a few buttons, he is irritated and asks why he can change elements in Evince but not in Gedit. He feels irritated.

Maybe assuming that Gedit offers a toolbar editor as well, if he has to access the toolbar editor through the menu then he might get confused as well, because the option to access the editor might be burried around some deep menu structure or offer a different name.

He is also confused and irritated because he can drag off a toolbar from Gnumeric but can't do so with Evince, He will also be confused once he set the global "Toolbar & Menus" capplet (control center) and realizes that only 1/3 of the default GNOME application obey these rules and others not.

This is totally inacceptable and for me this is a bug. What I don't understand is, that even if you point the people to these obvious bugs they seem to not be willing to solve them.

Another issue would be the way to concatenate filenames in GNOME but this will clearly be getting to technical here. It looks like everyone does whatever he feels right but at the end we get a wild mixture of applications that don't follow any standard guidelines. Maybe this is also put back due the lack of documentations but who knows.

How comes we don't have these "critical" issues inside KDE ? One possible answer is that the developers understand to follow some global guidelines, maybe they know aesthetics, or maybe their OOP approach is so foolproof that you can't do wrong, regardless if you try. Maybe their technology is supperior enough so people don't need to subclass things like toolbars. If they need something they improve the toolbar class and so make the resulting object more mature.

Anyways I hope my explaination wasn't overkill to you.

Reply Parent Score: 1