2008/5/15 Jason Simanek <firstname.lastname@example.org
On Thu, 2008-05-15 at 09:27 +0200, Benny Malengier wrote:
> css switcher change them for the user, or give the user one
> choice for primary, one for alternate, and one for printer?
> No, I wouldn't do that. This is the only calendar report in GRAMPS,
> no? I have the impression most people print out the calendar as gifts
> on eg newyear, so extra text specific for website viewing (eg css
> switcher) is an annoyance in that case.
First, I think that we're better off in both web plugins if we simply
offer a primary stylesheet, a High Contrast style sheet and the Print
stylesheet (which works automatically). The author will make a decision
about how their site should look and offering all of those other
sheets... I don't think it will be beneficial to 98% of our users or
their web site visitors. It seems to me that the main reason for adding
the style switcher is to benefit the visually impaired.
> So, if there is a css switcher, there should be a way to do away with
> it, if the user wants to create a gift instead of a calendar in a
When something like the style switcher is added to a site, the
available. If you don't make it that way there is potential for buttons
to be on screen that inexplicably don't function.
In the same way of thinking, a style sheet created with printing in mind
will exclude all items that have no purpose on the printed page. This
includes site navigation and definitely something like the proposed
It sounds like we need to offer options for print stylesheets in the
case of the WebCal.
> People want some customization, and editing a css file with a text
> editor is not a skill aunt Martha has. She is able to set a background
> in a dialog though.
> Perhaps split the css in two parts, where some user configurable
> options remain on the dialog and go to the css that is written out in
> the plugin. Make sure also the print version is very similar to what
> is seen on screen.
What a mess!
The first big problem with using HTML to construct a layout intended for
print is that most browsers block background colors and images from
printing. With that in mind, I think this method is a poor choice if
Aunt Martha is going to tweak the appearance.
But things are what they are, so: I can see leaving some of the style
options in place while having a primary stylesheet that controls the
whole appearance otherwise.
As for Aunt Martha, I think that if we provide a few great style options
that she can see in a preview image she won't even bother to alter the
colors. The way you select custom colors right now demands that you know
the 'name' of what you are coloring. I don't see laymen bothering with
this after realizing that there's no 'preview' pane. Personally, if they
want customization they can learn how to use Scribus, Inkscape, GIMP or
OpenOffice to create their own calendar. (In Ubuntu they could even
print the calendar to PDF, then open the PDF in Inkscape or GIMP to
customize to their every whim.)
We're trying to offer a dynamically generated website or calendar that
takes care of the appearance for them. It just works and looks good. We
need to stay focused on what GRAMPS is and is not. It's not a 'Create
Your OWN Calendar!' tool.
Ok, I just pointed out a frequent use-case for the calendar. If the print is good, and if we can put in the manual how users can do their own fine tuning (which they will want to do, think, oh, I want different kittens as background for the different months), then all is fine. As Gimp/inkscape/... are free tools like GRAMPS, I have no problem to direct users in the manual to that route.
I believe the present style editor is not adequate anyway for the things some users would like to do.
Note that most commercial genea apps have calendar tools because they are something users expect to be able to generate, so it is an important plugin for GRAMPS.