Bug 104454

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.