I'd like to propose some structural changes to both the codebase directory hierarchy and the directories created during installation. If these changes are acceptable, they could be introduced for the 0.38 development cycle.
Bryce
Distribution / Packaging Files ============================== Presently, we have a number of files in the codebase related to generation of distribution packages. Some of these files are in the root inkscape/ directory, others are in subdirs like inkscape/debian/.
To head off potential clutter as Inkscape becomes supported on a wider variety of systems, we should collect as many of these packaging files as feasible into a subdir called inkscape/packaging/.
Inside that directory would be distro-specific subdirs, plus a common directory for shared scripts and collateral:
inkscape/packaging/ common/ debian/ fedora/ fink/ mandrake/ suse/
Config Files ============ Currently we do not have global config files, but instead put the config file in the user's home dir in ~/.inkscape/. These are generated at run-time by Inkscape itself, so the defaults are hard-coded into the application, and can't be customized by the sysadmin except by editing the appropriate header file and recompiling/repackaging the app.
The correct approach for Linux apps is to have both user and global configs, and to use the global as the default if the user does not yet have a config file. This way, site customizations are known (such as the fact that its shared files are in /usr/share, vs. /usr/local/share, vs. /opt/inkscape/share, etc.)
The proposal is for Inkscape to establish its config file location in /etc/inkscape/, and to place a global preferences.xml file there, as well as any other config files we need later, like extensions.xml, etc.
Ideally, the global config file would be loaded first, and then the user config file "override" any portion of the global options. This way the user config file only needs to contain customizations, so that if we choose to change the defaults in a future install, the user's config files do not necessarily become invalid.
Inside the CVS codebase, the default etc. files would be stored in inkscape/etc/, instead of being produced by the application at runtime. During installation, installation-specific parameters (such as alternate paths for various files) will be substituted in appropriately.
"Share" Collateral ================== Inkscape currently generates a /usr/local/share/inkscape/ directory during install, and copies the contents of the codebase's icons/ directory to that location.
We need more pieces of collateral installed, and need to do so in a more organized manner. The recommendation is to establish a set of subdirs in /usr/local/share/inkscape/, as follows:
AUTHORS NEWS clipart/ examples/ extensions/ fonts/ gradients/ icons/ keyboards/ markers/ palettes/ patterns/ screens/ about.svg templates/ tutorials/
This uses a flat hierarchy for the sake of simplicity.
In the CVS codebase, all of these would be placed in inkscape/share/. This way, the installation script could be set up to recursively copy everything in that directory to the target share directory, and we won't need to specify each of the subdirs in that script, which will make maintenance less hassle.
For clipart, I think we definitely want to consider being able to tie in with "external" clipart collections. One way would be to simply put symlinks in the clipart dir to those collections. This way, if the flags package were to install into /usr/share/flags-svg/, we'd just symlink there.
Possibly similarly for extensions.
I think an argument could be made that the tutorials ought to be placed somewhere under the /usr/doc/ or /usr/local/doc/ path, so I'm not 100% certain of having the tutorials located here.
On Thu, 2004-02-12 at 00:22, Bryce Harrington wrote:
Distribution / Packaging Files
Sounds good to me.
Config Files
This sounds like a good thing to do, but I'm curious if it's not a waste of effort if we're going to go to a GConf/registry solution in the future. We get most of this configuration stuff for free from GConf in the unix world (and Windows people don't expect that level of administration ;).
"Share" Collateral
I like this too.
For clipart, I think we definitely want to consider being able to tie in with "external" clipart collections. One way would be to simply put symlinks in the clipart dir to those collections. This way, if the flags package were to install into /usr/share/flags-svg/, we'd just symlink there.
I think it would be better for us to have a configuration item that is the list of directories to look for clipart. This way we could have the same 'global' and 'user' directory, but also any clip-art library on the system directory.
Possibly similarly for extensions.
I think the above has to happen for extensions.
I think an argument could be made that the tutorials ought to be placed somewhere under the /usr/doc/ or /usr/local/doc/ path, so I'm not 100% certain of having the tutorials located here.
I like having them in share personally. Just because I think that most people are going to access them through the menu item - and thus are an internal function not a documentation one.
--Ted
On Thu, 12 Feb 2004, Ted Gould wrote:
On Thu, 2004-02-12 at 00:22, Bryce Harrington wrote:
Distribution / Packaging Files
Sounds good to me.
Config Files
This sounds like a good thing to do, but I'm curious if it's not a waste of effort if we're going to go to a GConf/registry solution in the future. We get most of this configuration stuff for free from GConf in the unix world (and Windows people don't expect that level of administration ;).
Oh, I didn't know we were going to go to GConf. Are we certain that's the right way to go?
"Share" Collateral
I like this too.
For clipart, I think we definitely want to consider being able to tie in with "external" clipart collections. One way would be to simply put symlinks in the clipart dir to those collections. This way, if the flags package were to install into /usr/share/flags-svg/, we'd just symlink there.
I think it would be better for us to have a configuration item that is the list of directories to look for clipart. This way we could have the same 'global' and 'user' directory, but also any clip-art library on the system directory.
My thinking is that if it is done via a config file, then when the application in question installs itself, it would need to parse and re-write Inkscape's config file, whereas with symlinks no such parsing and editing would be expected.
Possibly similarly for extensions.
I think the above has to happen for extensions.
I think an argument could be made that the tutorials ought to be placed somewhere under the /usr/doc/ or /usr/local/doc/ path, so I'm not 100% certain of having the tutorials located here.
I like having them in share personally. Just because I think that most people are going to access them through the menu item - and thus are an internal function not a documentation one.
That was my thinking as well.
Bryce
On Thu, 2004-02-12 at 19:57, Bryce Harrington wrote:
Oh, I didn't know we were going to go to GConf. Are we certain that's the right way to go?
I think so, I think the largest issue is what to do on Windows... I think that they're we're going to have to work with the registry directly. So, at some point, we'll have to abstract between the two.
I guess I see the reasons to go to GConf as basically the ones you've listed. You can have settings with defaults, over-writable by the user, and then also can have forced values by the administrator. Also, it makes it easy on us, we don't have to parse anything. It also has some nice data structures like lists built in, which can make things simpler.
I think it would be better for us to have a configuration item that is the list of directories to look for clipart. This way we could have the same 'global' and 'user' directory, but also any clip-art library on the system directory.
My thinking is that if it is done via a config file, then when the application in question installs itself, it would need to parse and re-write Inkscape's config file, whereas with symlinks no such parsing and editing would be expected.
Hmmm, yeah, didn't think of that. Symlinks seem like kinda a hack, but I can't think of anything better...
--Ted
Ted Gould wrote:
On Thu, 2004-02-12 at 19:57, Bryce Harrington wrote:
Oh, I didn't know we were going to go to GConf. Are we certain that's the right way to go?
I think so, I think the largest issue is what to do on Windows... I think that they're we're going to have to work with the registry directly. So, at some point, we'll have to abstract between the two.
Sounds doable.
But I would go further, and suggest that we design such a generic abstraction before we commit to GConf. This would be a reality check to make sure both architectures can support what is needed.
Bob
participants (3)
-
Bob Jamison -
Bryce Harrington -
Ted Gould