GNOME Bugzilla – Bug 714129
Allow styling composer HTML
Last modified: 2019-03-02 04:25:56 UTC
---- Reported by eric@yorba.org 2011-10-12 16:12:00 -0700 ---- Original Redmine bug id: 4249 Original URL: http://redmine.yorba.org/issues/4249 Searchable id: yorba-bug-4249 Original author: Eric Gregory Original description: GTK+3 supports a CSS-like syntax for themes. The same syntax can be used to theme individual applications. This is exploited by many popular Gnome themes for specific hacks/fixes on certain popular applications (Nautilus, Evolution, etc.) But applications can also load their own themes with little effort. Certain apps already do this, such as Gedit. Here's the basics of how we can do this in Geary. 1. Add this to MainWindow: try { Gtk.CssProvider p = new Gtk.CssProvider(); p.load_from_path("test.geary.css"); Gtk.StyleContext.add_provider_for_screen(get_screen(), p, Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION) ; } catch (Error err) { warning("Couldn't set style: %s", err.message); } 2. Build a default CSS file for users to hack on. I've attached a very preliminary version to the ticket. The upside to this is that users can style Geary however they like; the downside is that themes will be version specific. Related issues: related to geary - Feature #5319: Separate the HTML and CSS currently in the MessageViewer ... (Fixed) ---- Additional Comments From geary-maint@gnome.bugs 2012-01-31 14:26:00 -0800 ---- ### History #### #1 Updated by Eric Gregory almost 2 years ago * **Subject** changed from _Make Geary themeable with GTK-flavored CSS_ to _Make Geary themeable_ Note that with the addition of WebKit, we should expand this to include making the message area themeable as well. --- Bug imported by chaz@yorba.org 2013-11-21 20:25 UTC --- This bug was previously known as _bug_ 4249 at http://redmine.yorba.org/show_bug.cgi?id=4249 Imported an attachment (id=260871) Unknown Component Using default product and component set in Parameters Unknown version " in product geary. Setting version to "!unspecified". Unknown milestone "unknown in product geary. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
I feel like Geary in recent months has become quite themeable thanks to the good work of Wolfgang Steitz and Eric Gregory. I'm running it right now with Adwaita Dark and other than the conversation viewer and the composer edit box (i.e. WebKit) Geary seems properly themed. We've even shorn off many of the custom icons in favor of symbolic. I'm changing this ticket to reflect what I think is the last hurdle, getting our WebKit views to respect theming. If there's more work to be done here than I'm letting on, please say so.
The conversation viewer will be themeable using GTK theme CSS when Geary switches to a widget-based conversation view as part of Bug 714129. Not sure what part of the composer needs to be themable though, just the default foreground/background text colour?
This has improved a bit with 898fa33 landing on master, as part of Bug 728002 - message chrome such as the avatar, sender & recipients, etc are now GTK widgets and themeable as such. With Bug 728002, we'll get a more flexible way to add user style sheets, and should be able to close this off after that lands.
*** Bug 776435 has been marked as a duplicate of this bug. ***
As noted in bug 776435, it might be worth considering whether we still want Geary to be themeable, i.e. customizable without recompiling. (This is no longer the case since we started including the CSS as resources, injecting them directly into the binary).
Well the good news is that users can already provide their own custom CSS to change the appearance of GTK+ apps without needing to recompile them, by editing ~/.config/gtk-3.0/gtk.css and using app-specific CSS selectors. Geary master already includes a number of GTK CSS classes for the conversation viewer and a few other components, which can be discovered via the GTK Inspector, per this post: https://blogs.gnome.org/mclasen/2014/05/06/tweaking-a-the-gtk-theme-using-css/ [Evan, that might help you out with the issues you mentioned in Bug 776435, although bear in mind the widget structure and CSS classes are likely to change a bit more before 0.12 comes out. If there are any classes missing that are making it hard you achieve what you want, please feel free to lodge a new bug about that.] So, because GTK already provides a means of customising an app's appearance using CSS, I'm not very inclined to add duplicate support for it in Geary. Further, since we do still support theming individual message bodies in the conversation viewer via HTML CSS (loaded from the existing ~/.config/geary/user-message.css file), I think the only thing left that this bug could cover is themeing the composer's HTML view contents. What remains for this bug then comes down determining if it's safe to let user HTML CSS apply to the composer's web view contents (in terms of breaking the formatting of outgoing messages) and if so, decide to apply the existing user-message.css file to it, or use a different file ("user-composer.css"?), which should be pretty trivial under the WK2 port.
I just wanted to round the corners of the conversation view a bit (not a lot like a Mac, just enough to take the sharp edges off, like 3px). And since there was documentation around on how to do it, it seemed like a bug. I guess that the real bug is that https://wiki.gnome.org/Apps/Geary/FAQ needs to be updated since that info is no longer valid. For me, editing the source CSS is fine for now while things change ... after all, my own Geary is a bit hacked as a temporary work-around for another bug anyways! Once things settle, update the Wiki with the new instructions on per-app CSS via gtk.css. It's unclear if user-message.css is still supported? And just my 2 cents. I don't think any duplicate work is justified. Mail should be simple. My apps should be uniform, not every app with its own display settings (yuck). So, I don't think a custom theme on the composer is good idea at all. Its actually counter-productive since it won't be WYSIWYG unless you send a copy of that CSS with every outgoing message, and I'm only just starting to be okay with HTML email. I'd prefer to strip out all CSS on incoming email and certainly wouldn't impose my CSS on someone else! So, why customize the composer if its not going to send it that way? As long as it looks like 90% of my other GTK/Gnome apps, then I'm good.
Hmm, good point about the docs on the wiki. When 0.12 is released we'll want to update that so that people on that as well as earlier versions know how to adjust the new GTK theming. I'm marking this as 0.12 for the wiki docs, but applying CSS to the composer web view is probably going to have to wait a bit, unless someone provides a patch. /:)
Mass-reassigning bugs that won't make 0.12.
Re-titling to reflect outstanding work.
Thinking about this a bit, it's probably reasonable to expect the composer body to be styled with custom CSS (or just follow the GTK theme in general) when in plain text mode, since no styling information is sent with the message. However it's a bit fraught when in rich text mode, since if this is implemented in the same way as for the conversation viewer at the moment, the custom CSS won't be sent along as part of the message body and hence the sender will see a different message than the recipients, breaking WYSIWYG. So we have a few options here: 0. Don't allow styling the composer body (or follow the GTK theme) at all, i.e. resolve this as WONTFIX. 1. Apply GTK theme defaults and/or custom CSS to the composer body only in plain text mode, but not in rich text mode, so as to keep the existing neutral HTML defaults of black text on a white background when composing rich text messages. 2. Apply GTK theme defaults and/or custom CSS in both modes, and include that styling as CSS in outgoing messages so as to not break the WYSIWYG principle of the rich text editor. I'm leaning towards (1) since that would mean the result of composing a rich text message will be much closer to what recipients will see, better preserving WYSIWYG, and (2) would be difficult to implement, especially in the case of the pulling the GTK style out and applying it to the outgoing message, which may not be possible.
Bump tickets to 0.14 that aren't going to make 0.13.
One really nice reason to allow the composer to be themed is if you use Dark Themes for your apps. (and are attempting to have all dark apps to protect your eyes/are sensitive to white light) I have all aspects of geary dark now, after tweaking user-content.css, except for the composer, which is jarringly white whenever I open it. It would be really nice to be able to also make the composer dark (by tweaking with css) A comment above suggests this could be done by tweaking gtk.css, but I was unable to figure out how to do this. Cheers,
Nazgum, do you usually send plain text or rich text email? If the latter, what would you expect to be the case in Comment #11, above?
Well, perhaps I would suggest handling this the same as the Evolution email client to side-step the css debate. With Evolution, when you have a dark theme applied the plain text compose is also dark. By default the html/rich format is white, but they have an option in the Compose Preferences, "Inherit theme colors in HTML format", and if you enable this then the compose also goes dark for rich text emails. This is perfect, does not send this formatting as part of the message, allows dark themes to work, and makes the email client match the gtk theme much better. But if that option is not possible: I use gmail and imap, so usually rich text. I would assume per Comment#11 that geary would send rich text emails as html with no styling, as the styling would be applied by clients. As far as I can tell from geary's compose, all of the rich text buttons simply insert an html tag: <b> <i> <u> <s> <ul> <ol> <blockquote> <a> <img> So it seems there is no css styling added with any of these options, so user css added should not affect the composed message. For at least me personally, I want to make changes to the compose to make it match my gtk (ie dark mode everywhere); any changes I make I would expect to only be client-side and not sent with emails.
I agree with Nazgum. All three options in Comment #11 are wrong. I don't want my email styled by someone else. HTML markup is fine, but someone else shouldn't decide that my background should be white, so why would there by an expectation that I can do that to someone else? In fact, there is no expectation of WYSIWYG because we know the recipient can override styling. Its basic markup, not a perfect document. If I wanted the latter, I'd send a PDF! 0 Having the styling ignored for some UI elements and not others seems wrong. It's not a consistent UI. 1 Again, not a consistent UI 2 If I send CSS, will the other end apply it? Why would I want my viewing preferences to be asserted? I don't want other's CSS to be applied to emails I read! It's a waste of bandwidth to include outgoing CSS. Would I be packaging my commercial fonts and including them in the email as well? At some point, WYSIWYG doesn't apply!
Geary's composer background is white, regardless of theme, for the same reason OpenOffice's, Inkscape's and GIMP's is - because they are content editors, and content is not themable. This is really the only sane default. So I think that's a strong argument for option (1), to be honest. However despite that, as you guys point out, I should acknowledge that people do enjoying creatively breaking their apps via theming on Linux. :) So from that perspective, the option that I deliberately left out because it breaks WYSIWYG (i.e. apply theme/custom CSS in both modes, but don't send it), is probably the "right" thing to do here considering the user CSS hack exists in the first place. If people want to play with a foot-gun, they should be prepared to deal with the consequences. Will look at getting it into 3.32!
Landed on master by https://gitlab.gnome.org/GNOME/geary/merge_requests/151
Thanks Michael, that is awesome =)
Oh NB, per the comment in the merge request, I changed the name of the user CSS stylesheet from "user-message.css" to "user-style.css" since that's a bit more general. Both will be supported for a while, but I guess I should make Geary start warning people using the old name.