Thanks Duncan. The lack of the facility was down to where I was looking for it.
I've degenerated into a subhuman and now mostly use the mouse. Comes from too
many years of writing non pc software under windoze. The kit is usually a mix of
what really should be run in msdos and windoze apps for emulators etc. Actually
speed wise I don't think there is much difference providing editor keys are
used. A windoze window however does usually fly a lot quicker if driven with
<alt> whatever. Dubious advantage really as most time is spent in it actually
doing what ever it does. I try to give into change rather than fighting it as
most change does have some advantages. - somewhere if you can find it.
John
----- Original Message ----
From: Duncan <1i5t5.duncan@xxxxxxx>
To: kde@xxxxxxxxxxxx
Sent: Sat, 30 April, 2011 13:22:43
Subject: Re: Application launch files
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.
___________________________________________________
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.
