| 02:52:46 | gazer | looks in. |
| 03:35:42 | mibus | howdy everyone! |
| 03:53:58 | mibus | slaps his head VERY VERY hard as he released an appmgr version 0.9-2 not 0.09-2 as he'd thought |
| 03:54:07 | mibus | doh! |
| 04:01:55 | | dc_ was last seen on #gpe 1 days, 7 hours, 14 minutes and 40 seconds ago, saying: school work :/ [Fri Sep 20 21:47:15 2002] |
| 04:01:55 | mibus | ibot: seen dc_? |
| 04:02:22 | | mallum was last seen on #gpe 5 hours, 2 minutes and 11 seconds ago, saying: cool [Sun Sep 22 00:00:11 2002] |
| 04:02:22 | mibus | ibot: seen mallum? |
| 04:02:22 | | pb_ was last seen on #gpe 13 hours, 26 seconds ago, saying: cmarqu: try now. [Sat Sep 21 16:01:56 2002] |
| 04:02:22 | mibus | ibot: seen pb_? |
| 04:04:58 | | mibus: no idea |
| 04:04:58 | mibus | ibot: wassup? |
| 04:05:32 | | OK, mibus. |
| 04:05:32 | mibus | ibot: wassup is <reply>just chillin, $who... |
| 04:05:43 | | just chillin, mibus... |
| 04:05:43 | mibus | ibot: wassup? |
| 04:06:11 | mibus | lol |
| 04:06:15 | | it has been said that lol is a acronym that stands for Laugh Out Loud. Go to http://mankindvsme.50megs.com/windowsfan.html for more information. |
| 04:06:15 | mibus | ibot: lol |
| 04:13:27 | | mibus: i'm not following you... |
| 04:13:27 | mibus | ibot: convert 390eu to aud |
| 04:13:38 | | mibus: sorry... |
| 04:13:38 | mibus | ibot: gah |
| 04:14:33 | mibus | :P |
| 04:16:26 | | 'mibus' is 0% lame, mibus |
| 04:16:26 | mibus | ibot: nickometer mibus |
| 04:16:43 | | mibus: excuse me? |
| 04:16:43 | mibus | ibot: translate to german hello world |
| 04:17:26 | mibus | ibot: change 30 euro to aud |
| 04:17:35 | | mibus: 30.00 (Euro (EUR)) makes 53.9912 (Australia Dollar (AUD)) |
| 04:17:50 | mibus | ibot: change 190 euro to aud |
| 04:17:59 | | mibus: 190.00 (Euro (EUR)) makes 341.944 (Australia Dollar (AUD)) |
| 05:06:05 | mibus | is gonna go muck about for an hour or so |
| 05:06:12 | mibus | dont talk too much without me ;-) |
| 05:06:13 | mibus | :D |
| 06:55:36 | mibus | is astounded at the lack of conversation for the last 3+1/2 hours |
| 07:14:47 | mibus | hallo |
| 07:38:13 | mibus | goes and eats tea |
| 08:05:24 | mibus | ok bye! |
| 08:47:47 | dc_ | hey |
| 08:50:40 | pb_ | hey dc_ |
| 08:52:14 | dc_ | pb_: morning :D |
| 08:52:38 | pb_ | mibus just sent me his latest gpe-appmgr alpha to play with. |
| 08:52:44 | dc_ | w00t |
| 08:52:49 | dc_ | with a background image/ |
| 08:52:50 | dc_ | ? |
| 08:53:00 | pb_ | not sure yet, I haven't managed to make it compile. |
| 08:53:10 | pb_ | seems I broke libgpewidget sometime last week :-( |
| 08:53:14 | dc_ | ah hehe |
| 08:53:20 | dc_ | :/ |
| 08:53:30 | pigeon | yo dc_, pb_ |
| 08:53:38 | pb_ | hi pigeon |
| 08:53:43 | dc_ | ooooooh |
| 08:53:50 | dc_ | gpe-login wit a bg image :DD |
| 08:53:53 | dc_ | w00t |
| 08:53:55 | dc_ | pigeon: hey! |
| 08:54:05 | dc_ | nice image btw |
| 08:54:20 | pb_ | dc_: wow yeah, it does have a background image |
| 08:54:48 | pb_ | dc_: this new appmgr code rocks :-) |
| 08:54:53 | dc_ | looks very good indeed |
| 08:55:02 | dc_ | pb_: oh, take a scap :) |
| 08:55:27 | pb_ | dc_: ok, it'll take a minute for me to get it onto my ipaq (just running it on the desktop right now) |
| 08:55:42 | dc_ | cool |
| 08:55:49 | pb_ | dc_: and first I have to _find_ my ipaq, I think it's downstairs somewhere. |
| 08:56:47 | pb_ | dc_: yeah, the gpe-login background image was Colin's work |
| 08:57:18 | pb_ | dc_: it does look very nice. |
| 09:04:01 | pb_ | dc_: argh, I left the CF card with the gtk2 libs on at the office. |
| 09:04:09 | dc_ | ouch :{ |
| 09:04:14 | pb_ | dc_: so, no scap I'm afraid. |
| 09:04:38 | pb_ | dc_: I can forward you the mail if you want, I don't think mibus would mind. |
| 09:06:04 | dc_ | ah my email's down today :/ |
| 09:06:16 | pb_ | oh. :-( |
| 09:06:33 | dc_ | hrm |
| 09:06:44 | dc_ | that's not cool, rootme won't wor on my iPAQ ... |
| 09:06:47 | dc_ | work... |
| 09:07:09 | pb_ | ha, locked out of your own machine? |
| 09:07:10 | dc_ | ahh |
| 09:07:13 | dc_ | that's better ;[ |
| 09:07:14 | dc_ | ;] |
| 09:07:25 | dc_ | wrong ip, I was doing 101 instead of 100 |
| 09:07:36 | dc_ | wtf.. |
| 09:07:36 | pb_ | heh. |
| 09:07:56 | dc_ | hrm |
| 09:07:57 | dc_ | no. |
| 09:08:28 | | ssh-keygen is something you need to run to setup my ipaq's host keys. To do this run the following on my ipaq:'/usr/bin/ssh-keygen -b 1024 -f /etc/ssh/ssh_host_key -N ""' and '/usr/bin/ssh-keygen -d -f /etc/ssh/ssh_host_dsa_key -N ""' |
| 09:08:28 | dc_ | ibot ssh-keygen |
| 09:10:54 | dc_ | hum |
| 09:11:01 | dc_ | wat ssh key type do I want... |
| 09:11:02 | dc_ | ssh1? |
| 09:11:18 | dc_ | rm |
| 09:11:19 | dc_ | hrm |
| 09:11:59 | dc_ | rsa1 :] |
| 09:12:27 | pb_ | yeah, rsa should be ok. |
| 09:12:32 | pb_ | I think the default for ssh2 is dsa. |
| 09:24:49 | wizly | hi |
| 09:27:17 | dc_ | hey |
| 09:27:38 | wizly | hi dc_ |
| 09:27:38 | wizly | :) |
| 09:31:05 | dc_ | hrm |
| 09:31:11 | dc_ | it wont load my amn host keys... |
| 09:31:16 | dc_ | danm... |
| 09:31:21 | dc_ | damn.. |
| 09:31:28 | wizly | eH? |
| 09:32:17 | hagbard3 | what webbrowser do u use? |
| 09:32:25 | dc_ | ... |
| 09:32:57 | pb_ | dc_: what's its complaint about the host keys? |
| 09:33:29 | dc_ | pb_: cannot load host key /etc/ssh/ssh_host_key |
| 09:33:35 | pb_ | dc_: does that file exist? |
| 09:33:41 | dc_ | pb_: I made that one with ssh-keygen -t rsa1 |
| 09:34:10 | dc_ | yep |
| 09:34:12 | pb_ | dc_: mmm, should be ok. |
| 09:34:22 | pb_ | dc_: what does it look like? |
| 09:34:56 | dc_ | err... |
| 09:35:08 | dc_ | SSH PRIVATE KEY FILE FORMAT 1.1 |
| 09:35:13 | dc_ | then some rubish |
| 09:35:13 | wizly | hi again |
| 09:35:18 | pb_ | dc_: that looks about right. |
| 09:35:24 | pb_ | dc_: it's some inscrutable binary format. :-/ |
| 09:35:31 | dc_ | it seems |
| 09:35:46 | pb_ | dc_: weird, I wonder why it won't load. |
| 09:38:39 | dc_ | me to.. |
| 09:40:48 | dc_ | hrm |
| 09:40:50 | dc_ | anyway |
| 09:40:51 | dc_ | bbl |
| 11:28:26 | hagbard3 | Configuring dillo...pkg_run_script: `/usr/lib/ipkg/info/dillo.postinst configure' failed: I |
| 11:28:26 | hagbard3 | llegal seek. |
| 11:28:26 | hagbard3 | ERROR: dillo.postinst returned 1 |
| 11:30:37 | pb_ | What happens if you run update-menus manually? |
| 11:36:47 | hagbard3 | i dont even have that command... all i did was getting the familiar bootstrap root image with gpe and the ipkg install gpe |
| 11:36:55 | hagbard3 | to update gpe |
| 11:37:05 | hagbard3 | i dont have the update-menus binary |
| 11:38:13 | pb_ | ah, ok, that would be the problem then. |
| 11:38:20 | pb_ | either ignore the error, or ipkg install update-menus. |
| 11:41:54 | hagbard3 | ok |
| 11:45:22 | hagbard3 | update-menus |
| 11:45:22 | hagbard3 | kill: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or |
| 11:45:22 | hagbard3 | kill -l [exitstatus] |
| 11:46:51 | hagbard3 | i guess it should spew to the user that there are no argument? |
| 11:47:59 | pb_ | That's a bug in one or other of the menu programs that you have installed. |
| 11:48:08 | pb_ | ie gpe-appmgr, mmenu or something like that. |
| 11:49:44 | hagbard3 | ic |
| 12:19:39 | hagbard3 | how do i add a proxy to dillo? |
| 12:20:34 | pb_ | Put an http_proxy line in your dillorc. |
| 12:21:47 | hagbard3 | ok |
| 12:25:22 | hagbard3 | how do i change the font in terminal? |
| 12:25:25 | colin_ | Eeek. My DSL is b0rked. |
| 12:42:29 | colin__ | Argh. |
| 12:49:52 | pb_ | colin__: Hell! |
| 12:50:28 | colin__ | Yeah... |
| 12:50:39 | colin__ | Will have to go offline till the meeting. |
| 12:50:53 | pb_ | Okay. Talk to you later, then. |
| 12:51:04 | colin__ | And then pay-per-minute, unless my DSL sync recovers... |
| 12:51:16 | pb_ | :-} |
| 12:51:29 | colin__ | pb_: Could you write another reminder to the list? |
| 12:51:37 | pb_ | Sure thing. |
| 12:51:38 | colin__ | Mine didn't get out... |
| 12:51:43 | colin__ | Thx. |
| 12:51:54 | pb_ | I think most people are aware, though. Mibus says he plans to get up at 4am so he can join in :-) |
| 12:51:54 | colin__ | Oh, and while i'm still online... |
| 12:52:02 | colin__ | Yep :) |
| 12:52:28 | colin__ | How would I make the gpe login background easily customizable? |
| 12:52:36 | colin__ | (btw, did you see the scaps?) |
| 12:52:45 | pb_ | Yeah, the scaps look really cool. |
| 12:52:49 | colin__ | Call 'gpe-setbg /etc/gpe/gpe-login-bg.png' in |
| 12:52:49 | colin__ | /etc/X11/gpe-login.setup, where gpe-login-bg.png is a symlink to |
| 12:52:49 | colin__ | /usr/share/pixmaps/gpe-default-bg.png, and gpe-conf will just set a |
| 12:52:49 | colin__ | different symlink when the user wants a different image? Remove the |
| 12:52:49 | colin__ | file (or leave a dangling symlink) if no bg image is wanted, |
| 12:52:51 | colin__ | gpe-login.setup will fall back to the bg color. |
| 12:53:08 | pb_ | Sounds reasonable to me, yeah. |
| 12:53:14 | colin__ | That's what I came up with, but there might be better ways... |
| 12:53:33 | pb_ | Well, I think that will do for now. We can always refine it later if someone has a better plan. |
| 12:53:40 | colin__ | Okay. |
| 12:54:40 | colin__ | We have election today, so maybe they cut my DSL because I elected the wrong ones! :) |
| 12:55:01 | pb_ | colin__: Yeah, the German election has been in the news a lot over here. |
| 12:55:08 | colin__ | Ah. |
| 12:55:35 | colin__ | Well, going off for now. BBL |
| 12:55:38 | pb_ | Okay. |
| 13:19:03 | hagbard3 | when i click to times fast at two different location it behaves like there was a double-click, shouldnt that be region specific? |
| 13:19:10 | hagbard3 | s/to/two |
| 13:25:48 | hagbard3 | you have to double-click to enter a directory, but if you click the first click on one directory and the 2nd on another it behaves like the dblclk was on the 2nd |
| 13:26:02 | hagbard3 | its the open-dialog box in gpe's texteditor |
| 13:40:12 | ade | is the thing at 19:00 still on ? |
| 13:41:13 | pb_ | Yes. See the note I sent to the mailing list about 45 minutes ago. |
| 13:41:18 | pb_ | It's 20:00 British time, though. |
| 13:42:17 | ade | just as monarch of the glenn is on .. doh . have to set the video |
| 13:42:49 | pb_ | heh. |
| 14:25:03 | MarkMorga | hello ppl |
| 14:25:16 | MarkMorga | can someone please help me out in installing gpe on my zaurus |
| 14:25:19 | MarkMorga | i just got it |
| 14:28:57 | pb_ | What do you have installed on the Zaurus at the moment? |
| 14:29:38 | MarkMorga | pb - thanks |
| 14:29:43 | MarkMorga | ive got nothing installed |
| 14:29:45 | MarkMorga | just got it |
| 14:29:51 | MarkMorga | so it has the standard qtopia setup |
| 14:31:03 | MarkMorga | hello ?? |
| 14:31:16 | pb_ | hmm, right. |
| 14:31:27 | pb_ | The easiest way to install GPE is as part of Familiar. |
| 14:31:48 | pb_ | So, I guess the first thing for you to do is go over to #handhelds.org or #familiar, and see if you can find someone to help you install the base system. |
| 14:32:01 | MarkMorga | ok thanks |
| 14:32:20 | MarkMorga | before i embark on this though pb...do i need a memory expansion - beacuse i dont have one as yeyt |
| 14:32:30 | pb_ | I don't think so. |
| 14:32:46 | pb_ | You can run GPE on an ipaq with 16MB flash and 32MB ram, presumably your zaurus has at least that much? |
| 14:33:06 | MarkMorga | yes it does :) |
| 14:33:20 | MarkMorga | ok i'll ask if someone can help me install the base system... |
| 14:33:25 | MarkMorga | how long does it usually take ? |
| 14:34:32 | pb_ | Well, you have to download a big file over a serial line. Maybe 15 minutes if you know what you're doing. |
| 14:35:02 | pb_ | If it's the first time you've done it, perhaps a little longer. |
| 14:35:24 | MarkMorga | pb - do you know the name of the file - sorry to ask. but not getting much response at handhelds.org |
| 14:35:45 | MarkMorga | hey are you philip blundell from cambridge?? |
| 14:37:07 | MarkMorga | hello ?? |
| 14:38:30 | pb_ | yes, that's me. |
| 14:38:36 | MarkMorga | pleased to meet you |
| 14:38:44 | MarkMorga | Im Mark Morgan - Im from London |
| 14:38:48 | pb_ | well, I know the name of the jffs file, but I don't have a clue how you make it work with the zaurus bootloader. |
| 14:38:55 | MarkMorga | i just saw your name on the site |
| 14:39:00 | pb_ | aha :-) |
| 14:39:23 | pb_ | I think there might be a #zaurus channel as well, you could see if anybody in there knows. |
| 14:39:51 | MarkMorga | cheers...i tried...but no luck |
| 14:40:00 | MarkMorga | do you have the link or the name of this jffs file ? |
| 14:40:39 | pb_ | let me look, one moment |
| 14:41:42 | MarkMorga | thanks ever so much :) |
| 14:42:13 | pb_ | ftp.handhelds.org:familiar/releases/v0.6-rc1/install/H3600/bootgpe-v06-12-h3100.jffs2, I think. |
| 14:45:00 | MarkMorga | thanks :) |
| 14:45:14 | MarkMorga | once i get it..where should i look for instructions |
| 14:46:29 | pb_ | well, there is an installation guide on the familiar web site. |
| 14:46:44 | pb_ | beyond that, I don't know. Maybe there is something on one of the zaurus sites. |
| 14:46:56 | MarkMorga | thanks philip |
| 14:47:05 | MarkMorga | and then, i download gpe ? |
| 14:47:14 | pb_ | yeah, "ipkg install gpe" |
| 14:47:14 | MarkMorga | it seems to be load of little programs |
| 14:47:29 | MarkMorga | hang on ...once ive dloaded the file youve told me |
| 14:47:32 | pb_ | The "gpe" metapackage will get you everything. |
| 14:47:33 | pb_ | Yes. |
| 14:47:38 | MarkMorga | tp.handhelds.org:familiar/releases/v0.6-rc1/install/H3600/bootgpe-v06-12-h3100.jffs2 |
| 14:47:54 | pb_ | bootgpe is the bootstrap image, it contains a minimal system. |
| 14:47:56 | MarkMorga | do i need to dl anything else ?? |
| 14:47:59 | MarkMorga | sorry |
| 14:48:10 | MarkMorga | ok so i install bootgpe;...then i need to dl something else |
| 14:48:17 | MarkMorga | remember my zaurus doesnt have internet acxcess |
| 14:48:18 | MarkMorga | access |
| 14:49:24 | Ksso_Vodka | pow! |
| 14:50:59 | pb_ | well, you can download the files and copy them to the zaurus individually, but it would be much easier if you could arrange an internet connection for the zaurus. |
| 14:51:07 | pb_ | anyway, you can worry about that once you have the bootstrap image installed. |
| 14:51:56 | MarkMorga | thanks for your help philip..im going to try it in a few moments |
| 14:52:15 | ade | does the h3100 image do ipaq h3100 monochrome ipaq |
| 14:54:03 | pb_ | yes, the h3100 monochrome ipaq image is for h3100 monochrome ipaqs, if that's what you're asking. |
| 14:56:23 | ade | just wondering why you directed markmorga to a 3100 image , thats all |
| 14:56:38 | MarkMorga | i was gonna ask... |
| 14:56:43 | MarkMorga | isnt this for the ipaq ??? |
| 14:57:57 | ade | if you try the opie lot , they might get you to the base familiar install easily but ingnore the opie install part and ipkg task-gpe instead |
| 14:58:07 | ade | #opie btw |
| 14:58:26 | MarkMorga | thanks ade |
| 14:59:16 | ade_ | grr i hate 2hour dial-up |
| 15:00:31 | pb_ | the 3100 image will work on any machine, from what I remember. |
| 15:00:39 | MarkMorga | ade...bt ?? |
| 15:00:43 | pb_ | maybe the 3600 image would work on the zaurus too, for that matter, I dunno. |
| 15:01:14 | ade_ | freeserve |
| 15:01:38 | MarkMorga | oh ok |
| 15:02:33 | Ksso_Vodka | pb_: isn't the zaurus xscale? |
| 15:02:55 | Ksso_Vodka | is the instrucion set compatible ? |
| 15:02:56 | ade_ | hell no |
| 15:03:19 | ade_ | zaurus is very sa1110 |
| 15:03:33 | Ksso_Vodka | hummm |
| 15:03:40 | Ksso_Vodka | chotto matte |
| 15:03:47 | ade_ | unless they have updated it |
| 15:04:08 | Ksso_Vodka | http://www.sofmap.com/shop/product/tanpin.asp?PRDT_ID=1371342 |
| 15:04:09 | Ksso_Vodka | check this out man |
| 15:04:23 | Ksso_Vodka | that's the only one i found with linux inside out of the box |
| 15:04:38 | Ksso_Vodka | xscale 200mhz |
| 15:04:49 | Ksso_Vodka | i don't know about european models |
| 15:05:09 | ade_ | thats the new a300 :) |
| 15:05:43 | Ksso_Vodka | i got a mi-l1 myself |
| 15:05:54 | Ksso_Vodka | but it's not under linux at all |
| 15:06:09 | Ksso_Vodka | it has a strange proprietary os |
| 15:06:25 | Ksso_Vodka | all injapanese plenty of fxxxing kanjis :p |
| 15:07:07 | ade_ | the sl5000 is sa1110 and linux with qtopia |
| 15:07:24 | Ksso_Vodka | k |
| 15:07:28 | pb_ | the xscale instruction set is compatible, as it happens, so everything bar the kernel ought to work anyway. |
| 15:07:37 | pb_ | pretty much the same situation as ipaq vs zaurus. |
| 15:07:40 | Ksso_Vodka | i didn't find those one here .. |
| 15:08:14 | Ksso_Vodka | pb_: would it be why ppc2002 has trouble with xscale ? |
| 15:08:21 | Ksso_Vodka | they didnt recompile it ? :p |
| 15:08:22 | pb_ | I have no idea. |
| 15:08:44 | ade_ | the 3900 work ok dont they ? |
| 15:08:59 | pb_ | from what I hear, yes. |
| 15:09:58 | ade_ | advise never put a debian 'packages' in IE6, it can't open a 6mb text file |
| 15:10:09 | Ksso_Vodka | ;) |
| 15:10:11 | ade_ | and IE6 cops out |
| 15:10:18 | Ksso_Vodka | lol |
| 15:10:31 | Ksso_Vodka | happens with galeon to you know :p |
| 15:10:41 | Ksso_Vodka | unless it is properly configured :p |
| 15:11:24 | ade_ | all i want to do is find out what version gcc/glibc/binutils are on debian mipsel/unstable |
| 15:11:42 | pb_ | libc6 | 2.2.5-14.3 | unstable | arm, hppa, i386, m68k, mips, mipsel, powerpc, s390, sparc |
| 15:11:51 | pb_ | binutils | 2.13.90.0.4-1 | unstable | source, alpha, arm, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc |
| 15:12:03 | pb_ | gcc | 2:2.95.4-17 | unstable | alpha, arm, i386, m68k, mips, mipsel, powerpc, s390, sparc |
| 15:12:31 | ade_ | is there gcc3 on mipsel |
| 15:12:43 | pb_ | gcc-3.2 | 1:3.2.1-0pre2 | unstable | alpha, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc |
| 15:12:43 | pb_ | |
| 15:12:49 | ade_ | many thanks pb_ |
| 15:14:03 | ade_ | guess i'll download the diffs and start the cross-toolchain building |
| 15:14:13 | ade_ | ho hum |
| 15:20:35 | Ksso_Vodka | hummm what about ipaq h39xx... does familiar/gpe work out f the box on them ? |
| 15:21:42 | ade_ | dont think so yet, nearly |
| 15:22:55 | Ksso_Vodka | humm ;) |
| 15:23:24 | Ksso_Vodka | maybe before i get one;) |
| 15:32:36 | ade_ | i'd like to have an ipaq with more than 16mb flash :( more ram would be good too |
| 15:33:10 | Ksso_Vodka | yeah!!! |
| 15:33:19 | Ksso_Vodka | i got a 3630 with 16mb flash |
| 15:33:23 | Ksso_Vodka | it's a pain... |
| 15:33:38 | ade_ | has a 3630 too |
| 15:34:05 | Ksso_Vodka | shit happens man |
| 15:34:34 | ade_ | when gpe moves to gtk2 and xlibs are changed things won't be so tight , hopefully |
| 15:35:05 | ade_ | having apps on cf is a pain |
| 15:35:07 | Ksso_Vodka | ;) |
| 15:35:12 | Ksso_Vodka | yep |
| 15:35:14 | Ksso_Vodka | i know |
| 15:36:17 | ade_ | pb_: your mission, should you choose to accept it, is to port everything to gtk2 by 19:00 GMT for testing ;) |
| 15:36:49 | Ksso_Vodka | lol |
| 15:37:03 | ade_ | worth a go |
| 15:37:15 | Ksso_Vodka | btw do you have a cross compilation toolchain ? |
| 15:37:22 | Ksso_Vodka | or do you use skiffcluster? |
| 15:37:43 | ade_ | i use intimate for compiles |
| 15:37:50 | Ksso_Vodka | k |
| 15:38:05 | Ksso_Vodka | got it on a cf ? |
| 15:38:18 | Ksso_Vodka | 128mb is enough for the toolchain ? |
| 15:38:19 | ade_ | but need to make a new mipsel toolchain and i guess i'll do an arm one too while i'm at it :) |
| 15:38:30 | Ksso_Vodka | ;) |
| 15:38:32 | ade_ | i nfs it |
| 15:38:39 | Ksso_Vodka | ok |
| 15:38:42 | Ksso_Vodka | i prefer that |
| 15:38:43 | Ksso_Vodka | ;) |
| 15:38:59 | Ksso_Vodka | wireless lan ? |
| 15:39:21 | ade_ | i wish |
| 15:39:31 | Ksso_Vodka | lol |
| 15:39:33 | Ksso_Vodka | ppp ? |
| 15:39:39 | ade_ | over the top with 100mbit nic |
| 15:39:58 | ade_ | ok its 100mbit , runs at 20mbit really |
| 15:40:16 | Ksso_Vodka | ;) |
| 15:40:21 | ade_ | so my switch reports |
| 15:40:39 | ade_ | i like telneting into my switch , its fun |
| 15:40:54 | ade_ | never had one with a serial port on before |
| 15:41:18 | ade_ | suddenly realises how sad he really is |
| 15:41:23 | Ksso_Vodka | ;) |
| 15:41:26 | Ksso_Vodka | loool |
| 15:42:02 | Ksso_Vodka | dcc a nice cisco lego game : router do it yourself |
| 15:42:43 | ade_ | lol |
| 16:12:25 | pb_ | hey dc_ |
| 16:17:06 | colin_ | Hi |
| 16:17:11 | pb_ | hi colin_ |
| 16:17:45 | ade_ | hi |
| 16:18:11 | colin_ | nils not here yet, huh? :) |
| 16:18:37 | ade_ | i feel sorry for the .au peeps :( |
| 16:18:45 | pb_ | Not yet. There's a kind of expectant atmosphere though, the crowd are on the edge of their seats. |
| 16:19:02 | colin_ | So am I :) |
| 16:19:26 | ade_ | falls off his chair .... sdhsdlfkjghsdk f |
| 16:20:07 | pb_ | Of course, we don't know what nick Nils will use. So it's possible he's been here for some time, unnoticed, and he'll just "de-cloak" in dramatic fashion at 1900 hours. |
| 16:20:30 | colin_ | Oh right. Now that would be a stunt. |
| 16:21:24 | ade_ | poke each #gpe member and see what ip they return |
| 16:23:00 | colin_ | Actually, I myself am nils. |
| 16:23:08 | pb_ | No! |
| 16:23:19 | colin_ | Now go and delete all your GTK2 apps! |
| 16:23:32 | pb_ | Crumbs, you really _are_ Nils! |
| 16:23:51 | ade_ | rm -rf cvs |
| 16:23:58 | nils | ! |
| 16:24:15 | colin_ | I want my DSL back... |
| 16:27:40 | colin_ | Well, going off again, BB in 85 mins |
| 16:28:27 | pb_ | Gosh, the tension is almost too much. |
| 16:29:15 | ade_ | pb_: go have a drink to calm the nerves |
| 16:29:33 | pb_ | I should probably go and do some more digging in the garden instead. |
| 16:29:54 | ade_ | bit cold now |
| 16:30:03 | pb_ | It's quite warm here today actually. |
| 16:30:08 | ade_ | guess you would soon warm up |
| 16:30:18 | ade_ | in cambs |
| 16:30:21 | pb_ | yeah. |
| 16:30:31 | ade_ | norfolk's bloody cold |
| 16:30:38 | ade_ | sunny but cold |
| 16:30:55 | ade_ | must be the extra miles north :) |
| 16:31:10 | pb_ | indeed :-) |
| 16:34:34 | ade_ | time to set the video recorder |
| 16:35:40 | mallum | hey |
| 16:40:04 | gazer | looks in. |
| 16:42:01 | ade_ | time left to download gcc3.2 ..17 hours 14 mins ... hmmm fun |
| 16:42:54 | gazer | the alarm meeting thing is in an hour, right? |
| 16:43:19 | ade_ | 1 hour 10 |
| 16:44:11 | gazer | ade_: cool. Just making sure that my GMT -> EDT calculation was correct. |
| 16:44:31 | ade_ | it is :) |
| 16:45:36 | Jacmet | ade_ ;) |
| 16:46:13 | Jacmet | ade_: I crosscompiled gcc 3.2 the other day - it takes quite some time ;) |
| 16:46:29 | ade_ | what host/target ? |
| 16:46:41 | gazer | I wonder if anyone has had any luck cross compiling gcc for OSX? I've only managed it on my linux box. |
| 16:46:46 | Jacmet | ade_: i386 -> armv4l (ipaq) |
| 16:47:12 | Jacmet | ade_: I used the debian toolchain-source package, so I created .deb files of it |
| 16:47:37 | ade_ | if i get bored in a couple of weeks i might try arm4l --> i386 for a laugh |
| 16:47:49 | Jacmet | ade_: heh |
| 16:48:36 | ade_ | gazer: if i had a mac to try it on, i'd have a go , but alas ... |
| 16:49:02 | ade_ | Jacmet: is the deb toolchain-source good then ? |
| 16:49:24 | gazer | I've tried it, maybe not 3.2, but 3.1, and it failed with syntax errors. |
| 16:49:32 | gazer | I'm probably not using the proper incantations ... :) |
| 16:49:48 | ade_ | what do you fall out with, unstable current gcc/glibc/binutils |
| 16:50:06 | gazer | the actual compilation of gcc, the compilation of binutils worked fine. |
| 16:50:10 | Jacmet | ade_: I had some problems first - but that's just because I didn't RTFM ;) |
| 16:50:33 | mallum | gazer: have you built a x86 -> powerpc gcc ? |
| 16:50:39 | gazer | no. |
| 16:50:57 | gazer | I have a powerpc (darwin) gcc already installed. |
| 16:51:00 | ade_ | never read the damn things |
| 16:51:09 | Jacmet | I forgot to install libc for the target (tpkg-install-libc arm-linux) |
| 16:51:26 | ade_ | whoops |
| 16:51:34 | Jacmet | after that it worked fine |
| 16:51:51 | Jacmet | gazer: I still have the debs - do you want a copy? |
| 16:52:01 | gazer | debs aren't going to help me ... :) |
| 16:52:16 | gazer | I have a working cross compiler on my linux box, just not on my laptop (which is OSX 10.2) |
| 16:52:32 | ade_ | i really must make an arm xcompiler , speed it up over native |
| 16:52:56 | gazer | ade_: the prepackaged one on handhelds.org worked for me out of the box. |
| 16:53:15 | Jacmet | gazer: ohh ok |
| 16:54:21 | ade_ | wish debian did a binary cross compilers rather than the source built it local way. would make life easy |
| 16:54:35 | gazer | I'll probably try to get it working this week. It would stink to not have a devel platform with me at the devel weekend. |
| 16:54:57 | gazer | ade_: http://handhelds.org/z/wiki/GpeCrossCompilation |
| 16:55:08 | gazer | (those are my notes on making a cross compilation environment work) |
| 16:55:11 | ade_ | guess debian don't want people to cross compile : do it native and make your machine a buildd |
| 16:55:48 | ade_ | k ta gazer |
| 16:56:33 | gazer | ade_: let me know if you have luck with it. |
| 16:57:25 | ade_ | will try over the next week or so, am going back to uni soon so need to pack pcs up and move. |
| 16:57:40 | Jacmet | ade_: the reason is afaik that it's just much easier to have a single toolchain-source package than having to keep a bunch of crosscompile debs in the distribution for all the platforms |
| 16:58:25 | ade_ | indeed it is, i am just lasy and want the debian autobuilders to do it for me :) |
| 16:58:30 | gazer | ade_: cool. |
| 16:59:44 | Jacmet | ade_ ;) |
| 17:00:57 | ade | anyone want to give me a new pc with more ram and a modern cpu ? |
| 17:01:35 | ade | doh: worth a go :( |
| 17:02:04 | ade | 50mins to go... tension rising |
| 17:05:24 | pb_ | hi mallum |
| 17:07:07 | mallum | hey pb_ |
| 17:09:20 | ade | is away: coffee breck |
| 17:12:20 | florian_ | Hello! |
| 17:28:34 | ade | is back |
| 17:29:18 | BBrox | [OT] any C++ low level experts here :-) ? |
| 17:30:27 | Jacmet | BBrox: expert would probably be stretching the truth quite a bit, but... ;) |
| 17:30:43 | ade | surely C++ and low level is a contradition in terms ;) |
| 17:31:07 | Jacmet | ade: why? |
| 17:32:08 | BBrox | Well, wanted to know how multiple inheritance works at the VTBL level :-) |
| 17:33:01 | ade | Jacmet: using c++ at low level is not really c++ anymore its so similar to c surely |
| 17:33:22 | BBrox | ade: I do not want to use C++ at a low level, I want to know how C++ works at a low level. |
| 17:33:26 | BBrox | ade: it's different :-) |
| 17:33:42 | pb_ | BBrox: presumably there are details on the ABI page: http://www.codesourcery.com/cxx-abi/ |
| 17:34:05 | Jacmet | BBrox: check with g++ -S ;) |
| 17:35:33 | Jacmet | ade: that's the same as saying that C code interfacing with hw is no longer C as it's so close to asm ;) |
| 17:35:53 | BBrox | Jacmet: hehe :-) |
| 17:40:24 | colin_ | Can somebody else switch on logging please? I don't trust my connection. |
| 17:42:48 | PaxAnima | brrrr.. feels like winter outside (+5C) |
| 17:43:14 | Jacmet | PaxAnima: well, you're also ALMOST at the northpole ;) |
| 17:43:55 | PaxAnima | far too close to it, yes ;) |
| 17:44:27 | colin_ | waits for the moment when spung changes his nick and suddenly is nils :) |
| 17:45:32 | pb_ | colin_: presumably we will have the ibot logs to fall back on. |
| 17:45:40 | pb_ | mibus: morning |
| 17:45:42 | mibus | hey ppls |
| 17:45:50 | colin_ | pb_: Yes, and cmarqu is logging too, but hey... |
| 17:45:52 | PaxAnima | morning mibus |
| 17:45:56 | mibus | if ur concerned about logs for this, xchat logs stuff for me ;-) |
| 17:46:02 | pb_ | phew |
| 17:46:03 | colin_ | mibus: Good morning. Got coffee already? |
| 17:46:07 | mibus | rubs his eyes |
| 17:46:12 | mibus | not yet |
| 17:46:12 | Jacmet | mibus ;) |
| 17:46:21 | mibus | gotta wake up enough to remember how to make it |
| 17:46:23 | mibus | ;-) |
| 17:46:33 | mibus | actually, if this only takes an hour or so im going back to bed |
| 17:46:38 | mibus | so coffee = bad then ;-) |
| 17:46:44 | colin_ | declares mibus the hero of the day |
| 17:46:47 | PaxAnima | mibus: got your mail... the bracket balancing thing is added... not done an ipkg yet... |
| 17:46:52 | mibus | lol |
| 17:46:56 | mibus | hey cool wow |
| 17:47:03 | mibus | what about graphing? :P |
| 17:47:20 | colin_ | get something to eat |
| 17:47:20 | PaxAnima | that would take more than 2 minutes, I'm afraid... ;) |
| 17:47:25 | mibus | ;-) |
| 17:47:28 | pb_ | Argh! |
| 17:47:28 | ade_ | gateway falls over at just the right time :( |
| 17:47:38 | pb_ | See Nils' mail on the gpe list. |
| 17:47:41 | mibus | im working today :D |
| 17:47:54 | mibus | im SO glad my work is casual and I just rock up when I feel like it ;-) |
| 17:48:01 | mibus | hey nils |
| 17:48:02 | __moray | hello nils |
| 17:48:10 | ade_ | lo nils |
| 17:48:12 | florian_ | nils: moin! |
| 17:48:22 | nils | Hi all! Finally made it ;) |
| 17:48:51 | mibus | wonders why none of his friends are on MSN messenger or IRC ;-) |
| 17:50:30 | mallum | hey nils |
| 17:50:41 | mibus | bleh - i have 6 unread emails in my inbox (ie. not mailling lists) since six hours ago... |
| 17:50:45 | mibus | hi mallum |
| 17:50:53 | mallum | hey mibus |
| 17:52:41 | colin_ | nils: Master! ;) |
| 17:53:10 | nils | Huhh ... this IRC confuses me ;) I am not used to it at so please excuse if am not familiar with usual habits here. |
| 17:53:36 | ade_ | time peoples ? |
| 17:53:43 | nils | colin_: don't exaggerate :) |
| 17:54:04 | mibus | nils: you dont use IRC???? shame! :P |
| 17:54:04 | colin_ | nils: Just regard everything said as a joke and you'll be fine |
| 17:54:33 | nils | Nope, not using IRC: We don't have a leased line :((( |
| 17:54:45 | ade_ | colin_: that only works with people under 18 |
| 17:54:59 | nils | Anyway, let's go? |
| 17:55:09 | colin_ | Regarding calendar/alarm, I'll let you guys do the talking as I don't have a real clue. |
| 17:55:23 | mallum | no dc_ ? |
| 17:55:27 | mibus | sounds fair - ill be working for a minute so don't expect me to respond quickly ;-) |
| 17:55:28 | pb_ | no mccarthy either. |
| 17:55:31 | colin_ | No mccarthy either |
| 17:55:31 | | dc was last seen on #gpe 48 days, 8 hours, 17 minutes and 41 seconds ago, saying: colin_werk: ah thanks alot. [Mon Aug 5 10:37:50 2002] |
| 17:55:31 | mibus | ibot: seen dc? |
| 17:55:33 | | dc_ was last seen on #gpe 8 hours, 14 minutes and 42 seconds ago, saying: bbl [Sun Sep 22 10:40:51 2002] |
| 17:55:33 | mibus | ibot: seen dc_? |
| 17:55:33 | mallum | ah |
| 17:55:36 | colin_ | pb_: ^5! |
| 17:56:06 | pb_ | :-} |
| 17:56:25 | nils | OK, then tackle it. Does anyone have any new ideas on the alarm issue? |
| 17:56:27 | colin_ | pb_: Okay, that was american... |
| 17:56:53 | mibus | pb_: you rock - that line of code fixed appmgr-alpha ;-) |
| 17:57:01 | mibus | pb_: now i can move to stage #3 :D |
| 17:57:18 | mibus | pats pb_ on the back |
| 17:57:23 | pb_ | mibus: cool. |
| 17:57:43 | pb_ | nils: well, hmm. Can you start by explaining what the essential differences are between rtcd and (say) atd? |
| 17:57:49 | colin_ | I'd like to understand the difference between rtcd and atd |
| 17:57:53 | colin_ | (!) |
| 17:58:01 | pb_ | Hmm, there seems to be some kind of echo in here. |
| 17:59:03 | pb_ | nils: as you might be aware, the current implementation in gpe-calendar is based on rtcd. However, it comes with some kind of large health warning that implies it's not suitable for release. |
| 17:59:20 | mibus | hang on, there's alarm code at all? |
| 17:59:45 | nils | To be honest, I don't know the current iPaq atd that much. I started rtcd because of the need for programming just that _one_ RTC alarm. I also wanted functions like seen with the Psion PDAs,i.e. that you can easily fetch a list of pending alarms. Next was that wanted not just beeing able to call scripts/binaries like atd does. |
| 17:59:49 | pb_ | mibus: yeah. |
| 18:00:01 | nils | Sure there is alarm code! It's in rtcd and libgpe. |
| 18:00:31 | colin_ | Too bad nelson is not here in realtime |
| 18:00:36 | pb_ | Yes. |
| 18:00:59 | colin_ | "not just beeing able to call scripts/binaries like atd does" meaning...? |
| 18:01:02 | pb_ | nils: Mmm, okay. What do you mean by "not just being able to call scripts/binaries", exactly? |
| 18:01:11 | colin_ | pb_: Oh stop it! ;) |
| 18:01:18 | pb_ | Okay, I'm just gonna give up typing and let colin_ speak for me. |
| 18:01:19 | moray_ | from the point-of-view of GPE, would it be a good idea to have one user-level alarm program which sets alarms and is called by atd/rtcd/whatever? |
| 18:01:20 | nils | The biggest, and it seems everlasting, issue with rtcd is now how to properly do asynchronous signalling of the applications. That's mostly the problem. |
| 18:01:57 | moray_ | since you can't predict when you want to originally set an alarm what behaviour you want to happen when the alarm time comes |
| 18:02:06 | mallum | X Selections ? |
| 18:02:28 | nils | pb_: You see, atd can "only" call a script or binary upon alarm expiry. I wanted an application to install an alarm and that very same application beeing notified upon expiry. |
| 18:02:41 | mibus | you could just be lame - store an AlarmID and run "program --alarm <AlarmID>"... |
| 18:02:47 | pb_ | nils: Mmm, right, but the application could be notified by running a copy of itself with some magic arguments. |
| 18:02:54 | moray_ | nils: there are two separate things really - you want to show the user that the alarm has come, for which there could be one central program, and you want to tell the program it's happened, when it might want to do something |
| 18:02:56 | mibus | pb_: hey i just said that! |
| 18:03:17 | PaxAnima | nils: is rtcd intended to be something very gpe-spesific or something general that can be used by non-gpe stuff as well? if there's only 1 alarm that can be set on the ipaq, it should be coordinated with opie folks as well, and maybe done as general as possible, and let the higher level apps deal with multiuser issues |
| 18:03:18 | pb_ | nils: I can't think of any easy, robust way for atd to find the original program in order to signal it with any kind of IPC, given that the alarm could be going off years later and after many reboots. |
| 18:03:20 | mibus | though there's no point waking up gpe-calendar just to display a dialog... |
| 18:03:40 | moray_ | a central user-level alarm program lets you easily do things like have a 'snooze' type button on all alarms (i.e. 'remind me in N minutes') |
| 18:03:48 | nils | Not really. The central program should just manage all alarms because we just have _one_ RTC alarm. The applications themselves should do user notification and thelike. |
| 18:04:30 | mibus | nils: but surely not all apps will individually do notification? most will just want a standard GPE "this is the appt." style dialog? |
| 18:04:44 | colin_ | Let's define some terms please: scheduling app (gpe-calendar), wake-up app (rtcd/atd/uschedule), announcing app (gpe-announce)? |
| 18:04:45 | moray_ | pb_: I don't think we want e.g. all your calendar events to be set as alarms, when they're created - if the alarm program is told when one goes off, it could always have only the next one set |
| 18:05:25 | moray_ | colin_: there could potentially be alarms set by other gpe apps too, so we should have a system that can cope with that |
| 18:05:46 | pb_ | moray: right. |
| 18:05:52 | colin_ | Well, yes, scheduling app should be many scheduling apps really |
| 18:05:53 | mibus | moray_: also, gpe-calendar would create an infinite number of alarms for recurring events |
| 18:05:54 | nils | Anyway, we all know that the current rtcd is not the best way to do it. What I know from atd it has this wake-up-any-24h-problem. So IMHO atd is at the current state no choice either. |
| 18:06:20 | pb_ | nils: I'm more interested at this stage in establishing interface, not implementation. |
| 18:06:27 | moray_ | mibus: indeed, I guess that's a case that shows you can only schedule a few things at a time (and it seems neatest to make 'a few' just one) |
| 18:06:35 | pb_ | nils: From what I understand, the wake-up-every-24h thing is just a bug, and can be fixed if necessary. |
| 18:06:35 | colin_ | All of the schduling apps would set rtcd/atd |
| 18:06:47 | nils | moray: Sure, but rtcd is one way, atd is another ;) |
| 18:06:59 | moray_ | if we had a non-buggy atd, what would be wrong with it as the bottom layer? |
| 18:07:15 | nils | I think nothing :) |
| 18:07:32 | moray_ | I have a bias towards atd from using it on desktop machines already ;) |
| 18:07:32 | nils | We would just have to define some way of how atd can notify apps. |
| 18:07:32 | colin_ | I'd lean towards atd too since OPIE uses it. |
| 18:07:37 | pb_ | Indeed. |
| 18:08:03 | pb_ | nils: Well, in a sense, each app can worry about how it gets notified individually. |
| 18:08:04 | moray_ | nils: I think we may want to have a layer (or even more than one) between apps and atd |
| 18:08:20 | nils | OK then, let's look at atd. |
| 18:08:27 | moray_ | nils: if we did that there could potentially be several different implementations of the bottom layer |
| 18:08:28 | mibus | moray_: that can go in libgpe? |
| 18:08:31 | nils | moray: what for? |
| 18:08:32 | colin_ | This layer was there as ipaqalarm (with uschedule as a "backend") |
| 18:08:42 | colin_ | This is what storm used |
| 18:08:48 | pb_ | moray_: Maybe, yeah. Opie has opie-alarm, which seems to translate atd events into QCOP from what I remember. |
| 18:09:21 | nils | The QCOP is something that is still missing in GPE, i.e. some means for proper IPC. |
| 18:10:01 | pb_ | Well, Max seems to have signed me up for porting QCOP to X. :- |
| 18:10:01 | moray_ | mibus/nils: well, I already mentioned in one direction it would be potentially good to have a centralised alarm notification system (notify app, notify user unless the alarm is marked otherwise); similarly, in the other direction having the alarm setting as a gpe protocol would let us configure it centrally, have a central record of alarms for gpe, etc. |
| 18:10:04 | nils | This IPC could also very well be used for the alarm signalling and other nice stuff (think of when it comes to synchronisation and signalling data changes). |
| 18:11:04 | moray_ | nils: yes, for the alarms we could hack around it by leaving it up to programs (i.e. just run the program with arguments, and leave it to the program to see if an instance is already running if it cares), but it would be nicer to sort it out properly |
| 18:11:07 | nils | moray: How would you implement (just roughly) a "GPE protocol"? |
| 18:11:12 | mibus | the palmos progammer's companion section on alarms: http://tinfpc2.vub.ac.be/manuals/palm/devdoc/SystemFeatures.html#924958 |
| 18:12:00 | moray_ | nils: well, possibly it should be pretty simple: set an alarm for this time, e.g. with an optional message and optional command to run, and potentially an optional ipc message to send |
| 18:12:24 | moray_ | nils: the calendar program is probably the right place to deal with repeating alarms, 'first thursday of the month' etc. |
| 18:12:44 | nils | The IPC is the most interesting question ;) We currently have no consistant IPC I think... |
| 18:12:53 | mibus | nils: if any at all... |
| 18:13:22 | moray_ | nils: if we have a protocol then we can fill in the ipc option once it's written - again, if apps do this directly it would be quite nasty to fit in... |
| 18:13:40 | PaxAnima | as a sort-of independent (haven't done any GPE stuff (yet)), but the alarm thing should be layers, where the lowlevel one should be shared by GPE/Opie/whatever, and push the logics in the upper levels |
| 18:14:13 | moray_ | PaxAnima: yes - if we used atd then it's shared by the whole unix-level system, not just the GUIs |
| 18:14:24 | nils | Yes, OPIE compatability is really a good idea (besides: OPIE wants to use the sqlite interface and usqld too!) |
| 18:14:53 | moray_ | would there be any good reason for the GPE alarm interface to deal with more complex things than 'an alarm at a particular time (and date)'? |
| 18:14:53 | colin_ | repeating alarms would be just single alarms for atd, no connection between them. |
| 18:15:16 | nils | OK then, we have at least a partial agreement on using (and fixing) atd. |
| 18:15:29 | pb_ | moray_: Well, you probably need to convey some user information. |
| 18:15:55 | moray_ | pb_: yes, I think I was assuming that the system knew that, but it would need to be stored explicitly |
| 18:16:11 | pb_ | ok. |
| 18:16:15 | PaxAnima | nils: fixing atd would be good for all parts, I think |
| 18:16:51 | moray_ | we don't need to work out fine details yet, but what kind of thing were people thinking should go into atd as alarms - i.e. what program are these alarms going to be linked to? |
| 18:17:43 | moray_ | e.g. a GPE-specific thing, or something lower-level first? (I don't know if we need an extra layer there or not) |
| 18:18:06 | nils | I would vote for the easy way: Specify this when creating the alarm. I.e. for gpe-calendar it could register a callback program with arguments like "gpe-alarm --alarm-reached" or similar. |
| 18:18:30 | nils | Sorry ... should read "gpe-calendar..." |
| 18:18:35 | pierre | [yes] |
| 18:18:45 | pb_ | agreed. |
| 18:18:46 | mibus | dont forget that the text on an alarm may change when its edited |
| 18:19:01 | moray_ | nils: well, that stops alarm notifications being consistent across programs though? or I suppose we could have a library thing for 'show alarm notification' |
| 18:19:04 | mibus | also, if the ipaq is off when an alarm goes off do you want the intervening alarms? |
| 18:19:11 | nils | What the application does then is up to the application. It could launch gpe-announce or create forms of notification itself. |
| 18:19:20 | moray_ | mibus: people can also cancel alarms between their setting and their expiry... |
| 18:19:21 | colin_ | I thought the announcing app would not be the app that scheduled the alarm |
| 18:19:33 | mibus | moray_: good point |
| 18:19:49 | pb_ | colin_: The app that scheduled the alarm needs to be the thing that finds out about it. It might well call something else to do the actual announcing. |
| 18:19:50 | mibus | so really the calendar should cancel and (if needed) recreate the alarm |
| 18:20:05 | nils | pb_: exactly! |
| 18:20:13 | mibus | pb_: why cant it call announce *directly*, not through the calendar? what's the point? |
| 18:20:27 | moray_ | pb_: well, I guess it's a question of whether we want alarm-setter -> alarm-announcer or alarm-conduit -> alarm-setter, user |
| 18:20:29 | pb_ | mibus: e.g. for a recurring event, the calendar needs to set up for the next instance. |
| 18:20:30 | colin_ | I don't see why it needs to be the same app |
| 18:20:41 | mibus | pb_: gah, of course. |
| 18:20:41 | PaxAnima | I also speak for my own psPIM calendar as well when it comes to the alarm handling, and having a fixed atd, that also survives reboot. is good... and have an alarm layer for each system that interfaces with their apps... |
| 18:20:50 | moray_ | pb_: but the calendar could be notified separately from the user being notified? |
| 18:20:59 | nils | First the calendar gets to know that the alarm expires and second it was just an example ;) For sure calendar could register gpe-announce as handler. |
| 18:21:26 | pb_ | moray_: sure, it could, but I don't see much benefit in separating them out. |
| 18:22:11 | colin_ | Okay, I see the problem with the recurring alarms |
| 18:22:13 | moray_ | hm, this system doesn't seem to easily allow e.g. a user preference for how long before events to notify? or perhaps we could have that just in the calendar though? |
| 18:22:37 | colin_ | moray_: Yeah, that's what storm did |
| 18:22:42 | pb_ | moray_: The calendar's alarm window has an explicit field for that at the moment. I think it's probably something you want to set per app, if not per event. |
| 18:22:50 | moray_ | pb_: fine |
| 18:23:10 | colin_ | Per event for sure. |
| 18:23:15 | nils | The "how long before" should be, and usually is, an option during alarm creation inside the application. We should not break things people already know from other systems. |
| 18:23:32 | colin_ | Seems we all agree on that one |
| 18:23:41 | moray_ | pb_: what about the 'remind me in five minutes' button that could be useful? is there some way we can do that without duplicating code? |
| 18:23:53 | mibus | how long before should be able to be set as a default, as well as an option for an alarm being on by default IMHO |
| 18:24:00 | moray_ | mibus: yes |
| 18:24:19 | nils | This brings us directly to system setup and global options :) |
| 18:24:21 | pb_ | moray_: gpe-announce could handle the UI and we could arrange for it to pass information back to its caller in the return code or something. |
| 18:24:24 | mibus | moray_: just recreate an alarm with the same text and time+5 ;) |
| 18:24:46 | mibus | moray_: that'd be announce |
| 18:24:52 | mibus | ...'s job |
| 18:24:56 | moray_ | mibus: ok, I suppose that would be possible to include in the announcement program/library |
| 18:25:24 | moray_ | mibus: if there was some other program associated with the alarm, presumably that would just get run at the first time and then not run again? |
| 18:26:10 | mibus | moray_: if an app handles the alarm itself, we assume it'll handle "snooze" itself, because it probably isn't using the alarm for user notification... ? |
| 18:27:12 | moray_ | mibus: ok, in that case do we want alarms to be ipc *or* program *or* text rather than a combinariotion? |
| 18:27:15 | moray_ | is suffering from lag and can't see what he's typing |
| 18:27:36 | mibus | moray_: yes ;-) |
| 18:27:51 | mibus | moray_: i'd say ipc/program if any combination |
| 18:27:58 | mibus | moray_: i'd say program would probably do |
| 18:28:07 | mibus | gpe-calendar --alarm [id] |
| 18:28:16 | nils | mibus: Yes, program should be sufficient. Keep the rest for the app! |
| 18:28:22 | moray_ | well, obviously you can do anything once a program is run, but I'm thinking what it would be useful to have in the gpe interface |
| 18:28:25 | mibus | or gpe-announce --title HELLO --text WORLD |
| 18:28:47 | moray_ | i.e. which bits of code are likely to be used by several programs and so should be put into libraries/central programs |
| 18:29:25 | nils | Alarm creation should clearly be helped by a lib-call! |
| 18:29:26 | mibus | moray_: something to keep track of that app's 'next' alarm |
| 18:29:50 | mibus | we'll end up with two alarm queues, one in each app and one in rtcd (containing one alarm from each app's queue) |
| 18:30:03 | nils | Yes, why not? |
| 18:30:32 | moray_ | mibus: I think that's the Right Thing, since subsequent alarms may well depend on what goes on with the first one |
| 18:30:37 | mibus | yup |
| 18:30:58 | nils | For apps that only carry a limited amount of alarms this isn't a problem. I just wonder how calendar should handle alarms? |
| 18:31:19 | nils | Create all at once? One after another? |
| 18:31:34 | mibus | when atd says there arent any alarms, pull the next one straight out of the list of appointments |
| 18:32:05 | nils | Then there is no other choice in calling calendar anyway ;) |
| 18:32:08 | moray_ | the calendar needs to be able to find events in order for display etc., so it shouldn't be hard to find the next alarm to set? |
| 18:33:02 | mibus | moray_: yep, sounds right |
| 18:33:16 | moray_ | as I said before, if we accept that the calendar can't set alarms immediately for *all* future events, I don't think it's harder to just set one than set half/quarter/eighth of them... |
| 18:33:38 | PaxAnima | I think that that logic should be handle by an alarm layer... gpe-calendar tells gpe-alarm/whatever that the alarm should go at time x and y and z and so on, and let the alarm-app handle it |
| 18:34:01 | nils | BTW: I am besides reading that PalmOS doc, it seems it says mostly the same we are slowly agreeing on ;) |
| 18:34:17 | mibus | PaxAnima: what about recurring events? i dont think atd needs to know about the next 20 years of birthday reminders! |
| 18:35:09 | PaxAnima | mibus: no, but the alarm layer would handle it (and not fill the atd spool with 1000000000 alarms) |
| 18:35:12 | moray_ | yes, and the calendar will end up doing a lot of work setting and unsetting alarms for events that in fact get delted |
| 18:35:26 | moray_ | PaxAnima: but if only the calendar uses this, it's better to put it there? |
| 18:35:46 | mibus | PaxAnima: but what about alarms that recur infinitely? |
| 18:35:57 | mibus | PaxAnima: not to mention storage of the "just" 10000000000 alarms? ;-) |
| 18:36:52 | moray_ | mibus: well, you could special-case repeating alarms - but I don't see that that's beneficial |
| 18:37:01 | PaxAnima | mibus: still think that the alarm layer should handle it, as it's not the calendars job to alarm the events... the calendar is a GUI app that shows dates and appointments |
| 18:37:05 | nils | Not only calendar will use alarms. I would for example like to have a seperate alarm application (actually in CVS as gpe-alarm) that can be used as an alarm clock without the need fo are real event. |
| 18:37:15 | mibus | maybe we should *allow* multiple alarms per app, but make the calendar be "special"? |
| 18:37:26 | moray_ | nils: but does that alarm program need to deal with repeats etc.? |
| 18:37:36 | nils | Yes I think so. |
| 18:37:40 | colin_ | Maybe recurring alarms are single alarms that just happen to be re-scheduled again? |
| 18:37:40 | moray_ | nils: and if it does, surely those events should be being displayed in the calendar program anyway? |
| 18:37:45 | pierre | mibus: recurent alarm can be set up for 2 or 3 alarm and |
| 18:37:56 | moray_ | nils: and if they're displayed in the calendar program, can't the calendar program schedule them? |
| 18:37:58 | nils | Oh sorry, read "should", it currently does not but I wanted to do it. |
| 18:38:30 | moray_ | nils: hm, why wouldn't you want the alarm to show up in the calendar? |
| 18:38:36 | nils | moray: they are not displayed in calendar. They are seperate from calendar. |
| 18:38:48 | pb_ | moray_: I guess nils wants gpe-alarm to be able to do "wake me up at 7am each weekday" type things. |
| 18:38:55 | nils | Yes! |
| 18:39:00 | mibus | moray_: he means for (eg.) wakeup alarms, its from a diff't app |
| 18:39:06 | nils | Do you know the Psion devices? |
| 18:39:31 | pb_ | moray_: You probably don't want that cluttering up the calendar display. Admittedly, calendar could be made smarter about which events to display at what times. |
| 18:39:44 | colin_ | Couldn't this just be another "view" in gpe-calendar though? |
| 18:40:03 | nils | They have such a wake-up alarm app. It's very nice a) for wake-up alarms and b) to schedule a simple reminder quickly. I liked it very much! |
| 18:40:07 | moray_ | colin_: I would have thought so probably |
| 18:40:18 | moray_ | nils: I'm not arguing there shouldn't be such an interface |
| 18:40:18 | mibus | colin_: believe me, having a seperate "alarm" app rocks, its soooo easy for wakeup alarms |
| 18:40:22 | pb_ | colin_: Yes. Or, rather, a view option. It probably doesn't hurt for these to show up in the day view, but you usually wouldn't want to see them in the week view or anything else. |
| 18:40:47 | colin_ | I know wince has one like that, and I didn't really understand why |
| 18:40:50 | mibus | colin_: i used one on my Palm, and the Palm's calendar rocked better than anything i've seen ;-) |
| 18:41:04 | mibus | colin_: its simplicity - click |
| 18:41:04 | pierre | and you may want to view what 's going tomorow, at evening.. |
| 18:41:06 | mibus | 'eek |
| 18:41:09 | pb_ | mibus: the question is whether you want it to be a complete other app, or just a thinly disguised instance of the calendar. |
| 18:41:19 | colin_ | pierre: That would be gpe-today's job |
| 18:41:20 | moray_ | but I don't see it's worth making the alarm layer 1000 times more complex to allow there to be two calendar apps rather than one (where one is the alarm app) |
| 18:41:24 | mibus | click 'monday tuesday wednesday' and set the time to 7AM... done! |
| 18:41:51 | moray_ | pb_: well, it could be a different interface that just happened to call the calendar stuff to finally set the event |
| 18:41:58 | mibus | pb_: id say other app - its "feature" is simplicity IMHO |
| 18:42:11 | colin_ | mibus: Isn't this a recurring app with zero time span in calendar? |
| 18:42:16 | mibus | moray_: at which point we need IPC and sutff, eeeek :) |
| 18:42:40 | mibus | colin_: sort-of, it could be implemented that way |
| 18:42:44 | moray_ | mibus: well, I think we've agreed we're going to need it... - but in fact you could do that just by running some command line |
| 18:42:46 | pb_ | mibus: but you're talking about GUI simplicity; there is no reason at all why you couldn't add a mode to the calendar where it presented a simplified "alarm" UI if you started it with some special option (say, "--alarm") |
| 18:42:58 | moray_ | pb_: yup |
| 18:43:01 | mibus | colin_: but then there's no need for a framework, cos we've only got one app again ;-) |
| 18:43:22 | mibus | pb_: yup, but what about when the calendar is already loaded etc.? |
| 18:43:41 | pb_ | mibus: makes no difference. |
| 18:44:01 | mibus | pb_: hmmm, i s'pose... |
| 18:44:10 | pb_ | mibus: oh, are you thinking about that losing xsi stuff? |
| 18:44:13 | moray_ | mibus: at the moment gpe-soundbite does that sort of thing with record/play modes |
| 18:44:28 | nils | We need the framework, calendar back and forth. There will be other apps that need alarms, e.g. automated backup etc. |
| 18:44:35 | moray_ | nils: yes |
| 18:44:44 | PaxAnima | as an observer (kind of), I'd say that layers and abstraction is a good thing, and should be used for the alarm handling |
| 18:45:26 | mibus | so where's the harm in a seperate alarm app anyway? if nothing else, that means ppl won't need gpe-calendar installed ;-) |
| 18:45:45 | nils | Sure abstraction is nice, but where and how? |
| 18:46:04 | PaxAnima | nils: atd->alarm-layer->app |
| 18:46:05 | moray_ | mibus: if we put half the calendar code into the gpe libraries/announce app, then people won't gain from not having it installed :/ |
| 18:46:26 | moray_ | mibus: that's why I think the alarm layer should be as simple as possible (just an alarm at a time) |
| 18:46:26 | mibus | :/ |
| 18:46:37 | mibus | moray_: yup, i agree ;-) |
| 18:46:39 | pb_ | moray_: quite. |
| 18:47:19 | moray_ | and if we implement that first we can always add more complex alarms later if it's really needed... |
| 18:47:35 | pb_ | we can always arrange to put the calendar's recurrence engine into a shared library if other programs really want to use it. |
| 18:47:39 | pierre | moray_: why not make a gpe-libcalendar |
| 18:47:47 | pierre | or gpe-libalarm |
| 18:48:01 | moray_ | pierre: again, no problem if we need to, but I think the low-level alarm stuff should be separated out |
| 18:48:02 | nils | gpe-libalarm is more or less already in libgpe |
| 18:48:08 | pierre | and keep the gui in libgpe |
| 18:48:18 | nils | GUI of what?` |
| 18:48:30 | pierre | the gui fonction |
| 18:48:48 | pb_ | pierre: what functionality would be in this gpe-libcalendar and/or gpe-libalarm, precisely? |
| 18:48:48 | pierre | of gpe |
| 18:49:10 | pierre | all the shared code that would be usefull to manage alarm. |
| 18:49:18 | colin_ | What happens if I set an alarm for next week, and later one for tomorrow? Does the alarm-layer store the one for next week and makes the one for tomorrow the one that atd sees? |
| 18:49:32 | pierre | create-answer, reschedule, etc |
| 18:50:15 | nils | colin_: I thought that atd manages this? Else its almost useless! |
| 18:50:15 | moray_ | colin_: I'd say the alarm layer would remove the earlier-set one to keep the 'one alarm at a time' thing |
| 18:50:43 | moray_ | nils: atd deals with working out when the events actually happen in an efficient way... |
| 18:51:17 | moray_ | colin_: actually, I'd say the program would remove the first-set one if it wants, and leave it if it wants, but either way the operation would go through the gpe layer |
| 18:51:34 | colin_ | BTW, "Registering for a Notification" seems like a nice concept from this Palm doc |
| 18:51:57 | moray_ | if programs are using alarms for 'internal' command stuff there's no reason they can't have several atd events set |
| 18:53:36 | PaxAnima | the alarm-layer should at least take care of repeating events and doing the actually writing to the atd spool, IMHO |
| 18:53:41 | pb_ | okay, so, can we try to nail down the semantics of this gpe layer? Is it just going to abstract the operations of setting and deleting alarms, so an app can say "run this command at this time"? |
| 18:54:22 | colin_ | Maybe we need a "use case" with every conceivable scenario in it, then see where we cut layers |
| 18:54:30 | nils | Let's devide this in two parts, the forward creation and backward notification, OK? |
| 18:54:46 | mibus | PaxAnima: no no no! then we have to hack *stacks* of recurrance code in libgpealarm (whatever) as well as everywhere else! |
| 18:55:00 | colin_ | pb_: Sounds like atd alone can do this already? |
| 18:55:07 | mibus | PaxAnima: if <app> wants to have recurred alarms, let it set them IMHO |
| 18:55:24 | pb_ | colin_: What does the atd API look like, do you know? |
| 18:55:25 | moray_ | pb_/colin_: but we might want a 'set text message alarm' library call? |
| 18:55:41 | colin_ | pb_: No... |
| 18:55:50 | nils | But if we want to handle recurrences inside GPE somewhere we need a third application! |
| 18:55:56 | mibus | colin_: very nearly, if not totally... we probably want to wrap around it so you can call gpe_set_alarm (unixtime, "program") or gpe_set_alarm_message (unixtime, "title", "message"); |
| 18:56:05 | mibus | nils: like gpe-calendar! |
| 18:56:09 | pb_ | moray_: Okay, that's just a slightly higher-level thing, right? It would arrange to call gpe-announce at the specified time and hand it some arguments. |
| 18:56:22 | colin_ | pb_: ACK |
| 18:56:30 | moray_ | pb_: yes |
| 18:56:44 | moray_ | pb_: e.g. include an urgency level |
| 18:56:52 | pb_ | yup. |
| 18:57:04 | colin_ | Or a "silent" flag |
| 18:57:04 | moray_ | pb_: (then we can centrally configure the level for which to beep / flash screen / self-destruct etc.) |
| 18:57:06 | PaxAnima | mibus: don't quite agree... |
| 18:57:18 | mibus | PaxAnima: :P |
| 18:57:49 | mibus | PaxAnima: while it would be nice, recurring events are (IMHO) complex, and unless we have libgperecurrance it's gonna be alot of code duplication |
| 18:58:06 | pb_ | moray_: right, yeah. |
| 18:58:11 | moray_ | mibus: the calendar needs the code itself so it can do displays |
| 18:58:23 | PaxAnima | mibus: well, recurrence for the alarm should be easy: when an recurring alarm sets off, add and alarm for the next recurrence |
| 18:58:43 | moray_ | PaxAnima: if it's easy then there's no harm in programs doing it themselves... |
| 18:58:43 | mibus | moray_: yes, hence duplication unless there's a lib for it ;-) |
| 18:58:52 | mibus | PaxAnima: but its figuring out the next 'recurrance' thats the issue |
| 18:59:13 | mibus | PaxAnima: gpe-calendar's recurrance is actually incomplete ATM |
| 18:59:15 | PaxAnima | mibus: if the alarm layer has the info "run this alarm every day", adding 1 day to the date isn't a problem |
| 18:59:26 | mibus | PaxAnima: but you go and look and see how many options are there :D |
| 18:59:40 | mibus | PaxAnima: ok, sure, but what about more complex recurrance? or will we just ignore that? |
| 18:59:42 | moray_ | PaxAnima: but if you're going to have recurrence you need to deal with all the options, including the ones we haven't written yet |
| 18:59:58 | PaxAnima | mibus: how complex? |
| 19:00:06 | pb_ | arbitrarily complex. |
| 19:00:19 | mibus | lol |
| 19:00:20 | mibus | pretty much |
| 19:00:22 | moray_ | PaxAnima: again, say we add 'repeat on days with "s" in them when it's raining' functionality, if the calendar is going to deal with that itself it's as easy for it to deal with all recurrence |
| 19:00:54 | mibus | moray_: yeah, basically my idea; if an app is complex enough to support recurrance, let it set it's own alarms too :) |
| 19:01:05 | pb_ | seems like an eminently sensible plan. |
| 19:01:57 | colin_ | Also, that Palm doc doesn't seem to talk about recurrance, so I guess the apps handle it themselves there too |
| 19:02:04 | mibus | is concerned someone thinks him sensible... time to switch tactics ;-) |
| 19:02:12 | mibus | colin_: yes IIRC |
| 19:02:26 | pb_ | It's not at all clear to me what it really buys you to have the alarm layer handle recurrence, anyway. |
| 19:02:35 | PaxAnima | mibus: sure, if they have something very advanced alarms like "get me water when I'm drunk", sure, let the app add the required dates for the alarm, but most alarms can be breaked down to simpler ones |
| 19:03:17 | colin_ | PaxAnima: breaking them down is bad for when you want to edit them later |
| 19:03:32 | mibus | PaxAnima: well we could add another layer of abstraction, the libgpealarmrecurrancetokeeppetterhappy :P |
| 19:03:48 | colin_ | i.e., the calendar/whatever still needs to see them as a whole |
| 19:04:36 | PaxAnima | but handling the logic to the alarm layer is a good thing, IMHO |
| 19:04:43 | pb_ | What is the benefit? |
| 19:04:47 | moray_ | if people know what I think by now, I should go and get some of the food that my family have been eating without me? :/ |
| 19:05:07 | pb_ | moray_: sure, we can try to struggle on without you :-) |
| 19:05:25 | moray_ | pb_: ha, I'm sure you'll cope. ;) |
| 19:05:40 | moray_ | apologises for having to rush off and departs for now... |
| 19:05:50 | mibus | :) |
| 19:06:05 | mibus | looks longingly at the clock not even showing 6AM... |
| 19:06:07 | mibus | ;) |
| 19:06:25 | pb_ | mibus: you're a student, you aren't supposed to have even gone to bed yet. |
| 19:06:30 | colin_ | Should we try to write down some points we agreed on? |
| 19:06:33 | pb_ | Yes. |
| 19:06:38 | colin_ | (if we ghave such points) |
| 19:06:38 | nils | Yes! |
| 19:06:56 | colin_ | So, uh... :) |
| 19:06:58 | nils | That's what I tried 1/4h ago ;) |
| 19:06:58 | pb_ | Anybody want to take an action to fix atd? |
| 19:07:08 | colin_ | nelson! :) |
| 19:07:11 | mibus | pb_: no, im supposed to be getting drunk in town ;-) |
| 19:07:16 | nils | Yes, I'lll have a look at it. |
| 19:07:28 | pb_ | Okay! Write that down, colin_! |
| 19:07:45 | colin_ | nils: Talk to nelson too |
| 19:07:45 | mibus | ok, ppl agree on the 3 layers? atd, libgpe-alarm, <app>? |
| 19:07:59 | pb_ | In terms of abstraction, yes. |
| 19:08:01 | mibus | and we only need to be able to run a "program"? |
| 19:08:02 | nils | Sure. I want to first look at what atd actually _really_ does. |
| 19:08:30 | pb_ | If nothing else, having the libgpe-alarm API in there would allow us to replace atd with something better in the future. Like, I dunno, rtcd. |
| 19:08:30 | mibus | apps *can* register as many alarms as they want, but gpe-calendar will only do 1? |
| 19:08:41 | mibus | pb_: :P |
| 19:08:41 | nils | So libgpe(-alarm) contains functions for what? Registering alarms, OK? |
| 19:08:43 | pb_ | Let's just say apps can register as many as they want. |
| 19:08:55 | pb_ | nils: Yes. |
| 19:08:58 | mibus | nils: yes, just for simplicity, especially when adding alerts |
| 19:09:05 | mibus | ok thats five points... |
| 19:09:10 | mibus | THREE SIR, THREE |
| 19:09:14 | mibus | ;) |
| 19:09:25 | colin_ | Yes, three. |
| 19:09:56 | nils | Does anyone know of a good IPC method we could use then? |
| 19:09:57 | PaxAnima | I think that the alarm layer should handle at least some logics, like simple recurence |
| 19:10:07 | mibus | does everyone like my prototype API? |
| 19:10:11 | mibus | PaxAnima: :P |
| 19:10:16 | pb_ | nils: Let's just stick with running a program for now. |
| 19:10:47 | pb_ | nils: We can probably design the api in a way that leaves the door open to a future IPC scheme, if and when we find one. |
| 19:10:51 | nils | pb_: Sure, but running a new instance of calendar does not really help ;) It will have to notify the running one somehow. |
| 19:11:01 | pb_ | nils: The calendar can worry about that. |
| 19:11:11 | colin_ | "Running a program" wraps the call back to the scheduking app and the announcing? |
| 19:11:17 | nils | pb_: Sure, I was just curious and... |
| 19:11:36 | mibus | nils: in the meantime the calendar can IPC to itself if needed... |
| 19:11:56 | pb_ | nils: I duno, exactly. It might do something with X selections, or maybe some magic file in $HOME_VOLATILE. |
| 19:12:01 | nils | mibus: yes, but how? what is best? |
| 19:12:09 | mibus | nils: its up to the gpe-calendar hackers i guess ;) |
| 19:13:19 | nils | Sure, but why I insist in it is that it might be reasonable to become part of libgpe(-alarm) some time. |
| 19:13:29 | pb_ | Or just a Unix socket /tmp/.gpe-calendar-$USER. A whole cornucopia of possibilities. |
| 19:13:39 | pb_ | nils: We can always add it to a library at some later date. |
| 19:14:09 | mibus | nils: ok, but as pb_ says we can easily add it later |
| 19:14:15 | pb_ | nils: I think we should wait until some best practice emerges and then codify it, rather than trying to prescribe something in advance. |
| 19:14:24 | mibus | is writing an email to the GPE list with semi-agreed things |
| 19:14:30 | pb_ | Yay. |
| 19:14:35 | nils | mibus: thanks! |
| 19:14:40 | colin_ | mibus: Oh thanks. I feared I'd have to do it :) |
| 19:14:59 | mibus | no probs ppl, i rarely pull my weight around here ;) |
| 19:15:18 | colin_ | Let's also read that Palm doc some more in our non-IRC time |
| 19:15:25 | pb_ | Good plan. |
| 19:15:28 | ade | butts in with AnyOtherBusiness at this meeting ? |
| 19:15:45 | colin_ | nils: Was this event okay for you? Could we repeat it later, like in a week or so? |
| 19:15:54 | mibus | *cough*gtk2*cough* |
| 19:16:08 | pb_ | mibus: Can you put the URL to the palm doc in your mail too? |
| 19:16:14 | nils | colin_: Sure! ATMO we have a flat-rate ISDN connection... just the question how long it will last :( |
| 19:16:17 | mibus | ok |
| 19:16:46 | colin_ | nils: Good. Just today, my DSL flat got cut off (not permanently though) |
| 19:16:55 | pb_ | colin_: You hope. |
| 19:17:01 | colin_ | :) |
| 19:17:15 | florian_ | nils: If you run in troube with your connection - feel free to visit me :-) |
| 19:17:48 | colin_ | We should also look at opiealarm and ipaqalarm/uschedule (http://www.ohse.de/uwe/uschedule.html) |
| 19:17:57 | nils | Apropos visit: Anyone planning to come to Oldenburg next weekend? |
| 19:18:14 | colin_ | florian_: Hey, do you know Timo G. too? |
| 19:18:23 | nils | mibus: plz add colin's link to your mail too... |
| 19:18:27 | mibus | nils: its sorta out of my way, otherwise i would ;-) |
| 19:18:39 | mibus | done |
| 19:18:40 | colin_ | nils: Not me. What's happening there? |
| 19:18:43 | mibus | anything else? |
| 19:18:59 | nils | mibus: sorta, yes ;) But there are some more Europeans here I think... |
| 19:19:09 | florian_ | colin_: i dont think so... who ist this guy? |
| 19:19:11 | mibus | :D |
| 19:19:12 | colin_ | I'll paste the log to a wiki page |
| 19:19:24 | colin_ | florian_: colleague of mine, nils knows him from universoty |
| 19:19:41 | nils | It's a traditional non-x86 kernel hacker meeting, all other weird hackers invited too. |
| 19:19:43 | mibus | <brb> |
| 19:19:56 | colin_ | nils: Got a URL? |
| 19:19:59 | pb_ | Oh, is that the Linux/m68k hackers thing? |
| 19:20:16 | colin_ | Well, I'm not a hacker anyway... |
| 19:20:26 | nils | colin_: http://oldenburger.linuxtage.de/devel.html |
| 19:20:37 | florian_ | colin_: hmm maybe - i have a way too short memory for names ;-) |
| 19:20:41 | nils | Hacker or not, it's fun ;) |
| 19:21:05 | mibus | <b> |
| 19:21:17 | colin_ | Actually... mibus, could you do the wiki page thing too? I pay per minute at the moment... :/ |
| 19:21:21 | mibus | anyone want to add anything to the notes before i send them to the list? |
| 19:21:25 | pb_ | Okay, so, any volunteer to actually create libgpe-alarm? |
| 19:21:31 | colin_ | mibus: just wrap the "code" in <pre> tags |
| 19:21:31 | mibus | colin_: gah! certainly, i just got unlimited |
| 19:21:37 | mibus | :) |
| 19:21:46 | mibus | colin_: ok, sure, thanks |
| 19:21:59 | mibus | pb_: i *would*, but ATM dont have a sodding clue about atd :D |
| 19:22:01 | colin_ | mibus: Thank *you* |
| 19:22:05 | nils | Why not modify the ligpe rtcd alarm code? |
| 19:22:25 | mibus | if someone points me at some docs i might be able to have a look (at a more reasonable time of day tho ;) |
| 19:22:35 | colin_ | nils: Try to recruit some more GPe hackers there :) |
| 19:23:07 | nils | colin_: I am not supposed to talk about it, but expect this to happen soon ;)) |
| 19:23:24 | mibus | colin_: um how do you create a new page? |
| 19:23:50 | pb_ | mibus: just mention the WackyWikiName of your new page in an existing one, then click on the "?" link that appears next to it. |
| 19:23:59 | colin_ | mibus: Go to a "root" page (GPE, e.g.), then create a WikiName there |
| 19:24:18 | colin_ | nils: Oh cool. |
| 19:24:44 | pb_ | mibus: I have no idea where the atd docs are, try the distribution tarball or harass nelson. |
| 19:25:37 | mibus | ok thanks |
| 19:29:28 | nils | mibus: Have you had a look at libgpe? I ask because AFAIK you don't use the libgpe-exec call in appmgr, right? |
| 19:29:38 | pb_ | ah, now, how about this issue of alarms that go off when the user is not logged in? |
| 19:29:58 | nils | pb_: Grr ... got us ;) |
| 19:30:04 | mibus | nils: i use gnome_spawn_async or something IIRC |
| 19:30:21 | mibus | pb_: make atd per-user |
| 19:30:23 | colin_ | A notification that doesn't give personal info would be fine, if feasible |
| 19:31:30 | mibus | galeon isnt co-operating pasting in text :( |
| 19:31:47 | PaxAnima | mibus: oh? |
| 19:31:52 | nils | mibus: Would you change? If not, why? |
| 19:32:37 | mibus | nils: change what? |
| 19:32:41 | colin_ | mibus: Works for me, normally. |
| 19:32:54 | mibus | mozilla doesnt want to paste either; it freezes for a moment but then nothing shows up... |
| 19:33:00 | nils | mibus: Change to the libgpe functions... |
| 19:33:20 | mibus | nils: oh ok. i never knew it was there, ill look at it :D |
| 19:33:32 | mibus | colin_: yeah it seems ok with 1 line, lets see how many it will do... |
| 19:33:46 | pb_ | nils: what do the gpe-exec functions do, exactly? |
| 19:34:25 | nils | More or less the same as the gnome functions but I have also included the xsi stuff... don't remember the details anymore isnce it is some time ago I did this. |
| 19:35:11 | pb_ | colin_: Yeah, a notification with no personal info is a possibility. Personally I'm leaning towards not doing alarms at all for non logged in users, which I guess would be mibus's idea of making atd per user. |
| 19:35:24 | colin_ | nils: You gotta plug the functions more by adding them to the web pages |
| 19:35:36 | pb_ | Yeah. |
| 19:36:10 | mibus | pb_: it also solves running random apps as root or nobody |
| 19:36:30 | nils | colin_: I should, yes ... oh well ... there's lot's to do! |
| 19:36:33 | mibus | nils: xsi will be replaced soonish because it doesn't like gtk2 apps :( |
| 19:36:38 | mibus | http://handhelds.org/z/wiki/IRCAlarmMeetingLog |
| 19:37:01 | mibus | the formatting is... broken :( |
| 19:37:11 | pb_ | mibus: yeah. |
| 19:37:24 | mibus | takes a look |
| 19:37:48 | mibus | gah, i think its interpreting the names as html |
| 19:37:52 | nils | mibus: Err... how can it fail? It only looks for window titles and uses xlib functions. What has GTK2 to do with it? |
| 19:38:32 | mibus | nils: i dont know, complain to mallum :D |
| 19:38:43 | mibus | nils: but gtk2 apps dont show up when xsi looks for them |
| 19:39:03 | mibus | nils: im writing a replacement that uses EWMH (?) specs to query for titles |
| 19:39:15 | nils | mibus: happy happy joy joy ... :( GTK2 port will becom funny... |
| 19:39:15 | mibus | nils: but ive had some issues with it, so im sorta stalled ATM |
| 19:39:41 | mibus | nils: funny? huh? |
| 19:40:00 | mibus | pb_: ok, <pre> isnt stopping it from interpreting html in the body, which is Bad(TM) |
| 19:40:19 | pb_ | mibus: the wiki sucks. |
| 19:40:28 | pb_ | mibus: maybe put it on an ordinary web page somewhere? |
| 19:40:42 | pb_ | mibus: say, on the gpe web site for example. |
| 19:40:54 | mibus | sounds fair |
| 19:41:10 | mibus | can i delete the wikipage? |
| 19:41:14 | pb_ | yeah. |
| 19:41:28 | colin_ | Let it point to the web page |
| 19:41:29 | pb_ | or replace it with one that says "you have come to the wrong place, go to ... instead" |
| 19:41:50 | mibus | doing it now... |
| 19:41:51 | gazer | mibus: the only arguement for keeping the wiki page is so that there can be further discussion. |
| 19:42:20 | mibus | gazer: and the fact we cant delete it ;) |
| 19:43:01 | colin_ | Does GnomeMeeting support a whiteboard and "channels"? That might help for our layering discussion. |
| 19:43:16 | gazer | mibus: d'oh. :) |
| 19:43:18 | mibus | colin_: nope IIRC |
| 19:43:22 | colin_ | No video, just text, like IRC |
| 19:43:26 | colin_ | mibus: Damn. |
| 19:43:48 | colin_ | Gotta install NetMeeting :) |
| 19:44:55 | mibus | lol |
| 19:45:37 | colin_ | I should go offline soon to save my phone bill |
| 19:45:46 | pb_ | ok. |
| 19:45:55 | pb_ | mibus, are you going to circulate that list of resolutions to the list? |
| 19:46:00 | mibus | ok cool |
| 19:46:09 | mibus | yeah im just making sure the wiki is OK so i can link to it |
| 19:46:13 | mibus | itll be <5min |
| 19:46:14 | pb_ | excellent |
| 19:46:25 | mibus | im also adding the notes to the wiki in the IRCAlarmMeetingLog page |
| 19:47:27 | colin_ | Good. |
| 19:47:27 | mibus | almost done... |
| 19:48:11 | mibus | gah, wrong name in ~mibus/public_html, renaming... |
| 19:48:18 | pb_ | ! |
| 19:48:40 | colin_ | pb_: Unrelated... Do you think I can take some vertical space away from gpe-login to remove the GtkFrame and make it a "category" (i.e., indent everythign below it)? |
| 19:48:48 | mibus | ok its on its way! |
| 19:49:05 | pb_ | colin_: sure, yeah. |
| 19:49:34 | colin_ | pb_: Good. Would look nicer with the background I guess... |
| 19:49:52 | pb_ | Yup. |
| 19:49:59 | mibus | speaking of which |
| 19:50:09 | colin_ | OTOH, xkbd wouldn't be centered anymore... |
| 19:50:12 | colin_ | Hrrm. |
| 19:50:21 | mibus | im working on a partial rewrite of appmgr which can have backgrounds that dont suck :) |
| 19:50:44 | colin_ | mibus: Cool. gpe-setbg will be there then :) |
| 19:50:51 | pb_ | colin_: well, we can put xkbd more or less anywhere on the screen by giving it appropriate geometry. |
| 19:51:25 | pb_ | oh, hm, not while it remains swallowed I suppose. |
| 19:51:35 | colin_ | I'll have to experiment... |
| 19:51:40 | pb_ | Yeah. |
| 19:51:41 | mibus | colin_: will i just be able to listen using gpe-confd or somesuch? |
| 19:52:21 | colin_ | pb_: Or remove the category title altogether? but then ownerinfo is a category too |
| 19:52:44 | colin_ | mibus: Uhm. It sets the root window, and you are just transparent? |
| 19:53:00 | pb_ | colin_: sadly mibus is anything but transparent. |
| 19:53:10 | colin_ | :) |
| 19:53:18 | pb_ | we need to figure out a way to not have two copies of the background pixmap in memory, for sure. |
| 19:53:29 | colin_ | Hmm. |
| 19:54:11 | colin_ | I'll need help there :) |
| 19:54:14 | pb_ | I have no idea how, though. Unless we make appmgr special in some way, and that would go against everything I stand for. |
| 19:54:18 | colin_ | Biiiig help. |
| 19:54:19 | mibus | colin_: no cos transparency doesnt work under matchbox |
| 19:54:35 | mibus | pb_: im opaque! yay, no ABI issues ;) |
| 19:54:38 | colin_ | Hmmm... |
| 19:54:52 | pb_ | mibus: matchbox would be easily fixed, it's more that you can't do your compositing trick with transparent windows isn't it? |
| 19:54:58 | mibus | "gpe-ownerinfo -t" just has black crap everywhere IIRC |
| 19:55:13 | mibus | pb_: hmm, probably that too, don't know... |
| 19:55:26 | pb_ | mibus: making matchbox set its frame window to parentrelative is probably a one line change. |
| 19:55:47 | mibus | pb_: but i have an appmgr that is 'transparent'; 'cos of matchbox I set the bg of the main window to a pic... |
| 19:56:11 | pb_ | mibus: right, but what I'm saying is that the matchbox bug is absolutely not a valid reason to do that. |
| 19:56:27 | mibus | pb_: sure, right |
| 19:56:37 | mibus | pb_: but when i set the bg of the window then used transparency |
| 19:56:43 | mibus | pb_: it didnt like that anyway :( |
| 19:57:00 | mibus | pb_: setting the viewport would make half of the window (well outside the viewport) 'imaged' |
| 19:57:10 | mibus | pb_: there was a scap of it somewhen... |
| 19:57:18 | pb_ | hmm, right. |
| 19:57:38 | pb_ | as it happens, I do think the compositing thing is reason enough to do the background the way you do it now, even if you don't (!) |
| 19:57:50 | mibus | :D |
| 19:58:11 | mibus | aaaaah, if i dont set the bg myself the pixbuf has random stuff in it IIRC |
| 19:58:16 | mibus | so yes |
| 19:59:01 | pb_ | I think there was some possibility that you might be able to use XRender to solve the problem a different way, but unless you are a black belt in xlib that is probably not a good option. |
| 19:59:17 | mibus | pb_: im not even white belt ;) |
| 20:00:09 | colin_ | Night guys, I'm going offline. |
| 20:00:14 | pb_ | night colin_ |
| 20:00:17 | ade_ | night |
| 20:00:19 | mibus | night |
| 20:00:24 | pb_ | at least we'll still have cmarqu to keep us company, even if he doesn't say much. |
| 20:00:24 | mibus | (morning :P) |
| 20:00:26 | mibus | its not even 7AM |
| 20:00:32 | mibus | i might go to bed for an hour :D |
| 20:00:34 | mibus | :P |
| 20:00:40 | mallum | mibus: matchbox not setting parent relative is _definelty_ _not_ _a_ _bug_ |
| 20:00:55 | mibus | mallum: i didnt say it was, did i? hmm, sorry |
| 20:01:16 | mallum | mibus: no youyr right sorry |
| 20:01:16 | mibus | "<mibus> colin_: no cos transparency doesnt work under matchbox" -> no mention of that being wrong |
| 20:01:27 | pb_ | mallum: why is it not a bug? |
| 20:01:27 | mibus | just like "directx doesnt work under linux" :P |
| 20:01:30 | mallum | goes back to hole |
| 20:01:32 | mibus | mallum: well you oughta be :P |
| 20:01:40 | mibus | pb_: unnecessary feature :P |
| 20:01:46 | pb_ | hmph. |
| 20:02:01 | mallum | mibus: a better way to do it is to grab the root window pixmap ID |
| 20:02:18 | mallum | mibus: and stick that in your background |
| 20:02:29 | mibus | hmm, but i dont think i can composite that onto a widget anyway...? |
| 20:02:37 | mallum | mibus: the parent relative this is just a hack |
| 20:03:09 | mibus | is it how transparent terms are done? or is that just i-know-the-pixbuf-and-offset? |
| 20:03:26 | mallum | mibus: yes |
| 20:04:04 | mallum | mibus: if transparency worked you just get the contents of the window beneath as your background anyway |
| 20:04:12 | mibus | gah |
| 20:04:23 | mibus | option 1 XOR option 2 :P |
| 20:06:40 | pb_ | mccarthy! |
| 20:06:55 | mccarthy | oops |
| 20:06:58 | pb_ | ! |
| 20:07:07 | mccarthy | so what's I miss (is what I meant to say)! |
| 20:07:13 | mibus | lol |
| 20:07:29 | mccarthy | (I have *no idea* how I did that) |
| 20:07:33 | mibus | The log is at: |
| 20:07:38 | mibus | http://handhelds.org/~mibus/irc_alarm_meeting.log |
| 20:07:38 | mibus | Discussions and notes can be put here: |
| 20:07:38 | mibus | http://handhelds.org/z/wiki/IRCAlarmMeetingLog |
| 20:07:41 | mccarthy | (nor why I cannot spe what's :) |
| 20:07:46 | pb_ | mccarthy: guess you clicked in the wrong bit of xchat. |
| 20:08:10 | mccarthy | ok. let me catch up.... |
| 20:08:50 | mibus | pb_: add a link to IRCAlarmMeetingLog in the title! |
| 20:08:56 | pb_ | ah, good idea |
| 20:08:56 | mibus | im going to bed for a couple of hours :D |
| 20:09:12 | mibus | 6:45AM, im supposed to be sleeping ;-) |
| 20:09:22 | mibus | not that i think im likely to be able to get back to sleep... |
| 20:09:53 | pb_ | mibus: ok, sweet dreams. |
| 20:10:06 | mibus | ok ciao |
| 20:10:19 | mccarthy | so did I miss *everything*? (I thought it was supposed to be 5 my time) I am only 10 minutes late then! |
| 20:10:29 | pb_ | mccarthy: no, it was 2 hours ago. |
| 20:10:36 | pb_ | mccarthy: what timezone are you in? |
| 20:10:40 | mccarthy | 2 hours?! |
| 20:10:44 | mccarthy | New York |
| 20:10:52 | mccarthy | I thought it was -4 |
| 20:10:56 | mccarthy | sp 5PM |
| 20:11:03 | mccarthy | sp=so |
| 20:11:19 | mccarthy | maybe dst messed me up here (as well as in gpe-calendar)! |
| 20:11:31 | pb_ | yes, it's -4, but the time was 1900UTC, so 1500 your time. |
| 20:11:40 | mccarthy | oops |
| 20:11:58 | mccarthy | 1500 doesnt equal 1700 does it :( |
| 20:12:20 | mccarthy | stupid americans with their 12 hour clocks ;) |
| 20:12:36 | pb_ | :-} |
| 20:12:42 | pb_ | oh well. |
| 20:12:59 | mccarthy | and I tried really hard to get here on time :( |
| 20:13:20 | mccarthy | (the wife is holding off on studying til later and the kids are out playing with the neighbors) |
| 20:13:26 | pb_ | gutted. |
| 20:13:30 | mccarthy | if only I was not an idiot it would have worked out great! |
| 20:14:32 | moray_ | mccarthy: you can still put forward ideas about the per-user problem ;) |
| 20:14:43 | moray_ | pb_: though is there actually a problem anyway? |
| 20:15:01 | moray_ | pb_: as in, with atd the programs will get run as the user who set the alarms automatically |
| 20:15:08 | pb_ | moray_: probably not, it sounds like we are resolved to just run atd as the user (with a private spool presumably) and deal with things that way. |
| 20:15:27 | mccarthy | nils gave in and wants to run atd?! |
| 20:15:34 | moray_ | pb_: hm, atd run as a normal daemon copes happily with there being more than one user though... |
| 20:15:38 | pb_ | mccarthy: yeah. |
| 20:15:54 | pb_ | moray_: oh, does it? |
| 20:16:01 | mccarthy | whats the time-line on shifting over (how close to "fixed" is nelson's atd?! |
| 20:16:15 | pb_ | moray_: the code I'm looking at must be outdated, there is no user handling in here. |
| 20:16:57 | pb_ | mccarthy: nils took an action to fix the "midnight bug" in atd. |
| 20:17:15 | mccarthy | oh, cool. so it is pretty well "ready to go" |
| 20:17:20 | pb_ | I think so. |
| 20:17:29 | mccarthy | other than whatever user issue you guys are still discussing? |
| 20:17:52 | mccarthy | pb_: so are we to symply use a system command? |
| 20:18:02 | pb_ | mccarthy: yes, that seems to be the consensus. |
| 20:18:08 | mccarthy | (I am going to blame my typing on the modem :) |
| 20:18:29 | pb_ | mccarthy: nils wants to be able to add some kind of IPC system in the future, but since we don't have one yet this is probably not an immediate concern. |
| 20:18:38 | pb_ | mccarthy: line noise, huh? :-) |
| 20:18:39 | mccarthy | pb_: so recurring alarms will be handled purely by the app itself? |
| 20:18:46 | pb_ | mccarthy: yes. |
| 20:19:11 | mccarthy | pb_: and what about being "notified" about the signalling of an alarm? |
| 20:19:52 | pb_ | mccarthy: you do that with the command line, eg by arranging to run "gpe-calendar --alarm-notify <event id>" |
| 20:20:15 | pb_ | mccarthy: gpe-calendar can worry about doing IPC with any instance of itself that might already be running, if it cares. |
| 20:20:18 | mccarthy | pb_: oh, I guess that would work fine wouldn't it.... |
| 20:20:49 | mccarthy | IPC?! (remember I am dumb) |
| 20:20:56 | pb_ | inter process communication |
| 20:21:04 | pb_ | like, signals or QCOP or something. |
| 20:21:22 | mccarthy | oh |
| 20:21:52 | mccarthy | cant we simply have some sort of "single instance" thingie going on? |
| 20:22:08 | pb_ | I think it's easiest to leave that up to the application concerned. |
| 20:22:27 | pb_ | If all that's going to happen when the alarm goes off is that gpe-announce will pop up, there is no need for anything clever. |
| 20:22:38 | moray_ | mccarthy: for most things you probably just want the alarm to pop up a message / run some program, so it doesn't matter if other copies of the alarm-setting app are running |
| 20:23:38 | mccarthy | moray pb: the problem comes up with recurring alarms |
| 20:23:48 | mccarthy | I assume we do not want to set *all* of them at once |
| 20:23:55 | mccarthy | (they might go infinitely after all) |
| 20:24:02 | pb_ | mccarthy: no, we would just set the "next" one. |
| 20:24:08 | mccarthy | so we need to "set next alarm" periodically for them |
| 20:24:25 | mccarthy | but if there are two instances they might *both* set next alarm |
| 20:24:39 | mccarthy | which might have weird results |
| 20:25:50 | pb_ | Yeah, that will need a bit of thought. |
| 20:26:28 | pb_ | Maybe gpe-calendar will need to store the uid for the event it has set an alarm on in the database, or something like that. |
| 20:26:30 | mccarthy | pb_: but if we only have one copy run at any given time |
| 20:26:51 | mccarthy | then we set the "next" recurring alarm whenever it is editted |
| 20:26:56 | mccarthy | or when we get the "signal" |
| 20:27:02 | pb_ | mccarthy: yeah, like I say, gpe-calendar can take care of that itself if it wants to. |
| 20:27:04 | mccarthy | all other alarms are set immediately |
| 20:28:27 | pb_ | mccarthy: I don't think the alarm system itself should get into trying any kind of single-instance stuff. |
| 20:29:14 | mccarthy | pb_: I just thought we might have a wrapper of some sort that would do it for us |
| 20:29:25 | mccarthy | pb_: like "wrapper gpe-calendar --alarm" |
| 20:29:38 | mccarthy | and wrapper would look for an existing gpe-calendar and then send it a signale |
| 20:29:44 | mccarthy | or it would start a new one |
| 20:30:04 | pb_ | yeah, maybe. We can think about that, and it's easy to change later. |
| 20:30:13 | mccarthy | (this is essentially what I tried to teach rtcd to do before I gave up) |
| 20:30:46 | pb_ | How would the wrapper find the existing gpe-calendar, though? |
| 20:31:19 | mccarthy | pb_: cant it look through proc like a killall would? |
| 20:32:51 | pb_ | Mmm. I guess so. |
| 20:34:19 | pb_ | You still have the problem that the user might be running more than one gpe-calendar already, though. |
| 20:35:00 | mccarthy | pb_: not if we always "wrapper gpe-calendar" :) |
| 20:35:17 | mccarthy | but youare right |
| 20:35:34 | mccarthy | it looks like the logged in/not logged in problem did not get resolved! |
| 20:36:14 | moray_ | mccarthy: well either we run an atd per user when you log in, in which case there's no problem, but alarms are ignored when you're not logged in |
| 20:36:37 | moray_ | mccarthy: or we run a central one, and alarm-notified programs have to spot you're not logged in and give up / do something else |
| 20:36:39 | pb_ | well, we could just make gpe-calendar refuse to start if it sees another one of itself running, but I think there are legitimate reasons you might want to do that (eg multiple displays) |
| 20:37:23 | mccarthy | moray_: but I guess at the gpe-calendar level it doesnt matter which one happens... |
| 20:37:37 | mccarthy | pb_: are you gonna code the changes or should I? |
| 20:37:54 | mccarthy | (btw, I dont know how to do the --alarm thingie :) |
| 20:37:57 | pb_ | mccarthy: I'll have a go. |
| 20:38:25 | pb_ | mccarthy: There isn't a lot we can do until mibus produces this library interface to atd, and nils fixes atd so that it actually works. |
| 20:38:37 | mccarthy | pb_: are we gonna use gpe-announce (or something like it) for the actual alarm ringing |
| 20:38:41 | pb_ | sure. |
| 20:38:52 | mccarthy | oh |
| 20:38:54 | pb_ | did you see mibus's remarks about that on the gpe mailing list? |
| 20:39:09 | mccarthy | so we *arent* gonna simply do a system call to atd itself? |
| 20:39:36 | mccarthy | (at least not in gpe-calendar) |
| 20:39:37 | pb_ | well, almost, but nils wants to wrap this in a library. |
| 20:39:57 | mccarthy | so it will still look like: |
| 20:39:58 | pb_ | and there are valid reasons for doing that, so I guess we may as well wait. |
| 20:40:15 | mccarthy | set_alarm(time,alarm_info,text); |
| 20:40:26 | pb_ | Yeah. |
| 20:40:32 | mccarthy | ok |
| 20:40:40 | pb_ | See the stuff mibus wrote on the wiki page (and in the mailing list) |
| 20:40:41 | mccarthy | I hope we dont have to wait long |
| 20:40:56 | pb_ | indeed. |
| 20:41:38 | pb_ | well, I'll try to do the gpe-calendar side of things in the next couple of days. I have some other outstanding changes that I haven't checked in, relating to gpe-todo/gpe-calendar integration. I'm not sure what to do with those at the moment. |
| 20:42:59 | mccarthy | ok. |
| 20:43:17 | mccarthy | did you ever undo my dst changes? |
| 20:43:27 | pb_ | hmm, I don't remember. |
| 20:43:28 | mccarthy | IIRC one of them might not have beennecessary |
| 20:43:45 | mccarthy | (I shouldnt go so long without working on gpe-calendar) |
| 20:44:25 | pb_ | I don't see anything in the changelog about undoing them. So I guess they are still there. |
| 20:44:40 | mccarthy | pb_: do you really think we only set the "next" alarm?! or do we do that just for the recurring alarms |
| 20:44:42 | mccarthy | ? |
| 20:45:01 | pb_ | mccarthy: I don't think it makes a lot of difference, to be honest. |
| 20:45:39 | mccarthy | pb_: gpe-calendar will have to be "smarter" about sorting things if we only do the "next" alarm |
| 20:45:55 | mccarthy | it can be dumb and set 1 alarm per entry |
| 20:46:03 | mccarthy | and then simply update the ones that recur |
| 20:46:09 | mccarthy | (with no real sorting at all) |
| 20:46:14 | mccarthy | seems easier to me |
| 20:46:18 | pb_ | mccarthy: true, but the extra smarts are not very complicated. It just needs another list of events, ordered by alarm time. |
| 20:46:53 | mccarthy | (and *re*ordered whenever a recurring alarm rings) |
| 20:47:07 | mccarthy | but I guess it wouldnt be *that* hard |
| 20:47:14 | mccarthy | I am just lazy |
| 20:47:23 | mccarthy | oh well. |
| 20:47:24 | moray_ | mccarthy: if the calendar doesn't do it, atd will need to - atd already knows how etc., however atd will do this more often, and so waste more time/memory |
| 20:47:31 | mccarthy | looks like the meeting went fine without me |
| 20:47:38 | mccarthy | I will talk with you later in the week |
| 20:48:08 | mccarthy | moray perhaps you are right |
| 20:48:09 | pb_ | mccarthy: yeah, but how often do recurring alarms actually go off? For most people, I guess probably not more than once a day. |
| 20:48:20 | mccarthy | pb_: right |
| 20:48:29 | mccarthy | mine would go off every other day :) |
| 20:48:45 | mccarthy | (except when I reboot!) |
| 20:49:01 | pb_ | yeah. |
| 20:49:41 | mccarthy | good work everyone. next time tell the dumb american the time in 12hr format and he might actually show up :) |
| 20:49:47 | mccarthy | later |
| 20:49:48 | pb_ | heh :-) |
| 20:49:51 | pb_ | later. |
| 20:52:36 | PaxAnima | people and their time formats |
| 20:57:18 | moray_ | PaxAnima: well, next time maybe we can give out an alarm for people to set ;) |
| 20:57:55 | PaxAnima | make the ipaq jump around on the table and scream out "MEEEEETING" ;) |
| 20:58:08 | moray_ | ha |
| 21:02:46 | | OK, PaxAnima. |
| 21:02:46 | PaxAnima | ibot: message for mibus New version of pscalc is out, with some bugfixes and your requested bracket auto-balancing ;) |
| 21:03:18 | | OK, PaxAnima. |
| 21:03:18 | PaxAnima | ibot: message for mibus oh, and the URL is http://handhelds.org/~paxanima/files/pscalc_0.3_arm.ipk |
| 21:53:54 | sendman | does anybody knows about a utility to import palm database files into gpe? |
| 22:24:37 | mallum | hey jg |
| 22:25:16 | jg | mallum: hi. |
| 22:26:01 | mallum | jg: Im writing an outline in gtk2 |
| 22:26:09 | mallum | s/outline/outliner/ |
| 22:26:19 | jg | good stuff... |
| 22:27:12 | mallum | gtk2 seems alot nicer to code than 1.2 |
| 22:27:13 | gazer | looks in. |
| 22:27:26 | mallum | espesially the tree stuff |
| 22:27:41 | jg | yup |
| 22:27:42 | gazer | is there a plan for moving to gtk2? Are the gtk2 packages available stable-ish? |
| 22:28:19 | jg | gazer: no plan quite yet, but I think there is consensus to do it after the current funtionality stabilizes a bit. |
| 22:29:27 | gazer | jg: so are the packages currently available in the unstable feed usable? |
| 22:30:15 | jg | gazer: haven't played with them for a week or two. generally, yes; then they get moved to .6 |
| 22:30:43 | gazer | okay. I might start coding against them soon. |
| 22:30:53 | gazer | to keep my stuff future-proof. |