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."
Thread beginning with comment 56650
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Developer's POV
by on Sun 6th Nov 2005 01:46 UTC in reply to "RE[3]: Developer's POV"

Member since:

ick umbrello and kivio. Kivio was straight up useless and umbrello would spontaneously crash on my slackware system. It makes me wonder if there was this much crying when slackware dropped gnome. It made me switch over to debian. I think slackware dropping gnome hurts WAY more then suse dropping kde. I might try dropline or some alternative but ill hold off on that.

yes the UI for most of the kde toolbar is exceptionally cluttered. Some people like it, some people absolutely hate it. There is no other DE which just throws a barrage of icons at your face then kde.

as for kde crashing, I mean it happens to me. It aint super frequent but a lot of things would tip it off, from kscreensaver to kopete. Gnome never crashed for me unless i run xcompmgr. The number of crashing was the same compared to running kde with kcompmgr......which was really high (someone fix it!!)

When it came to looks. KDE would lliterally make me barf until i did a good bit of tweaking. Had to custom build my own icon set cause the ones that were out were either for 3 year olds or OSX ripoffs....or gceanzze.... those are some good icons but they are only really for mime types. Then i needed kpager2, then mtaskbar, of course the only viable theme was baghira (blatant OSX ripoff but only thing i can stand). At that point, i could at most make running kde bearable, but it got a bit to complex.

I have successfully found gtk-gnome applications that is on par or better then kde applications (and i do a lot of different things on linux). And some of these mono projects are looking really good. From my testing monoUML simply destroys umbrello as does monoDevelop does KDevelop (although KDevelop have more tools here and there). And as i mentioned before i love using beagle and luminosity. Since my computer is a speed machine i use them with no problem. and i like gaim, totem, graveman, bluefish, evolution, and gedit and im still stuck in xmms world even with all the songs i got =).

Although Konqueror is nice, I will honestly tell the kde team to simply give up on koffice. And i hate that monolithic package system. Thank god they now have options to install by app, because there is so much crap that i dont need when using those packages.

Well umm in the end.... i like gnome. leave me alone, because i dont feel any less inferior or productive then the kde camp. Suse picked gnome.....leave them alone because they feel just content with the decision..........or else they wouldnt have made it. There is a reason where they are where theyre at........and you guys are where u are at. Of course the company is not doing spectacular at the moment, but they have focus and bring in their revenue and have way more people that know more than u.

It sucks when a company cant make a damn decision without some crackpot useless flame war starting up. I didnt see the gnome camp spewing this crap when kde was the default for suse..... it would be best if the kde campe return the favor.

Reply Parent Score: 0

RE[5]: Developer's POV
by on Sun 6th Nov 2005 02:03 in reply to "RE[4]: Developer's POV"
Member since:

If you hit random crashes on various KDE applications then you should investigate whether its a compiler issue or not (generating broken code) and from your comment I conclude that this is the case. Try recompiling your KDE without and leet CXXFLAGS primarily -O0 -g and investigate into the backtraces. In case you might want to report to slackware (was it that distro) to throw an eye on their packages.

As for MONO. I can tell you that there are mixed feelings about MONO in the GNOME camp and even amongst the core developers. There are a few who like developing in MONO and there are even companies pushing it and even argue against using JAVA and then there are developers and companies involved into GNOME doing exactly the oposite. I will see hell freeze once MONO becomes part of GNOME. Sadly MONO is a nogo for my personal system because simply for the fact that the license issues with MONO are not clear and I don't know how the future for it looks and what Microsoft is going to say or do in the future. As long as these issues are not cleared I (and many others) are stepping away from it.

Looking at the MONOUML page and reading their HOWTO (and looking at the screenshot provided) the program looks like its in the beginnings of something. KDE's Umbrellos is regulary being worked on, don't depend on MONO and correctly integrates into KDE as a whole. It's possible to export stuff in various languages, import diagrams (xmi), you can do usecases, colaboration diagrams, class diagrams and a few other things as well such as component view and deployment diagrams. And this was already possible a few years ago. Nowadays Umbrello has received many changes and improvements. I regulary keep throwing an eye on it but my personal needs for Umbrello isn't existing anymore due the fact that my university times are over. But maybe I need it again one day in my daily work.

About the toolbar issue you described. I wasn't refering to all the buttons you got thrown to your head. I was more talking about the toolbar object as a whole.

It's one ready written object that exists inside KDE. The toolbar offers the possibility to set buttons, change the toolbar (editor), have the toolbar show up under various ways (text below icons, icons only, text only, text beside icons), then the buttons can be shown with different sizes 16x16, 24x24, 48x48 and so on. Things the GNOME derivates don't offer. That's why you see Evince as well as Epiphany coming with their own toolbar editor while other gnome applications don't offer it. That's why you see so many different types of toolbars and toolbar styles, behavior, features etc. It's not the buttons I talked about, it's the toolbar as a whole and imagine this for many other cool objects that KDE offers.

You like to throw an eye on that screenshot above.

Reply Parent Score: 0

RE[6]: Developer's POV
by on Sun 6th Nov 2005 03:41 in reply to "RE[5]: Developer's POV"
Member since:

Im running on a slackware system. I assume that kde was compiled at the max -O2 when it comes to optimizations. -O2 is not l33t in anyway. It's stable and everything runs fine.

KDE crashes. I aint really go beyond that and blame anything but KDE. Its not that often so i dont really get on its case, but it does crash and i would expect that. In fact it was the 3.4 version that I used, and it might have been fixed in 3.4.1. who knows. Its a big project.... and I dont mind thinking that the kde developers are incapable of implementing "crash-free" code.

I mean umbrello is ick to me. Oh its better than visio, but it crashes way to often and I cant really get far with it. Prolly because I am a software designer, and I do use tools like this very often (though i stick with rational rose).

Anyways with the toolbar issue one thing is that i never saw gtk and gnome as the same thing. That screenshot doesnt really tell me anything. Having evenly sized toolbars across all apps for a DE is not a criterea for being usable, even creating a greater sense of integration. No DE provides what ur saying. There is a great deal of apps outside of the KDE packages that are created with the QT toolkit, but looks way off in size shape compared to other apps. Alot of people dont use the toolbar objects to develop their software..... and thats ok. Windows dont do it, OSX doesnt do it. Its a moot issue to me.

Reply Parent Score: 0

RE[5]: Developer's POV
by Mystilleef on Sun 6th Nov 2005 06:52 in reply to "RE[4]: Developer's POV"
Mystilleef Member since:

Ali you are clown. 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.

Reply Parent Score: 2

RE[6]: Developer's POV
by on Sun 6th Nov 2005 10:25 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