console/desktop integration

[Dave Cridland]

On Sun Aug  8 12:10:05 2004, Mike Hearn wrote:
> I'm not a Gnome or KDE developer, but here are some initial thoughts
> anyway:
> 
> - Is it smart to have the app itself generate all this text which is
> parsed? Would it be better to add the information to .desktop files
> instead? Having it in the app seems to dynamism at the expense of
> complexity.
> 
> 
Also, what happens if the command normally does something akin to 
taking the command line argument, and writing several thousand meg of 
data to it? Or worse, execute it [eg, nohup]? Or ignore all command 
line arguments and do something dangerous [eg, lots of shell 
scripts]? There's no backwards compatibility for older applications 
(when I say 'older', I mean 'current'.)

Bear in mind that not all applications support long command lines, or 
'--help', which have both been around for a while. I don't think 
expecting this kind of support from utility writers is at all 
practical.

A nicer interface would be:

parameter-list gnome-cd

Or a DLL interface, which could then look it up in a database or 
something.

Or possibly it might parse the man page, which would be pretty cool.


> - Is it solving the problem? Shouldn't apps like Nautilus, Totem 
> etc be
> having this configuration (what do I do when a disk is inserted?) 
> as part
> of their standard configuration UI? If so, would it be better to 
> simply
> activate the given app with a "disk inserted" message, either via 
> command
> line arguments or a service activator like DBUS?
> 
> - Even if arguments like --no-desktop were configured graphically 
> these
> are implementation details of the system. It might be smarter to 
> have a
> simple set of standards like "All programs that can do something 
> useful
> when a blank cd is inserted should add the following to their 
> .desktop
> files" and then the drop down list in these sorts of windows can 
> compile
> it from that.
> 
> 
The above two are interesting in combination. "I can handle these 
system-level events." would be an interesting thing for applications 
to be able to say. "Use this application to handle this system level 
event" is an interesting thing for the user to be able to say, too.

I like this.


> Basically I don't think you want to be super-generic here, command 
> line
> arguments are meant for usage from the command line: many don't 
> even make
> sense in a graphical context. I think it'd be better to have a 
> specific
> solution to this sort of "pick an app" problem instead.
> 
> 
I think both are interesting, for different purposes. The first is 
useful as a general catch-all case for running an otherwise unknown 
application for the user's nefarious purposes - it can be useful.

The second requires a uniform system event notification/dispatch 
system, and plonks us back into that thread. 
As for device names for network interfaces, that's a bit of a problem 
since they're arbitrary - moreover, it's vital for a 'real' systems 
administrator to know what they are.

However, I basically agree that GNOME could manage to say "Wireless 
LAN (eth1)", since it obviously knows this to be the case in order to 
display the sig strength.

Dave.