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