Re: gnome-shell and custom desktop files

Le mardi 08 novembre 2011 à 10:41 +0100, Aurélien Naldi a écrit :
> On Tue, Nov 8, 2011 at 10:05 AM, Olav Vitters <olav vitters nl> wrote:
> > On Tue, Nov 08, 2011 at 09:57:02AM +0100, Aurélien Naldi wrote:
> >> * manually installed applications: I rely on some manually installed
> >> applications (especially java ones), which do not provide a .desktop
> >> file. Making one is easy enough (yet I think GNOME should provide (or
> >> reuse) a GUI for this).
> >
> > No, the developers should provide the desktop file. There is a GUI for
> > making them, but it is wrong to expect users to ever create such a file.
> Many java applications are just provided "as is" without integration,
> or without integration for linux.
> I agree that the dev or distributor should be the one doing it, but if
> he doesn't, why should it be hard for a user to do it himself (and
> then suggest the dev to integrate it)
> >> Once the .desktop file exists and is installed in the proper place,
> >> the shell can launch the application, but the dock does not associate
> >> the window to the .desktop file. How can I solve this?
> >
> > I guess something is missing. No idea. Maybe StartupWMClass / needs
> > StartupNotify=true.
> >
> >> * custom options for existing applications: I use separate profiles
> >> for gnome-terminal, firefox, google-chrome. These applications provide
> >> a command-line switch to select the profile, but the opened window is
> >> then associated to the "main" desktop file instead of the custom one.
> >> I guess the source of the problem is similar to the previous one.
> >
> > WMClass needs to be different IIRC.
> >
> >> I am asking this not only as a user who would like to make his
> >> everyday life slightly more confortable, but also as a developer (of
> >> java application) who would like to improve integration with the
> >> environment, without too much headache...
> >
> > No idea if we have documentation for this. If not, we should.
> Some guidelines are provided here:
> It helps from the developer point of view at least.
> Unfortunately the java side of things is not so convenient for this:
> the java WM sets the class name by herself (even if some tricks exist
> to try and fool it but I would rather not rely on this):
> the WM_CLASS I get is:
> WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "name-of-the-main-class"
> matching on the second name does not work, and if I give the first
> name to my .desktop file, the application does not even get launched
> Did anyone here have this working for java applications without having
> to rely on java-gnome (which defeats the point of using a
> "cross-platform" language) ?
I suppose there can be a solution to that problem. If StartupWMClass is
correctly filled in the .desktop file, the Shell can easily detect, when
a .desktop file was clicked, what is the window associated to it. It
just need to suppose the first window that appears with the specified
WM_CLASS following the .desktop file activation is the right one.

AFAICT, this would work for Java apps that have a silly WM_CLASS, and
for different app instances (that wouldn't support the --class
argument). There would only be problems if you activate two .desktop
files with the same WM_CLASS in a row, but that's a relatively rare


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]