Il giorno mar, 20/03/2007 alle 17.58 -0400, Thomas Fitzsimmons ha scritto: > Mario Torre wrote: > > Hello! > > > > I've added some stuff in it. Above all it is now a command line tool, > > with a gui option (that need some love, but it is usable). > > > > Only for today, the name of the tool is "tap". Suggestion for a name > > welcomed! > > I'm a little hesitant to add this tool as a full top-level binary, > because it will only be used by non-KDE and non-Gnome desktop users. > That said, I can't think of a better way to provide this functionality, > so I guess I can't object.
Yeah, I think that too, even if my original idea was to expand this tool to cover other aspects of the configuration, not only the desktop api (and import/export of preferences for backup). For example, we could get the XML factory class name, instead of querying /META-INF/services/javax.xml.parsers.DocumentBuilderFactory, by querying a runtime preference. This could revert to a fine default if no preferences are stored. The benefits here are that users and packages can configure classpath without recompiling/repackaging, and in a permanent but flexible way (as opposed to defining a system properties that have to be done every time). Note that the tool is used to let the users to configure these settings, not to retrieve the settings at runtime (for that we will use the standard preferences api) Anyway, I'm convinced too that it is too soon to talk about that (I'm still thinking about it, and I'm not really sure of all the side effects etc...). > The binary needs a more descriptive name though. Anything with > "classpath" in the name could be confused with a CLASSPATH manipulation > script. Any suggestions? Yeah, true... In my tree I have it named just gsetuptool, but this name does not convince me either... I'm really bad at finding names, sorry. > Also, maybe there should be a configure option to disable this, for > distributions that do choose a preferred desktop (most distros); > otherwise users may think they should configure classpath using this > binary, rather than relying on auto-detection/their desktop's > configuration tool. True, but notice that the autodetection works based on the desktop the user is running, and not the default desktop the distro chooses. This is important, because if I want to run, say, on Fedora, an xfce session, the application will not work if the requested command is not found in the preferences (or given as a property). So disabling it will prevent other users to access easily the values needed to change this behaviour (though one can use gconftool-2 or edit by hand the content of ~/.classpath/path_to_prefereces.xml) [1]. Said that, I guess the best would be to put this into the examples directory, and putting all these configuration files into a README.configurations for example, so that even if the tool is not enabled, users know where to look. > Tom Thanks for the comments! Ciao, Mario [1] Btw, we have done a better job than Sun here already, because we support more operations, KDE support out of the box all the operations, Gnome misses only the print tool, while every other desktop is configurable, and we could use this API even from the command line in an headless environment if we would! -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: [EMAIL PROTECTED] - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
signature.asc
Description: Questa รจ una parte del messaggio firmata digitalmente
