Re: Netstatus dialog
> Where did you get the (stupid) idea of
> /dev/MyDriver? There is no such thing in
> almost, if not all all UNIX like
> systems. Network interfaces are not
> character or block devices, they live in
> a namespace of there own.
I fully agree that there are cases unknown to me. I just wanted to show that if the dialog doesn't know a registered name for the device it can print (unknown device) in combination with whatever is available. This way you get the original name on screen. The original name may always be shown besides the descriptive name. Being descriptive as far as it works was the aim of my example. Nothing else, calm down.
Console and desktop shaking hands II
Because of heavy dispute I decided to write this second part. The dispute showed four types of comments:
1. what it's worth for?
2. doesn't work
3. can you give some alternatives
4. would love it
I will not answer to the first type because these people are just not target of my article. The comments of second type weren't always helpful. Some authors were just off topic. I think, I reach them more effectively by answering to the third type. The authors of the fourth type will love that too, I think.
My article crossed three main problems:
1. desktop and console are lacking interoperability
2. the console is not feasibly discovered and documented
3. console tools don't share internals in a computer-processible way
I discussed the problems in the order in that I discovered them. The comments, however, showed me that this didn't work out. The new approach is based on what was discussed most and how I think this is to be put in order.
Both the comments of second and third type argued about which side is to provide the computer-processible information to enable an automated integration of commandline tools (not only into desktops but also into apps like vi or mc). The graph of possiblilities ranged from highest decentralization (every tool a special parameter) to highest centralization (one single db located on the internet). Both ends of the graph seem to be only suboptimal.
The commandline parameter
Some argued that the developers of commandline tools will never support a new parameter. I still don't agree with them. If a parameter will be available in future is dependent on its sense and not on the number of tools. Most of today's usual parameters (-h,-v,-u,--enable,--disable,--with,--without, to list a few), parameter-styles (short and long form) and even options (yes/no/auto) have been spreaded by just copying them from other tools.
However, there is a crucial problem with the parameter --parameter-list proposed in the first part of this article. The problem is not related to the parameter itself but to the way of using it. There may exist commandline tools that start actions without checking for parameters. If a dialog tries to ask such a tool for its parameters it starts an unwished chain reaction of unknown dimension. I don't want to discuss about the dangerous product design of such tools. They may exist and that's why a dialog or application should not start unknown commandline tools to check for parameters.
I still see sense in optionally supporting the parameter. However, this should be based on the solution discussed further below.
Centralized solutions first sound inviting but fade at second look. My critique is based on four arguments.
1. centralized solutions need full acceptance, otherwise they die out
2. the necessary 24h-availability doesn't only depend on the provider
3. keeping the database up to date is hard work for a single provider
4. providing the right version of information may need client-side knowledge as well
Some argued that such a database should be provided distributor-wise or desktop-wise. The companies or projects have the power to do this. However, xxx-wise alsways means incompatible and redundant work. Some pointed at the .desktop format. This would be enough for the dawn of a solution if it wasn't used desktop-wise only.
The distributors and desktop projects may sample, assort and distribute (parts of) the database. However, there should only be one installation per system, at appropriate place and accessible by all who want to. And, I don't think that console-interoperability should base on strategies unknown to the console.
The mixed approach
I tend to a well-tested organization model. The model splits the database into application-wise files and organizes them at typical places in the filesystem. The same strategy is used by man, info and other tools. I prefer it because
1. the model works very well
2. it works centralized as well as decentralized
3. reasonable desktop integration is possible, as being proofed
4. the question of distribution is solved for years now
5. all parties (distributors, projects, individual developers and users) accept the model
6. everybody is enabled to create, distribute, localize and use the information
7. administrators are enabled to organize the database system-dependent
8. the model can profit from an online-archive, CVS-like update and download features, etc.
There's the problem of finding a good place in the filesystem. I think that placing a new directory besides man and info and storing parameter descriptions in there is not enough. Drawing conclusions from the dispute, there is a need for a new, global and interdependent organization of application-relevant information. For example, a search dialog must be enabled to provide the user with
1. a catalog of relevant application
2. brief information to the selected application
3. ways to go deeper into the materies
4. the application parameters in a feasible manner
5. mime-based actions
Consequently, it would be reasonable to argue that parameter list, man page and other necessary resources must be reduced to just one, big XML document. I don't agree to this because different types of information should be kept separately to ease maintenance and future development.
However, there should be a root directory. For example, there could be a new directory named desc. Below that directory the parameters are found in params, catalog information is found in cat, desktop information is found in desktop, etc. As you can see, I don't believe in the way the desktops go today. They should open their resources and integrate them into a more general, system-wide (not system-dependent) database. If this is sorted subject-wise or app-wise is something to discuss about.
Most comments favourized XML for the formatting of the files. My only critique on XML is that I understand something different under human readable. The format should be easily convertable from XML to txt and back to support "normal" text editing. The concrete formats are a matter of the initiative working on this new approach. Considering the example in the first part, the parameter document could look like:
<app name="GNOME-CD" type="media" class="player" keywords="CD,DVD" param_version="1.0">
The CD Player application enables you to play audio Compact Discs (CDs) on your computer.
<param name="--help" type="switch" title="short help" target="all">
A brief parameter overview
<param name="--version" type="switch" title="version info" target="all">
Display the version number
<param name="--device=" type="string" title="device" target="all">
CD device to use
<param name="--unique" type="switch" title="concurrent play" target="all">
Play the CD on startup
<param name="--play" type="switch" title="auto-play" target="all">
Only start if there isn't a CD player running
<param name="--disable-sound" type="switch" title="ignore sound server" target="GNOME2">
Disable sound server usage
<param name="--gdk-debug=" type="string" title="debug" target="GTK+2">
GDK debugging flags to set
<param name="--gdk-no-debug=" type="string" title="debugging off" target="GTK+2">
Debugging flags to unset
<param name="--disable-crash-dialog" type="switch" title="no alert dialog" target="GNOME2">
Don't display the alert dialog if an error occurs
So far for now. Can't sum up every thought here. Maybe the discussion will go on.