gnustep-dev
[Top][All Lists]
Advanced

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

.desktop files [Was: Google Summer of Code]


From: Fred Kiefer
Subject: .desktop files [Was: Google Summer of Code]
Date: Tue, 07 Feb 2012 11:14:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0

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.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]