console/desktop integration

[Dennis Heuer]

>Furthermore, please, please, try to remember that this is not just 
>about free operating systems - there are commercial UNIX variants 
>which deploy GNOME et al. So you'd have to convince them to add all 
>that stuff to their utility set.
>
>Moreover, for existing tools on proprietary operating systems, it's 
>unlikely to ever get supported by the tool itself. I swear some of 
>those proprietary UNIXes have stuck with the same 'find' and 'ls' 
>source for the past decade or two.

I agree that this can cause problems.  I'm alright with a database if FreeDesktop wants to host it? Still the dialog layout is dynamic. Maybe the selection method should be a bit like clicking through yahoo and finding the right app by category.

>Of course, having a command line switch that generates a database 
>entry is useful, however, it would never be universal, and is an 
>implementation detail belonging in a recommendations document, rather 
>than a standard.

Actually, it was a proposal. If not only an article ;)

>Well, many command line tools are just that - command line tools. 

Urgs, don't say that. I'm working on the desktop but find myself using the console more than 60% of the time. There's a need for more integration. The desktop won't fully satisfy my needs in the next 5 years, I'm shure.

>Only a very few make sense to launch in a GUI.

They don't have to launch in a GUI, they shall be started through the GUI. This can make sense with very many tools.

>I don't think your proposal, or a similarly designed working one, 
>would be useful in all cases:
>

Your critique here is targeting at well known patterns. Only a database or clearly defined actions can provide well-prepared patterns. If not, the user has no choice but must search for the right tool and learn how to start it right. Differ between well-prepared use-cases and the rest.

>2) The GNOME "Run Command..." dialog.

My critique was different. Actually, there are two points of critique. First, there is no search button or other selection method. Second, there is no way to find out the parameters of a tool. You have to know them or start the tool in a text console first. I didn't write about GUI methods for "generic programming", you got too far with that.

>
>Even if you restrict the concept to running a single command, I'd 
>appreciate a GUI rendition of 'find', and the proposed output of 
>'find --list-params' to go with it. I cannot actually think of a 
>suitable way of achieving what you want here.

Seems that my english is not so good. If I understand this right you talk about a GUI specifically for 'find'. Then there's no need for "--parameter-list". The article targets at more general dialogs and apps.

>> There was another person saying that "generating" the parameter 
>> text is complex. No, it isn't. It is the same complex as printing 
>> the help message (application --help).
>> 
>> 
>It is significantly higher complexity, to be fair.

No, it isn't. You got something wrong. The commandline tool only prints a text. It does not generate anything. I really mean plain text. It is formatted, but by the author and not by the tool. The formatting is in the text (how it is written) and not a process. Only the parsing dialog must conquer the format. This said, the text is created and updated the same as the "--help" output, really.

>So please don't attack people simply because they disagree with you. 

I do not attack, I defend. Its the others... Its just that most of the critique up to your message was nothing but braindead slaughter.
 
Regards,
Dennis