Il giorno sab, 23/07/2011 alle 11.27 +0200, Dodji Seketeli ha scritto: > Matthias Clasen <matthias clasen gmail com> a écrit: > > > I don't think Shauns proposal addresses the issue, really. > > Why? Do you have an example that would show where Shaun's proposal > falls short? You have two .desktop files, matching the same application, so it is possible gnome-shell, unity or kde could pick the wrong one when matching desktop files to windows (unless you tweak Exec to pass --class, but that fails again with single-instance applications) > > If you want an app to be usable in different environments, then there > > are some good solutions: > > - make sure the app is self-contained and manages all of its settings itself > > - make your app smart enough to pick up the relevant settings from the > > different environments you want to support > > > > And there are bad solutions, including: > > - making the app drag along half of its original environment, via dependencies > > You don't say why these would better address the issue "here and now" in > comparison with what Shaun is proposing. You get to configure your apps once for both Gtk and Qt apps, which is better for the user and makes the system more consistent In particular, I underline "Gtk and Qt": you don't write GNOME apps, and you don't write KDE apps, you write Gtk and Qt (or Qt+kdelibs) apps, and then the toolkits adapts themselves to the environment. If you can write a Qt+kdelibs app that work on windows or mac os x, you can make it work out of the box in GNOME, without dragging in the entire workspace. This still doesn't address GNOME Core / KDE Workspace collisions, but since those components are desktop specific, it makes sense to use OnlyShowIn for them. Giovanni
Attachment:
signature.asc
Description: This is a digitally signed message part