console/desktop integration

Mike Hearn mike at navi.cx
Sun Aug 8 14:10:05 EEST 2004


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.

- 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.

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.

thanks -mike

On Sun, 08 Aug 2004 10:36:09 +0200, Dennis Heuer wrote:
> Sorry, didn't know where to post it.
> 
> I've written an article that's in heavy dispute. Some writer told me:
> 
> I would suggest getting your idea started as a thread on a freedeskop
> list that is relevant, or a gnome list. Your going to do your idea a
> disservice if you get too hung up on specific implementation details
> before the 'right' people get a chance to be sold the importance of
> addressing the problem raised in the article.
> 
> So, ok, I try to pronounce my article here:
> 
> Console and Desktop Shaking Hands
> http://freshmeat.net/articles/view/1267/
> 
> Regards
> Dennis Heuer




More information about the xdg mailing list