Idea about generic command framework for launching common applications

[Darren Fulton]

>> Very interesting.   Thank you.  If I just wanted to open a text 
>> editor 
>> [this is just an example], so that I could type up a quick note, I 
>> would 
>> [I don't know what anyone else would do] open a text editor, type 
>> stuff 
>> (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 
>> with 
>> confidence, click Start, Run, type notepad.exe and click the Ok 
>> button.  
>>     
>
> 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 
>> different 
>> distributions, our multiple desktop environments, and the enormous 
>> variety of included and optional applications, I'm not able to get 
>> that 
>> program open so easily.  I won't even know immediately whether 
>> firefox, 
>> 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 
>> those 
>> commands being configurable (system wide and also by individual 
>> users) 
>> 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 
>> you.
>>     
>
> 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 
implemented.

     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.

--
Darren Fulton