[02:54] any know pygtk? [02:55] I don't. sadly. [02:56] I'm having a bad time with this app I'm writing. When I have it paint a new screen, it seems to do more work every time do a new screen [02:56] I'm wondering if I need to manually clear the queue [02:57] well, you got far further than I would in writing a program. :) [03:12] I know pygtk [03:12] but the docs know it better [03:13] http://www.pygtk.org/reference.html [03:13] cy1, yea I'm not really getting anywhere with the docs, although I'm not reading them that closely [03:13] tgm4883: Are you connecting the signal once, or every expose event? That would cause a geometrically increasing # of screen refreshes... [03:14] every expose event [03:14] which is wrong, so i'm trying to tweak it until it's correct [03:14] Yes, only connect the signal once, at program initialization. Otherwise it does n expose events every nth expose event. [03:15] Signals are persistent, and have to be explicitly removed. [03:15] cy1, ok, so how am I suppose to call it later then? [03:15] right now, everytime I press the right arrow key, it does "self.mainDA.connect("expose-event", self.expose)" [03:15] The callback you provide gets called every expose event. You don't need to connect to the signal to get repeated calls. [03:16] tgm4883: It seems you want to trigger an expose event, not connect to one, when hitting the right arrow? [03:16] yes [03:17] as I'll have multiple screens I want to paint, depending on which key is pressed [03:18] tgm4883: http://developer.gnome.org/pygtk/stable/class-gtkwidget.html#method-gtkwidget--queue-draw [03:19] invalidate rect is how to trigger a window to emit an expose event. (Generally you don't emit the signals in your own code, but provoke their emission in existing code.) [03:19] and queue draw calls invalidate rect with that widget's dimensions [03:20] hmm [03:20] I'm using queue_draw after I connect the event [03:21] but you are saying I need to use it to trigger the event rather than do the connect on the event [03:21] "self.mainDA.connect("expose-event", self.expose)" => "self.mainDA.queue_draw()" [03:21] the former adds a callback to the signal, without triggering it. [03:21] No limit to how many callbacks you can connect to a signal. [03:21] And it doesn't check if it's the same function. [03:21] So, don't do that. Do queue_draw or whatnot. [03:22] Are you making a gaaame? =) [03:22] cy1, I'm making a calibration tool for Ubuntu TV [03:22] or for TV's in general [03:23] aw [03:23] I can't imagine you'd need a drawable area for that. What sorts of drawings are you displaying? Like a histogram or something? [03:24] so then if I'm using 'self.mainDA.queue_draw()' to paint the screen, I should have a separate drawing area for each? [03:24] cy1, one of them is this http://en.wikipedia.org/wiki/File:SMPTE_Color_Bars_16x9.svg [03:24] I'm generating that [03:24] Ahh, neat. [03:24] I also have one for aspect ratio and overscan [03:25] Good use for a drawing area! [03:25] so is it correct that I need a separate drawing area for each of those then [03:26] So you press right and you want those color bars to auto-update as the monitor is tweaked. Wouldn't it defeat the purpose of testing a monitor for color correctness if the colors changed with the settings? [03:26] Not a separate drawing area I'd say. Depends if you want to refresh them independently or not. [03:26] no, press right and those color bars are displayed. They don't change while you are changing settings on your monitor [03:27] but if you press 2, it switches to your #2 monitor, and changes to fit the new resolution [03:27] So, they're not displayed just when you start the program? [03:27] Oh, I don't know anything about monitor switching... [03:27] no, the first screen displayed is the instructions screen [03:27] I've got monitoring switching all figured out :) [03:29] so I also have 'self.mainDA.connect("expose-event", self.draw_aspect_ratio)' when you press left. How would I differentiate between the two screens if I'm just doing 'self.mainDA.queue_draw()' [03:56] cy1, I think I figured it out. Thanks for pointing me in the right direction [04:40] has anyone here had the event where running apt-get purge wine1.5 purges GRUB2? [04:44] tgm4883: no problem ^.^ [04:44] cy1, you haven't had apt-get purge purge GRUB2, correct? [04:45] c_smith: I'm on Arch. :/ [04:46] I tried arch. [04:47] but on with my story, I was purging wine1.5 with the intent of reinstalling it, it purge GRUB2, PPPOEconf (those are what I know of) and then tried to reinstall Wine1.5 after thoroughly devastating the system. [04:47] apt-get purge in this case is a nightmare. [04:52] geh, dunno what to tell you [04:53] eh, good thing I'm downloading LMDE. [04:54] and strange thing is I'm not angry at all, I'm laughing at this whole thing. [05:02] I am seriously beginning to hate ubuntu. [05:10] tgm4883: is this the same Ubuntu TV that Canonical essentially said their would be a wall between Canonical and Community? :P [05:10] there* [05:11] bkerensa, you saw my description of what happened to me with apt-get purge, right? [05:11] c_smith: no [05:12] well, let's just say it purged GRUB when I told it to purge Wine1.5 [05:12] that, and PPPOEConf [05:12] neither of which are remotely related to Wine1.5 [05:13] so, I don't have a bootloader, and I don't feel like installing it, so I'm going to install another distro. [05:14] yep, I'm taking that harder way out. [05:14] or is it the easier way..... hmmmm..... [05:17] I find it hard to believe apt-get purge wine resulted in grub being removed seems like there was some level of user error involved and why would you purge wine anyways? [05:17] to reinstall it. [05:17] was the package broken? Were you experimenting with a development version? [05:17] >.< [05:17] you dont need to use purge to reinstall [05:17] purge the configuration file to see if it fixed the sound issues. [05:18] rm -f -r ./wine ? [05:18] sudo apt-get remove wine? [05:18] sudo apt-get install wine [05:18] done [05:18] did that, I was making sure I got rid of other traced of config. [05:18] eck .wine even [05:18] rm -f -r .wine from your home and there would be no trace [05:18] hmmmm, ok,\ [05:19] * bkerensa is going to see what this is about because I have no idea why purge would remove GRUB [05:19] * bkerensa has wine installed so lets see [05:19] still gonna try another distro, this system is messed up beyond what I care to fix (it's possible, but I don't care nor have the time to fix it) [05:20] why would you distro hop over a broken bootloader? [05:20] Its not Ubuntu's fault you nuked GRUB :P [05:20] don't know, but I'm bored, and this happens when I'm bored, I distro hop. :P [05:21] yeah I just purged wine and it absolutely did nothing to Grub [05:21] I was going to try another XFCE distro anyway, see what is out there. [05:21] it just removed all the depends and the ms font garbage [05:21] :D [05:21] strange, glitch maybe? [05:21] unlikely [05:21] but possible? [05:21] better lucky of winning the lotto? [05:22] luck* [05:22] xD I see your point. [05:22] the wine package has absolutely no ties to Grub so there is absolutely no reason for apt-get purge to touch grub [05:22] albeit, I'm as clueless as you on this. [05:25] * bkerensa goes back to playing with system76 laptop [05:30] have fun. [05:31] I think I'm going to talk to someone about seeing if I can give away a system76 laptop :P [05:35] c_smith: wine1.5 is a purely virtual package; if you had a real wine1.5 package installed, where did you get it from? [05:36] Ubuntu Wine Team PPA [05:39] sbeattie: almost makes me want to look at the ppa :P to see how any of this was possible [05:41] wine1.5_1.5.4-0ubuntu1~ppa1~precise1+pulse17.debian.tar.gz [05:42] lets have a look [06:00] * sbeattie calls it a night [06:03] * bkerensa hits harvest up for some bug work ;p [14:27] slangasek: the php guys disagree with us... https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1002443 [14:27] :P [14:27] Launchpad bug 1002443 in php5 (Debian) "php5-fpm exposes full ubuntu package version in headers" [Unknown,Won't fix] [15:00] nathwill: well, Marc Deslauriers is on the ubuntu security team, calling him a php guy is likely to not make him happy. [15:00] lol [15:07] nathwill: with you, you mean; I don't have a dog in this fight :) [15:08] lol. naturally. [15:09] i'd hardly call it a fight [15:34] morning markdude [15:34] Morning [15:38] * MarkDude loves the smell of napalm in the morning... [16:07] i see [16:07] RedBeacon is nifty for hiring people to mow lawn and do work for u :D [16:08] I just found someone to mow my lawn and trim my bushes for $25 [16:08] :P [16:09] bkerensa neighborhood youth? [16:09] professional [16:09] :D [16:10] http://redbe.co/r/mvu5w <-- they only use licensed or professional companies in your areas [16:10] you can get like your house cleaned by a maid service for $60 a week or so :D [16:55] woot, first charm promulgated [16:55] nathwill: congratz! [17:36] nathwill: did clint promulgate it? [17:38] bkerensa, no idea yet. they said it might take some time. [17:38] i'm not worried about it. they said it was approved, so it'll show up whenever the flow goes through [17:38] dude... http://en.wikipedia.org/wiki/Black_money_scam [17:38] creepy weird [17:39] weird indeed [18:25] bkerensa: if they only work with licensed professionals, why is their domain registered in colombia? ;) [18:26] Hmm? [18:26] http://who.is/whois/redbeacon.com/ [18:26] thats just their short name [18:26] * bkerensa would love to have a .ly which would require a registered agent in libya but ya too expensive ;) [18:29] ah ;) [19:26] The hotdog debate still rages.... https://docs.google.com/document/d/1h5kHxrn-DxotB-YCNHbdgfdhewkwVXCJ0D6WilkiDVU/edit [19:38] markdude, you should do up a bikeshed textured with hotdogs [19:47] haha [19:50] Dead on nathwill [19:51] http://lists.fedoraproject.org/pipermail/ambassadors/2012-May/019624.html [19:51] * MarkDude did that the other day [19:51] rofl [19:51] i want the graphic though :P [19:53] well [19:53] * MarkDude is working on *video response* [19:53] Epic video will be epic [23:24] Letter is done http://lists.fedoraproject.org/pipermail/advisory-board/2012-May/011612.html