20080415:15:48:15 -!- david_r [n=david@nat/novell/x-ce97e276f8fd2f5b]
20080415:20:10:27 -!- quit david_r [n=david@nat/novell/x-ce97e276f8fd2f5b] ["Leaving"]
20080416:12:56:37 -!- david_r [n=david@nat/novell/x-ae3a32174916cc5b]
20080417:14:06:44 < cyberorg> is that david_r in the room?
20080417:14:07:55 < ~david_r> cyberorg: yes, it's me :)
20080417:14:08:15 < cyberorg> hi david_r :)
20080417:14:10:09 < cyberorg> maniac103, ask away your questions, david_r is here :)
20080417:14:10:39 < maniac103> david_r, any timeframe for getting into Compiz development again? ;-)
20080417:14:13:15 < cyberorg> david_r, what is keeping you busy these days?
20080417:14:14:19 < ~david_r> maniac103: even though im not getting as much done as I would like, im still getting quite a bit done on the object-framework branch
20080417:14:15:03 < ~david_r> maniac103: im working on a remote desktop solution and this new version of compiz is a requirement for that..
20080417:14:15:47 < cyberorg> david_r, anything we would be able to use on kiwi-ltsp? http://en.opensuse.org/LTSP
20080417:14:16:02 < ~david_r> maniac103: once I've been able to get it to the point where it can be merged with master, I'll go back to working on master and be back in the loop again..
20080417:14:16:36 < maniac103> david_r, ah, so you just haven't pushed?
20080417:14:17:13 < onestone> david_r: what do you think about switching to fullscreen output painting if we detect overlapping outputs, because we are painting regions twice on randr clone mode and if one output device is smaler it can result in ugly rendered effects
20080417:14:18:53 < maniac103> david_r, we badly need you for the decoeration corruption problem ... cf bug #781 contains a lot of info about that
20080417:14:19:09 < ~david_r> onestone: yes, the code probably needs to smarter to handle clone mode properly
20080417:14:19:24 < ~david_r> onestone: do whatever you think is best
20080417:14:19:33 < onestone> david_r: ok thx
20080417:14:22:20 < ~david_r> maniac103: 781? freedesktop.org bug?
20080417:14:22:28 < cyberorg> david_r, it would be really nice if you drop in once in a while like this
20080417:14:22:44 < maniac103> david_r, no, http://bugs.opencompositing.org/show_bug.cgi?id=781
20080417:14:23:50 < ~david_r> maniac103: thanks, im looking at the bug...
20080417:14:26:14 < onestone> david_r: if you haven't seen it yet. This is the reason for the core/cube/rotate changes during the last weeks http://dev.compiz-fusion.org/~onestone/blog/?p=6
20080417:14:47:26 < maniac103> david_r, what we also need a solution for is the command line parameter situation ... both gnome and kde people have asked us for the correct command line parameters for their session scripts, and we haven't been able to give them an answer that satisfies all users
20080417:14:51:48 < ~david_r> onestone: looks cool, I can't wait to get back to hacking on fun stuff like that again :)
20080417:14:52:11 < ~david_r> maniac103: not sure about that bug but I've updated it with some questions and info..
20080417:14:53:26 < ~david_r> maniac103: I sort of have a solution for the command line issue in local compiz tree
20080417:14:54:54 < ~david_r> maniac103: object-framework plugins can optionally be built-in to the same binary as compiz
20080417:14:55:59 < ~david_r> maniac103: so you could have a compiz-gnome binary with the appropriate config plugin built-in
20080417:14:57:03 < ~david_r> maniac103: not sure that this is the best solution to your problem though..
20080417:14:58:48 < ~david_r> maniac103: maybe just adding an env-var that compiz will read in addition to the command line would be better
20080417:14:59:15 < onestone> david_r: it's the problem that there is no way to start compiz that works on each hardware
20080417:14:59:54 < maniac103> david_r, my question was more about hardware related command line parameters (direct/indirect, strict/loose etc)
20080417:15:02:28 < ~david_r> maniac103: ok, that's not really compiz's problem but a plugin that will do some kind auto-detection of all those things could of course be added
20080417:15:06:00 < onestone> david_r: do we really want to keep the config plugins? wouldn't it be easier to have a dbus-compiz-settings-*-daemon (kde/gnome/...) that provides a simple (get, set, changed signal) generic dbus interface to get setting values. A compiz dbussettings plugin could then simply read the values out of the daemon with something like get (path, setting name, type). An dbus autostart script could do check what DE is running and start the right
20080417:15:11:22 < ~david_r> onestone: yes, we definitely want configuration moved out of the compiz process
chrisw@thinkpad ~ $ grep david_r irclogs/freenode/#opensuse-gnome.log
20080415:15:48:15 -!- david_r [n=david@nat/novell/x-ce97e276f8fd2f5b]
20080415:20:10:27 -!- quit david_r [n=david@nat/novell/x-ce97e276f8fd2f5b] ["Leaving"]
20080416:12:56:37 -!- david_r [n=david@nat/novell/x-ae3a32174916cc5b]
20080417:14:06:44 < cyberorg> is that david_r in the room?
20080417:14:07:55 < ~david_r> cyberorg: yes, it's me :)
20080417:14:08:15 < cyberorg> hi david_r :)
20080417:14:10:09 < cyberorg> maniac103, ask away your questions, david_r is here :)
20080417:14:10:39 < maniac103> david_r, any timeframe for getting into Compiz development again? ;-)
20080417:14:13:15 < cyberorg> david_r, what is keeping you busy these days?
20080417:14:14:19 < ~david_r> maniac103: even though im not getting as much done as I would like, im still getting quite a bit done on the object-framework branch
20080417:14:15:03 < ~david_r> maniac103: im working on a remote desktop solution and this new version of compiz is a requirement for that..
20080417:14:15:47 < cyberorg> david_r, anything we would be able to use on kiwi-ltsp? http://en.opensuse.org/LTSP
20080417:14:16:02 < ~david_r> maniac103: once I've been able to get it to the point where it can be merged with master, I'll go back to working on master and be back in the loop again..
20080417:14:16:36 < maniac103> david_r, ah, so you just haven't pushed?
20080417:14:17:13 < onestone> david_r: what do you think about switching to fullscreen output painting if we detect overlapping outputs, because we are painting regions twice on randr clone mode and if one output device is smaler it can result in ugly rendered effects
20080417:14:18:53 < maniac103> david_r, we badly need you for the decoeration corruption problem ... cf bug #781 contains a lot of info about that
20080417:14:19:09 < ~david_r> onestone: yes, the code probably needs to smarter to handle clone mode properly
20080417:14:19:24 < ~david_r> onestone: do whatever you think is best
20080417:14:19:33 < onestone> david_r: ok thx
20080417:14:22:20 < ~david_r> maniac103: 781? freedesktop.org bug?
20080417:14:22:28 < cyberorg> david_r, it would be really nice if you drop in once in a while like this
20080417:14:22:44 < maniac103> david_r, no, http://bugs.opencompositing.org/show_bug.cgi?id=781
20080417:14:23:50 < ~david_r> maniac103: thanks, im looking at the bug...
20080417:14:26:14 < onestone> david_r: if you haven't seen it yet. This is the reason for the core/cube/rotate changes during the last weeks http://dev.compiz-fusion.org/~onestone/blog/?p=6
20080417:14:47:26 < maniac103> david_r, what we also need a solution for is the command line parameter situation ... both gnome and kde people have asked us for the correct command line parameters for their session scripts, and we haven't been able to give them an answer that satisfies all users
20080417:14:51:48 < ~david_r> onestone: looks cool, I can't wait to get back to hacking on fun stuff like that again :)
20080417:14:52:11 < ~david_r> maniac103: not sure about that bug but I've updated it with some questions and info..
20080417:14:53:26 < ~david_r> maniac103: I sort of have a solution for the command line issue in local compiz tree
20080417:14:54:54 < ~david_r> maniac103: object-framework plugins can optionally be built-in to the same binary as compiz
20080417:14:55:59 < ~david_r> maniac103: so you could have a compiz-gnome binary with the appropriate config plugin built-in
20080417:14:57:03 < ~david_r> maniac103: not sure that this is the best solution to your problem though..
20080417:14:58:48 < ~david_r> maniac103: maybe just adding an env-var that compiz will read in addition to the command line would be better
20080417:14:59:15 < onestone> david_r: it's the problem that there is no way to start compiz that works on each hardware
20080417:14:59:54 < maniac103> david_r, my question was more about hardware related command line parameters (direct/indirect, strict/loose etc)
20080417:15:02:28 < ~david_r> maniac103: ok, that's not really compiz's problem but a plugin that will do some kind auto-detection of all those things could of course be added
20080417:15:06:00 < onestone> david_r: do we really want to keep the config plugins? wouldn't it be easier to have a dbus-compiz-settings-*-daemon (kde/gnome/...) that provides a simple (get, set, changed signal) generic dbus interface to get setting values. A compiz dbussettings plugin could then simply read the values out of the daemon with something like get (path, setting name, type). An dbus autostart script could do check what DE is running and start the right
20080417:15:11:22 < ~david_r> onestone: yes, we definitely want configuration moved out of the compiz process
20080417:15:14:42 < onestone> david_r: my problem is that I don't know how the object framework system will handle settings (types/lists...), and so I have no idea what a dbus interface will be needed