Bugzilla – Bug 104454
Kontact (KDEPIM) is installed with GNOME due to dependency of taskjuggler
Last modified: 2006-01-22 11:00:10 UTC
When GNOME is chosen as a desktop environment, Kontact (KDEPIM) is installed due to a dependency of TaskJuggler. This seems unneccessary to have the full Kontact suite installed for one application. Couldn't it depend on Evolution instead?
It seems that TaskJuggler is a KDE/Qt application so why is it installed with GNOME anyway?
It's the only real project management program we have. It's similar to k3b and khelpcenter which get installed no matter what desktop you select. TaskJuggler needs KDEPIM because of the KDEPIM iCal libraries.
We plan to remove all applications with non-GTK/GNOME UI from GNOME selection.
Planner is a project management app for gnome. We ship it already.
TaskJuggler is in the office selection, not in the GNOME selection. So you either have to create your own office selection or live with it. Planner is not more than a toy. I had several people complaining to me that they just waisted time with it before finding TaskJuggler. Planner is lacking vital features that you really need for project planning. It's got not even 10% of the current TaskJuggler feature set. Since there is no alternative to TaskJuggler on GNOME I don't see a reason why we should not offer it to GNOME users as well.
Why do we have conflicting comments about what is happening? Stanislav said it will be removed (Yeh!) but Chris said it will stay :-(. Chris: I am not doubting how good TaskJuggler is but the fact is a.) it is NOT a GNOME application and is NOT a GTK applications which means when I choose GNOME Desktop, it should NOT be installed. Can't it be made so when you choose GNOME, it is removed? Stanislav: I hope what you saying is correct! The only QT things I could find were KPager, TaskJuggler and Kontact. Will these be removed by Beta 2/3?
Also, it would be great shame to 'go back in time'. Previously, I felt that GNOME was in SUSE because they felt it should be but from SUSE 9.3, you guys have made a real effort and the results are excellent. If you start to include QT apps like Kontact and TaskJuggler, you are going backwards. Seb
It's OK to have OpenOffice, taskjuggler and other office applications in Office selection, but not in GNOME selection. But name of GNOME selection implies, that it contains only GNOME/GTK+ applications and GNOME team tried hard to remove all cross-desktop dependencies. We have not yet been successful, kdebase is still present. Beta2 will still have old selection - my first attempt to generate list with dependencies failed, but I want to review it before beta3.
I must say, I'm a bit mystified by this bug report. GTK gets installed alongside KDE and Qt, and in KDE GTK apps can be installed and run easily and seamlessly. The GIMP is installed and run, and integrates fine in KDE, so I fail to see why the Gnome option in Suse should remove even the ability to do that from the user, certainly out of the box. As a KDE user I can tell you that I'm not bothered by GTK being installed (and like the option of the apps), and I fail to see why that should be otherwise vice versa. Notice that I'm looking at the user point of view here. Although running KDE apps within Gnome, or Gnome/GTK apps within KDE, isn't ideal, it does give a user an option to get the functionality that he/she needs or prefers. Rather than closing off the application options presented to a user who uses Gnome, might I suggest you look at useful integrative technology like the QtGTK theme engine and work on the KDE apps to Gnome integration side of things? Otherwise, I can only interpret this bug report as a serious slice of NIH syndrome.
Having a mixture of apps from different desktops is suboptimal from a performance standpoint: two effectively redundant sets of shared libraries in memory, two effectively redundant sets of user-space daemons in memory. There's also the issue of extra disk space, but it's typically less of a concern. Theme engines hacks don't do anything to solve the performance problem, and in my experience they mostly just introduce bugs, most often crashes. Moreover, they generally don't resolve less superficial aspects of UI consistency (button ordering, single- vs. double-click, etc.). People who want apps from both desktops are free to install them and pay whatever penalties they like in terms of performance and stability, but people should also have the option of avoiding those problems. That's the rationale behind this bug.
(In reply to comment #10) > Having a mixture of apps from different desktops is suboptimal from a > performance standpoint: two effectively redundant sets of shared libraries in > memory, two effectively redundant sets of user-space daemons in memory. I don't buy that at all. As the functionality of desktops increases you're going to get a lot of different code potentially overlapping each other in some way. I just don't think you get very far with a 'not written with GTK' attitude really. This distribution is called 'openSUSE' - it's not called 'Gnome'. > There's also the issue of extra disk space, but it's typically less of a > concern. Install Windows, and then a full KDE and Gnome alongside and compare. > Theme engines hacks don't do anything to solve the performance > problem, and in my experience they mostly just introduce bugs, most often > crashes. I've never experienced any problems at all, nor have I experienced performance issues even though this tends to be more of a problem for someone running GTK apps in KDE. I would have thought the situation might improve the other way around. > Moreover, they generally don't resolve less superficial aspects of UI > consistency (button ordering, single- vs. double-click, etc.). There's no reason at all why they can't. This can all be coded and switched, if things are written properly. No one's asking for things to be made absolutely perfect, just for an open attempt to be made. It can be done. > People who want apps from both desktops are free to install them and pay > whatever penalties they like in terms of performance and stability, I'm sure your userbase is really glad to hear that. They are certainly free to install them, and they should expect a desktop to be open enough to applications written with different technology. There's no reason at all why it cannot be done. > but people should also have the option of avoiding those problems. That's the > rationale behind this bug. At the expense of integration and a choice of applications? Most users will not choose that at all, and I just think you're creating your own problems and marginalising your own platform there. Sorry.
I agree with what Mark Gordon said. Performance penalties are evident if you start GNOME applications under KDE and viceversa. You don't notice it too much for GNOME apps under KDE in SuSE 10 due to the preload performed for Firefox and some other apps. Choice of applications doesn't seem the subject of the discussion to me. No one wants to eliminate the possibility of installing KDE software under GNOME and viceversa. GNOME just should be "clean", as KDE is, in its default installation. There's very little integration between KDE and GNOME apps. It's evident the integration in Gnome-Evolution-Gaim-Nautilus, or in Kmail-kalendar-kontact-kopete, but not between apps of different window managers.
Dependencies has been changed for 10.1.