console/desktop integration

[Maciej Katafiasz]

Dnia 09-08-2004, pon o godzinie 12:01 +0200, Dennis Heuer napisał:
> Sorry but kidnaps comment is naive because he just mixes up some
> grasped information without reflecting what he was writing. Your tip,
> eventuality, shows that you didn't reflect the article as well. A
> better tip would have been: http://www.systemstability.com/ccli.html

Of course I understood your article, and as I say, it's pretty naive.
First thing is what knipknap points out: how are you going to tackle
parameter-ignoring script someone placed in your path that does "rm -rf
~/"? Second thing is, you ignore completely more complex activation
scenarios, like network-based ones, and influencing already running
application -- support for that from command line means turning _every_
app into "unique app" instance, and coming up with sketchy ad-hoc IPC
mechanism anyway. Thank you very much, I'll pass.

> There is no similarity between eventuality and my approach because
> "Eventuality is designed to fully leverage on latest-and-greatest
> technologies in F/LOSS world, particularly D-BUS, Evolution Data
> Server, and GNotify. " and trying to substitute action-based systems
> like cron while my approach just wants to make existing console tools
> communicating about themselves to enable other apps (dialogs, midnight
> commander, nautilus, vi and other tools that provide a kind of console
> access) to integrate these tools. The difference is that eventuality
> relies on predefined "actions" (OO-commandlines) but my article
> focuses on how to integrate unknown but existing and still used
> commandline tools.

Oh, really?

mathrick at megumi:~$ gimp --parameter-list

Invalid option "--parameter-list"
GIMP version 2.0.3

Usage: gimp [option ... ] [file ... ]
(...)

I don't see it being used in "existing but still used tools"
Adding support for it means:
1) Work of coming up with sensible and well-covered spec for it
2) Work of documenting every option
3) Work of restructuring apps' internals into interfaces supporting it
4) Work of testing it in real life
5) Work of fighting with old, non-conformant apps (remember rm -rf ~/ ?)

I can't see how it's better or easier than adding proper support for
something that's actually designed for that purpose.

> The more I discuss about the problem the more I see that people do not
> even want to see the problem because they see things from only their
> position, their project and their ivory tower. Eventuality, d-bus,
> gconf etc. are all future solutions not playing well with today's
> console tools. Console tools would have to support this future vision
> which means that the developers must do far more than they'd have to
> for my idea. So, what's the point about "not getting developers to
> support it". As I wrote, not every tool on earth must support it. And,
> most apps support "-h,--help" or "-v,--version" or "-u,--usage" in
> either way today. That not really all (100%) tools support these
> parameters doesn't mean anything. It's like not all archives support
> configure/make. However, more than 80% do, and you always find an
> alternative app using it.

And? Do you think it's only a matter of extending --help? For small
hacks, sure, but for any reasonable coverage, it's 5 points above, and
it's still essentially a hack after all the work.

> The second possible approach is creating a database like an RDF-based
> system, as was mentioned at Footnotes.org. This would not be
> maintained by the developers themselves, pushing the work to the users
> or maintainers (distributors) who will never catch up if there's not a
> simple way of producing the db automatically. This is what my approach
> offers. My approach also offers the documentation of the parameters,
> not only the app type.

DBUS interfaces are pretty much self-documenting, when it comes to
listing supported methods and parameters. And real documentation still
needs to be written, and can't be autogenerated.

> To make that absolutely clear now: My article is not just about future
> GNOME, it is about those situations where a user MUST find a dynamic
> solution or is left alone with writing an action or commandline
> somehow. I'm talking about when the user needs to select a commandline
> tool that may be registered somehow in a db but not to the extend that
> the user could just configure the attributes and make it run
> appropriately. You can try to provide him with an action-based script
> language or a more complex solution, you can try to support him with a
> functionally restricted registry, you can base on GNOME-apps only.
> But, if the user wants to access the console tools on his system, as
> they are given today and for the next years, what can he do then
> except starting the terminal? How can he make them work fine with,
> say, nautilus console (an often formulated wish)? How the user can
> select these tools from dialogs in an almost HIG-compliant way?

Can you tell me, what is the basis of your statements here? Why do you
think Evt _has to_ be limited, GNOME-only, or terminal unfriendly, or
that it can't provide friendly dialogs? And your almost-HIG is bullshit
anyway, starting with "help" and "version" parameters as the very first
ones listed in your "HIGgish" dialog.

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

Pffft, again the same naive thinking. _Printing_ text dump is easy, I
can hack up script that does that for DBUS interfaces right _now_. What
is hard is making it do something _useful_.

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl