Idea about generic command framework for launching common applications
dfulton at gmail.com
Tue Nov 18 15:44:52 PST 2008
>> Very interesting. Thank you. If I just wanted to open a text
>> [this is just an example], so that I could type up a quick note, I
>> [I don't know what anyone else would do] open a text editor, type
>> (maybe print it if necessary), then probably click File, click Save,
>> decide where to save it, and what to name it.
> That wasn't my point. The point was to show that not all platforms use
> symlinks. :p
Sorry. I have a better understanding now of what you were saying.
Thank you for clarifying that for me.
>> If I were on a Windows PC on somebody's network somewhere, I could
>> confidence, click Start, Run, type notepad.exe and click the Ok
> Except someone might prefer using UltraEdit and set it as default in
> the registry. Which would end up working a bit like on BeOS, just not
> as clean.
Right. I think you get it. In case there is anyone else that doesn't
-- the point is that on Windows, we at least know the name of one
graphical text editor that is going to be installed and have a standard
way to launch it with a command. We (computer users) don't have that
with Linux because we don't know which specific programs are installed
on any give computer.
We can equal that small Windows feature by adding a similar consistency
and we can best the Windows method by allowing for generic commands
that can abstract the actual program name (without breaking the way
anything works today).
>> A graphical text editor would open. In Linux, with our many
>> distributions, our multiple desktop environments, and the enormous
>> variety of included and optional applications, I'm not able to get
>> program open so easily. I won't even know immediately whether
>> or gedit, or kwrite, or any particular graphic application is
>> installed. By aliasing a generic command to an installed graphical
>> application, that problem goes away. Add in the bonus benefit of
>> commands being configurable (system wide and also by individual
>> you end up with something that is very simple and very useful in my
>> opinion. Please chime in and let me know if you agree or not. Thank
> I'm just not sure it's the best way to do it. But maybe it's the
> simplest one on Linux... just don't forget there are other OSes out
> there. Haiku will not support all fdo standards of course, but some
> other Unices might want to do things differently anyway. So I was just
> showing a different point of view into the discussion.
I'm not sure either. I certainly don't know how best to do it in BeOS.
There are a lot of smart programmers who subscribe to this list that can
chime in on the best ways to implement. I am just trying to get people
to understand the concept, understand that it will not (hopefully) break
anything, understand that it will not force anyone to do anything
differently, and build a consensus that this is something that will be
useful to do. Then we can figure out how best to do it and get it
I suppose the $EDITOR thingy don't map well to the gui usage...
That is right I think. I don't think there is a problem setting a
graphical editor as $EDITOR (actually, it might break stuff, like maybe
break crontab?), but that wouldn't work if you were in a text console.
It also doesn't address all the other application types that I'd like to
include that don't have shell (environment) variables yet.
Thank you François.
More information about the xdg