polly-open-team team mailing list archive

[Joern Konopka <cldx3000@xxxxxxxxxxxxxx>]

Oh great, now i accidentally sent this?
This was in my Drafts Folder for months, so i don't even know what's the
current state of this. If it is comepletely outdated please excuse me. Also
excuse me if there are sentences that don't make sense whatsoever. I was
just brainstorming and just wrote from the top of my Head.

2012/10/8 Joern Konopka <cldx3000@xxxxxxxxxxxxxx>

> Hey everybody,
>
> this Thread is supposed to shed some light on what will be possible with
> Stylesheets in Polly and will hopefully grow with various opinions and
> debates around things like:
>
>
> -What *can* be done anyways
>     http://gnomejournal.org/article/107/styling-gtk-with-css  <- This
> Page provides a nice overview of what can be achieved with CSS and GTK. Now
> we would have to start getting
>     creative with it as soon as CSS support lands. Sandboxing like a Boss.
>
> -Do people even WANT styles?
>    A lot of people love Styles, it would now be nice to know how many
> actual Polly Users (even though we are not that many yet) would like to see
> it supported in a more direct way (meaning an UI Element that will let me
> pick a style). Of course everybody who can write a Style can use a Style in
> GTK3 but that's something for advanced Users and a selection box is not
> evil by any means, it's just not a priority right now.
>
> -How do we fallback if we can't support Styles in some Environment?
>  This is probably the most important thing to keep in mind, not everybody
> has Style out of the Box or even wants that, or at least we can say; we
> shouldn't rely on a style being there.
>
> -----------------------
>
> Some Pro and Contra of Stylesheets in Apps:
>
> Pro:
>   - People love GUI Gimmicks and personalisation (look at this Software
> Center Thingie...that shiny one)
>   - Styles encourage people to get creative and they can contribute to the
> Community without invasive Code changes
>   - Styles are not just gimmicks, they can enhance readability and
> usability too if used right.
>   - Styles are well-known, a lot of people can contribute without having
> to know Python or GTK, they just need a basic Stylesheet.
>
> Contra:
>   - Stylesheets are a Consistency Breaker
>   - Stylesheets might clash with hardcoded values and we have to prevent
> ugly crap before it can happen.
>   - Stylesheets have a bit of a "Toy" Image, but Polly should look Pro and
> Confident
>
> ------------------
>
> So what do I think about Stylesheets? I gotta say this is just random
> stuff going through my Head, please don't punch me if i get stuff wrong,
> especially in terms of GTK, i just don't know enough about it:
>
> Just recently Conscious User posted a new Blog Entry
> http://consciouslyusing.blogspot.com/2012/02/design-rethinking-style-preferences.html
> which has some overlapping with the CSS Topic, so let's look what's going
> on in that post:
>  -Unread Items get their own custom color
>  -Mentions get their own custom color
>  -Each will support an array of pre-defined colors (for convenience), a
> custom color ,the ability to make the Items appear Bold or Italic or just
> no styling at all.
>
> That's where my Bells started ringing in terms of "Wait, if i make a
> Theme, i cannot set (or suggest) the Colors for that?" and i started
> wondering if that is a bad thing.
>
> One could argue that a User who changes his Style, can also pick some
> suitable colors himself. Which is most likely what people will do when they
> realize their green Mentions don't go well with their Pink Style.
>
> Also i know that, for now, Stylesheets will not become a
> Gamechanger-Feature, but how do we approach the new school of handling App
> Styles in general?
> After all, we might end up having the Basic UI, plus an "advanced" UI that
> makes use of some CSS beauty like decent gradients or
> animations/transitions at some point in the future for all the people who
> CAN and want to take advantage of it.
>
> Having a Custom Stylesheet control the highlight (and other states) of
> those different "Types" of Widgets just makes sense and it can still fall
> back to a default color, also the fact that GTK most obviously doesn't
> feature Classes that are called "mentions" or "unread" for Widgets, leaves
> us with having to implement a way of making those Widgets distinguish
> themselves from usual Posts anyways. And i probably don't have to remind
> you that it should be no problem to use UI consistent Colors in a
> Stylesheet thanks to mix, shade and direct pointers to those colors via the
> @ selector in CSS.
>
>
> So what i'd like to see is:
>
> Default Settings as a Fallback (of course)
>
> -A basic stylesheet that provides Selectors to all important Widgets and
> Containers (and see Polly make use of it where it improves the basic App )
>      -Can be used for experimenting or creating custom Styles from it
>
> ----------------------------------------------------------------------------------------------------------------------------------
> /* Polly Stylesheet */
> *{}
> .menubar{}
> .toolbar{}
> /* ... */
>
> .mentions{ background-color: darker(@bg_color); }     /* we set some
> default color from system color, can be overridden in the Custom Style  */
> .mentions:selected{ background-color: shade(@bg_color,0.7); }  /* we're of
> course only deriving colors from current background color in the basic
> stylesheet */
> .mentions:hover{ background-color: mix(@bg_color, darker(@bg_color)); }
> /* ... */
>
> .unread{}
> .unread:selected{}
> .unread:hover{}
> /* ... */
>
>
> -----------------------------------------------------------------------------------------------------------------------------------
>
>
> -A Color Stylesheet that provides a basic set of suggested Colors (or
> Gradients!) for the User to pick from the settings a la:
>
> -----------------------------------------------------------------------------------------------------------------------------------
> /* Polly Colors CSS */
>        .mention-color-variant-1 {
>  background-image: -gtk-gradient (linear, left top, left bottom, from
> (shade (@selected_bg_color, 0.9)), to (shade(@selected_bg_color,0.7) ) );
>        }
>
>       .unread-color-variant-1 {
>                    background-image: -gtk-gradient (linear, left top,
> left bottom, from (shade (@selected_bg_color, 0.3)), to
> (shade(@selected_bg_color,0.5) ) );
>       }
>
>       .brick-red{ background-color : val; }
>       .grass-green { background-image: -gtk-gradient:thisandthat; }
>       /* ... */
>
> ---------------------------------------------------------------------------------------------------------
>
> -These Stylesheets can be easily maintained, which is a big plus
> -Some way of saving custom colors? in a CSS?
>
> So it would end up parsing like:
>
> Default Settings (Bold, Italic, [Custom Color] ) can be overridden by..
>    - optional Default Stylesheet (provided by the Team) can be overridden
> by..
>    - optional Custom Stylesheet (provided by whoever wants to write it)
> can be overridden by..
>    - optional Color Stylesheet (lives on top cause we want to leave color
> control up to the user)
>
> Now you see we have those nice Classes, they will be parsed into the
> GtkStyleContext, but since no GTK Widget has a class with that name it will
> have no effect, the class that shall be used has to be added to the element
> with gtk_wiget_path_iter_add_class(Widget, pos, classname) and
> gtk_widget_path_iter_remove_class() respectively. (
> http://www.lanedo.com/~carlos/gtk3-doc/gtk3-GtkWidgetPath.html#gtk-widget-path-iter-add-class )
> which will then add the class. From what i understood GTK will be smart
> enough to react directly to the added class and will redraw the targeted
> Widget instantly.
>
> So what would happen here in terms of CSS would be:
>
> Item.mentions <- will be set from either Default Settings and/or Default
> Stylesheet
>
> Now if somebody want's to make this custom styled, he can do it in his CSS
>
> Now i selected my Custom Stylesheet and just don't like the Mentions or
> Unread Color so i go to the Settings and set that manually from a list that
> will be parsed from the Colors.css now GTK will just append that class to
> the Elements a la:
>
> Item.mentions .grass-green
>
> and since the :hover and :selected States are usually just derivations of
> the bg_color it will look allright, if somebody overrides those states with
> hard values in the custom CSS it might look fucked up, but thats probably
> not the theme you would want to use and you can just kick out the theme or
> even fix it yourself.
>
>
>
> About the Color Picker:
>
> On G+ i suggested to Marcelo that he should add a "Theme Color" to the
> Selection shown at
> http://consciouslyusing.blogspot.com/2012/02/design-rethinking-style-preferences.html ,
> to which he replied:
>
> "Even if GTK provided support for names, the problem is that Adwaita,
> Ambiance, Radiance and all other popular themes would not have the name. So
> we would require the usage of a custom theme or a manual change in the
> current theme, which in my opinion kinda defeats the purpose of having a
> "theme color" option in the first place..."
>
> Which of course is right , i would probably expect Polly to pick a Color
> for Mentions that will fit in with f.e. Ambiance, like a light version of a
> highlight color or another derivation of a theme color currently used.
> That case would be covered by the way the Default Stylesheet or Default
> Settings are applied using derivations and variants of Theme Colors.
>
> So having a special "Theme/Style Color" is not neccessary like Marcelo
> sad, but colors that are set in Custom Stylesheets should not just simply
> dissapear, matter of fact, they should just be added to the list of
> selectable colors in the Color Picker without further notice about it's
> origin.
>
> [image: Inline-Bild 1]
> 1. Adding a Style will change the default colors if used (pushing the
> current colors to "previous color")
>   -If the User selected a custom color before applying a style, the Style
> Color would just be added to the list of selectable colors
>
>