(old)Puppy Linux Discussion Forum

For puppy 1.0.9 we are implementing a menu system that does not depend on updating the menu files manually. It greatelly simplifies adding apps to the menu without worrying what Window manager is being used. Or what menu structure is used.

This is, you don't add your application to a specific submenu. Instead you specify categories for your application and the menu system decides where to put it.

The only thing you have to do when preparing a package is to include a file named after your application with a .desktop extension. and save it to

/usr/share/applications

For example Abiword-wordprocessor.desktop

If you are just repackaging an application that already has a .desktop file, just make sure that .desktop file gets copied to the appropriate location (/usr/share/applications).

If you are packaging an application that does not provide its own .desktop file, then create one. The format of the file is very simple. Use the following example as a template. (Note that this file is Case sensitive) Here is the quick explanation for each parameter:

Encoding ---> Always leave it as UTF-8 for now
Name ---> Name that will appear in the Menu
Icon --> Icon file that will appear in the Menu. It can be a full path.
Comment --> A comment that may appear as a hint in the right WM.
Exec --> command to execute the application
Terminal --> dfoes the app run in a terminal?
Type --> Always "Application"
Categories --> a semicolon (;) separated list of categories. Read this for a full list of registered categories. An application can belong to multiple categories.
GenericName ---> A generic name, also used by some window managers to better qualify the menu entry. (e.g. some put the generic name in brackets beside the app name)


The full specification for .desktop files is here http://standards.freedesktop.org/deskto ... 01s04.html. You don't really need to read it unless you are really curious.

Hi. I am using MU's dotpup wizard -06 for this...

So the appropiate way would be if someone, preferable Mark (MU) is so kind
to update this wizard...

PS

I've talked to Mark about this. There are still several issues:

* Mark does not know if he will be able to modify the utility in time for 1.0.9.
* Not everyone uses Mark's utility. (many pre-date Mark's utility)
* Some packages already include a .desktop file, it's just a matter of putting them in the rigth folder. I guess that Mu's utility could ask if there is already a .desktop file and add the commands in the script to copy it to the right location instead of creating it.

I agree that Mark's utility could help the user create the desktop file for packages that don't already have one. Meanwhile it's just a matter of adding another file to the package.

The other place the .desktop files go is /usr/local/share/applications.
Why not just (i) add that path to your menu program or (ii) create it as a link to /usr/share/applications?

There are several other locations that 'could' be used.

I am asking developers to use a single folder for simplicity and standardization purposes.

If packagers start installing to all the different valid locations, it may make it marginaly simpler for them but all the other users will have to deal with .desktop files all over the place.

For the XDG tool it's the same (Except when there are conflicts and certain rules apply based on some path variables which makes it even more complex for the users)

With my recommendation, the package developer only needs to care about ONE .desktop file under this scenario and users will know where their .desktop files are.

So, I really favour one tiny extra step for one person (the packager) that will simplify the lives of all the users. And really, copying a file to a standard place wouldn't be that much of an inconvinience, would it?

I second everything in Rarsa's last post. It's not too much to ask that we keep them all in one place, other distros and Unix varients have certain preferred locations for certain system files, and this is no different.

For instance, when using FreeBSD all graphical applications are compiled for the prefix /usr/X11R6, which used to be a common Unix convention. It is quite easy and will work just fine if you compile for /usr or /usr/local or even /opt, but they just don't do it and the entire system stays much more organized because of it. To their way of thinking /bin for basic system utilities, /usr/bin for cli programs, and /usr/X11R6 for graphical programs.

So to recap, please just go along with this so we can get the feature implemented as smoothly as possible with the least headaches.

Nathan

Perhaps a suggested 'check list' for package developers, prominently posted in the several Puppy websites where developers might read it, would be a good idea.

XDG is in 2.14 as is a new package management system
http://puppylinux.org/wikka/Puppy214

rarsa wrote:The only thing you have to do when preparing a package is to include a file named after your application with a .desktop extension. and save it to

/usr/share/applications

Why? What does this achieve?
Where/when do .desktop files get picked up?
Is this request still current?
Does this include rox apps when packaged into a DotPup?

Thanks.

"What does this achieve? "

.desktop files, if they are configured properly, will get added to the window manager's (jwm, icewm, etc) menu when fixmenus is run

if the file is deleted, it will be removed from the menu when fixmenus is run

so basically it is a way to add your application to the menu without needing to edit the menu configuration files directly from an installer script, for example, by using sed

"when do .desktop files get picked up?"

when fixmenus is run

"Is this request still current?"

Puppy 216 uses the .desktop files in /usr/share/applications to generate it's menus dynamically, so yes, if you want to add your application to the menu, it would be the way to do it ... if you make a package for a command line program, and you do not want to have a menu item to start the program in an rxvt window, then you would not need a .desktop file

"Does this include rox apps"

if you like ... if you want the application to appear in the menu, you would install a .desktop file that can start your application ... a Rox application directory can usually be made so that it can be moved anywhere and it will run where ever it is put, but a .desktop file could be installed that points to the location where it was installed ... a roxapp could be run like this:

rox /root/my-roxapps/Xmix

or like this:

/root/my-roxapps/Xmix/AppRun

or there could be a wrapper script somewhere in the PATH to start the application, like this:

#!/bin/sh
exec /root/my-roxapps/Xmix/AppRun

or:

#!/bin/sh
rox /root/my-roxapps/Xmix

so the .desktop file might start the roxapp by running the wrapper script "xmix"

Getnikar wrote:

rarsa wrote:The only thing you have to do when preparing a package is to include a file named after your application with a .desktop extension. and save it to

/usr/share/applications

Why? What does this achieve?
Where/when do .desktop files get picked up?
Is this request still current?
Does this include rox apps when packaged into a DotPup?

Why? Because the Puppy XDG menu system uses .desktop files to specify menu entries and the icons and executables that go with them.

The files are "picked up" each time PETget is run to add an application, and whenever fixmenus is run from a console.

The request is still current and applies to both dotpups and dotpets when a menu entry is needed in the XDG menu system.

IMHO it is preferrable for developers to create dotpets rather than dotpups. Although MU has developed the dotpup wizard, there are fewer steps in creating a dotpet and it is generally easier to get things installed where you want.

Many thanks Guest2 and Whodo.

WhoDo wrote:IMHO it is preferrable for developers to create dotpets rather than dotpups. Although MU has developed the dotpup wizard, there are fewer steps in creating a dotpet and it is generally easier to get things installed where you want.

In this regard, I have just created a MakeDotPup that is a wizard-style gui. Its focussed on rox apps, but is OK for anything. It is attached for anyone interested.

I need to hack it into a MakeDotPet, to either run (as per http://www.puppylinux.com/development/createpet.htm) , or maybe I might rip the relevant code out of those scripts and merge it in ... when I get time ...

Makes dot pups nicely. Install it and its help will pop up, and an initial setup is run. This needs to be morphed into a MakeDotPet.

Hi, I need a hand.


I want to translate the menu, but I can only traslate aplicattions 'name' on the menu.

How do I traslate, for example, the shutdown item? Or setup, persay.

Sorry to disturb.

categories:
see:
http://murga-linux.com/puppy/viewtopic.php?t=25925

shutdown:
edit the files in:
/etc/xdg/templates/

Mark