Application launch files

[Duncan]

John Woodhouse posted on Sat, 30 Apr 2011 02:38:52 -0700 as excerpted:

> Thanks Duncan. I hope at some point a dev adds one of 3.x's nice feature
> where these were available for editing directly via a right click.

Referring to *.desktop files?  They are right-click editable, at least 
here.  Of course subject to permissions, but I have both a properties 
dialog with various tabs including *.desktop file specific tabs that allow 
editing, and an entry to open with kwrite (my primary kde editor, altho in 
practice I use mc/mcedit far more).

Also note that it's still possible to launch kmenuedit, either by context-
click on the menu plasmoid (classic, kickoff or lancelot) and choosing the 
menu editor function, or by launching kmenuedit directly, via krunner, 
konsole, or the like.

> I mostly use that to run something or the other as su but would also
> like to modify icons at times. For instance I currently have 2 dolphin
> icons on quick launch. One launches as su the other as per normal. Icons
> are identical.  I usually add an editor running as su as well. I prefer
> a version of Kate that remembers all of the files it's worked on for
> that.

I don't normally use quick-launch as I prefer keyboard shortcut launching, 
and indeed, had quite some difficulties transferring to kde4 because the 
kde3 multikey hotkeys quit working, and I tended to use a two-key 
sequence, one as my launcher prefix key (customized launch menu triggered 
by that key, if you will), the second to launch whatever app, and kde4's 
lack of multi-key hotkey support killed that for me.

After screwing with it for awhile, I realized that I could get essentially 
the same effect, by setting a kde hotkey to launch a custom launcher app, 
which then took one key and launched the app associated with it.  Well, 
I'm not a dev, but I'm decent at admin-level shell scripting, so I ended 
up creating a script that took one key, looked it up in a list, and 
launched the associated app.  I then setup a special konsole profile and 
special window rules for that konsole profile, and finally setup a kde 
hotkey to launch that script in my special konsole profile.

So I launch nearly everything I use routinely via hotkey sequence.  What I 
don't, I launch either from krunner, konsole, or the kickoff menu, and 
don't tend to have much use for an icon launcher plasmoid.  But that's 
just me.  The plasmoid's there for those who find it useful.

Anyway, quickly unlocking widgets, then adding a quicklaunch plasmoid so I 
can perform a few quick tests for this reply, it seems to have the 
expected context edit actions, etc.

Now what I *DO* see is that by default, it's using entries from the 
applications menu, which again by default, if they've not been edited 
there, are going to be the normal global system config entries.  As such, 
they won't be directly editable as your normal user.  That's to be 
expected as the global entries are system level and therefore need sysadmin 
level privs to edit.

However, if when adding a launcher, you type in the path to the executable 
directly (so /usr/bin/gwenview, for instance, instead of simply gwenview), 
then kde will create a NEW entry instead of using the existing menu entry 
(as it would had you simply typed the name, gwenview), and the NEW one 
will be fully editable. =:^)  If you check the properties, the desktop 
file itself will be found in something like (I've customized my setup and 
don't know the default any longer, so this is a guess) ~/.local/share/
applications/ instead of the system location, /usr/share/applications/.  
That's why it's fully editable.

> ;-) Seems quick launch is a panel now - but a panel for what.

??

Quick-launch is a plasmoid, a plasma widget.  It can be placed on the 
desktop (or other activity style), or in a panel, the same as any other 
plasmoid.  It's not a panel of its own, but can be placed in one if 
desired, or on the desktop if desired.

> As to security if some one can get in and make changes little matters
> really if it's a desktop file or something else. The important aspect is
> no back doors.

When the news came out, the point was that *.desktop files, much like MS 
Windows *.lnk (shortcut) files, allow the creator to choose both the icon 
and the command run -- without anything requiring a specific icon for a 
specific command.  Because, very similar to the MS *.lnk files, desktop 
environments of the time tended to hide the extension, an attack very 
similar to one used on MS Windows was possible.  It was quite easy to 
socially engineer a user into downloading and then clicking on a *.desktop 
file loaded with some sort of nefarious command, but identified with 
whatever icon was the default for something far less dangerous.

The result was some changes to the way things were handled.  I didn't 
follow all the details, but in certain cases, the system will now prompt 
whether you're sure you want to run <command>, where it wouldn't, before, 
and I believe this has been one reason for the move away from a common 
desktop dir used for both normal downloads and *.desktop shortcuts as well.

> All systems are weak in some respect. I often wonder how
> long it will be before some on pretends to be a java update on windoze.
> That sort of thing could be applied to any system.

FWIW, it'd be more difficult on a Linux system where all updates come thru 
the system-common  package-management setup, instead of each app checking 
and prompting for its own updates.  Where that breaks is for stuff like 
firefox and chromium extensions, even if the apps themselves are handled 
by the usual distribution system update mechanism.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.