> First check this one here: > https://bugzilla.gnome.org/show_bug.cgi?id=48455 > > It's about improving terminology in sawfish-ui, something we should > think about in my eyes.
I've been using sawfish for at least 6-7 years and still never knew what "matched windows" are :) Since I never bothered to look it up I just assumed it's something I don't need to know about and this approach worked pretty well :) But I agree, this terminology could be improved along the lines of the OP in the bug report. > Next: > https://bugzilla.gnome.org/show_bug.cgi?id=48460 > > It's about a "generic interface to change the titlebar font color", > currently that's not possible, only if the theme has an option like > that, but I guess it would require (partial)rewrite of all themes. > > For this also making all themes "active theming"/"custom stuff in > titlebar" compatible could be considered. This is an overkill I think, I mean to rewrite all themes to be title-text-color-aware. There are tons more themes out there, ones that are not shipped with sawfish, and so the "problem" would only be delayed not "solved". I use quotation marks because I think there is not really an issue here. I suppose not many people want to change the title-text-color anyway, most people are happy with picking a theme. If the theme provides this level of customization, users can find it in the tab of the theme. I'd leave the situation as it is currently. If you nevertheless want to have a theme-independent place to set the title bar text color then one solution would be to only make this option available outside of the theme Tab when the theme supports it. When the theme doesn't support it, hide this option. But then sawfish-ui needs to know if the theme supports this customization or not, which can be complicated. On top of the color, there are millions of other generic options which one might expect to find in a theme-independent place, but only some themes support it. Why would you stop with the title color only? This would then lead to a horribly complicated sawfish-ui, when it has to find out from a given theme whether it supports feature X, Y, Z, ................... And then the user would need to click through all features, only to find that only some of them are available anyway. I'd say it's more user friendly to collect theme-specific options (options which are not necessarily supported by all themes and by all I mean all, not only sawfish-shipped) under the theme's tab, just the way it is currently. Think about the mx-flat theme, which is my personal favorite. It has tons of options, expecting all themes to support all of them is crazy. So no matter how smart sawfish-ui is in introspecting themes, lots of options will be left to the theme's tab anyway. Cheers, Daniel > "all themes" means all themes shipped with sawfish, here. > > At least 9 Reports from BGO I've marked as Milestone 3.0.x: > https://bugzilla.gnome.org/buglist.cgi?product=Sawfish&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=3.0.x > > Chris > -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
