[12:11] <slickymasterWork> LP 1731905
[12:11] <slickymasterWork> ochosi, flocculant, bluesabre ^^^
[16:41] <ochosi> slickymasterWork: noted. will have to try to set up a 32bit system so i can debug that properly i guess
[16:42] <slickymasterWork> :)
[16:42] <slickymasterWork> I'll set up a 32-bit system tomorrow and will report back
[17:05] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-notifyd 0.4.1 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-notifyd-0-4-1-released-tp50263.html (by Simon Steinbeiss)
[21:20] <ochosi> bluesabre: lol, gtk-theme-config still has references to the unico engine
[21:21] <ochosi> bluesabre: did we maintain it here or elsewhere? https://github.com/satya164/gtk-theme-config
[21:22] <ochosi> oh, it's here ofc https://code.launchpad.net/~gtk-theme-config-maintainers/gtk-theme-config/trunk
[21:27] <ochosi> now that LP supports git i would really prefer to use it there too...
[21:38] <ochosi> holy crap, that gtk-theme-config code is so bad...
[21:38] <ochosi> i really don't know how to touch it "efficiently" (i.e. without rewriting it)
[21:43] <ochosi> i mean seriously: 130 lines long string variables...
[22:38] <bluesabre> ochosi: yup!
[22:38] <ochosi> the main problem that i see with gtk-theme-config is that it's really unmaintainable in its current state
[22:38] <ochosi> how is one supposed to edit the css there
[22:38] <ochosi> that's simply terrifying
[22:39] <ochosi> plus instead of toggling a single gtk.css file with "include" lines for panel, menu etc it always writes the whole file when updating..?
[22:39] <ochosi> oh dear...
[22:39] <ochosi> maybe we should rewrite it in python
[22:39] <bluesabre> Some parts of the css support might not have been fully supported by gtk3 when satya first made it
[22:39] <ochosi> would be easier to maintain, and would make interaction with the text files easier
[22:40] <ochosi> yeah definitely
[22:40] <ochosi> i mean what we need is a current version of greybird/adwaita as starting point
[22:40] <ochosi> ideally we'd keep the sass in the repo and then just compile it for each release
[22:40] <bluesabre> Sounds sane
[22:40] <ochosi> so that there is no dependency for ppl who install it
[22:40] <ochosi> but so that the code is maintainable
[22:41] <bluesabre> brb
[23:09] <ochosi> bluesabre: ok, i think i at least have a concept of how to continue, we probably should discuss whether to stick to vala or whether to rewrite in python...
[23:16] <bluesabre> ochosi: would probably be pretty easy to rewrite in python
[23:16] <bluesabre> the vala code is not the worse thing
[23:16] <bluesabre> but it is a pain to tweak
[23:17] <knome> theoretically python might be something i might help maintain
[23:17] <knome> i've been doing some python ;P
[23:17] <ochosi> it's possible that we will have to step away from the "highlight color" feature
[23:17] <ochosi> not sure it can still work
[23:17] <knome> huhu?
[23:17] <ochosi> with gtk3
[23:17] <knome> eg. the only one that is useful?
[23:18] <ochosi> it will only work with themes that have been "fixed" to work it with
[23:18] <ochosi> all themes that are sass/scss based have all the color values hardcoded in the compiled css
[23:19] <ochosi> before there were global symbolic color names
[23:19] <knome> mm, true
[23:19] <ochosi> and gtk-theme-config was using that to swap them out
[23:19] <knome> :(
[23:19] <ochosi> now you would basically have to regenerate the theme, just with different color values
[23:19] <knome> yes
[23:19] <ochosi> we could do a greybird-theme-config
[23:19] <knome> meh
[23:19] <ochosi> or an adwaita-theme-config
[23:19] <knome> i mean, yay...
[23:19] <ochosi> but nothing that will generically work
[23:20] <knome> could it be pluggable to gtk-theme-config, eg. just appear there if the theme you use supports it?
[23:20] <ochosi> not sure if we can easily find out if the theme (still) supports these color values
[23:21] <ochosi> in gtk2-land the highlight color will continue to work
[23:21] <ochosi> but that doesn't really help us much
[23:21] <knome> yeah but it's gtk2
[23:21] <knome> yes
[23:22] <ochosi> so if we don't care about the panel (because its bg color can be set from the prefs dialog) and the menus i would say we should drop gtk-theme-config
[23:22] <knome> the menus... meh
[23:22] <ochosi> unless we find another way (that i currently can't think of) to change the highlight color
[23:22] <knome> i mean it's fine to be able to edit the colors i guess
[23:22] <knome> highlight color is the thing i want gtk-theme-config for
[23:23] <knome> it's the only thing i have enabled
[23:24] <ochosi> but it doesn't work anymore for greybird in gtk3 for you, does it?
[23:24] <knome> i have noooo idea
[23:24] <ochosi> what is possible is this:
[23:24] <knome> you are correct
[23:24] <knome> it does not work for gtk3
[23:25] <ochosi> take adwaita's scss, chop it down to every :selected selector and then add a "background-color: blah;" line to each of those as skeleton
[23:25] <ochosi> that would still make for one homungous file, but it would probably work
[23:25] <knome> heh
[23:25] <ochosi> but it really means: overriding every widget in the theme
[23:25] <knome> yep
[23:26] <ochosi> not sure what that does to performance or if gtk doesn't care if you overload your theme with a second theme
[23:26] <knome> mmeh
[23:26] <knome> yeah
[23:26] <knome> try it?
[23:27] <ochosi> it's not like chopping up the original scss is not a lot of (potentially useless) work
[23:27] <knome> yeah i know...
[23:27] <knome> i mean
[23:27] <ochosi> i think i'd rather focus on more important things, like pushing out a long-needed xfpm release
[23:27] <knome> by trying it, i mean we could probably try doing "another css file" that is essentially the same as the first one
[23:28] <knome> and it should affect performance (close to) as much as if it changed everything, right?
[23:28] <knome> *if* it has any noticeable performance hit
[23:28] <bluesabre> Shouldn't have a performance hit
[23:28] <knome> re: greybird-theme-config, that should just be a script that builds greybird from sass and creates a new theme with a new color
[23:29] <knome> eg. greybird-red-like-rudolphs-nose
[23:29] <knome> then you could switch to that
[23:29] <knome> and you could have X variants all at the same time
[23:29] <knome> i might or might not have my own benefits in mind when i say that
[23:29] <knome> ...but that's how it should be :P
[23:29] <ochosi> if you want to build greybird you need to have all those ruby depends installed
[23:29] <ochosi> so meh
[23:29] <knome> who cares?
[23:29] <knome> :P
[23:30] <knome> isn't it more flexible that way anyway?
[23:31] <knome> or is greybird using highlight colors as is, eg. 0% transparency and no variations?
[23:31] <ochosi> i think it would work
[23:31] <ochosi> but it would only work for greybird
[23:31] <knome> yes, i understand
[23:32] <ochosi> anyway, i dunno
[23:32] <knome> yeah
[23:33] <ochosi> bluesabre: what's your take? should we really try to do the "strip down adwaita to certain selectors" approach or just drop gtk-theme-config for 18.04?
[23:33] <knome> we've kind of been drumming for it
[23:33] <knome> so it would be a shame to just drop it from that POV
[23:34] <ochosi> we've been drumming a long time ago
[23:34] <bluesabre> ochosi: I think if we can create an adwaita-compatible version of it, it supports our minimum needs
[23:34] <knome> ochosi, i understand, but people do not like to lose things they've been once given
[23:35] <ochosi> then they need to get involved and fix things :)
[23:35] <knome> i'm not defending "them" :)
[23:35] <bluesabre> if we wanted to have some fun, we could make a greybird theme customizer on shimmer.o :)
[23:36] <ochosi> humm, tbh i already see issues with the approach i mentioned
[23:36] <knome> .o?
[23:36] <ochosi> a lot of places contain variants of the selected_bg_color
[23:36] <bluesabre> https://shimmerproject.org/
[23:36] <knome> lol
[23:36] <bluesabre> You might have seen that site before
[23:36] <knome> like use all of the resources xfce is begging for running some sp.org errands?
[23:37] <bluesabre> :D
[23:37] <knome> just write a python script that depends on greybird build deps
[23:37] <ochosi> so the theme will look very flat after having gtk-theme-config's color applied
[23:37] <knome> and get on with it ;)
[23:37] <knome> ochosi, yeah, that's what i thought
[23:37] <ochosi> and in that sense it will be an ugly solution
[23:37] <ochosi> or alternatively we take the shades of adwaita
[23:38] <ochosi> but then it may suck with other themes (especially dark ones)
[23:38] <bluesabre> We can also use Adwaita's dark base theme
[23:39] <knome> how would the config app know if the user is using a dark theme or not?
[23:39] <knome> another knobby knob?
[23:39] <bluesabre> yeah
[23:39] <knome> meh :)
[23:40] <bluesabre> or detect fg color
[23:40] <ochosi> argh
[23:40] <ochosi> that is bound to fail
[23:40] <knome> yeah, argh
[23:40] <ochosi> a switch is definitely better
[23:40] <bluesabre> argv
[23:40] <ochosi> but anyway, i think it'll be a lot of work
[23:40] <knome> sure
[23:40] <ochosi> and it's rather low on my personal priority list
[23:41] <ochosi> anyway, sleepytime
[23:41] <bluesabre> Could start making a list of things new contributors want to mess with
[23:41] <knome> just do it with greybird
[23:41] <bluesabre> Somewhere that is easy to find
[23:41] <ochosi> knome: that'll be just as much work. then i'd rather do it with adwaita. you can do it too btw, all we need is the chopped down css file
[23:42] <knome> yeah...
[23:42] <knome> i'll consider
[23:42] <ochosi> anyone who knows what a :selected selector is can do it
[23:42] <ochosi> ideally you chop down the scss file
[23:42] <ochosi> it'll be less work than the css
[23:42] <ochosi> and more maintainable
[23:42] <knome> yep
[23:42] <ochosi> anyway, nighty!
[23:42] <knome> night :)
[23:43] <bluesabre> happy to help with that once we've got a base s(css) file to play with
[23:43] <bluesabre> nighty ochosi
[23:49] <bluesabre> knome: when do we want to kick off the contest?
[23:50] <knome> i'm in the process of moving the code of the current plugin into a slightly different format
[23:50] <knome> eg. submissions happen from the frontend
[23:50] <knome> i'd still probably make people log in
[23:50] <knome> i'm also making sure we can have multiple contests at a time
[23:51] <knome> which we couldn't do previously
[23:51] <knome> fwiw, that part is taken care of already
[23:51] <bluesabre> knome: very nice
[23:51] <knome> so i'd say january first
[23:51] <knome> or sth :P
[23:51] <bluesabre> Sounds good to me
[23:51] <bluesabre> Nice way to start the year
[23:51] <knome> i'll need a few more sessions of coding to get it finished
[23:51] <knome> basically everything is ready except voting
[23:51] <bluesabre> Maybe with an announcement towards the end of the year
[23:52] <knome> but since it'll use very much the same code, it's mostly a copy-paste job
[23:52] <knome> then some quick testing
[23:53] <bluesabre> :)