> On Jul 31, 2017, at 11:02 PM, Geert Janssens <geert.gnuc...@kobaltwit.be>
> wrote:
>
> Bob,
>
> As hinted in my previous message in the Gtk3 thread, I'd like to zoom in a
> bit
> on using Css for gnucash.
>
> Let me start with a basic context for this discussion:
> * css in gtk (and hence gnucash) is used to define the visual representation
> of the graphical user interface (defined through a set of "widgets").
> * for the best user experience the GUI should be consistent in style.
> * for standard widgets, gtk defines a default style (the Adwaita theme).
> However users are free to configure a different style (or theme) for their
> environment. Optionally each property in a theme can be overridden at a user
> level by a user-defined css file.
>
> So for standard widgets, gnucash usually doesn't have to do anything. This is
> different for our custom widgets, such as the register and the SX overview
> calendar (both based on a GtkLayout and doing custom drawing via cairo), or
> widgets that define their own functional colors (like the transaction matcher
> in the generic import code).
>
> These widgets don't have a style by default, and hence we need to define it.
> At the same time though, themes should be able to override whatever default
> style we choose. This suggests our own styling should generally have a
> FALLBACK priority rather than APPLICATION priority.
>
> For any style property that is defined in the theme set by the user, this
> will
> then be used. If we define gnucash-only properties, these will most likely
> not
> appear in any theme and hence the values from our fallback will be used
> instead.
>
> The tricky part here is to define a fallback that goes well with whatever
> theme the user has set for his environment. Take for example the colors used
> in the SX overview calendar (white background/black text). These may not work
> well with all themes so we should avoid to hard-code properties as much as
> possible. I would instead propose to leverage the style classes as defined in
> GtkStyleContext as much as possible [1]. Again for the SX overview calendar,
> add a style class GTK_STYLE_CLASS_CALENDAR and then use whatever styling
> information that gets set because of this [2]. Perhaps it requires more than
> one style class to be added to get this to work completely. You can look for
> examples in the Gtk source, like the use of the RUBBERBAND class in
> gtktreeview.c [3]. I believe/hope when done carefully this can result in a
> much more consistent GUI for gnucash and may reduce the amount of css we have
> to maintain ourselves.
>
> Then, specifically for the register we have an option that allows the user to
> switch between the system level theme or our yellow/green theme. Building on
> the above, the system level theme should be composed using the right style
> classes. The yellow/green theme on the other hand is the first example I have
> found that warrants a separate css definition. And this time with APPLICATION
> priority because it's supposed to override theme specific styles. I would
> define a new style class (something like "gnc-custom-colors"). And in css
> write a section like this:
>
> .gnc-custom-colors
> {
> color a: xyz;
> color b: abc;
> ...
> }
>
> What the exact properties should be will depend on the properties we combine
> from the built-in style classes. If the built-in style classes for example
> provide a property "separator-color", we should set this property also in the
> .gnc-custom-colors class.
>
> With this css in place, switching from default theme colors to our gnucash
> yellow/green theme is a matter of adding/removing the gnc-custom-colors style
> class from all register related widgets.
>
> This same technique could be used for the label colors (negative numbers in
> red). Only define an additional class ("negative-numbers-in-red" would do
> fine) in which you explicitly set the red color to use and then add or remove
> this class from all widgets that need to be able to display negative numbers
> in red based on the user preference.
>
> The last thing I'd like to bring up is the choice of property names. I read
> in
> your initial conversion to css you have chosen names very close to the
> internally used variable names. While this is not wrong, I would prefer to
> use
> names that better describe the property's function.
> Let me explain with an example: the rows in the import matcher can have 3
> colors (currently red, yellow or green). These colors support the state of
> each line (unmatched, partially/potentially matched, matched? This may not be
> the exact state meanings).
> The name of the class you have chosen describes which property gets changed
> to
> what. That's 1) redundant, 2) little informative and 3) restrictive. The
> property itself already holds the information (hence redundant), it doesn't
> tell the user why this property is changed (little informative) and will make
> the user hesitate to change it to anything else than a red background
> (restrictive). What if a theme designer decided a better approach to making
> this distinction would be to use a different font ? So rather than making
> class names describing which property is changed to what ("background color
> should be red") the class names should describe its function. In this
> particular case the class names could have become: "no-match", "partial-
> match", "full-match". Feel free to use even better names if my interpretation
> of their function is incorrect.
>
> Those are my thoughts so far on css.
>
> What do you think of this ?
>
+1 on all points.
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
