[07:45] <ochosi> morning everyone
[09:11] <ochosi> hey sergio-br2 
[09:14] <sergio-br2> hey
[09:15] <ochosi> how's it going?
[09:16] <sergio-br2> well, don't touch anything since that day
[09:16] <sergio-br2> one thing i realized using unity
[09:17] <sergio-br2> thumbnails in nautilus is active by default, and mimetype for text files such as .c, .cpp, .txt and .lua, they not appear
[09:18] <sergio-br2> in humanity theme, text-x-preview is a .icon file, not a png or svg
[09:20] <sergio-br2> so, you have a thumbnail showing a small fraction of your text. But using elementary, all them are blank.
[09:21] <ochosi> right
[09:21] <ochosi> i think i'd consider that a bug in nautilus rather than a feature
[09:21] <ochosi> don't think there's much we can do about that
[09:22] <ochosi> thumbnails are also activated by default in thunar, but not all thumbnailers are installed by defaut
[09:22] <ochosi> default
[09:22] <sergio-br2> only for pictures?
[09:22] <ochosi> i think there's a tumbler-extras package or something
[09:22] <ochosi> pics and pdfs mostly
[09:22] <ochosi> and movie files i think
[09:23] <ochosi> but there can always be pics or movies where the thumbnailing service fails for some reason to create a thumbnail
[09:25] <sergio-br2> hum, so in nautilus, if  text-x-preview is a png or svg icon, it should use the default mimetypes of text files, instead a thumbnail?
[09:27] <sergio-br2> it makes more sense
[09:29] <sergio-br2> hum, tumbler-plugin-extra you said ?
[09:35] <ochosi> yeah
[09:36] <ochosi> in thunar you have very fine-grain control over thumbnailing
[09:36] <ochosi> you can enable specific thumbnailers only for some directories etc
[09:41] <sergio-br2> i will see this in trusty, maybe nautilus got improvements in this
[09:41] <sergio-br2> see you later !
[09:51] <bluesabre> morning ochosi
[09:54] <ochosi> hey bluesabre 
[09:54] <ochosi> andrew has quite a few branches for the greeter in the pipe btw
[09:54] <ochosi> not only the one/s i referenced in the email today
[09:55] <ochosi> there's one for orca support (which would be great, i think)
[09:55] <bluesabre> saw all that, yeah, let's roll them into trunk
[09:56] <ochosi> as we've both been a bit slow processing his merge-requests i thought it's a good idea to motivate him to occasionally just push to trunk too
[09:56] <ochosi> especially when it's bugfix
[09:58] <bluesabre> yeah
[10:00] <bluesabre> I'll try to merge those in this morning/tonight
[10:00] <bluesabre> working on the debian merge atm
[10:01] <ochosi> for the 1.8.5 release?
[10:02] <bluesabre> yes
[10:05] <ochosi> cool
[10:16] <ochosi> bluesabre: btw, i'm really curious how the whole gtk3-only transition and using only a single window for the greeter will mess with all the positioning code
[10:16] <bluesabre> it will greatly simplify it
[10:16] <ochosi> yeah, and i guess there won't be such a big need for checking whether the window is offscreen
[10:16] <bluesabre> GtkOverlay lets you easily specify where the overlay items will be placed
[10:16] <ochosi> cause it'll be inside a window
[10:16] <bluesabre> yup
[10:17] <ochosi> just checked another item on the todo-list for xfpm today
[10:17] <ochosi> mostly one thing left to do, then we'll do a huge merge/push to the git repo
[10:17] <ochosi> and then a dev release
[10:18] <ochosi> really looking forward to that
[10:29] <ochosi> bluesabre: maybe we could look at the lid-close stuff again together soonis
[10:30] <ochosi> h
[10:30] <ochosi> i think the patch by eric needs to be tweaked/extended a little
[10:30] <bluesabre> ok, I'll probably be free this evening
[10:35] <ochosi> cool, can't promise yet but i'll try
[11:46] <knome> what do people generally think about the timespan for voting on the mailing list?
[11:47] <ochosi> i'm currently considering a 1-week period for votes like the one we're holding about the MÃL
[11:48] <knome> MÃL ?
[11:48] <ochosi> yeah, Mï¿½L
[11:48] <ochosi> that's a common shorthand for mailinglist in german ;D
[11:48] <knome> aha ;)
[11:48] <knome> i thought a with ~ was more connected to spanish ;)
[11:49] <knome> anyway, another idea is...
[11:49] <knome> we could *begin* the voting on the ML, then finish it off in a meeting
[11:49] <knome> currently people voted on the meeting, *then* we got the arguments on the ML
[11:50] <knome> so in a way, the votes on the meeting might not have been as informed as votes after the arguments
[11:50] <slickymasterWork> I agree with knome 
[11:50] <slickymasterWork> or else will be dragging the vote
[11:50] <knome> i guess we all agree there has to be some deadline
[11:50] <ochosi> slickymasterWork: well the dragging is only a problem if there is no fixed maximum period
[11:50] <ochosi> yeah
[11:51] <slickymasterWork> but is that maximum period fixed?
[11:51] <knome> i don't see why it wouldn't be
[11:51] <ochosi> knome: in this current vote, we *did* have a discussion on the ML first
[11:51] <knome> ochosi, sure, but some of the arguments weren't posted before the voting :)
[11:52] <slickymasterWork> just asking because I don't remember when it was fixed
[11:52] <knome> which i guess can be pinpointed to be another problem
[11:52] <knome> slickymasterWork, it wasn't... there is no deadline for this vote
[11:52] <slickymasterWork> hence my question
[11:53] <slickymasterWork> but I do agree with your reasoning knome 
[11:53] <ochosi> knome: i can also point arguments on the ML after this vote is finished... that can always happen
[11:53] <ochosi> i think that the order in which we executed this vote was fine
[11:54] <ochosi> first put the proposal on the mailinglist
[11:54] <ochosi> then discuss in the meeting, then vote
[11:54] <knome> ochosi, absolutely... what i'm saying is it would benefit the voters (and ultimately, the project) most if arguments were made in advance
[11:54] <ochosi> yeah, there's no arguing with that :)
[11:54] <knome> we could have had more time between the proposal and voting
[11:55] <ochosi> pleia2: ^ did you read that ;D
[11:55] <knome> otoh...
[11:55] <knome> we really should just decide/vote
[11:55] <knome> to not drag along
[11:55] <ochosi> yeah, discussions are fine, but i wanna get things done too
[11:55] <knome> hardly any decisions are irreversible
[11:56] <ochosi> yeah, and the proposal even contained a sort of "natural deadline" to the "lockdown"
[11:57] <knome> and finally, those who do, decide... so if somebody is away for more than a week or two (from the original proposal to voting ending), it's fair to not count their vote
[12:00] <knome> anyway, i'm off to buy some food
[12:00] <knome> bbl
[14:55] <elfy> the other question re this vote on m/l is - what happens if not enough people vote to get quorum?
[14:56] <elfy> I think that a week - given that it was on the agenda for at least as long as the discussion first started
[14:57] <elfy> however, perhaps there is some virtue in - discuss on m/l vote on m/l in the week leading up to the next irc meeting - final vote in the irc meet - then everyone knows exactly when the vote will end
[15:06] <ochosi> hey elfy 
[15:07] <ochosi> yeah, i'm not sure though that this (slightly complicated) process, even though it might bear some virtue, is very feasible in practice
[15:07] <ochosi> imo we can keep voting as we did, try to announce votes (that aren't adhoc) previously on the ML
[15:08] <ochosi> and then if we don't have a quorum extend the voting for a week to the ML
[15:10] <elfy> I'm just throwing out thoughts - though I think the only complicated thing is knowing that we might want to vote on something :)
[15:11] <elfy> anyway - I'm pretty easy about it 
[15:17] <ochosi> yup, same here :)
[18:59] <brainwash> ochosi: bug 1318307
[18:59] <brainwash> any idea?
[19:00] <brainwash> it can be only cause by xfdesktop, because it's the only Xfce app which has been patched to support accountsservice
[19:00] <brainwash> caused
[19:05] <ali1234> correct
[19:05] <ali1234> xfdesktop now has per-workspace wallpapers
[19:05] <ali1234> accounts service does not
[19:05] <ali1234> so each time you switch workspace, it writes the new wallpaper to accounts service
[19:06] <ali1234> this is just a guess
[19:06] <brainwash> yes, I think this is what's going on
[19:07] <brainwash> we... uhm, ochosi needs to adjust the patch then :)
[19:11] <brainwash> but it should work properly
[19:11] <brainwash> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/xfdesktop4/trusty/view/head:/debian/patches/xubuntu_set-accountsservice-user-bg.patch
[19:15] <brainwash> Gtk-Message: Failed to load module "overlay-scrollbar"
[19:15] <brainwash> Gtk-Message: Failed to load module "unity-gtk-module"
[19:15] <brainwash> ali1234: any idea? ^
[19:15] <ali1234> about what?
[19:16] <brainwash> why something tries to load these gtk modules and fails?
[19:16] <ali1234> bug 1307657
[19:16] <brainwash> woot
[19:16] <brainwash> still not fixed
[19:16] <ali1234> patch available though
[19:17] <ali1234> poke tedg if it you have a specific problem caused by this... at the moment it is relatively harmless on a default setup
[19:17] <ali1234> (and attente)
[19:18] <brainwash> I thought that people which use xubuntu + unity have this problem
[19:18] <ali1234> yes, but that isn't a default setup
[19:19] <ali1234> and they're not al unity's fault either, eg fork() after gtk_init()
[19:19] <brainwash> but this cannot be a reason to not upload the patched version
[19:19] <ali1234> the patch hasn't even been merged upstream yet
[19:21] <brainwash> once a final release is out everything is going in slowmotion
[19:22] <ali1234> start chasing people then :)
[19:23] <brainwash> I already left the ubuntu channels :P
[19:39] <ali1234> the thunar crash should be fixed soonish... the fix is in saucy-proposed now