| 00:14.49 | *** join/#gpe prpplague (~joebob@21-190.lctv-b4.cablelynx.com) |
| 00:25.55 | pb_ | hi pigeon |
| 00:26.00 | pigeon | hey pb_! |
| 00:26.20 | pigeon | Hmm... I'm wondering... |
| 00:26.47 | pigeon | If I switch my current gpe to gpe2... |
| 00:26.57 | pb_ | ... |
| 00:27.00 | pigeon | What about the old data/database? |
| 00:27.08 | pb_ | It should all survive. |
| 00:27.26 | pb_ | You might want to back it up first, but in theory the new programs will read (and convert where necessary) old data. |
| 00:34.58 | *** join/#gpe dc_ (~dc@modem-162-59-60-62.vip.uk.com) |
| 00:35.05 | pb_ | dc_: evening |
| 00:35.10 | dc_ | morning :) |
| 00:35.17 | pb_ | well, yes. |
| 00:35.22 | dc_ | pb_: just watched minority report. |
| 00:35.25 | dc_ | quite good ;) |
| 00:35.41 | pigeon | dc_: yo |
| 00:35.48 | dc_ | pigeon: hey! |
| 00:35.51 | pb_ | dc_: ah, heh. cool. |
| 00:36.02 | dc_ | pb_: I think I have this expose event stuff sorted now :) |
| 00:36.20 | pb_ | great! |
| 00:44.45 | dc_ | oh dear, parse error. |
| 00:44.49 | dc_ | always my favorite |
| 00:44.53 | pb_ | ah. |
| 00:52.22 | dc_ | typdef struct { |
| 00:52.22 | dc_ | <PROTECTED> |
| 00:52.22 | dc_ | <PROTECTED> |
| 00:52.22 | dc_ | <PROTECTED> |
| 00:52.23 | dc_ | <PROTECTED> |
| 00:52.25 | dc_ | <PROTECTED> |
| 00:52.27 | dc_ | } ImageInfo; |
| 00:52.29 | dc_ | look okay? |
| 00:52.49 | pb_ | aside from typdef vs typedef, yes. |
| 00:52.58 | dc_ | ah ha! |
| 00:53.30 | pb_ | :-} |
| 00:54.31 | dc_ | problem solved |
| 00:55.34 | pb_ | dc_: phew |
| 01:18.20 | dc_ | bah |
| 01:18.34 | dc_ | oh yay it worked |
| 01:18.36 | dc_ | bold text :} |
| 01:21.02 | moray | dc_: bold text in what, btw? |
| 01:21.24 | dc_ | moray: gpe-gallery list view ! |
| 01:21.31 | dc_ | moray: yes...that's right...not a new app. |
| 01:21.39 | dc_ | moray: improvments on an old one! |
| 01:21.40 | dc_ | :} |
| 01:22.03 | moray | dc_: ha :) |
| 01:22.20 | dc_ | it's all very exciting |
| 01:22.46 | moray | dc_: no scap yet? ;) |
| 01:23.12 | *** join/#gpe mallum (~mallum@pc-80-193-218-21-hw.blueyonder.co.uk) |
| 01:23.16 | dc_ | mallum: ! |
| 01:23.22 | dc_ | mallum: gpe-gallery list view is born :) |
| 01:23.26 | pigeon | greetings mallum. |
| 01:23.31 | dc_ | mallum: and hello :) |
| 01:25.34 | mallum | hello :-) |
| 01:33.33 | dc_ | mallum: and hello :) |
| 01:33.36 | dc_ | oops |
| 01:59.30 | dc_ | arg... |
| 02:00.37 | dc_ | :/ |
| 02:00.39 | dc_ | damn it. |
| 02:00.42 | dc_ | one second it's there |
| 02:00.54 | dc_ | not the damn GtkDrawingArea won't show itself!! |
| 02:00.55 | dc_ | damn it. |
| 02:01.04 | pigeon | Heh. |
| 02:01.34 | pigeon | Not showing or not drawing? |
| 02:01.42 | dc_ | not showing |
| 02:01.51 | dc_ | it's giving no rendering errors. |
| 02:04.26 | dc_ | this is mad... |
| 02:04.38 | mallum | bedtime |
| 02:04.42 | mallum | g'night all |
| 02:04.45 | dc_ | what could have caused this.. |
| 02:04.48 | dc_ | mallum: night :) |
| 02:36.07 | *** join/#gpe dc__ (~dc@modem-252-44-60-62.vip.uk.com) |
| 02:45.12 | *** join/#gpe prpplague (~joebob@21-190.lctv-b4.cablelynx.com) |
| 02:47.17 | *** join/#gpe jg (~jg@dialup-63.214.113.35.Dial1.Boston1.Level3.net) |
| 02:49.09 | jg | dc__: sounds painful.... |
| 02:49.49 | dc__ | it's this damn GtkDrawingArea. |
| 02:49.53 | dc__ | it forced me |
| 02:51.21 | dc__ | ah ha! |
| 02:51.25 | dc__ | fixed it |
| 02:51.26 | dc__ | huray |
| 02:51.28 | dc__ | I can live on :D |
| 02:52.56 | pigeon | Hmm cinemas can never tell how long they're going to show the movie for :\ |
| 02:55.21 | dc__ | :\ |
| 03:03.51 | dc__ | cmarqu: ! |
| 03:03.58 | dc__ | cmarqu: list view is in cvs :D |
| 03:04.19 | dc__ | I need some sleep now, as school start on monday :/ |
| 03:04.31 | dc__ | need to get back to earlier nights ;] |
| 03:04.44 | moray | hm, I'll need to do that before next Thursday somehow :/ |
| 03:04.53 | moray | (silly test thing in the morning then) |
| 03:05.00 | moray | (which I don't yet know anything for ;) |
| 03:05.07 | moray | night dc__ |
| 03:05.17 | dc__ | ibot message for cmarqu: the start of the listview code for gpe-gallery, not all features work, and it's damn slow, but looks cool ehh? |
| 03:05.24 | dc__ | moray: night |
| 03:05.26 | dc__ | :} |
| 04:33.50 | spung | ai ca tou todo esbroado |
| 07:56.21 | *** join/#gpe paul ([p8gGGUh3e@hibernia.jakma.org) |
| 08:03.31 | paul | morn.. |
| 08:48.31 | *** join/#gpe paul__ ([AoZTNoPxl@hibernia.jakma.org) |
| 09:32.06 | *** join/#gpe TheMasterMind1 (foobar@h-68-164-249-32.MCLNVA23.covad.net) |
| 11:34.13 | *** join/#gpe pb_ (~pb@pc2-cmbg4-3-cust239.cmbg.cable.ntl.com) |
| 11:36.45 | paul | hi pb |
| 11:37.18 | pb_ | hi paul |
| 11:40.12 | paul | a suspended ipaq still uses battery i take it? (for DRAM, anything else?) |
| 11:40.33 | paul | unfortunately... a suspended ipaq that runs out of juice seems to need a reset before it will turn on again. |
| 11:41.14 | pb_ | Yes, but it should use only a tiny amount of power in that state. |
| 11:41.40 | pb_ | There seems to be some bug on the 3900 that stops the machine from getting fully into the low-power mode at the moment, so it runs down the battery much too quickly in suspend. |
| 11:42.44 | paul | aha.. i forgot to put mine into its cradle yesterday evening when i came home, this morning it was dead - which surprised me. |
| 11:43.18 | pb_ | Right, that certainly shouldn't happen. |
| 11:44.19 | paul | is the cause of the bug known? or still determined? |
| 11:44.36 | paul | s/still/still to be/ |
| 11:44.37 | pb_ | No, it is still a mystery at the moment. |
| 11:45.26 | pb_ | Unfortunately this kind of thing is difficult to debug. |
| 11:47.05 | paul | bootldr bug presumably? |
| 11:47.28 | pb_ | no, kernel I think. |
| 11:47.46 | pb_ | The bootldr is only in charge of waking up, and that seems to be working OK. |
| 11:48.05 | paul | ah |
| 11:50.06 | pb_ | Might be worth turning off the periodic wakeup for battery checking and see if that helps. I'll make that change in the next kernel images. |
| 11:50.21 | *** join/#gpe PaxAnima (~petter@v058b.studby.ntnu.no) |
| 11:50.51 | PaxAnima | morning |
| 11:56.28 | paul | hi pax |
| 11:56.54 | paul | pb_: waking up from suspend to check the battery? whats that for? |
| 11:57.36 | pb_ | paul: it's meant to only happen while the unit is on AC power, so it can tell when the battery is fully charged. But I think we have had trouble before with it happening even when the AC was disconnected. |
| 11:57.51 | paul | ah |
| 11:58.15 | pb_ | also, it doesn't currently do anything useful anyway, because the code to actually inspect the battery status is disabled. |
| 12:02.15 | paul | oh :) |
| 12:02.40 | paul | pb_: also, what is this battery learning i've heard mention of? |
| 12:03.18 | pb_ | paul: the battery monitor chip can keep track of the real-world capacity of your particular battery in order to provide more accurate remaining-charge estimates. |
| 12:03.27 | paul | ah |
| 12:03.44 | paul | is a complete discharge + charge cycle sufficient to train it? |
| 12:03.44 | pb_ | paul: but, to do that, it needs to see at least one complete cycle from fully-discharged to fully charged. |
| 12:04.07 | paul | well, then i've 'trained' my battery monitor today so :) |
| 12:04.22 | pb_ | Yes. You just need to run the battery down until it's empty, then connect the external power and leave it there until the battery is full (LED stops flashing). |
| 12:04.39 | paul | i noticed it did report strange times after i got my sleeve - the additional battery seemed to confuse it. |
| 12:04.51 | pb_ | Yeah, that's certainly possible. |
| 12:05.18 | pb_ | You can check /proc/asic/battery to find out what the battery monitor thinks about the internal battery. The external one doesn't provide that level of detail though. |
| 12:06.05 | paul | ah |
| 12:06.55 | paul | lifetime: -1 min |
| 12:06.56 | paul | ? |
| 12:07.38 | pb_ | -1 means "unknown". |
| 12:07.46 | pb_ | Is it still charging? |
| 12:09.26 | pb_ | The lifetime is basically the accumulated current divided by the active current. If you have the AC connected, the active current is likely to be negative or zero, so you can't get a useful life estimate. |
| 12:09.57 | paul | aha |
| 12:10.01 | paul | yes it was charging |
| 12:10.37 | paul | backlight on full -> 400mA, low -> 300mA, off -> 230mA. cute.. |
| 12:11.02 | paul | must try that out for cpu scaling, whenever i update to rmk6. |
| 12:11.17 | pb_ | Yeah, that'd be interesting. |
| 12:11.35 | paul | a wee little dock app to select between 'profiles' would be useful. (might hack one up once i have rmk6 installed) |
| 12:12.15 | pb_ | Right. |
| 12:12.35 | paul | does anyone know if the touchscreen lockup issue has been fixed? (thats why i wont update) |
| 12:13.09 | pb_ | I don't think so. I have a patch from Christian which looks like it will fix it, though I was hoping to get some input from Andy before checking it in. |
| 12:13.17 | pb_ | Maybe I should just commit it anyway and see what happens. |
| 12:13.48 | paul | :) |
| 12:14.16 | paul | OffTopic: http://www.jakma.org/pics/slashdot-spam.png |
| 12:14.45 | paul | pb_: what was/is the problem? |
| 12:15.14 | pb_ | It's related to some irq-handling changes in the rmk6 kernel. I will forward you the message I sent to Andy. |
| 12:16.22 | pb_ | Ah, no I won't, it's on my machine at the office. |
| 12:16.59 | pb_ | But the gist was that the asic driver was resetting some state when suspending that it probably shouldn't, and this was causing touchscreen interrupts to end up disabled if you suspended at the wrong moment. |
| 12:17.38 | paul | could it affect other interrupts? or ts specific? |
| 12:20.20 | pb_ | No, it's pretty specific to the touchscreen. |
| 12:24.46 | *** join/#gpe Jacmet (~jacmet@98.adsl0.abc.worldonline.dk) |
| 13:44.17 | *** join/#gpe dc_ (~dc@modem-137-44-60-62.vip.uk.com) |
| 13:44.30 | pb_ | dc_: afternoon |
| 13:44.44 | dc_ | :D |
| 13:44.57 | dc_ | pb_: checkout the list view in gpe-gallery now :) |
| 13:45.03 | pb_ | dc_: :-) |
| 13:45.07 | dc_ | pb_: I got the layout properly working last night. |
| 13:45.11 | dc_ | pb_: very cool indeed. |
| 13:45.13 | pb_ | dc_: sounds cool, I'll take a look in a minute. |
| 13:45.22 | dc_ | cmarqu: awake? |
| 13:46.31 | pb_ | dc_: you want me to build a new gallery package? |
| 13:47.13 | pb_ | dc_: wow, very cool indeed! |
| 13:49.54 | dc_ | pb_: well a few more features need to be implemented. |
| 13:50.03 | dc_ | pb_: but hopefully by tonight it should be ready |
| 13:53.09 | *** join/#gpe flypiper (~netwinder@12-222-141-210.client.insightBB.com) |
| 14:11.09 | pb_ | okay, cool. |
| 14:13.24 | pb_ | dc_: btw, do you think gpe-gallery should recurse into directories when it searches for image files? |
| 14:13.37 | pb_ | might be nice to have as an option at least. |
| 14:14.39 | dc_ | ah yes |
| 14:14.41 | dc_ | it would be |
| 14:16.25 | pb_ | btw, it doesn't seem to be able to make up its mind whether it is rendering the text in bold or not. |
| 14:16.52 | pb_ | the names start out in bold, but if I wipe another window over the top, they go to regular. |
| 14:18.17 | dc_ | hrm |
| 14:18.43 | pb_ | also, I don't think you want to be calling gtk_main_iteration or the progress bar stuff in your expose handler. |
| 14:18.46 | dc_ | works okay for me |
| 14:19.02 | dc_ | ah yes okay. |
| 14:24.22 | dc_ | pb_: I think gpe_create_dir_browser should also return itself or somthing in its callback |
| 14:24.31 | *** join/#gpe cmarqu (colin@buug.mind.de) |
| 14:24.44 | dc_ | pb_: so the gpe-gallery can hide the dir browser to show the loading bar. |
| 14:24.53 | dc_ | s/ the// |
| 14:25.11 | pb_ | dc_: Probably. I just kept the old interface that the XMMS dirbrowser used, so as to not break existing programs. |
| 14:25.18 | pb_ | But I could add a new one easily enough. |
| 14:25.19 | dc_ | :) |
| 14:25.36 | dc_ | well, just returning the dir browser's window is good enough |
| 14:25.53 | pb_ | Okay. I'll see what I can do. |
| 14:26.38 | dc_ | ah found it. |
| 14:28.22 | dc_ | pb_: right, I've made it hide the dir browser window before it calls handler (path) on line 159 |
| 14:28.30 | dc_ | pb_: then it still destroys it later on. |
| 14:28.48 | pb_ | dc_: seems reasonable. |
| 14:29.02 | dc_ | pb_: do you think any apps will disagree with it hiding itself? |
| 14:29.15 | pb_ | dc_: can't think that they would. |
| 14:31.38 | *** join/#gpe ade|indy (~adrian@unimatrix.ex.ac.uk) |
| 14:33.22 | *** join/#gpe dan_t (~dan_t@212-41-206-101.adsl.galactica.it) |
| 14:45.59 | dc_ | pb_: any idea on how to make a number round up? |
| 14:46.09 | dc_ | pb_: to the nearest whole |
| 14:48.12 | Jacmet | dc_: (int)(x+1.0f) ? |
| 14:49.27 | dc_ | Jacmet: let me try :} |
| 14:50.13 | dc_ | Jacmet: :)) |
| 14:50.18 | dc_ | Jacmet: thanks |
| 14:51.04 | Jacmet | dc_: it fails whenever the decimal part is zero |
| 14:51.23 | dc_ | Jacmet: :\ |
| 14:51.27 | PaxAnima | dc_: better use ceil() |
| 14:51.47 | dc_ | PaxAnima: ah, of course |
| 14:51.53 | PaxAnima | or floor() |
| 14:56.31 | pb_ | dc_: by the way, another thought on your libgpewidget documentation. In the toolbar stuff, it may be better to encourage people to use gtk_toolbar_get_icon_size () rather than hard-coding GTK_ICON_SIZE_SMALL_TOOLBAR. |
| 14:56.47 | dc_ | pb_: hrm |
| 14:57.01 | dc_ | pb_: have we found out how to change the icon size for toolbars in gconf then? |
| 14:57.14 | pb_ | dc_: xst write Gtk/ToolbarIconSize int 2 |
| 14:57.30 | pb_ | (the next version of gpe-session-scripts will have that as default) |
| 14:57.47 | dc_ | pb_: have you tested using the stock toolbar add fucntion with the size set to GTK_ICON_SIZE_SMALL_TOOLBAR? |
| 14:57.57 | pb_ | dc_: yes, it works well. |
| 14:58.02 | pb_ | dc_: that's what gpe-nmf does nowadays for example. |
| 14:58.10 | dc_ | doh, I didn't know that. |
| 14:58.11 | dc_ | :} |
| 14:58.20 | dc_ | pb_: so yeah, the stock function shall be used :) |
| 14:58.29 | pb_ | cool :-) |
| 15:01.44 | pb_ | right, supermarket time, back in 30. |
| 15:04.19 | *** join/#gpe jg (~jg@dialup-63.214.67.222.Dial1.Boston1.Level3.net) |
| 15:06.47 | *** join/#gpe jg_ (~jg@dialup-63.214.99.172.Dial1.Boston1.Level3.net) |
| 15:32.32 | cmarqu | dc_: Wow, gpe-gallery looks nice indeed. |
| 15:36.51 | *** join/#gpe TheMasterMind1 (foobar@h-68-164-249-32.MCLNVA23.covad.net) |
| 15:45.16 | *** join/#gpe dc__ (~dc@modem-23-49-60-62.vip.uk.com) |
| 16:03.44 | Jacmet | hmm, gpe-gallery seems to have problems with jpegs |
| 16:11.05 | pb_ | Do you have the JPEG loader installed? |
| 16:11.39 | Jacmet | pb_: yes |
| 16:12.10 | pb_ | What goes wrong with them, exactly? |
| 16:12.56 | Jacmet | <PROTECTED> |
| 16:12.56 | Jacmet | Status: install ok installed |
| 16:13.17 | Jacmet | pb_: they don't display - .png and .xpm's works fine |
| 16:13.33 | Jacmet | using the 0.7-pre4 image |
| 16:13.52 | pb_ | Do you mean gpe-gallery just doesn't find them at all, or that it attempts to load them and the image doesn't show up right? |
| 16:13.53 | Jacmet | (the jpeg loader wasn't preinstalled) |
| 16:14.14 | Jacmet | pb_: it attempts to load them but doesn't display anything |
| 16:14.50 | pb_ | Does /etc/gtk-2.0/gdk-pixbuf.loaders mention the jpeg loader? |
| 16:15.15 | pb_ | It works OK with jpegs on my desktop. Haven't tried on the ipaq though. |
| 16:15.54 | Jacmet | pb_: no it doesn't - wait a sec, I'll add it |
| 16:16.50 | pb_ | Ah, sounds like the postinst in the loader package is broken or missing. |
| 16:16.55 | Jacmet | yes |
| 16:17.03 | pb_ | Just do gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders. |
| 16:17.59 | Jacmet | pb_: great, it works - thanks |
| 16:18.16 | pb_ | ok, cool |
| 16:20.10 | Jacmet | Rendering image /mnt/hda/dcim/100pentx/imgp1246.jpg |
| 16:20.10 | Jacmet | Rendering image /mnt/hda/dcim/100pentx/imgp1247.jpg |
| 16:20.10 | Jacmet | Rendering image /mnt/hda/dcim/100pentx/imgp1248.jpg |
| 16:20.10 | Jacmet | Rendering image /mnt/hda/dcim/100pentx/imgp1249.jpg |
| 16:20.10 | Jacmet | Terminated |
| 16:20.18 | Jacmet | hmm.. out-of-memory perhaps |
| 16:21.05 | Jacmet | ~ # free |
| 16:21.06 | Jacmet | <PROTECTED> |
| 16:21.06 | Jacmet | <PROTECTED> |
| 16:21.06 | Jacmet | <PROTECTED> |
| 16:21.06 | Jacmet | Total: 30920 30468 452 |
| 16:21.06 | Jacmet | ~ # |
| 16:21.28 | pb_ | http://europa.debian.org/cgi-bin/bugzilla/show_bug.cgi?id=157 is most likely the problem there. |
| 16:23.53 | Jacmet | ohh ok, thanks |
| 16:24.11 | pb_ | I guess we need to lean on our man in Australia to do something about it. |
| 16:29.58 | cmarqu | Eeek. |
| 16:30.01 | cmarqu | boot> copy hda1:/bootgpe2-v0.7-pre4-h3600.jffs2 root |
| 16:30.13 | cmarqu | boot> boot |
| 16:30.13 | cmarqu | booting jffs2... |
| 16:30.13 | cmarqu | booting boot/zImage from partition >root< |
| 16:30.15 | cmarqu | [...] |
| 16:30.19 | cmarqu | Unrecognized kernel image |
| 16:30.31 | pb_ | Hell. |
| 16:30.46 | cmarqu | I guess I should turn to nelson. |
| 16:30.51 | pb_ | Guess so. |
| 17:14.56 | dc__ | :\ |
| 17:14.57 | dc__ | cmarqu: ! |
| 17:15.23 | cmarqu | dc__: Hey. |
| 17:15.42 | dc__ | cmarqu: checkout the new code? |
| 17:16.12 | cmarqu | dc__: Yes, it looks great. |
| 17:16.25 | dc__ | Jacmet: wait till the new version is release this evenin |
| 17:16.25 | dc__ | g |
| 17:16.29 | dc__ | cmarqu: :D |
| 17:16.43 | pb_ | Ah, I see walters plans to package D-BUS in Debian. |
| 17:16.47 | dc__ | oooh |
| 17:16.56 | cmarqu | dc__: Will the new version fix the iconlist problem? |
| 17:17.04 | dc__ | cmarqu: no :} |
| 17:17.17 | cmarqu | By not using it? |
| 17:17.21 | dc__ | hehe |
| 17:17.40 | pb_ | Is that the out-of-memory iconlist problem, or a different one? |
| 17:17.41 | dc__ | I dunno, I guess I should put the option to switch between them back in |
| 17:18.13 | cmarqu | Well, I |
| 17:18.31 | cmarqu | 'm just asking if we will have an OOM problem in the new gpe-gallery. |
| 17:18.40 | dc__ | eh? |
| 17:18.50 | cmarqu | dc__: http://europa.debian.org/cgi-bin/bugzilla/show_bug.cgi?id=157 |
| 17:19.23 | pb_ | I guess I can check in my fix for gpe-iconlist now, and let mibus change it later if he wants. |
| 17:19.30 | dc__ | pb_: best |
| 17:19.39 | dc__ | pb_: what's your fix? |
| 17:20.00 | pb_ | one minute, let me look again. |
| 17:20.03 | dc__ | cmarqu: ah wait, I know how I can prevent it in the list iew. |
| 17:20.18 | dc__ | cmarqu: we can have only the icons in view rendered. |
| 17:20.29 | dc__ | cmarqu: although this will make scrolling slow. |
| 17:21.18 | cmarqu | Hmm. |
| 17:21.47 | pb_ | dc__: handhelds.org/~pb/iconlist.diff |
| 17:21.55 | dc__ | cmarqu: although this may not be needed, as the list view doesn't keep full size pixbufs of the images, just the scaled ones. |
| 17:22.20 | dc__ | cmarqu: but if you try to open a directory of like 500+ images I guess it could die. |
| 17:22.30 | cmarqu | Then it sounds as if it's okay. |
| 17:22.37 | dc__ | ah okay. |
| 17:22.39 | dc__ | yeah |
| 17:22.46 | dc__ | well if iconlist is fixed we should be okay |
| 17:23.08 | dc__ | pb_: ah cool, well commit it I say :) |
| 17:23.22 | dc__ | pb_: then we can hopefully release the new gpe-gallery safely today |
| 17:23.28 | pb_ | Okay. |
| 17:23.35 | dc__ | heh, a few words the wrong way round there |
| 17:27.40 | pb_ | dc__: it's checked in. I'll build a new package now, unless you have anything else to be added. |
| 17:27.59 | dc__ | for iconlist, no |
| 17:28.09 | pb_ | well, or anything else in libgpewidget. |
| 17:28.25 | dc__ | let me see |
| 17:28.32 | dc__ | nothing. |
| 17:28.34 | dc__ | go ahead :) |
| 17:29.08 | pb_ | Okay, building now. |
| 17:30.01 | dc__ | gpe-gallery seems to be segfaulting on tzset () when I call ctime () |
| 17:30.12 | dc__ | could libgpewidget be not calling something beforehand? |
| 17:30.12 | pb_ | Crumbs. |
| 17:30.25 | pb_ | Doubt it. I don't think the time functions need any initialisation. |
| 17:30.30 | dc__ | hrm |
| 17:30.38 | dc__ | pb_: when using a time_t |
| 17:31.11 | dc__ | pb_: if I have time_t *foo, I can just do foo = some_stat.st_mtime right? |
| 17:31.22 | dc__ | then ctime (foo); |
| 17:31.24 | pb_ | ah, no. |
| 17:31.27 | dc__ | ahh |
| 17:31.29 | pb_ | that would elicit a compiler warning. |
| 17:31.37 | pb_ | and, more to the point, would segfault at run time. |
| 17:31.44 | dc__ | right. |
| 17:31.53 | dc__ | what's wrong in it? |
| 17:31.55 | pb_ | ctime wants a time_t*, ie pointer to time_t. |
| 17:32.15 | dc__ | &some_stat.st_mtime? |
| 17:32.18 | pb_ | so, you could do time_t foo = some_stat.st_mtime; ctime (&foo) |
| 17:32.28 | dc__ | ah okay |
| 17:32.31 | pb_ | or, yes, that, so long as some_stat didn't go out of scope before you called ctime. |
| 17:32.45 | dc__ | which is what's going to happen :) |
| 17:32.47 | dc__ | hehe |
| 17:33.34 | dc__ | &image_info->file_modified is not going to think I'm wanting the address of image_info is it? |
| 17:33.54 | pb_ | No, it'll give you the address of (image_info->file_modified). |
| 17:34.02 | dc__ | great, yep works.. |
| 17:34.25 | pb_ | dc__: you need to pay more attention to those compiler warnings. :-/ |
| 17:34.30 | dc__ | :} |
| 17:34.37 | dc__ | and get rid of the useless ones |
| 17:34.38 | dc__ | first. |
| 17:34.47 | pb_ | yes, that also. |
| 17:37.12 | dc__ | I'll do that one I get this date formatted ;] |
| 17:37.22 | pb_ | :-) |
| 17:39.18 | pb_ | okay, libgpewidget1_0.52 (+ locale packages) uploaded. |
| 17:39.24 | dc__ | great |
| 17:41.52 | dc__ | hrm |
| 17:42.01 | dc__ | something is up with the pango attribute lists. |
| 17:42.17 | dc__ | it seems to not be keeping the attributes when you scroll |
| 17:42.47 | pb_ | ah, maybe that would explain my earlier problems with text going non-bold. |
| 17:42.58 | dc__ | pb_: do you think making them global and not remaking them on every expose event might be help? |
| 17:43.07 | pb_ | dc__: might be a good idea. |
| 17:46.17 | *** join/#gpe dc___ (~dc@modem-88-63-60-62.vip.uk.com) |
| 17:46.34 | dc___ | eek, not I get no attributes showing at all |
| 17:46.54 | pb_ | Oh dear. |
| 17:47.04 | dc___ | pb_: when is the normal time to set attributes on a pango layout? |
| 17:47.31 | pb_ | dc___: I think you can set them at any time. |
| 17:48.06 | pb_ | dc___: If all you are trying to do is make the text bold, though, there should be no need to use an attribute list anyway. |
| 17:48.13 | pb_ | Just put tags like <b>...</b> in your markup. |
| 17:48.16 | dc___ | ah okay |
| 17:48.18 | dc___ | markup |
| 17:48.26 | nelson | cmarqu: interesting. I"m running the same image and had no trouble booting. |
| 17:49.33 | dc___ | pb_: much better :} |
| 17:50.45 | pb_ | cool |
| 17:51.12 | nelson | Is the current desktop supposed to have a background image? |
| 17:51.23 | nelson | It seems to have a light aqua color. |
| 17:51.41 | pb_ | Yes, it does that for me too. I think this is a function of the new matchbox that went into unstable recently. |
| 17:52.11 | nelson | Okay, then I won't worry about it. |
| 17:52.20 | pb_ | You might be able to change it in gpe-conf. |
| 17:52.58 | pb_ | (Settings -> Global Appearance -> Background) |
| 17:57.16 | *** join/#gpe dc_ (~dc@modem-88-63-60-62.vip.uk.com) |
| 17:57.24 | dc_ | not cool |
| 17:57.30 | dc_ | just crashed X with gpe-gallery. |
| 17:57.30 | pb_ | crash? |
| 17:57.34 | pb_ | suck. |
| 17:57.58 | dc_ | take x |
| 17:58.10 | dc_ | in xnest :_ |
| 18:02.15 | pb_ | hrm, NMF volume control is a bit dysfunctional. |
| 18:02.43 | dc_ | :// |
| 18:03.00 | pb_ | it goes to full volume at the start of every track, which isn't really what's wanted. |
| 18:06.28 | dc_ | okay....looking alot better now |
| 18:06.36 | pb_ | cool |
| 18:06.44 | dc_ | I hope people like small fonts though :) |
| 18:06.58 | pb_ | heh |
| 18:07.03 | pb_ | you probably ought to make the fonts configurable somehow. |
| 18:07.08 | dc_ | :/ |
| 18:07.13 | pb_ | Some people are bound to complain if they are small and there is no way to change them. |
| 18:07.17 | dc_ | I've make them absolute |
| 18:07.42 | dc_ | problem is you can't fit them on if they're much bigger |
| 18:07.51 | pb_ | ah. |
| 18:08.00 | pb_ | you can't wrap the text onto more lines? |
| 18:08.57 | pb_ | I suppose that might look a bit strange, but then images with long names are already running off the side for me. |
| 18:09.14 | dc_ | quite. |
| 18:09.39 | dc_ | ah. |
| 18:09.51 | dc_ | I can make it expand with the text size, verticly. |
| 18:15.15 | pb_ | right. |
| 18:20.50 | *** join/#gpe Len_M (~vze24hrw@pool-138-89-67-248.mad.east.verizon.net) |
| 18:20.55 | Len_M | hi to all... |
| 18:21.01 | Len_M | May I ask a question? |
| 18:21.25 | dc_ | Len_M: sure thing :) |
| 18:21.45 | Len_M | Thanks... |
| 18:22.11 | Len_M | How do I save a screen image? (We're running Familiar/GPE 0.6.1 on an iPAQ.) |
| 18:22.39 | dc_ | Len_M: do 'ipkg install scap' |
| 18:22.50 | dc_ | Len_M: then run scap from the terminal or menu. |
| 18:22.59 | dc_ | Len_M: and you image will be uploaded to handhelds.org/scap |
| 18:23.44 | Len_M | In what formaty? |
| 18:23.47 | Len_M | -y |
| 18:24.04 | cmarqu | PNG |
| 18:24.06 | dc_ | well, you can download the image in many formats from handhelds.org/scap |
| 18:24.15 | Len_M | very cool. |
| 18:24.26 | Len_M | Thanks! I'll try it. |
| 18:24.53 | cmarqu | Ah, indeed, there is a jpeg option on scap... |
| 18:25.14 | Len_M | thanks -- that will help... |
| 18:27.17 | Len_M | How about privacy? Is there any way to delete it after it's on /scap? |
| 18:27.46 | dc_ | no :} |
| 18:28.42 | Len_M | Well, any other ways to do a screen capture? (Our code will be GPLed, but we're not ready to go public with development screens.) |
| 18:28.57 | dc_ | Len_M: you could always setup your own scap server/ |
| 18:29.05 | dc_ | Len_M: might want to persu nelson |
| 18:29.11 | dc_ | iirc |
| 18:29.59 | Len_M | will do... thanks! |
| 18:32.15 | dc_ | pb_, cmarqu: okay, the is officialy cool new |
| 18:32.17 | dc_ | s/new/now/ |
| 18:32.25 | dc_ | :) |
| 18:34.16 | Len_M | dc_: indeed! |
| 18:34.24 | dc_ | hehe |
| 18:34.32 | dc_ | pb_: ready to build an ipkg? |
| 18:34.47 | dc_ | oh wait, we want iconlist aswell :} |
| 18:36.41 | pb_ | Len_M: you can get the source for the program behind scap from the webpage. It's pretty simple. |
| 18:37.01 | pb_ | just takes a raw dump of /dev/fb0 and converts it into pnm or something, and thence to png. |
| 18:37.45 | Len_M | I don't know much about graphic formats... <sigh> |
| 18:37.50 | pb_ | dc_: the? |
| 18:37.54 | pb_ | gpe-gallery? |
| 18:38.31 | dc_ | well, in a but |
| 18:38.33 | Jacmet | Len_M: or alternatively you can just write a simple program on the ipaq which dumps a 24bit raw image suitable for gimp or convert .. |
| 18:38.35 | dc_ | s/but/bit/ |
| 18:39.17 | pb_ | dc_: ok, alert me when you are ready to go. |
| 18:39.29 | Len_M | Jacmet: Thanks, I'll pass that info along... |
| 18:41.22 | Len_M | off topic... ppp over usb: where do I get that? |
| 18:41.27 | Jacmet | Len_M: Simply read 320x240x16bit from /dev/fb0, convert to 24bit and write it out to a file |
| 18:41.39 | Len_M | Jacmet: "simply..." lol! |
| 18:41.55 | Jacmet | Len_M: well .. ;) |
| 18:55.09 | dc_ | yay |
| 18:55.12 | dc_ | view changing works now :)) |
| 18:58.30 | dc_ | be happy. |
| 18:58.31 | dc_ | :} |
| 19:00.54 | dc_ | pb_: okay, we're ready for an ipkg :D |
| 19:00.57 | dc_ | bbl, food. |
| 19:02.21 | pb_ | dc_: okay. |
| 19:08.22 | cmarqu | Hmm, so why can't I mount my 2nd partition of my CF card? |
| 19:08.56 | cmarqu | ~ # mount -t ext2 /dev/hda2 /mnt/hda2 |
| 19:08.57 | cmarqu | mount: Mounting /dev/hda2 on /mnt/hda2 failed: No such device |
| 19:08.57 | cmarqu | ~ # mount /dev/hda2 /mnt/hda2 |
| 19:08.57 | cmarqu | mount: Mounting /dev/hda2 on /mnt/hda2 failed: Invalid argument |
| 19:09.38 | pb_ | All the right modules loaded? |
| 19:09.47 | pb_ | (ext2, say) |
| 19:10.00 | pb_ | dc_: gpe-gallery 0.6 uploaded |
| 19:10.03 | cmarqu | Argh, of course... |
| 19:10.18 | cmarqu | I mean, of course not. |
| 19:10.20 | cmarqu | :) |
| 19:10.26 | pb_ | Hehe. |
| 19:10.40 | pb_ | You'd think mount would be able to detect that and print a more useful error, really. |
| 19:10.46 | cmarqu | Yeah. |
| 19:10.58 | cmarqu | busybox mount I guess. |
| 19:11.09 | pb_ | Yeah. |
| 19:11.10 | cmarqu | ipkg install mount wouldn'y do it... |
| 19:24.45 | cmarqu | pb_: gpe-nmf segfault at http://handhelds.org/scap/port.17328.png (scap was the easiest way to get the output) |
| 19:25.15 | pb_ | Ah, nasty. Any idea what caused it? |
| 19:25.55 | cmarqu | I was running as a user and wanted to add a few files to the playlist, recursively. |
| 19:26.09 | cmarqu | Happened twice at the same time. |
| 19:26.55 | pb_ | Okay. I'll look into that. |
| 19:27.14 | cmarqu | Hmm. Maybe I need to gst-register, I now got another segfault, at another time. |
| 19:27.26 | cmarqu | Ah, one thing: |
| 19:27.42 | cmarqu | I had the gpe-nmf main window folded down when I tried to add the files. |
| 19:27.53 | cmarqu | In case that matters |
| 19:28.06 | pb_ | Right. I don't think it ought to make any difference, but I'll check. |
| 19:30.35 | cmarqu | Hmm, the last package seems to be confused when I have a global gstreamer registry and one in ~/.gstreamer. |
| 19:30.52 | cmarqu | I rm -r'ed /.gstreamer/, and now it works. |
| 19:31.01 | *** join/#gpe florian (~fuchs@pD9E5F795.dip.t-dialin.net) |
| 19:31.06 | florian | hi all! |
| 19:32.07 | cmarqu | Hi florian |
| 19:32.43 | florian | cmarqu: hi |
| 19:33.36 | cmarqu | pb_: Okay, the clicks when playing audio are still there with ALSA, so I'll ask jamey about buffering. |
| 19:33.50 | pb_ | hi florian |
| 19:33.52 | pb_ | cmarqu: right. |
| 19:34.12 | cmarqu | CPU usage spikes rather high once there was an underrun. |
| 19:35.56 | *** join/#gpe luccio (luccio@cs78237024.pp.htv.fi) |
| 19:36.05 | florian | pb_: hi |
| 19:36.05 | cmarqu | pb_: Is gpe-nmf-mp3 obsolete? If yes, shouldn't it be added to Replaces: gpe-nmf-ogg, gpe-nmf-mad in gpe-nmf? |
| 19:36.09 | luccio | hi |
| 19:36.12 | pb_ | hi luccio |
| 19:36.15 | cmarqu | Hi luccio |
| 19:36.37 | pb_ | cmarqu: Ah, yes. Most likely I meant to write gpe-nmf-mp3 but misspelt it as "-mad". |
| 19:36.54 | cmarqu | Ah. |
| 19:37.09 | pb_ | I'll correct it in the next version. |
| 19:37.56 | cmarqu | "added plugin mad with 1 feature(s)" -- wouldn't that give me mp3 playback? Doesn't give sound, but also doesn't error out. |
| 19:38.28 | pb_ | Yes, that's the mp3 decoder. |
| 19:38.46 | cmarqu | Ah, "Could not find media type" when trying to play. |
| 19:38.50 | pb_ | Ah, that again. |
| 19:46.39 | *** join/#gpe walters (walters@216.226.142.129) |
| 19:47.13 | Len_M | Bye for now. Thanks for the help! |
| 19:47.16 | *** join/#gpe luc_ (luccio@cs78237024.pp.htv.fi) |
| 19:47.16 | *** part/#gpe Len_M (~vze24hrw@pool-138-89-67-248.mad.east.verizon.net) |
| 19:49.27 | luc_ | name changed... |
| 19:50.24 | luc_ | are dummy question welcomeäö |
| 19:50.50 | pb_ | sure :-) |
| 19:51.23 | luc_ | I am wondering... GUI building take lot of code, |
| 19:51.38 | luc_ | and just used at launch time, |
| 19:51.53 | luc_ | could it be doable to load it |
| 19:52.06 | luc_ | then unload when unused and free memory+ |
| 19:52.30 | luc_ | (+ was question mark...) |
| 19:52.44 | pb_ | Mmm, that's an interesting idea. |
| 19:52.51 | pb_ | I wonder how much memory would actually be saved though. |
| 19:53.17 | pb_ | Do you have any measurements for how large the GUI initialisation code is in some programs? |
| 19:53.43 | luc_ | hmmm no. how to do that |
| 19:54.06 | pb_ | I guess you could put it in a separate source file, compile that file, then use "size" on the .o. |
| 19:54.11 | luc_ | I just have the idea it is about half at least as line of codes |
| 19:55.09 | pb_ | Another option would be to use libglade to build the GUI from a definition in an XML file. |
| 19:55.28 | luc_ | sketchbook has separated gui stuff, more or less |
| 19:55.30 | pb_ | Obviously, libglade itself is quite a lot of code, but at least it can be shared between many programs. |
| 19:55.55 | luc_ | gpe-sketchbook 46.629 |
| 19:56.19 | luc_ | gui 3120 + 6440 |
| 19:56.31 | luc_ | about one fourth |
| 19:59.50 | pb_ | Right. Well, I'm not sure that 10k of code is really worth worrying about too much to be honest. |
| 20:00.38 | pb_ | You could put it in a shared library and use dlopen/dlclose if you wanted. But, there are probably easier ways to save that amount of memory in other parts of the system. |
| 20:01.39 | luc_ | well just 10Ko because sketchbook is... small |
| 20:02.06 | luc_ | but one fourth on the overall actually, it may be worth sometimes |
| 20:03.24 | luc_ | Anyway I was just wondering... |
| 20:03.31 | luc_ | another question, |
| 20:04.02 | luc_ | I tried to add gtk-stock icons, |
| 20:04.23 | luc_ | but icons is not found (on desktop) |
| 20:04.47 | luc_ | is it again because I am still running GTK2.0 |
| 20:05.25 | pb_ | It might be, yes. I don't remember how much support for stock icons there was in GTK 2.0. |
| 20:06.09 | luc_ | OK, I definitly need to upgrade... |
| 20:06.16 | pb_ | Sounds like a good idea. |
| 20:06.38 | luc_ | *grin* |
| 20:28.50 | cmarqu | familiar:~$ DISPLAY=localhost:0.0 gpe-todo |
| 20:28.50 | cmarqu | (gpe-todo:2179): GLib-GObject-CRITICAL **: file /home/pb/glib-2.1.5/gobject/gobject.c: line 1316 (g_object_unref): assertion `object->ref_count > 0' failed |
| 20:28.53 | cmarqu | (gpe-todo:2179): GLib-GObject-CRITICAL **: file /home/pb/glib-2.1.5/gobject/gobject.c: line 1298 (g_object_ref): assertion `object->ref_count > 0' failed |
| 20:29.03 | cmarqu | Segmentation fault |
| 20:29.05 | pb_ | Wow |
| 20:29.08 | cmarqu | It saves the data of course. |
| 20:29.14 | pb_ | Oh, that's when you quit? |
| 20:29.24 | cmarqu | Yes. |
| 20:29.31 | cmarqu | You don't see that normally I guess. |
| 20:29.36 | pb_ | Yeah, lots of programs seem to be doing that at the moment, and I don't have a clue why. |
| 20:29.51 | pb_ | It's dying somewhere deep inside GTK. |
| 20:29.58 | cmarqu | Ah. |
| 20:30.08 | cmarqu | Well, it all seems to be okay. |
| 20:34.02 | florian | pb_: Did you find the rest of critical bugs in dillo? |
| 20:34.22 | nelson | libglade! libglade! |
| 20:34.39 | nelson | It'll be important to use it when we start getting larger and larger screens. |
| 20:39.06 | *** join/#gpe paul ([tk5kPu28I@hibernia.jakma.org) |
| 20:39.10 | pb_ | florian: No, I haven't really looked yet. |
| 20:52.55 | paul | is jamey around? |
| 20:57.09 | pb_ | nope |
| 20:57.16 | pb_ | jamey doesn't tend to IRC much on the weekends. |
| 20:57.16 | *** join/#gpe mallum (~mallum@pc-80-193-218-21-hw.blueyonder.co.uk) |
| 20:57.24 | paul | ah |
| 20:57.35 | paul | wanted to ask him where he got the wlan-ng scripts from. |
| 20:57.55 | paul | hi mallum |
| 20:58.15 | mallum | hey paul |
| 21:02.09 | paul | mallum: http://handhelds.org/~mallum/xpkgs/ - the xserver package doesnt have the usual name, no? |
| 21:02.17 | florian | mallum: hi mallum |
| 21:03.21 | mallum | paul: no its changed |
| 21:03.23 | mallum | hey florian |
| 21:04.24 | mallum | paul: its not a h3600 specific server anymore, just a 'generic' one for framebuffers |
| 21:04.31 | paul | ah, ok. |
| 21:05.04 | mallum | paul: the only non generic stuff before was the ts stuff, but now there using tslib which deals with all the different ts interfaces rather than X itself |
| 21:06.29 | paul | the ipkg knows to remove the older Xserver package? |
| 21:07.12 | mallum | yeah it conflicts with it |
| 21:07.18 | paul | k |
| 21:09.09 | paul | anyone know how to decode ioctls? both wlanctl-ng and iwconfig are failing to find the wlan0 device, and they're both doing this: |
| 21:09.11 | paul | socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 |
| 21:09.11 | paul | ioctl(3, 0x8b1a, 0xbffffd14) = -1 ENODEV (No such device) |
| 21:09.43 | paul | well, that was iwconfig, wlanctl-ng is doing: |
| 21:09.44 | paul | ioctl(3, 0x89f1, 0xbfffed78) = -1 ENODEV (No such device) |
| 21:12.09 | mallum | jg_: ping |
| 21:12.26 | florian | paul: which driver do you use? |
| 21:12.44 | paul | florian: i'm trying to use the prism2_cs driver. |
| 21:13.19 | paul | jamey was kind enough to build linux-wlan-ng packages for me. (the hostap_cs prism driver is hopeless, at least with my DWL-650) |
| 21:15.18 | mallum | paul: arg dwl-650 is eveeeeel |
| 21:15.33 | paul | mallum: how so? |
| 21:15.45 | mallum | paul: I think it has broken firmware |
| 21:15.55 | paul | mallum: aha. |
| 21:16.04 | mallum | paul: are you passing the vcc=3.3v thingy to it ? |
| 21:16.12 | paul | no, whats that? |
| 21:16.34 | paul | there's no modinfo on familiar so.. |
| 21:16.35 | mallum | paul: I think the dwl-650 says its wants 5v when really it only wants 3.5 |
| 21:16.41 | paul | aha |
| 21:16.47 | mallum | 3.3 rather |
| 21:17.00 | mallum | paul: so theres some option to force it |
| 21:17.00 | florian | mallum: but this is easy to solve... |
| 21:17.17 | florian | paul: did you try orinoco_cs? |
| 21:17.24 | paul | no |
| 21:17.43 | paul | i didnt think orinoco supported prism2 |
| 21:17.52 | mallum | paul: iirc that works ok with it |
| 21:17.56 | paul | mallum: aha |
| 21:18.21 | mallum | paul: Im sure I've had hostap drivers working with it too |
| 21:18.39 | florian | paul: it does, and it's definitels more stable than any wlan-ng... |
| 21:18.42 | paul | modutils conflicts with busybox :( |
| 21:19.01 | paul | florian: wlan-ng works fine the card on an i386 laptop i have |
| 21:20.11 | paul | ok.. let me try orinocco |
| 21:20.33 | paul | if anyone has modutils installed with familiar unstable - could they do modinfo on the orinico and hostap_cs drivers? |
| 21:21.48 | florian | paul: i used wlan-ng quite long, mostly for wireless lan scanner... for some card they seem to wor, for other they seem to fail without a special reason :-/ |
| 21:23.35 | paul | drat.. modinfo isnt arch portable. :( |
| 21:28.05 | florian | mallum: Has the current unstable matchbox support for changing desktop font family and color via xsettings? |
| 21:29.28 | paul | florian: orinoco_cs doesnt seem to recognise it |
| 21:29.48 | mallum | florian: no not as yet :( |
| 21:30.09 | mallum | florian: its quite hard for me to hack in at the moment |
| 21:30.36 | mallum | florian: I need to spend some time shuffling the source around, will do that v.soon |
| 21:32.50 | florian | paul: it needs the option to force voltage too.. |
| 21:33.18 | paul | cardctl says its 3.3v already |
| 21:34.00 | florian | mallum: yep, ok |
| 21:34.29 | florian | paul: what says the driver? |
| 21:37.42 | paul | florian: ermm.. cant get it to work now |
| 21:38.42 | florian | paul: is it loaded? |
| 21:38.51 | paul | yes.. |
| 21:40.10 | paul | hang on, let me reboot it. somethings wedged. |
| 21:44.03 | paul | florian: ok, its working, and i've set ignore_cis_...=1 in modules.conf |
| 21:44.18 | paul | lets try scp'ing something, |
| 21:44.54 | paul | nope. still locks up. (hostap_cs) |
| 21:47.34 | *** join/#gpe dc__ (~dc@modem-90-52-60-62.vip.uk.com) |
| 21:48.46 | florian | paul: ok, i think this is necessary... |
| 21:50.18 | paul | hmm it still sort of locks up. |
| 21:50.45 | paul | it actuall went fine for one transfer just there, but did it again and boom. |
| 21:51.09 | paul | also, how do you tell pcmcia_cs to use orinoco_cs? |
| 21:51.20 | paul | (i've edited /etc/pcmcia/config - no joy) |
| 21:51.36 | pb_ | That should do it. The "bind" line in that file is what controls which driver is used. |
| 21:52.57 | paul | is it 'first match' or last match? |
| 21:53.14 | pb_ | I'm not sure. Normally you'd only have one matching entry. |
| 21:54.11 | florian | paul: danger! this dwl-650 is one of _many different_ cards using id 0x0156 0x0002 |
| 21:54.42 | paul | aha.. maybe i need to restart cardmgr? |
| 21:54.52 | florian | yep |
| 21:54.54 | pb_ | walters: good to see your ITP for dbus. |
| 21:55.00 | florian | brb |
| 21:55.01 | pb_ | paul: yes, or maybe you can send it SIGHUP. |
| 21:55.18 | walters | pb_: it's in queue/NEW :) |
| 21:55.24 | pb_ | walters: aha! |
| 21:56.44 | mallum | pb_: there are ipkg's of dbus here btw - http://www.handhelds.org/~mallum/dbus/ , I guess I should put them in unstable soon |
| 21:56.49 | paul | same problem with orinoco_cs :( |
| 21:57.31 | florian | re |
| 21:57.33 | walters | is gpe using dbus? |
| 21:57.51 | pb_ | walters: not yet, but we will probably start doing so fairly soon. |
| 21:58.01 | walters | cool |
| 21:58.21 | florian | paul: what exactly happens? |
| 21:58.34 | paul | with orinoco: |
| 21:58.36 | paul | eth0: Error -110 writing Tx descriptor to BAP |
| 21:58.36 | paul | NETDEV WATCHDOG: eth0: transmit timed out |
| 21:58.36 | paul | eth0: Tx timeout! Resetting card. ALLOCFID=0123, TXCOMPLFID=029d, EVSTAT=808b |
| 21:58.36 | paul | eth0: Error -110 writing packet header to BAP |
| 21:58.36 | paul | NETDEV WATCHDOG: eth0: transmit timed out |
| 21:58.37 | paul | eth0: Tx timeout! Resetting card. ALLOCFID=0123, TXCOMPLFID=014d, EVSTAT=808c |
| 21:58.41 | paul | eth0: Error -110 writing packet header to BAP |
| 21:58.43 | paul | eth0: Error -110 writing Tx descriptor to BAP |
| 21:58.45 | paul | eth0: Error -110 writing Tx descriptor to BAP |
| 21:59.02 | paul | with hostap_cs: |
| 21:59.03 | paul | prism2_hw_init() |
| 21:59.03 | paul | prism2_hw_config: initialized in 17056 iterations |
| 21:59.03 | paul | prism2_tx_timeout: wake up queue |
| 21:59.05 | paul | wlan0: hfa384x_cmd: command was not completed (res=0, entry=c1c114a0, type=0, cmd=0x0021, param0=0xfd43) |
| 21:59.06 | mallum | pb_: did you get a chance to look at the reset tslib problem ? |
| 21:59.07 | paul | wlan0: hfa384x_get_rid: CMDCODE_ACCESS failed (res=-110, rid=fd43, len=6) |
| 22:00.02 | pb_ | mallum: could you break up your ipks in the same way as the .debs, so there are separate libdbus0 and libdbus-glib0 packages? |
| 22:00.04 | pb_ | mallum: no, not yet. |
| 22:00.32 | florian | paul: this is really strange... i don't have my pcmcia jacket here to test, but i could do this tomorrow |
| 22:00.58 | florian | paul: how old is this card and what's the shape of the antenna? |
| 22:01.29 | paul | fairly new, bought it from dabs recently. prodid is: "D", "Link DWL-650 11Mbps WLAN Card", "Version 01.02", "" |
| 22:01.40 | mallum | pb_: sure, they were just quickly put togeather for some people that wanted to play with dbus on the ipaq |
| 22:02.19 | paul | antenna widens out and top side is curved. |
| 22:02.25 | paul | \^/ |
| 22:02.42 | pb_ | mallum: great. |
| 22:03.25 | florian | paul: ok, you don't have one of this new 650 with a different chipset... |
| 22:03.44 | paul | florian: no its not the 22Mbs 650+ |
| 22:04.13 | mallum | pb_: its difficult for me to debug the tslib until I get networking on my c700 |
| 22:04.25 | pb_ | mallum: do you not have an ipaq you can debug it on? |
| 22:04.26 | jg_ | mallum: pong |
| 22:05.09 | florian | paul: there are new 11Mbit cards called "650" (without +) with an unsupported chipset too :-( |
| 22:05.16 | paul | hmm.. |
| 22:05.35 | mallum | pb_: I have my 3600, but that needs a reflash and I've orderd a cf wlan card for the c700 which hopefully should get here tommorow :) |
| 22:05.40 | mallum | jg_: hey |
| 22:06.19 | mallum | jg_: do you know if when an XServer resets itself it clears env vars ? |
| 22:06.24 | paul | florian: its definitely prism2, works with the wlan-ng prism2_cs driver. a second card (bought exact same time, serial number is something like +3 or so from this one) is working fine in an i386 with prism2_cs. |
| 22:06.44 | jg_ | mallum: I'd be surprised. |
| 22:07.37 | mallum | jg_: tslib seems to get messed up after a server reset :( |
| 22:08.09 | jg_ | mallum: server does attempt to close everything, and reopen all files/fd's. |
| 22:08.44 | mallum | jg_: yeah I think tslib may be getting confused with the open/close/open for some reason |
| 22:09.17 | florian | paul: ok, i'll check how the 650s work tomorrow - i think i have access to at least four of them :-) |
| 22:09.24 | paul | woohoo |
| 22:09.33 | mallum | jg_: btw, there are very experimental 4.3 packages at http://handhelds.org/~mallum/xpkgs |
| 22:09.33 | florian | paul: if i forget - just remind me! |
| 22:09.50 | paul | florian: i have to remind you about the guest house booking too :) |
| 22:10.40 | jg_ | mallum: if you send me mail, I'll take them for a test drive tomorrow. |
| 22:10.43 | florian | paul: ahh, yes - at the moment i still have it in mind :-) |
| 22:11.21 | paul | florian: if i knew what the ioctl was that is failling for wlancfg-ng and iwconfig with prism2_cs i might stand a chance of getting somewhere. |
| 22:11.53 | mallum | jg_: wha ? am I your PA ? |
| 22:11.57 | mallum | ;-) |
| 22:12.39 | jg_ | mallum: I'll forget the URL by tomorrow.... |
| 22:12.40 | paul | florian: aha.. and the one time the transfer did go fast it must have gone over usb: |
| 22:12.44 | paul | default via 192.168.0.3 dev wlan0 |
| 22:12.44 | paul | default via 192.168.226.201 dev usbf |
| 22:15.14 | florian | oops.. |
| 22:15.51 | pb_ | paul: what's the ioctl number that you are having trouble with? |
| 22:16.54 | paul | pb_: ioctl(3, 0x8b1a, 0xbffffd14) |
| 22:17.00 | paul | and.. ioctl(3, 0x89f1, 0xbfffed78) |
| 22:17.10 | paul | in both cases the fd is: |
| 22:17.10 | pb_ | paul: the first one is SIOCSIWESSID |
| 22:17.15 | paul | socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 |
| 22:17.19 | paul | ok. |
| 22:17.35 | jg_ | pb_: thanks for the spec... |
| 22:17.50 | pb_ | paul: not so sure about the second one, it's not in the normal wireless range. |
| 22:18.05 | pb_ | paul: oh, it's one of the SIOCDEVPRIVATE ioctls. |
| 22:18.24 | paul | pb_: that'd sort of make sense, first one is iwconfig trying to set essid on a wlan-ng device. the second one is wlanctl-ng |
| 22:18.33 | jg_ | pb_: should go to the freedesktop.org mailng list soon.... |
| 22:18.36 | pb_ | jg_: sure, let me know what you think of it. |
| 22:18.46 | pb_ | jg_: yeah, probably a good idea. |
| 22:19.09 | pb_ | next I should write a description of the GPE interactive help protocol. |
| 22:19.16 | pb_ | paul: ah right. |
| 22:19.45 | jg_ | pb_: should probably be an extensible scheme, in some form. |
| 22:20.13 | jg_ | pb_: the interesting question is should we also try to deal with replication? |
| 22:20.15 | paul | florian: cardctl config on the ipaq (where card works very badly) and on i386 laptop (where's its fine): Vcc 3.3V Vpp1 0.0V Vpp2 0.0V - in both cases. |
| 22:21.08 | pb_ | jg_: what do you mean by replication, exactly? |
| 22:21.22 | jg_ | pb_: the migration control program presumably can decide whether to migrate some or all of an app..... |
| 22:21.46 | jg_ | pb_: e.g. emacs, which can have windows open on multiple displays simultaneously. |
| 22:22.21 | jg_ | (replicated apps may load some other UI for different res screens). |
| 22:22.27 | pb_ | jg_: yes. Our current implementation just migrates one window at a time, but it could be taught to figure out which windows form a group and move them all at once. |
| 22:23.49 | pb_ | jg_: alternatively, we could add a flag to the protocol to say "move this window, and all the windows in its group", which is conceptually perhaps less elegant, but easier in terms of implementation. |
| 22:24.38 | jg_ | pb_: should add this to the open questions section.... |
| 22:25.52 | pb_ | jg_: this is more or less what I meant by the "should all windows owned by one application be migrated together?" question that is there already, but perhaps it could use some rephrasing. |
| 22:26.45 | mallum | pb_: could I maybe have a look at it too, especially as I wrote the original .... ? |
| 22:27.06 | pb_ | mallum: it's in CVS; I don't think it's changed appreciably since the last one you saw. |
| 22:27.13 | pb_ | gpe/base/libdm/spec.txt |
| 22:27.41 | mallum | pb_: okey cool |
| 22:32.12 | florian | night all! |
| 22:32.20 | pb_ | florian: night |
| 22:32.52 | mallum | pb_: looks good |
| 22:33.51 | mallum | pb_: I would maybe add that an application should not attenpt to change _GPE_DISPLAY_CHANGE if it is non zero |
| 22:34.23 | pb_ | yes, that's probably a good idea. |
| 22:34.44 | mallum | pb_: and also say that the auth is for actually allowing the migration and not the connection to the alternate display |
| 22:36.15 | pb_ | yup, can't hurt I guess. |
| 22:37.01 | pb_ | I suppose I ought to add some more remarks on how the challenge string is handled as well. |
| 22:38.05 | pb_ | It's always a bit difficult to know where to draw the line between specification and implementation detail. |
| 22:41.55 | mallum | pb_: yeah definetly |
| 22:42.36 | mallum | pb_: I dont know if its worth thinks about things like multicasting apps |
| 22:42.57 | mallum | pb_: I guess that kind of thing is best done with a special proxy anyway |
| 22:43.04 | mallum | eek! 24 time !!! |
| 22:48.59 | cmarqu | Night. |
| 22:49.45 | pb_ | cmarqu: Night. |
| 22:50.16 | pb_ | dc__: hm, gpe-gallery (at least in list-view mode) seems to have some kind of memory leak. It has swelled from 11MB to 22MB in the last couple of minutes on my ipaq. |
| 23:13.34 | paul | arg.. blinking wireless cards. (3, 4ish different drivers each supporting sort of the same mix of cards, each driver with its own quirks.. arg..) |
| 23:13.40 | paul | anyway. night. |
| 23:25.30 | dc__ | pb_: oh no! |
| 23:25.44 | pb_ | dc__: quite! |
| 23:27.06 | dc__ | pb_: any clues? |
| 23:27.21 | dc__ | hrm...missed 24, oh well. |
| 23:27.23 | pb_ | dc__: let me peruse the code. |
| 23:27.36 | dc__ | mallum_24: cold feet is better ;p |
| 23:28.34 | dc__ | pb_: I'm minus one typing finger now, I managed to seriously burn it when a whole in the cook gloves was found.. |
| 23:28.40 | pb_ | dc__: hm, you leak pango_title_layout, but I doubt that can account for the degree of memory usage. |
| 23:28.43 | dc__ | the skin has started coming off :{ |
| 23:28.44 | pb_ | dc__: ouch, nasty. |
| 23:28.49 | dc__ | not cool. |
| 23:29.09 | pb_ | indeed. :-( |
| 23:29.10 | *** join/#gpe ade|indy (~adrian@unimatrix.ex.ac.uk) |
| 23:29.35 | dc__ | omfg...I have some bad problem with spelling on irc. |
| 23:29.46 | dc__ | s/whole/hole/ |
| 23:29.50 | pb_ | :-} |
| 23:29.52 | pigeon | dc__: Most people do. :) |
| 23:30.06 | dc__ | pigeon: that's good to hear :} |
| 23:31.10 | pigeon | dc__: Because it's so cute to do so. |
| 23:31.17 | dc__ | pb_: so eh, how does it get leaked? |
| 23:31.17 | pb_ | dc__: hm, I can't see much wrong besides those pango layouts. |
| 23:31.20 | dc__ | pigeon: ! |
| 23:31.26 | pb_ | dc__: well, you allocate it like this: |
| 23:31.30 | pb_ | <PROTECTED> |
| 23:31.37 | pb_ | dc__: and don't ever free it as far as I can see. |
| 23:31.39 | dc__ | ah |
| 23:31.51 | dc__ | um so I should free it after rendering it right? |
| 23:31.53 | pb_ | same goes for pango_dimensions_layout, pango_size_layout, ... |
| 23:31.58 | pb_ | dc__: yeah |
| 23:32.12 | dc__ | g_free I'll assume |
| 23:32.14 | pb_ | after you've done the gdk_draw_layout, you don't need it any more. |
| 23:32.19 | pb_ | dc__: g_object_unref I think |
| 23:32.22 | dc__ | quite |
| 23:33.11 | pb_ | see e.g. gpe-todo/list-ui.c |
| 23:34.11 | dc__ | right |
| 23:34.31 | dc__ | I must seem really silly using such long varible names ;) |
| 23:34.52 | dc__ | but they make me happy |
| 23:34.59 | dc__ | so no one can complain =P |
| 23:35.10 | pb_ | If that's what it takes... |
| 23:35.26 | dc__ | well, it doesn't take much |
| 23:36.07 | dc__ | oh dear |
| 23:36.08 | pb_ | btw, scrolling would probably be faster if your expose routine inspected the area it was being asked to draw, and only rendered the items that fall within that area, rather than doing all of them every time. |
| 23:36.11 | dc__ | I see it growing! |
| 23:36.21 | pb_ | ! |
| 23:36.22 | dc__ | pb_: yes, I am aware of then |
| 23:36.54 | dc__ | I fear old pixmaps are being left around |
| 23:37.02 | pb_ | Oh dear. |
| 23:37.35 | dc__ | I guess I need to iter through my GList of loaded pixmaps and unref each one rather than just clearing the GList :} |
| 23:37.45 | pb_ | Ah, er, yes. |
| 23:38.44 | dc__ | but |
| 23:38.52 | dc__ | I'm losing the list. |
| 23:39.02 | dc__ | as it's only local to render_list_view |
| 23:39.43 | dc__ | hrm, do we know how the icon list handle it? |
| 23:39.51 | dc__ | s/handle/handles/ |
| 23:40.00 | pb_ | I believe it stashes the list of icons within its own object structure. |
| 23:40.09 | dc__ | ah okay |
| 23:41.36 | dc__ | so then, when the widget get destroyed they do aswell? |
| 23:41.50 | pb_ | Yeah, I think so. |
| 23:42.08 | dc__ | pb_: can I use a destroy callback? |
| 23:42.11 | dc__ | pb_: think that might work. |
| 23:42.40 | pb_ | dc__: well, mmm, you don't really have a widget that's being destroyed, do you? |
| 23:42.46 | dc__ | pb_: I do. |
| 23:42.51 | pb_ | Ah, okay. |
| 23:42.59 | dc__ | render_view () |
| 23:43.10 | dc__ | the view_widget is getting destroyed |
| 23:43.13 | pb_ | Ah, got it. |
| 23:43.20 | dc__ | so lets try |
| 23:43.21 | pb_ | In that case, yes, a destroy callback should work fine. |
| 23:47.04 | *** join/#gpe dc___ (~dc@62.60.118.77) |
| 23:47.19 | dc___ | hum |
| 23:48.16 | dc___ | it's not calling the callback for some reason |
| 23:48.36 | mallum | dc__: cold feet !!! |
| 23:48.43 | dc___ | mallum: doh |
| 23:48.52 | dc___ | mallum: you watch it too then ;)? |
| 23:49.24 | mallum | dc__: no way, it totally for girlsd |
| 23:49.40 | dc___ | bahhhhh |
| 23:49.41 | dc___ | hehe |
| 23:51.29 | mallum | 24 rulez |
| 23:52.44 | dc___ | indeed, it does.. |
| 23:53.17 | mallum | dc__: back to school tommorow ? |
