[00:19] <ali1234> ochosi: new version with filtering when zoom is less than 4x, and some other improvements: http://paste.ubuntu.com/6402669/
[00:23] <ochosi> ali1234: wow!
[00:23] <ochosi> very smooth
[00:23] <ochosi> (and thanks for inverting the scroll-direction - feels *so* much better ;))
[00:25] <ochosi> being zoomed in does seem to eat up my cpu though (at least that's what top says)
[00:25] <ali1234> yes it will
[00:25] <ochosi> is that due to the smoothing?
[00:25] <ochosi> (didn't check that before)
[00:25] <ali1234> no, it's due to it has to poll mouse position
[00:25] <ochosi> ah
[00:25] <ochosi> hm
[00:25] <ochosi> i guess there's not really a way around this
[00:25] <ali1234> currently it is hardcoded to check it 60 times per second
[00:26] <ali1234> probably a bit much
[00:26] <ali1234> it's the g_timeout_add(32 ... line
[00:27] <ali1234> 32 msec
[00:27] <ali1234> i could make it check if the mouse coords are the same as last time and if so ignore them
[00:28] <ochosi> to be frank, even with 10 it seems extremely smooth
[00:29] <ochosi> heh, although i'm seeing now that that doesn't seem to help with the cpu
[00:30] <andrzejr> ali1234, I tried your patch - got a black screen with only a cursor on it. NVidia drivers.
[00:30] <ochosi> so yeah, maybe that check would help
[00:31] <ochosi> andrzejr: i'm also using nvidia proprietary btw
[00:31] <ali1234> i'm on nvidia too
[00:31] <ochosi> oh, fun :p
[00:31] <ali1234> andrzejr: is that only when zooming, or all the time?
[00:32] <andrzejr> just after xfwm4 --replace
[00:32] <ochosi> (fwiw, i'm not using git-master, but the ochosi/tabwin branch)
[00:32] <andrzejr> couldn't debug anything because linux console doesn't work with proprietary drivers
[00:34] <ali1234> er.... mine does?
[00:35] <ochosi> andrzejr: you mean VT? works fine here...
[00:35] <andrzejr> so maybe its a graphics card, or several ubuntu updates (I do get some other problems too)
[00:36] <ali1234> try commenting lines 3009, 3011, 3013
[00:36] <ali1234> if you comment them all, the whole thing should become a no-op
[00:36] <andrzejr> When I switch to a console the screen becomes grayish and gets progressively brighter/lighter.
[00:37] <ochosi> so xfwm4 works without the patch?
[00:38] <ali1234> did you build with --enable-compositor?
[00:38] <andrzejr> xfwm4 from git master works fine
[00:38] <ali1234> i haven't tested what happens if you don't do that, probably should
[00:39] <ochosi> ali1234: i put the value down to "3" now, still is smooth and cpu is still burning up...
[00:39] <andrzejr> no, I didn't (autoconf did enable it though so I assumed it is OK)
[00:39] <ochosi> ali1234: are you sure it's that which causes it?
[00:39] <ali1234> ochosi: you should increase it, not decrease it :P
[00:39] <ochosi> yeah, i also skipped the --enable-compositor, it should be enabled by default
[00:39] <ochosi> ooophs
[00:39] <ochosi> :)
[00:40] <ali1234> hang on though, new patch
[00:40] <ali1234> http://paste.ubuntu.com/6402727/
[00:41] <ochosi> building...
[00:42] <ochosi> ali1234: a bit less cpu usage, still 100% (as in: 1 of 2 cores) though
[00:44] <ali1234> my check doesn't work
[00:44] <ochosi> hm, seemingly
[00:45] <ali1234> maybe you can't use a static variable in a callback
[00:45] <ali1234> or maybe it's just a silly mistake
[00:45] <ali1234> the latter
[00:45] <ali1234> y_old != x_root -> should be y_root
[00:46] <ochosi> well it's that time of the day here already (silly-mistakes-o'clock)
[00:46] <ali1234> much better :)
[00:48] <ochosi> went down to 75% here
[00:49] <ali1234> for me it went down to a negligible amount when not moving the mouse
[00:50] <ochosi> yeah, this time it was my time for a silly mistake
[00:50]  * ochosi facepalms
[00:50] <ochosi> no more cpu-eating
[00:50] <ochosi> very nice
[00:50] <ali1234> in theory it should now have true zero overhead if there's no change in the zoom state
[00:51] <ochosi> yeah, that's also what top says
[00:51] <ochosi> (i decided to zoom in on a top-window)
[00:51] <ali1234> well, except the QueryPointer call but that's not much
[00:53] <ochosi> nice work ali1234 !
[00:53] <andrzejr> same problem with the new patch
[00:58] <ali1234> andrzejr: i didn't really think the new patch would help you, sorry
[00:59] <ali1234> try commenting lines 3009, 3011, 3013
[00:59] <ochosi> ali1234: zooming in on parole has funny effects :)
[01:00] <ali1234> hmm... it does
[01:01] <ali1234> the overlay window doesn't increase in size, so only part of the video shows
[01:02] <ali1234> that's due to the lazy updates
[01:02] <ali1234> or rather, forcing a full redraw fixes it
[01:03] <ali1234> not sure how to deal with that but there must be a way
[01:05] <ali1234> xterms do the same thing :S
[01:06] <ali1234> and youtube
[01:25] <ali1234> hmm... i think i know how to fix it. but i'm going to bed now... night
[01:36] <ochosi> ali1234: night!
[01:36]  * ochosi goes too
[09:56] <ali1234> morning
[09:57] <ali1234> i found a bug in xfwm which fixing it should have fixed the clipping area issues
[09:57] <ali1234> but it didn't :(
[09:59] <slickymaster> good morning all
[10:04] <ochosi> ali1234: what clipping area issues?
[10:04] <ochosi> and morning everyone
[10:04] <ali1234> well... you know blitting?
[10:04] <ali1234> dirty rectangles and so on?
[10:05] <ali1234> the compositor redraws only the damaged areas in the offscreen buffer
[10:05] <ali1234> then it copies only the damaged areas from the buffer to the display
[10:05] <ali1234> but the XserverRegions aren't affected by the PictureTransform, so the second copy copies the wrong areas
[10:06] <ochosi> oh
[10:06] <ali1234> there's two problems: first is it applies the region to the display instead of the buffer, which is a bug imo
[10:06] <ali1234> and the second is that it can't apply it to the buffer either on the second draw step, if we are zoomed in
[10:06] <ali1234> so... it's fixed, kind of
[10:07] <ochosi> not sure i was able to follow this all now
[10:08] <ali1234> heh
[10:08] <ali1234> basically XRender is a very 2D type system and it uses all the old style "redraw only the parts that changed" methods from framebuffer days
[10:08] <ali1234> but the damage system and XRender don't really talk to each other
[10:10] <ali1234> after fixing what i consider to be a bug, it might actually run faster anyway now
[10:11] <ochosi> is this specifically a zoom-problem or does it affect xfwm4 in general?
[10:12] <ochosi> (fwiw i'm startin to think you should become xfwm4's maintainer, no-one has really taken care of it for ages...)
[10:12] <ali1234> i'm not 100% sure
[10:12] <ali1234> depends exactly how Xrender treats the clip regions
[10:12] <ali1234> which annoyingly is probably implementation specific
[10:13] <ali1234> i am beginning to see why wayland
[10:13] <ali1234> i think it's a bug, could be intentional though i think
[10:14] <ali1234> anyway the bottom line is that we have to turn off all clipping when doing the buffer->display copy, but only if zoomed in
[10:14] <ali1234> because the clipping rects don't follow the Xrender transform, thus the wrong areas are clipped
[10:15] <ali1234> i'm going to push this on github because i can write comments on the source there :)
[10:17] <ochosi> cool
[10:30] <ali1234> https://github.com/ali1234/xfwm4/commits/zoom
[10:33] <ochosi> you should also post that on the xfce-dev-ml
[10:33] <ochosi> or at least the irc channel
[10:33] <ochosi> if it gets merged, it's probably one of the most exciting features for 4.12
[10:40] <ochosi> ali1234: fwiw, if you wanna help me finish the ochosi/tabwin branch lemme know ;)
[10:40] <ali1234> what does it do?
[10:42] <ochosi> it improves the style of the tabwin (alt-tab dialog)
[10:42] <ochosi> makes it themeable
[10:42] <ochosi> and in the end it should enable using the mouse to select a window
[10:43] <ochosi> nick pushed a commit for that, but it wasn't finished yet
[10:43] <ochosi> so it's not 100% working
[10:43] <ochosi> (i think the first click somehow doesn
[10:43] <ochosi> 't reach the widget or something)
[11:03] <ochosi> ali1234: this is the page where i listed some stuff i wanted to do: http://wiki.xfce.org/design/xfwm4/tabwin
[11:04] <ochosi> (only the screenshot is really implemented, although i think nick added a text-only listmode once too)
[11:31] <ali1234> i don't use alt-tab at all
[11:31] <ali1234> is there some specific bug or problem?
[11:32] <ochosi> problem 1) is that it uses weird widgets
[11:33] <ochosi> problem 2) (following from 1) is that the theming of it is therefore not very nice
[11:33] <ochosi> so no, it's an enhancement, not bugfix
[11:41] <ochosi> pleia2: ping
[13:11] <pleia2> ochosi: pong
[13:24] <knome> pleia2, have fun trying to pop in the same time :)
[13:24] <knome> pleia2, he wants to ask you about licenses for wallpapers
[13:25] <knome> (at least)
[13:25] <pleia2> ah
[13:29] <ochosi> hey pleia2 
[13:29] <ochosi> yeah, what knome said :)
[13:29] <pleia2> cc-by is nice
[13:29] <ochosi> i started drafting an email to the ML for wallpaper submissions for xubuntu
[13:29] <ochosi> so far i had put down cc-by and cc-by-sa
[13:29] <pleia2> or cc-by-sa
[13:29] <ochosi> but one license would/could make things easier
[13:29] <ochosi> not sure
[13:30] <ochosi> what do you think/suggest?
[13:30] <pleia2> consistancy would be nice
[13:30] <ochosi> (we could end up with a package with multiple licenses, not sure how problematic that really is though)
[13:30] <ochosi> yeah, i agree
[13:30] <pleia2> let's see what ubuntu dose
[13:30] <pleia2> does
[13:30] <ochosi> good idea
[13:31] <pleia2> they use cc-by-sa
[13:31] <pleia2> works for me :)
[13:32] <pleia2> https://wiki.ubuntu.com/Artwork/Documentation/Backgrounds#Constraints
[13:34] <ochosi> pleia2: great, let's stick to that then
[13:34] <ochosi> i'll check more of those requirements and integrate them in my call for wallpapers
[13:34] <ochosi> would you wanna read it before i send it out?
[13:35] <pleia2> ochosi: sure, if you'd like
[13:35] <ochosi> knome: check the page pleia2 just pasted, i think some of those guidelines we should also include (see background guidelines)
[13:35] <knome> ochosi, yup, agree
[13:36] <ochosi> acutally most of this document makes a lot of sense
[13:36] <ochosi> thanks for digging that up pleia2 !
[13:36] <pleia2> they've refined it over many cycles
[13:37] <ochosi> yeah, they've done a few of these contests
[13:37] <ochosi> and basically we're planning the same
[13:37] <pleia2> cool
[13:37] <ochosi> open submissions but a vote of the artwork-team on the "winners"
[13:37] <ochosi> kinda an editor's pick
[13:37]  * pleia2 nods
[14:19] <pleia2> I am going to try to sleep again
[14:46] <ochosi> knome: think i might end up copying over the complete page from the ubuntu wiki, they really thought it through...
[15:08] <knome> hm?
[16:52] <slickymaster> elfy, ping
[17:00] <elfy> slickymaster: pong if it's quick, if not then it'll need to wait - just got in
[17:01] <slickymaster> elfy: if you prefer I can ping you later on, after dinner
[17:02] <elfy> nope - it's ok I expect - ask and if I'm not I'll say :)
[17:02] <slickymaster> elfy, I think a correction needs to be made at http://packages.qa.ubuntu.com/qatracker/milestones/306/builds/55995/testcases/1585/results
[17:03] <slickymaster> elfy: one of the steps to be reproduced during the test is "...In dialogue type gksudo mousepad, press Launch"
[17:03] <slickymaster> elfy: gksudo and gksu, aren't presently packed with Xubuntu 
[17:04] <elfy> slickymaster: https://bugs.launchpad.net/ubuntu-manual-tests/+filebug
[17:04] <slickymaster> elfy: either we remove/re-write that step or we have to add a note informing on the of sudo apt-get install gksu
[17:04] <elfy> do it there - probably make it a 'general' thing rather than specific
[17:05] <elfy> slickymaster: from what I can tell they're wanting people to use sudo 
[17:05] <slickymaster> elfy: that's what I meant to ask you. I can fil a bug and re-write the entire testcas
[17:05] <slickymaster> testcase^^
[17:06] <elfy> slickymaster: make it general rather than for one testcase - when we know exactly what we're supposed to use then we can check them all for the same issue
[17:06] <elfy> I'll try and get a real answer later
[17:07] <slickymaster> elfy: I'll just fil the bug for the moment and wait until you have something more specific on the issue
[17:07] <elfy> ok 
[17:07] <elfy> slickymaster: I will probably work through and do the whole lot myself 
[17:08] <slickymaster> elfy: well, if you feel like you need any help, just ping me
[17:08] <elfy> slickymaster: can you subscribe or assign me to it 
[17:08] <elfy> slickymaster: yep - I will :)
[17:08] <slickymaster> elfy: I will
[17:09] <elfy> cheers
[17:09] <slickymaster> elfy: thanks
[17:09] <elfy> :)
[17:25] <slickymaster> elfy: here it is https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1250560
[17:27] <slickymaster> elfy: surprisingly I'm not able to assign it to you, LP is not recognizing your LP ID in the Assigned to box. I keep getting "No items matched "elfy"."
[17:27] <elfy> not sure why that is - I just assigned it to elfy
[17:28] <elfy> comes up as first choice when I search for me
[17:31]  * elfy passes the question along the chain :p
[17:31] <slickymaster> elfy: it's strange, really, because I'm still getting the same No items matched "elfy".
[17:31] <elfy> odd - you putting it in the box then pressing enter?
[17:31] <slickymaster> elfy: well, any way it's done as we intended 
[17:32] <slickymaster> elfy: yes, and alternatively clicking the magnifying glass 
[17:32] <elfy> odd - but it is launchpad :)
[17:33] <slickymaster> elfy: I even went to https://launchpad.net/~elfy to confirm your LP ID
[17:36] <slickymaster> knome: Just FYI https://translations.launchpad.net/xubuntu-docs/trusty/+pots/desktop-guide/pt/+translate is as of now completely translated into Portuguese
[17:36] <elfy> slickymaster: though it seems that pkexec isn't supposed to be used like that
[17:37] <slickymaster> I'll try now to figure out how to build the translated package in order to do a final proofread of it
[17:38] <slickymaster> elfy: I'm under the impression that pkexec is supposed to be the intended replacement for gksudo and gksu, but I can be wrong
[17:38] <brainwash> slickymaster: maybe you should also file a report on the debian bug tracker, bug 1250364
[17:38] <elfy> slickymaster: http://askubuntu.com/questions/313828/why-is-pkexec-preferred-over-gksudo-for-graphical-applications
[17:38] <elfy> slickymaster: doesn't appear so 
[17:39] <slickymaster> right, brainwash. Will do it
[17:39] <slickymaster> elfy: give a moment to read through that
[17:39] <slickymaster> give me ^^
[17:41] <brainwash> slickymaster: I tried to understand and fix this crash, but gave up due to lack of time (users-admin is quite complicated for me and I don't feel like breaking it)
[17:43] <brainwash> there are other issue too, like it still checks for the "admin" group instead of "sudo" one
[17:43] <slickymaster> elfy: well, now I'm confused and you are indeed right. That leaves me with the question about with the hell has gksu and gksudo been removed. Is it to just use sudo -i?
[17:43] <brainwash> so gnome-system-tools really needs a maintainer or a working replacement
[17:44] <elfy> slickymaster: seems so 
[17:44] <slickymaster> elfy: I'll correct the bug summary to reflect that, then 
[17:45] <slickymaster> brainwash: https://launchpad.net/bugs/1185396 was present in Saucy and it's still present in Trusty, and I think that it is a important issue that should be dealt with 
[17:47] <brainwash> right, it's the same old version of g-s-t
[17:47] <brainwash> and there is no one to maintain it
[17:47] <slickymaster> elfy: https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1250560 description corrected
[17:48] <brainwash> slickymaster: maybe we could use the current gnome solution
[17:50] <slickymaster> brainwash: can't really say as I never used gnome
[17:51] <slickymaster> and thus I'm not aware of their solution
[17:53] <brainwash> slickymaster: they did drop g-s-t
[17:53] <brainwash> new tool to manage accounts looks similar http://i.imgur.com/B3gze7K.png
[17:54] <slickymaster> brainwash: yeah, the GUI seems very similar
[17:54] <brainwash> so maybe a switch to the new one would be possible
[17:56] <slickymaster> brainwash: do you have any idea on who could answer that?
[17:57] <brainwash> the xubuntu team
[17:58] <slickymaster> brainwash: maybe you should address knome or ochosi on that
[17:59] <brainwash> a discussion would be required (do we lose functionality? does it pull more gnome dependencies? are customization needed to get it running under Xfce?)
[17:59] <brainwash> yeah
[18:00] <slickymaster> brainwash: yeah, you're right, particularly on the dependencies factor
[18:01] <slickymaster> well, got a pick up my son at school. bbl
[18:05] <GridCube> i propose we rize the minimum amount of needed ram to 1gb
[18:05] <Unit193> ^
[18:06] <GridCube> even if 512 will work, any webbrowser needs about that much to work with 3 or more tabs
[18:06] <elfy> I'd agree with changing it 
[18:07] <knome> can you please add that to the meeting agenda and prepare the discussion in the meeting itself; and please prepare with arguments why you are proposing
[18:07] <GridCube> alright
[18:14] <brainwash> oh meh, they removed the groups management part from the new gnome user tool
[18:15] <brainwash> looks like we need to keep the old user tool alive
[18:21] <ElderDryas> Speaking of the next meeting, the meeting web page still shows 7 Nov as the next meeting ( https://wiki.ubuntu.com/Xubuntu/Meetings )
[18:28] <knome> it's a wiki though, so editably by anyone
[22:11] <slickymaster> good night all
[22:11] <knome> hello slickymaster 
[22:12] <slickymaster> hi knome 
[22:15] <brainwash> slickymaster: so the new user management tool created by the gnome dev team is part of the gnome control center and lacks the ability to manage groups
[22:15] <ochosi> ali1234: i noticed that when e.g. typing in the zoomed state, the characters don't exactly fly to the screen (sometimes i have to move the mouse to make them visible), is that what you fixed in github this morning?
[22:15] <slickymaster> brainwash, so no dice for Xubuntu, then
[22:15] <ochosi> brainwash: i fear most of gnome3 is so tightly integrated with each other it'll be hard for us to use it without actually using gnome...
[22:16] <ochosi> gnome3 = goodbye modularity
[22:16] <brainwash> yeah, we will have to fix the current users-admin
[22:16] <slickymaster> yeah with the extra burden that all that stuff would bring with it
[22:18] <slickymaster> brainwash, which reminds me that I still have to report https://launchpad.net/bugs/1185396  on the debian bug tracker
[22:19] <brainwash> yeah
[22:22]  * skellat says file a bug against -docs if we have to do write-ups on command-line user management tools in case we don't find a graphical replacement
[22:23] <brainwash> "IRC: you can contact us in the #gst channel at irc.gimp.org"
[22:23] <brainwash> :D
[22:26] <brainwash> not everyone can create an bzr branch or?
[22:26] <brainwash> a bzr
[22:26] <knome> brainwash, can
[22:27] <brainwash> so I just clone the repo and create a new branch which gets uploaded to launchpad?
[22:27] <knome> brainwash, you can always push to lp:~youruser
[22:28] <knome> brainwash, if you want to branch, say xubuntu-docs, you can push to lp:~youruser/xubuntu-docs/my-docs-branch
[22:28] <brainwash> ok, thanks :)
[22:28] <knome> brainwash, if you want to push something that doesn't have a (project) branch in launchpad, you can push to lp:~youruser/+junk/whatever-branch
[22:29] <slickymaster> elfy, ping. https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1250560 still isn't fixed. running sudo -i in Application Finder dialog won't launch anything
[22:30] <brainwash> slickymaster: expected behavior, sudo won't open a terminal window or graphical password prompt
[22:30] <knome> brainwash, that wasn't why he pinged elfy...
[22:32] <slickymaster> brainwash, exactly my point. that's why I'm warning elfy about that
[22:32] <brainwash> and pkexec requires a policy for every single app or?
[22:32] <knome> slickymaster, i pushed the changes to the tracker. can you confirm it is actually fix-released-and-in-the-tracker now?
[22:33] <slickymaster> knome,  just a sec
[22:33] <knome> wait...
[22:33] <knome> i'm the one who's lost
[22:33] <slickymaster> knome, yeah, it's rollbacked to gksudo
[22:33] <knome> i did that because i thought that was wanted
[22:33] <knome> why did we do sudo -i in the first place?
[22:34] <slickymaster> knome, no that was the reason that lead me to raise the bug. IMO the entire test should be rewritten
[22:34] <knome> aha
[22:37]  * slickymaster thinks that by just adding a indication alerting the user to the need of having to install the gksudo package to further proceed with the testcase.
[22:37] <slickymaster> should be enough
[22:38] <knome> sounds like a semi-fishy workaround. isn't there really anything that works OOTB, and why are we dropping gksudo anyway?
[22:39] <slickymaster> knome, I think it's dropped since Saucy and tbh I also don't see a reason for that
[22:40] <knome> might've been a ubuntu decision based on privacy or dropping support for certain stuff
[22:40] <Unit193> knome: "Because it's deprecated, we use policykit now"
[22:41] <knome> that's it.
[22:41] <slickymaster> knome, please refer to http://askubuntu.com/questions/313828/why-is-pkexec-preferred-over-gksudo-for-graphical-applications and http://askubuntu.com/questions/313619/resolvedcould-not-save-the-file-usr-permission-denied-13-04/313625#313625
[22:42] <slickymaster> knome, my last link is wrong. Please don't pay no attention to it. What I meant was this one instead http://askubuntu.com/q/78352/33871
[22:44] <knome> yep, i see
[22:44] <Unit193> TL;DR: use gksudo. ;)
[22:45]  * slickymaster will discuss the all thing tomorrow with elfy
[22:47] <brainwash> but it was already missing in 13.04, right?
[22:47] <brainwash> so the discussion seems kinda late :)
[22:47] <Unit193> Ubuntu, yes, not Xubuntu.
[22:48] <brainwash> ah ok
[22:48] <slickymaster> Yes, Unit193 is right
[22:49] <slickymaster> afk
[23:44] <ali1234> ochosi: yes
[23:52] <ochosi> ali1234: darn, then i gotta try and merge that i guess
[23:54] <ali1234> it should be perfect now, graphically (including video players)
[23:54] <ali1234> it might be slightly slower though