Re: .desktop files [Was: Google Summer of Code]

[Sebastian Reitenbach]

On Tuesday, February 7, 2012 11:14 CET, Fred Kiefer <address@hidden> wrote: 
 
> On 07.02.2012 10:56, Sebastian Reitenbach wrote:
> > On Tuesday, February 7, 2012 09:42 CET, Fred Kiefer<address@hidden>  wrote:
> >> On 07.02.2012 09:21, Sebastian Reitenbach wrote:
> >>> Another thing I'd really like to have is some more cross desktop 
> >>> integration, for example,
> >>> allowing .desktop files, used in KDE and others,  to work. I'd really 
> >>> like to define Firefox or
> >>> something similar as my default browser. (until Vespucci is production 
> >>> ready ;)
> >>
> >> We already once had a Google Summer of Code student to work on cross
> >> desktop integration. Sadly not much came from that.
> >> I remember writing .desktop support ages ago. The file specification may
> >> have changed in between, most certainly it has, but it should be really
> >> easy to update our file generation to match the current standard. What
> >> is currently broken?
> >
> > Well, I have a couple of .desktop files around on my GWorkspace Destop. 
> > Double clicking
> > them, doesn't do anything. I'd expect them to start the application 
> > configured in Exec=, or open the
> > URL from URL=, and use the icon defined in Icon= ...
> > but nothing happens when I click on such icon.
> 
> I just checked that with Ink, after installing Ink it was sufficient to 
> click the .desktop file for it to start up the application.

Ah, I have a .desktop icon on my desktop for OpenOffice for example, and 
nothing happens.
The oofromtemplate defined in Exec= is in my path. I also have another icon, 
that doesn't have
a Exec=, but a URL= to a website, also there, nothing happens.

> 
> >> As for specifying a default browser, this should be as easy as to write
> >> a GNUstep wrapper, that is just a .plist file and to copy it to where
> >> make_services will find it. There must already be a lot of these
> >> wrappers out there, where do we collect them? Maybe we should set up
> >> some space in our source code repository to collect them?
> >
> > They are in GWorkspace apps_wrappers subdirectory. But this approach 
> > generally has a flaw:
> > For how many applications do we want to create wrappers, when/where do we 
> > stop? ;)
> > We obviously cannot do so for every application. Further, the paths to the 
> > application can be on
> > different places on different OS, for example /usr/bin and /usr/local/bin 
> > ...
> >
> > On the other hand, many applications install a .desktop file in 
> > /usr/local/share/applications/
> > (at least which is the path for me on OpenBSD), and icons too. Packages 
> > that do that then run
> > update-desktop-database from the desktop-file-utils package on install. 
> > Afterwards it shows
> > up in the users menu, under the defined categories.
> >
> > IIRC, the Makefiles support creation of .desktop files, from the info taken 
> > from the App bundle.
> >
> > AFAIK, there doesn't exist something the other way around, allowing other 
> > application to create
> > an App Wrapper automatically. Even if that would exist, you'd still have to 
> > get others to make use of
> > it, which I think is then the harder part.
> >
> > I'd also really like to have an applications menu in GWorkspace, built from 
> > the information from those
> > .desktop files in /usr/local/share/applications, that would allow me to 
> > browse all installed applications
> > and just start them from the menu ;)
> >
> > Supporting this really standard stuff would prevent us from 
> > creating/maintaining a truckload of
> > Apps Wrappers. I actually created some of those apps wrappers for about 20 
> > or so applications
> > but Riccardo refused to add them to the Apps wrappers, he said, this is not 
> > a kitchen sink, and
> > it should only contain really common used apps. Which I understand and is 
> > fine with me.
> > But on the other side, creating and maintaining own apps wrappers, is also 
> > a bit cumbersome.
> 
> To get support for all this we should start off to implement UTI (or 
> steal it from Etoile while they are busy with all the interesting stuff 
> they are doing) and integrate this with the native file mapping of the 
> system. The annoying thing here is that we need that to work for all our 
> possible environments, which means we need something for Windows and 
> also basic support for environments without native file to application 
> mappings.

Ah, here it sounds to get more complicated.
 
Sebastian