[PM] support for Desktop symlinks, similar to Deskbar menu symlinks

[ttcoder]

Some users prefer to have application symlinks on the Desktop, rather than use the Deskbar's Applications ..etc menus, but only the latter seems to be supported currently.

In my initial reading of the wiki, it seems that as things stand currently you have to use the post-install-scripts part of .PackageInfo and invoke ln -s; something more streamlined would be great. I also tried invoking package with a packageinfo leveraging global-writable-files with a relative path (../../file) but it seems there is a glass "ceiling" and the relative path is not applied, the file remains in the virtual volume, i.e. config/, no way to access ../Desktop.

If accessing ../Desktop and other files outside the PM hierarchy is a no-no, an alternative would be for Tracker to take a page from Deskbar and compose the desktop 'virtually' (just like Deskbar composes its menu by merging data/deskbar/menu ...etc), transparently merging, say data/tracker/desktop or some such. Then when I create a package I would just have to create a symlink in both directories, and it would appear in both the deskbar and on the desktop, problem solved.

[bonefish]

Yes, the global-writable-files shouldn't try anything outside the package's installation location. This is really only meant for things like mandatory global configuration files. Similarly the post-install-scripts should generally also restrict themselves to the package's installation location. That being said, if this is a package for a particular customer, using such a script is certainly a reasonable solution. Packages for the general public shouldn't do that, though. In the end, instead a few people having to create the symlink manually, you'd force everyone else to have to delete it.

Implementing this as an optional Tracker feature would indeed be the most acceptable solution. The virtual directory feature was implemented as a quick and flexible solution for the Deskbar menu. While it is possible to also display a virtual directory in a Tracker window, there are quite a few limitations ATM. But I think completing this functionality and allowing the desktop directory to be replaced with a virtual directory should be doable and would allow for the requested feature.

[Giova84]

To let users to decide if have or not links on Desktop, i use the following post_install script:

#!/bin/sh
question=$(alert "Do you want link "appname" on the Desktop?" "No, thanks" "Sure")
if [ "$question" = "Sure" ]
then
ln -s /boot/common/apps/app_name/app_executable /boot/home/Desktop/app_link
fi
if [ "$question" = "No, thanks" ]
then
exit
fi

[axeld]

I'd hate that. Any unnecessary dialog when installing software for that matter.

Can't you just create an application that looks for new links in the Deskbar menu after a package has been installed, that will then create that link?

[ttcoder]

From my experience, some end-users might actually like being offered the option, just for the chance to click "ok" and feel involved in the install process ;-) but yea for power-users I know the feeling, we want streamlined-everything... So might use Giova's script, or maybe just hardcode the links at install time when I prep a machine for a client...

Or come to think of it, maybe the best answer would be this: since all the software in my case will likely be linked from a newly created TT Systems folder (rather than Applications), it would be easy enough for the post-install script to go like this pseudo-code,

for each file in data/deskbar/menu/TTSystems
  ln -s --force /boot/home/Desktop $file

Even if repeatedly run after each package it will do the job seamlessly I think.

This does not buy me the auto-removal of symlinks on software un-install (the links-to-deskbar-menu-symlinks would remain, but be displayed as broken-links), but then again the apps are too awesome to ever uninstall so it does not apply *grin*.

Thus it's fine with me if this is closed as invalid/no-change-req and I do the "foreach" script instead. In fact if implementing this ticket means making Tracker complicated/bloated then I'd feel guilty, Tracker seems to be a sizeable enough beast already.

[axeld]

The problems with user interaction mostly are annoying when you update or install a number of them. Consider duplicating a complete package installation on another machine with dozens of packages. Or a system update that updates many packages.

And now imagine each of these packages asking you some useless stuff -- on every update :-)

[ttcoder]

Went with a simple post-install/tts_desktop.sh script that creates all symlinks silently when AK is installed (leaving them alone if they already exist, default ln -s behavior), didn't bother to do anything sophisticated: it's mostly done by dsuden when he sets up a station before shipping it (not even the end--user).. Then he fine-tunes the icons position, alignment ..etc.Works very well for us, for the handful station we started shipping with Haiku PM (yay!) lately, so this becomes a low- or no- priority for me now.

[Giova84]

Maybe this ticket #11502 which I opened is a kind of dup. But unlike from this ticket, on #11502 ticket I suggest to extend the ability to any other writable directory, not only to the Desktop.

And yeah, I also know that a power-user doesn't like these kind of automations, but I can also understand TTcorder, since, for my real life job, I do something similar.

I mean that for some customers (end-users), some parts of the system should be preconfigured based on their needs, with "preconfigure", to make some example, I mean that the browser should be configured to use a proxy, at the boot time some app/script should be automatically started, there should be some custom keyboard's shortcuts, and so on. For my job I always do this, according to customers needs. With Haiku this would be more simple, thanks to the wonderful package management. Would be possible just provide an HPKG file which contains all needed settings, shortcuts and so on. Thanks to the scripting, eg we can also set preferred apps for some mime type (eg using "mimeset"), set variables, automate some actions, and so on. Using the post_install scripts is possible to perfectly achieve these needs. I guess that, as I've read here and also on some other ticket, that also the guys from TuneTracker, take benefits from these post_install script. So I'd like to suggest, if some day the post_install scripts will be removed, to keep these ability in the package building itself. Or maybe just keeping these scripts just optional, for those which need to do some post_install action. Is a nice and simple feature :-)

[ttcoder]

Indeed before post-install is deprecated/retired it would be nice to have #11502 as a replacement. Taking into account security issues though, not sure what the implications are.

When so, this ticket could be retired (the create-symlink-at-install would be taken care of, and the remove-symlink-at-uninstall is not all that important), sparing us excessive Tracker complexity..

Specifically for the mimeset example cited, I'd say the preferred way is to create mime_db entries within home; e.g. for us ever since we've been shipping TT on Haiku PM we include a package that creates relative paths data/mime_db/audio/aiff ..etc with the mimeset-style attributes we need (Composer, Intro, Outro ..etc), saves me having to run the .sh script we had been using for a decade that calls setmime in extenso, very elegant and handy. Maybe there are other cases where writing files outside of the packagefs hierarchy can be replaced with another mechanism, as we'll probably want to keep that to a minimum.. Anyway for this one ticket, yea there are simpler ways to go, i'd rather keep this one low priority.

[bonefish]

Replying to ttcoder:

Indeed before post-install is deprecated/retired it would be nice to have #11502 as a replacement.

There are no intentions to deprecate/retire the mechanism without providing a a similar but at least equally powerful one.