From kde-usability Thu Dec 25 12:50:03 2003 From: Frans Englich Date: Thu, 25 Dec 2003 12:50:03 +0000 To: kde-usability Subject: Re: KMenu, gnome/kde app clashes X-MARC-Message: https://marc.info/?l=kde-usability&m=107235649631630 On Wednesday 24 December 2003 20:42, William Leese wrote: > Frans Englich wrote: > > On my Slackware 9.0 system my (KDE-HEAD) KMenu have a small problem - all > > over it is spread with 100% _irrelevant_ gnome apps. Do not misunderstand > > me, I don't mind GNOME, quite the opposite, and want them to live > > peacefully together, but "gnome control center" is not very useful in KDE > > and it would be most appropriate if they had a NotShowIn=KDE. Or what do > > do you think? There's alot of those obvious gnome system-specific. But > > when it comes to apps with _very_ similar functionality like > > Terminal/konsole Text Editor/Kedit it becomes hard and political tense to > > judge. Should we do a NotShowIn=GNOME on konsole and a NotShowIn=KDE on > > Terminal, etc? > > > > I really have no clue in this matter, but, I think it is clear that the > > current situation/KMenu is usability wise could be better. > > > > Should I make a pile of oneliners and this time not only bother kde > > developers but also gnomers? :) What do the wise people say in this > > matter? :) > > Urgh!!! > > This would mean WAR y'know ;) Yes, we don't want war. I think a small note to why I'm pushing this idea would be in place. If this is handled correctly I don't think it leads to war. The only place I've found WAR(aka FUD etc) is really on the dot, slashdot and Userinux::Discuss. I'm not worried this leads to war because it involves sane people and the idea in itself is not flamebait, it is purely pragmatic, just as fruitful for both projects and AFAIST a win-win situation. I don't get upset or feel insulted if someone says they prefer gedit in front of kedit( no names made up :) ) when running gnome. And I find it quite natural if someone says they prefer konsole infront of Terminal when running KDE - it is not about functionality, or the applications themselves because they *are* actually very similar and there really is no reason choosing the other in front of another. Except, when it comes to the desktop integration aspect, which makes us prefer one, even though they are functionality wise identical. There _are_ cases where having both the KDE and GNOME version around is just exsessive, there is no reason. If you choose gedit in front of kedit you really do it because you like GNOME/GTK feel not because of the app, and then you should be running GNOME(and probably is - problem naturally gone). There's a bunch of these highly identical apps, ie. System Monitor vs ksysguard. There's nothing to fight about, no reason to feel upset because this proposal does not say "KDE is bad", or "GNOME is bad", it only highlights the fact that we are two different DE projects with some duplicated functionality and then goes on to correct the usability problem the fd-menu-spec unfortunately leads to. Because usability wise the fd-menu-spec(FMS) when fully followed up by both DE's wont work. For example, the GNOME menu will be _flooded_ with tons of small, really-only-useful-for-1%-of-the-userbase KDE apps(and no X-KDE-More support..). If they pursue the FMS their menu will be useless. And our too when they have followed up. Our current situation of tons of apps, and those who are DE-dependent(some configuration apps, among others) could actually hinder the deployment of the FMS(thus a crucial part of desktop inegration), If you read between the line of the FMS it basically says "Applications conforming to the FMS _will_ run in different desktop enviroments, regardless of their belonging" and when the spec is fully followed up kde apps is (roughly) as much valued as gnome apps in the GNOME DE, and vice versa. To empasize, the spec does a giant blow for intergration. But, if the current situation remains, it won't work. The FMS is further important since the DE's implementing it conveys an (official) policy saying "This DE works with 'foreign' apps and sees it as a Good Thing". This is already implicit stated but is important for integration and stopping the FUD in massmedia and our "forums"(or what to call slashdot? Chicken run? :) ). I think my proposal is interesting because it forces GNOME/KDE to explicitly talk about these issues. There's a tension/FUD which says KDE hate GNOME, KDE apps are always better and not wanted(and vice versa) - my proposal forces us to talk about our apps in a way where FUD won't exist. As outlined above, the reasons to not have those particular GNOME apps in the KDE menu and vice versa is well funded, not BS - it is quite resonable and understandable and thus flameproof. To put it in another way, my proposal helps us to "ventilate" something that does not exist(a hostility and polarization between the DEs). Another interesting, important point is that it further forces us to explicit say "That gnome app is superior, please don't do a NotShowIn=KDE - because _we want it_"(and vice versa), it will bring the "KDEvsGNOME" discussion to a rational level. It demands a dialog - KDE will ask GNOME to change for KDE's improvement and GNOME will ask KDE for GNOME's improvement - it is a moral relationship which leads to collaboration, helps both projects, deploying FMS and boosts integration. It will be fun. It's very easy for us KDE developers(and vice versa actually) to think GNOME will "hurt" the most(and then you got everything backward). The proposal has a positive outcome, but most important, it requires, and gives as equally much to both projects - because it is not only GNOME apps that will be abscent in KDE, KDE apps will also be abscent in GNOME(and again, that is not a bad thing for KDE). When the FMS is deployed and the boundaries between the DE's will blur, intergration will be further pushed, people will start asking "Why is there Bug Report Tool and Konqi crash handler?"(suggesting bug reporting infrastructure to be merged) or perhaps "What is the difference between the GDM configurator and the thingy in the kontrol panel? Which one should I choose?"(perhaps leading to an ultimate, shared login manager with common cnfig interface....). Cheers, Frans _______________________________________________ kde-usability mailing list kde-usability@mail.kde.org https://mail.kde.org/mailman/listinfo/kde-usability