xboard-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] ideas for theme support


From: h.g. muller
Subject: Re: [XBoard-devel] ideas for theme support
Date: Sat, 08 Dec 2012 12:42:14 +0200

Some remarks:

A 'theme' does not only consists of (image) files, but also involves
abstract things that cannot be put in a directory (colors, linewidths,
highlight modes). If we want to distribute (or have users distribute)
themes as downloadable entities, the settings should be supplied
in some kind iof file. An ordinary settings file would be perfect for
the job, as it can contain every existing option. So there would be
no need to specify (and think about) what settings can be part
of a theme, and which not. The designer would have total freedom.

I don't see the need for theme distributions to cram everything in
a single directory. This would be a very un-Linux-like solution.
Better would be to have piece sets in one directory, board-square
textures in another, board rims in a third, etc. It should be easy
enough to zip all components into an archive from the default
XBoard data-dir. E.g. have the theme archive contain
pieces/<piece_theme>/*.svg with one svg file for each piece type,
two textures/*.png (or .svg) for light and dark squares, and a
borders/<theme>.png for a rim around the board.

By organizing the files by purpose, it is much easier for the user
to browse for alternatives (when the file browser is made to start
at the currently selected item) when he does want to create his
own theme 'a la carte'. Especially for textures this is a great
way to do it, as modern file browsers typically show you a preview
of the contents if an image file as thumbnail icon.
There is no need to separate svg from png resources, as the same
XBoard options or dialog entries ae used for both; it would just
hinder browsing through the possible alternatives.

Current implementation of themes in WinBoard is that a theme
is a collection of ordinary command-line options, saved on one line
of a new, multi-line -themeNames option. In complete analogy with
an 'installed engine' being a collection of options specifying the
engine binary and engine-related settings through command-line
options. The problems of theme and engine management are
in fact similar to a quite high degree.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]