slickymasterWork | LP 1731905 | 12:11 |
---|---|---|
ubottu | 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 |
slickymasterWork | ochosi, flocculant, bluesabre ^^^ | 12:11 |
ochosi | slickymasterWork: noted. will have to try to set up a 32bit system so i can debug that properly i guess | 16:41 |
slickymasterWork | :) | 16:42 |
slickymasterWork | I'll set up a 32-bit system tomorrow and will report back | 16:42 |
-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) | 17:05 | |
=== slickyma1ter is now known as slickymaster | ||
=== vinzv_away is now known as vinzv | ||
ochosi | bluesabre: lol, gtk-theme-config still has references to the unico engine | 21:20 |
ochosi | bluesabre: did we maintain it here or elsewhere? https://github.com/satya164/gtk-theme-config | 21:21 |
ochosi | oh, it's here ofc https://code.launchpad.net/~gtk-theme-config-maintainers/gtk-theme-config/trunk | 21:22 |
ochosi | now that LP supports git i would really prefer to use it there too... | 21:27 |
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:38 |
ochosi | i mean seriously: 130 lines long string variables... | 21:43 |
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:38 |
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:39 |
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:40 |
bluesabre | brb | 22:41 |
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:09 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
knome | it's the only thing i have enabled | 23:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
knome | isn't it more flexible that way anyway? | 23:30 |
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:31 |
ochosi | anyway, i dunno | 23:32 |
knome | yeah | 23:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
bluesabre | happy to help with that once we've got a base s(css) file to play with | 23:43 |
bluesabre | nighty ochosi | 23:43 |
bluesabre | knome: when do we want to kick off the contest? | 23:49 |
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:50 |
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:51 |
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:52 |
bluesabre | :) | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!