| 01:11:27 | Pule | Hrm |
| 01:11:43 | Pule | What's the second kernel in the familiar dir on handhelds.org? |
| 01:11:49 | Pule | fam1 vs fam2 |
| 03:14:19 | Pule | What is needing the most doing in familiar at the moment? or, what is the current TODO list? |
| 03:15:35 | Pule | or is the gnats interface where it's at? :) |
| 04:07:59 | Pule | hrm |
| 04:43:31 | edwardamZzZzZz | is away: I'm busy |
| 10:05:54 | a7r | is away: -> bed |
| 13:40:34 | jg | Good morning... |
| 13:40:58 | keithp | I went to sleep instead of hacking more last night. |
| 13:41:06 | jg | seems sensible... |
| 13:41:10 | jg | I'm merging right now... |
| 13:41:23 | jg | Not that I got that much written on the plane... |
| 13:41:26 | keithp | Now I've got to ponder how to build a pluggable layer for RandR support. |
| 13:41:45 | keithp | Have you cvsup'd already? |
| 13:41:54 | jg | yup. |
| 13:42:39 | jg | GetScreenInfo is a bit of a puzzle... |
| 13:43:21 | keithp | Yes it is. It does pack a bit of information into a single request. Do you want to have a "bag of bits" with accessor functions? Or expose the whole data structure? |
| 13:43:51 | jg | That's the second puzzle, not the first.... |
| 13:44:18 | keithp | Are you still puzzling over the contents? |
| 13:45:11 | jg | Not so much that... The issue I've been puzzling over is whether to/should this information be hung off the screen structure, and if so, this brings up the puzzle around knowing which screen to hang it off of... |
| 13:45:59 | keithp | Yeah, you'd have to believe the app when they handed you a window and a screen number. Not a pretty picture. |
| 13:46:28 | jg | Or maybe one just passes in a screen pointer, and the routine then uses the root window... |
| 13:46:45 | keithp | But the window is useful for the application to find out how to reconfigure for acceleration. |
| 13:47:09 | keithp | Ah, no. We should rip the acceleration stuff out and let the client walk through the data. |
| 13:47:54 | jg | what do you mean? |
| 13:48:41 | keithp | Right now the server walks over the data computing a list of visual sets that contain a specific visual. There's no reason to do that in the server; the client can walk over the data it receives to determine which configurations will support acceleration for a particular window. |
| 13:50:01 | jg | Yeah, but the server has to identify which will be accelerated... |
| 13:50:38 | keithp | Oh yeah. |
| 13:50:59 | keithp | Perhaps that should be a separate request? |
| 13:51:38 | keithp | No wait, the visual set completely describes the accelerated visuals -- that's what it's for. |
| 13:52:10 | jg | yup., |
| 13:52:54 | keithp | The current implementation doesn't require a DDX hook; the extension walks data that it collected from GetScreenInfo -- there's nothing done that the client can't do itself. |
| 13:53:48 | jg | No, how would the client know what is in software and what is in hardware? |
| 13:54:10 | keithp | The VisualSet lists the hardware visuals -- that's what it's for. |
| 13:55:45 | jg | So the accelerated list could go away, under this scheme? |
| 13:56:19 | keithp | Yes. That reduces network traffic, eliminates extra calls to determine additional information and changes the API from 'Window' to 'Screen'. |
| 13:57:36 | jg | Ok, let me get this straight: the visual-set is the set of *accelerated* visuals available (could easily be NULL); accelerated goes away entirely... |
| 13:58:35 | keithp | Each Size points at a set of visual sets, each visual set lists one combination of visuals that will be simultaneously accelerated. |
| 14:00:45 | jg | What happens when you have a size at which you can run either accelerated or not? You list the size more than once? |
| 14:01:35 | keithp | Each size has a *set* of visual sets -- each member of that set is the group of visuals accelerated together. |
| 14:02:03 | jg | OK, I guess I buy it... |
| 14:02:32 | keithp | At least, that's the current design. All I'm suggesting is that we eliminate the accelerated list as it's currently computable within the client. |
| 14:02:44 | jg | You want to reword that part of the spec, and mail it to me? |
| 14:03:28 | keithp | I don't think there's much to reword; just eliminate the accelerated list. We could reword the rest of the section to be a bit clearer though. |
| 14:03:29 | jg | All I worry about is that it might be able to change dynamically.... |
| 14:04:03 | keithp | Yes, it can change dynamically -- what I'm saying is that the accelerated list is *always* computable from the other information included in the reply. |
| 14:04:50 | jg | OK, now I'm confuseled again.... how? |
| 14:07:09 | keithp | Accelerated is a list of visual sets, each of which contains the visual of the specified window. When any of these visual sets is selected in SetScreenConfig, the desired visual will be accelerated. |
| 14:08:10 | keithp | The server computes this by searching for the desired visual in the list of visual sets; the client can do the same thing as it receives that entire list in GetScreenInfo. |
| 14:08:29 | jg | Maybe... Try reworking that section, and I'll see if a dummy like me can understand it... :-). |
| 14:14:01 | keithp | We've currently got two definitions that are interchangable -- 'SIZESET' == LISTofSIZES, SETofVISUALSET == LISTofVISUALSET. I'd like to eliminate the SIZESET/SETofVISUALSET and use LISTof everywhere. |
| 14:15:59 | jg | So each size will have a list of visualsets? |
| 14:16:16 | keithp | No, I'm not changing the encoding, just the terminology. |
| 14:18:54 | jg | Let me know when you have a revised section: I'll read and see if I understand it... |
| 14:19:46 | keithp | I'm atypin'. |
| 14:21:27 | jg | nikos: good morning.... |
| 14:22:18 | nikos | Hi jg, how are you? |
| 14:22:28 | jg | back on east coast... |
| 14:22:37 | nikos | How was Palo Alto? |
| 14:22:57 | jg | OK, saw doctor, lots of people, gave talks... |
| 14:23:32 | nikos | Will you be able to make it to the v0.5 Familiar planning committee this afternoon? |
| 14:23:39 | jg | yup. |
| 14:23:42 | nikos | Excellent. |
| 14:24:17 | nikos | I'm going to try to have a first draft of Bootldr installation and upgrading instructions for Familiar by then. |
| 14:25:10 | nikos | Email fishing for a hardware review to [iPAQ]? |
| 14:29:14 | Kero | will there be notes of the v0.5 planning on line? |
| 14:29:28 | nikos | I'm planning to save logs. |
| 14:29:41 | Kero | cool |
| 14:29:43 | nikos | Kero: At the very least I can get you those logs. |
| 14:29:58 | Kero | tries to think hard for wanted features, now... |
| 14:30:23 | nikos | Kero: If you think of anything, email familiar@handhelds.org please. |
| 14:31:42 | Kero | a pim-suite. |
| 14:43:46 | keithp | jg - I sent you an updated spec for GetScreenInfo |
| 14:44:24 | nikos | Ready for USENIX? ;) |
| 14:44:40 | keithp | Not yet. I've got screen size changing working, but I've got to get rotation.... |
| 14:44:44 | jg | not quite.... |
| 14:45:10 | nikos | Well, good luck. You have a lot of people on pins and needles. |
| 14:45:33 | keithp | I think that includes Jim and I... |
| 14:51:32 | jg | keithp: I got mail yesterday from Andy Christian saying he has the accelerometers working.... |
| 14:52:15 | keithp | Cool. I've cooresponded with the ion author about size switching. |
| 14:52:18 | Kero | nikos: mailed it. |
| 14:52:39 | nikos | Thanks Kero |
| 14:52:48 | keithp | jg: he seemed a bit surprised that the root window size might change... |
| 14:54:50 | jg | keithp: challenging presumptions is always fun... |
| 14:55:36 | keithp | I think I'll let him stew about how to fix ion himself, although I suspect we'll have to either prod him or try it ourselves. |
| 14:56:38 | jg | Point out to him it happens on laptops... |
| 14:57:09 | keithp | It's not the convincing, but getting him to do the work on our schedule. |
| 14:57:35 | jg | Yup. |
| 14:57:56 | nikos | So do you guys feel that we need to be concentrating on ion as WM? |
| 14:58:13 | nikos | I guess I need to try it out. |
| 14:58:45 | jg | Dunno for sure, but those who have tried ion seem to like it... |
| 14:59:02 | nikos | # ipkg install ion-nasty-hacks |
| 14:59:05 | nikos | :) |
| 14:59:18 | nikos | Give me a couple of minutes and I guess I will be a convert too. |
| 14:59:21 | keithp | It has some nice ideas for tiny screens. Certainly it's better than bb, but either need quite a bit of work to make them handheld friendly. In particular, we must be able to dock stuff like the keyboard emulator and application launcher. |
| 14:59:54 | jg | I believe that that is a panel's business: what we need is a decent panel app. |
| 15:00:26 | nikos | I would prefer to be able to dock on any screen edge. And be able to choose whether the other apps resize to adjust. |
| 15:01:08 | keithp | The WM must manage docking apps -- it's the only one with redirect for the root window. |
| 15:01:37 | jg | Then how does the Gnome panel do docking? (which it does...). |
| 15:02:13 | keithp | I don't know; I presume it either communicates with the WM (not likely) or docked apps look for it. |
| 15:02:38 | nikos | I believe to doc with the gnome panel apps have to be compiled specifically for it. |
| 15:02:43 | nikos | s/doc/dock/ |
| 15:02:45 | jg | Or they have a properties based protocol... |
| 15:03:15 | jg | nikos: don't think so: as I remember, it is possible to dock KDE apps with it... |
| 15:03:33 | nikos | jg: Hmm, OK. I could be a little behind. |
| 15:03:36 | keithp | I guess we should figure it out and use the same protocol. |
| 15:03:55 | jg | There is the Window Manager spec that they've worked on jointly. |
| 15:04:18 | jg | We could use the Gnome panel, but its code is ugly, according to the guy maintaining it.. |
| 15:11:04 | keithp | KDE uses a private protocol; I haven't found whether it also supports a standard protocol of some kind. The dockable apps are magic. |
| 15:11:05 | jg | keithp: So a frame buffer implementation returns a null visual-sets? |
| 15:11:29 | jg | I think that is in the new wm spec... |
| 15:12:04 | keithp | No, the frame buffer implementation returns visual sets cooresponding to the formats supported by the frame buffer. One of the characteristics of 'accelerated' is faster screen updates, which is true when the drawing is done directly to the hardware. |
| 15:12:16 | keithp | Even though there isn't any "acceleration" to speak of. |
| 15:13:07 | keithp | It's also important that apps know when their windows are realized with the actual colors requested rather than being re-rendered at a different depth. |
| 15:13:40 | jg | That isn't what the revised spec says... |
| 15:14:10 | jg | It says: ", applications can expect that any window using one of the visuals in theat set will be accelerated" |
| 15:14:23 | keithp | Yeah, I'll change that. |
| 15:18:53 | keithp | For each of these visual sets, when it |
| 15:18:53 | keithp | is selected in RRSetScreenConfig, applications can expect that any window |
| 15:18:53 | keithp | using one of the visuals in that set will be realized directly in the frame |
| 15:18:53 | keithp | buffer. When realized in the frame buffer, applications can expect that the |
| 15:18:53 | keithp | colors on the screen accurately reflect the expected colors. Rendering to |
| 15:18:53 | keithp | such visuals may be accelerated in hardware and may provide more timely |
| 15:18:55 | keithp | feedback for graphics requests. |
| 15:19:39 | jg | so there will be no guaranteed way of finding out if acceleration is available? |
| 15:20:25 | keithp | And how would you characterize such acceleration? What operations go how much faster with this acceleration? We've shied from this in the past. |
| 15:20:44 | jg | OK, fine... Just questioning.... |
| 15:21:23 | keithp | How about a somewhat stronger guarantee about the colors though: "When realized in the frame buffer, colors on the screen will accurately reflect the expected colors" |
| 15:21:43 | jg | sure. |
| 15:37:08 | jg | keithp: OK, I've merged the revised spec into the main spec.... |
| 15:37:22 | jg | keithp: I'm off to lunch... |
| 15:38:22 | keithp | jgLUNCH: I guess I'll get ready for the day then. |
| 15:38:50 | jgLUNCH | OK, I'll see what I can make out of it... |
| 16:38:20 | jg | keithp: I updated the spec and mailed it to you (with postscript). |
| 16:38:47 | keithp | e-mail lag < irc lag. |
| 17:32:23 | swente | hiho ... |
| 17:33:20 | swente | i just installed "v0.4", and ipkg gives me "crc data error" when i try to install 'task-x'. |
| 17:36:22 | Kero | that's not good. |
| 17:36:43 | Kero | If you try again, what happens? |
| 17:37:14 | nikos | swente: Can you give us the full command line and results? |
| 17:37:48 | swente | i'll retry ... sec please ... |
| 17:38:06 | swente | i type "ipkg install task-x" |
| 17:38:38 | swente | after dowloading "18:40:09 (7.22 KB/s) - `//tmp/ipkg//blackbox_0.1_arm.ipk.4' saved [145909]" i get: |
| 17:38:48 | swente | gzip: stdin: invalid compressed data--crc error |
| 17:38:49 | swente | :-( |
| 17:39:19 | swente | (a warning about a missing dep "xfree-86" in between ...) |
| 17:39:22 | nikos | rm -rf /tmp and try again |
| 17:39:28 | nikos | oops |
| 17:39:30 | nikos | don't do that |
| 17:39:34 | nikos | I mean rm -rf /tmp/ipkg |
| 17:39:39 | swente | eh, xfree86-common |
| 17:40:00 | swente | retrying ... |
| 17:41:10 | swente | i thought about caching - but he's downloading it each time ... |
| 17:41:30 | nikos | Same result? |
| 17:41:37 | swente | ups. it *works* - many thanks :) |
| 17:41:41 | nikos | Great |
| 17:41:44 | nikos | Sorry about that. |
| 17:41:59 | swente | but, it seems to me like a bug that he *downloads*, but tries to use the old file ... |
| 17:42:22 | nikos | I'll have to check on that. I'm not sure what was happening. |
| 17:42:39 | swente | nikos: you're working on ipkg ? |
| 17:42:57 | nikos | swente: Some, mostly cworth. |
| 17:43:39 | swente | nikos: ic. received cworth's mail on the mailinglist (<-- which seems somehow not much frequented) ;) |
| 17:44:03 | nikos | swente: What mailing list? What do you mean by not much frequented? |
| 17:44:28 | swente | ehm, "emdebian discussions", and i mean it's "dead" |
| 17:44:50 | nikos | swente: Ah, yeah he just announced there to let others know about ipkg. |
| 17:44:58 | nikos | swente: That's not a list we make any use of. |
| 17:45:08 | swente | cool ;) |
| 17:45:15 | swente | which others are there ? |
| 17:45:31 | nikos | http://handhelds.org/email_lists.html |
| 17:45:46 | swente | thanks |
| 17:45:55 | nikos | http://familiar.handhelds.org/#mailinglist |
| 17:46:25 | swente | later URL doesn't work for me - saw it a few minutes ago |
| 17:46:40 | nikos | familiar.handhelds.org doesn't work for you? |
| 17:46:56 | swente | (server mumbled something about bad url header - just on #mailinglis-URL) |
| 17:47:11 | nikos | Works fine for me. |
| 17:47:21 | nikos | drop of # and everything after it. |
| 17:47:24 | nikos | s/of/off/ |
| 17:47:32 | swente | curious - now i got it too. |
| 17:47:59 | swente | hm. maybe netscape garbled something ... ?! |
| 17:48:04 | nikos | Maybe |
| 17:48:27 | swente | anyway. do you cross-compile for ipaq ? |
| 17:48:44 | swente | (if i may take your time ... ) |
| 17:48:48 | nikos | Not really, I've setup a cross toolchain but haven't used it much. |
| 17:49:01 | nikos | I can "attempt" to answer a question I guess. |
| 17:49:26 | swente | ic. just wonder if it'd be possible to "direct-crosscompile" with dpkg's source-mechanism. |
| 17:49:56 | nikos | Hmm, I don't know. Seems possible. I'm not really familiar with debian packaging tools I'm afraid. |
| 17:51:01 | swente | :) |
| 17:51:13 | nikos | We just use an arm cross tool chain, I think it is pretty standard. |
| 17:51:17 | swente | well, thanks so far :)) |
| 17:51:20 | nikos | Sure |
| 17:51:45 | Kero | swente: I don't think auto-crosscompiling will work. |
| 17:51:58 | swente | - just downloaded the toolchain-debs... |
| 17:52:07 | swente | Kero: hm ... sad ;) |
| 17:52:17 | Kero | Unless debian packagers put a lot of effort in enabling their Makefiles |
| 17:52:45 | nikos | Kero: They already cross compile for ARM debian from which we steal packages. |
| 17:52:53 | nikos | Kero: What's the difference? |
| 17:52:55 | Kero | i.e. if its somewhere in their policy, it'll work, otherwise not. |
| 17:52:56 | swente | Kero: ic. is it "hard" to port software like "python-gtk" (<- my special wish) |
| 17:53:09 | nikos | swente: We already have it. |
| 17:53:18 | swente | nikos: didn't see it :-) |
| 17:53:30 | Kero | nikos: do they? I compile native on a skiff. |
| 17:53:36 | nikos | swente: The python stuff isn't broken up right now, its all in one ipkg. |
| 17:53:45 | Kero | What prevents debian packagers to do native compiling? |
| 17:53:51 | swente | nikos: great |
| 17:54:00 | Leeds | python-gtk is nice on the iPAQ |
| 17:54:24 | nikos | swente: glade/gtk/python is our recommended devel environment. At least it's mine. ;) |
| 17:54:29 | Kero | I'd guess auto-compiling on a skiff would be doable... |
| 17:54:39 | Kero | will have to try that sometime |
| 17:54:48 | swente | nikos: what is that ? "glade" ? |
| 17:54:58 | Kero | nikos: I sent ruby-tk to a7r :-) |
| 17:55:21 | nikos | swente: GUI builder |
| 17:55:29 | swente | Leeds: hope so :) |
| 17:55:53 | nikos | swente: http://glade.gnome.org |
| 17:56:02 | swente | nikos: yumm yumm .... |
| 17:56:46 | Leeds | likes building GUIs by hand :-) |
| 17:56:52 | | a7r was last seen on #handhelds.org 7 hours, 50 minutes and 58 seconds ago, saying: is away: -> bed [Sat May 26 11:05:54 2001] |
| 17:56:52 | nikos | ibot: seen a7r |
| 17:57:10 | swente | i'm really new to linux on ipaq - but i just want to say that it's *great* :) |
| 17:57:26 | nikos | Thank you. |
| 17:57:37 | Leeds | so who's going to wake a7r up then? :-) |
| 17:57:46 | nikos | Good question |
| 17:58:28 | jg | I don't have his home phone... |
| 17:58:58 | Leeds | better hope he's got a decent alarm clock... |
| 17:59:00 | keithp | thinks we should all YELL REALLY LOUD and see if that works. |
| 17:59:23 | a7r | Morning.. |
| 17:59:29 | nikos | Heh, morning |
| 17:59:34 | jg | boy, he's alive :-). |
| 17:59:38 | Leeds | ah-ha :-) |
| 17:59:54 | a7r | How's it going guys? |
| 18:00:27 | a7r | is back (gone 07:54:33) |
| 18:00:49 | Leeds | too hot in London :-( |
| 18:01:11 | swente | nikos: glade ... seems good |
| 18:01:15 | a7r | It's pretty gloomy in SoCal.. |
| 18:01:27 | a7r | Anyhow, let's kick this off. |
| 18:01:27 | jg | here too (in MA). |
| 18:01:30 | Kero | Eindhoven is probably just as hot as London |
| 18:02:02 | Kero | Otherwise, this is my third day off in a row, which gives my plenty of time to hack on iPAQ-related stuff. |
| 18:02:06 | a7r | How do you guys feel about moving away from people living on their iPAQs as root? |
| 18:02:15 | jg | a7r: necessary.... |
| 18:02:19 | nikos | Sounds like a very good idea |
| 18:02:55 | jg | Biggest issue is how to log in... Graffitti passwords will be a headache.... |
| 18:02:58 | Kero | a7r: feels good |
| 18:03:03 | a7r | I'd like to try to make the transition to that for v0.5. |
| 18:03:04 | swente | is away: playing with glade |
| 18:03:11 | a7r | jg: I had the idea of using a puzzle of some sort to authenticate. |
| 18:03:15 | Leeds | running as root is bad |
| 18:03:18 | Kero | jg: login without passwd. |
| 18:03:31 | a7r | or maybe even a signature if we have anyone who knows how to do something like that. |
| 18:03:32 | Leeds | gesture-based login? |
| 18:03:33 | nikos | I'm not sure login is really necessary for v0.5 |
| 18:03:35 | keithp | I don't think we need to login, just select a user. I'm after permissions, not security. |
| 18:03:37 | jg | Kero: fine for now, but someday we need something more secure.... |
| 18:03:57 | keithp | thinks we can have a screen saver that asks for a password. |
| 18:04:08 | jg | keithp: Yup. Until we can authenticate for real in some more convient way... |
| 18:04:10 | nikos | welcome Morph |
| 18:04:16 | Morph | nikos: hey |
| 18:04:17 | a7r | keithp: Nod.. I'd like a little bit of front end authentication, but for now you're right. |
| 18:04:21 | a7r | Morph: Hola. |
| 18:04:22 | jg | keithp: Screen saver goes off too often. |
| 18:04:26 | Morph | a7r: evening. |
| 18:04:32 | Morph | er morning. |
| 18:05:24 | a7r | When it comes down to it, we need an: xdm like application on the front end, sudo to make executing things as root easy, and a user management tool that can stick everything in the right places (probably through sysset). |
| 18:05:28 | keithp | jg: current screen saver is bogus; palmtops use a button to enable the backlight and suspend instead of blanking the screen. |
| 18:05:37 | nikos | a7r: Sounds good. |
| 18:05:50 | keithp | As long as 'sudo' doesn't need a password, I think we'll be fine. |
| 18:06:03 | a7r | nod.. it can be configured to not use one. |
| 18:06:04 | jg | we now have suspend at the push of the power button... |
| 18:06:17 | Leeds | something a touch more than 'click here to become root' might be nice... |
| 18:06:24 | a7r | once we get the authentication thing figured out, it can authenticate using PAM, with whatever system you like. |
| 18:06:45 | keithp | Leeds: we should hide 'root' and just have apps 'sudo' as needed for configuration stuff. |
| 18:06:58 | Leeds | keithp: good point |
| 18:07:14 | a7r | keithp: yup.. Mac OS X all works that way. |
| 18:07:41 | keithp | a7r: I'm not thinking desktop systems, but palmtops. Physical security is much more reasonable when you've got the box in your pocket. |
| 18:07:48 | Leeds | so we're talking about (under the hood) two users - root and 'other'? |
| 18:08:02 | a7r | Also, some bootstrap procedure is going to be required to get the user created as a bootstrap measure.. |
| 18:08:31 | a7r | keithp: Nod, and people would be able to hack around any front end security easily w/ the current state of the bootldr and kernel. |
| 18:08:32 | keithp | It'd be nice to allow multiple users so you can hand your box to a friend and let them play; not that we need this today, but we shouldn't assume 'other'. Besides, most of us want to use an existing UID so that NFS will work right. |
| 18:08:49 | jg | keithp: Palms also have some security mechanism in case you lose them. Currently not very usable.,.. |
| 18:08:51 | a7r | yeah.. multiple configurable users is a must. |
| 18:09:47 | a7r | OKay, I'll push sudo into the unstable feed, and start working on this. If anyone is interested on hacking on the user-side of things, let me know. |
| 18:10:09 | Leeds | have a default user or have to login to start up? (I'm trying to think through options) |
| 18:10:26 | keithp | How about encrypted file system for private data? That would take a password and could clear it on suspend. |
| 18:10:41 | nikos | Well, keep in mind true startup (reboot, return from shutdown) should not happen very often. |
| 18:10:41 | a7r | Leeds: just have a user you can choose to log in as, and also have the option to log into any user by default. |
| 18:10:59 | a7r | keithp: You thinking a loopback in RAMFS or something? |
| 18:11:47 | keithp | Or something. It'd be really nice if there was a single password for the "private" data but which allocated storage out of JFFS2 |
| 18:12:08 | Kero | guys, a PDA is used by one person. Don't look for elaborate solutions, look for simple ones. |
| 18:12:12 | jg | keithp: note that current encryption code often does compression as well... |
| 18:12:21 | Kero | Logging in as default, non-root, without password is fine. |
| 18:12:26 | jg | Kero: PDA's are also lost alot... |
| 18:12:36 | jg | but we need not solve this problem instantly... |
| 18:12:40 | Kero | jg: not by me :-) |
| 18:12:43 | keithp | Kero: yeah, no login, but it'd be nice if we had strong encryption for my visa number. |
| 18:12:45 | Kero | jg: you're right, though. |
| 18:12:49 | a7r | Nod, it's just a matter of pushing this all forward. |
| 18:12:51 | nikos | I'm sure just as compression can be plugged into jffs2, so could encryption. |
| 18:13:03 | jg | Just keep it in mind for later... |
| 18:13:18 | Kero | once compression is in place, encryption /should/ be relatively easy... |
| 18:13:26 | a7r | keithp: we should experiment with UIs for authentication. |
| 18:13:33 | keithp | nikos: yeah, kinda like CSS -- ioctls that pass the key down to the kernel so it can decrypt files. |
| 18:13:34 | nikos | Why can't files simply be individually compressed as you would on any system? |
| 18:13:44 | nikos | s/compressed/encrypted/ |
| 18:13:53 | jg | Yeah, gesture based authentication, either touchscreen or accelerometer.... |
| 18:13:59 | a7r | yup. |
| 18:14:01 | Leeds | in theory, most multi-user stuff should just fall out relatively easily once there's some support for *changing* user. |
| 18:14:16 | keithp | nikos: we'd like a central single place to unlock the file system that we could be certain would go away on suspend. |
| 18:14:23 | a7r | jg: I always thought the idea of manipulating puzzle pieces into the right state would be cool.. entirely visual. |
| 18:14:46 | nikos | a7r: Cool, but seems slow. |
| 18:14:56 | Leeds | a7r - people remember alphanumeric passwords because they think like that - puzzles seem less natural |
| 18:15:00 | a7r | Leeds: sudo offers that more than we could ever use. |
| 18:15:04 | nikos | a7r: At least if the puzzle had enough combinations to be secure. |
| 18:15:05 | Kero | keithp: suspend options sounds very OK. |
| 18:15:15 | a7r | Leeds: I don't think so.. people remember alphanumeric passwords because they've never had another option. |
| 18:15:34 | a7r | but if we're using PAM, we can experiment with whatever we want. |
| 18:15:55 | a7r | gestures, pictures, pussles, signatures,.. |
| 18:16:01 | Leeds | a7r: I was thinking more GUI for changing users - I meant the underlying stuff (filesystem, ID, etc.) is easy |
| 18:16:02 | a7r | er puzzles |
| 18:16:04 | nikos | I don't think we need to close off our options, this is an extremely good opportunity to experiment. |
| 18:16:13 | Leeds | I like the sound of pussles :-) |
| 18:16:15 | keithp | a7r: mac's use voice prints; we've got a mic. |
| 18:16:23 | a7r | keithp: yeah, that too. |
| 18:16:41 | jg | Neil was hacking on xdm: I'll ask him what state it is in... |
| 18:16:42 | Leeds | login by CueCat - there's a PAM module for it... |
| 18:16:55 | keithp | And they're cheap too! |
| 18:16:58 | a7r | Anyhow, anyone want to say anything else on the matter before we start coding? |
| 18:17:07 | Kero | Leeds: and tattoo a barcode on your stomach? |
| 18:17:08 | jg | nope |
| 18:17:24 | a7r | OKay. |
| 18:17:31 | Kero | a7r: no, I said what I wanted to say. |
| 18:17:35 | a7r | Next on my list is IPv6.. |
| 18:17:39 | Leeds | Kero: I have a company ID card with a barcode on it - if I lose that, losing access to my iPAQ is the least of my worries... |
| 18:17:47 | Kero | Leeds: :-) |
| 18:17:50 | swente | nikos: glade ... can't it write python-files ? |
| 18:17:54 | a7r | I'd like to work it into Familiar in a major way.. anyone interested in doing the work w/ me? |
| 18:18:05 | nikos | swente: No, libglade reads the xml glade files currently. |
| 18:18:14 | a7r | swente/nikos: can you guys /msg instead? |
| 18:18:18 | nikos | sure |
| 18:18:27 | Leeds | a7r: how stable is the existing Linux stuff, userspace and kernel? |
| 18:18:37 | a7r | Leeds: varrying degrees.. people do run it, though. |
| 18:18:50 | Kero | a7r: alternatively, we could go to #familiar.meeting |
| 18:18:53 | jg | IPV6 seems to work fine, modulo one bug we've noticed.... |
| 18:18:54 | a7r | I'm using KAME with BSD on my house routers.. I haven't dug into the Linux side of things. |
| 18:19:02 | a7r | Kero: Maybe next time. |
| 18:19:25 | jg | We're running it, and running mobile IP, and transitioning between networks very smoothly... |
| 18:19:31 | Morph | Back |
| 18:19:38 | a7r | OKay. |
| 18:19:39 | Leeds | only thinking that if it's going to add instability to the system for little *current practical* value... |
| 18:19:56 | jg | Its a kernel module: we won't load it unless you use it... |
| 18:20:01 | a7r | jg: What kind of work is required on the daemon and config side? And can all the IPv6 stuff be loaded as modules? |
| 18:20:21 | Leeds | okay, cool |
| 18:20:49 | jg | The user space code has to be built for V6; Steve Ayers and Jamey know what has to be done. |
| 18:21:03 | jg | The kernel modules are modules, and should be packaged independently. |
| 18:21:06 | a7r | OKay.. that could get interesting and possibly divergent from Debian, but that's fine. |
| 18:21:26 | a7r | jg: what about the X side of things? |
| 18:21:55 | jg | I was about to merge patches when my laptop got eaten by 2.4.2. Won't get to it until July at best... |
| 18:22:09 | a7r | OKay, no worries.. |
| 18:22:35 | keithp | Others may hack X in the meantime; there's sporadic interest. |
| 18:22:48 | jg | There are two sets of patches around... |
| 18:22:49 | a7r | nod. |
| 18:23:00 | jg | I looked at them; they need a bit of work to be "right"... |
| 18:23:48 | a7r | Nod. |
| 18:24:32 | a7r | OKay.. enough of that.. anyone interested in working on that w/ me? |
| 18:25:04 | keithp | which? IPV6 in general or X in particular? |
| 18:25:26 | a7r | IPv6. |
| 18:25:29 | a7r | er in general |
| 18:25:42 | jg | The biggest effort is setting up an IPV6 environment to work in... |
| 18:25:56 | a7r | nod.. I set mine up a couple nights ago.. |
| 18:26:04 | a7r | got routed a /56 from easynet in Belgium. |
| 18:27:32 | a7r | OKay.. we can come back to it maybe.. I'll just threaten Morph to get his IPv6 network up, so he can test it. |
| 18:27:48 | jg | We have it set up at CRL... |
| 18:28:02 | a7r | Anyone have anything else they want to talk about (e.g. PIM suite, issues w/ anything they want resolved for v0.5).. |
| 18:28:03 | jg | Biggest issue is how much time we'll have between now and June 18. |
| 18:28:04 | a7r | jg: nod. |
| 18:28:20 | a7r | Oh, BTW, I think I'm going to be out in Boston around then. :> |
| 18:28:29 | Kero | v0.5 will be released June 18? |
| 18:28:36 | nikos | Installation. I get the idea from Jamey that they are starting to feel comfortable with CF install. |
| 18:28:37 | jg | I've got the companionlink binaries in captivity: they are working on packaging them. |
| 18:28:45 | jg | Kero: No, we have two major demos that day... |
| 18:28:49 | Kero | ah :-) |
| 18:28:51 | nikos | We need to plan on making CF install images with v0.5 if not before. |
| 18:28:51 | Kero | good luck! |
| 18:28:53 | a7r | Kero: It'll be released when it starts working.. which will hopefully be around there. |
| 18:29:10 | Kero | okay. |
| 18:29:12 | a7r | nikos: Hmm.. let me add that to my release list. |
| 18:29:13 | Leeds | are people working on mingle-type PIM stuff? |
| 18:29:18 | a7r | nod. |
| 18:29:29 | a7r | Morph and I are getting together to do some hacking and BBQ on Mingle this weekend. |
| 18:30:02 | Kero | mingle? |
| 18:30:15 | a7r | Kero: You got your iPAQ pointed at the unstable feed? |
| 18:30:20 | Leeds | I managed to impress an Psion user with it this week... |
| 18:30:26 | nikos | What about primary WM issues? Do we think ion is the way to go and forget BlackBox? |
| 18:30:42 | a7r | nikos: I do, lets talk about that in a sec. |
| 18:30:45 | nikos | K |
| 18:30:50 | a7r | Leeds: hah, what did they like about it? |
| 18:30:51 | Kero | a7r: Yes, I'll look at it. |
| 18:31:16 | Kero | thinks a decent distro for a PDA needs a pim-suite. |
| 18:31:17 | Morph | nikos: ion is the way to go, which some additions to it of course. |
| 18:31:27 | Morph | Kero: thats what mingle and company will be. |
| 18:31:29 | Kero | read: I want a scheduler/agenda app :-) |
| 18:31:35 | a7r | Kero: then write one. |
| 18:31:41 | Leeds | a7r: the lots of extra fields and the slot for the photo - and I think he liked the layout, even in landscape (I don't like portrait...) |
| 18:31:53 | a7r | Leeds: cool cool. |
| 18:32:02 | Kero | a7r: If I have the time, I will :-) I do other stuff, too... |
| 18:32:16 | a7r | jg: how long do you guess till we see some CompanionLink ipks? |
| 18:32:20 | a7r | Kero: we all do. |
| 18:32:24 | Leeds | slightly related question: how easy is it to set a wakeup before suspending? |
| 18:32:38 | Kero | a7r: I know. |
| 18:32:40 | jg | The guy working on it is new to Linux... I suspect it will be sometime later this week. |
| 18:32:48 | a7r | jg: OKay.. |
| 18:32:50 | jg | I haven't tried the Windows side of it yet at all... |
| 18:33:13 | a7r | Leeds: the work on the RTC is there.. some people were talking about hacking atd to use the RTC as the backend. |
| 18:33:30 | Leeds | a7r: atd would be great :-) |
| 18:33:39 | jg | Also cron will need work... |
| 18:33:42 | a7r | yup. |
| 18:34:26 | a7r | there are a couple implementations available (e.g. Vixie's,. Net/Open BSDs).. |
| 18:34:36 | a7r | we'll have to look at the code. |
| 18:35:30 | nikos | My personal opinion is that we need to shy away from saving a bunch of temporary configuration information in FS like is normally the case on a desktop or server. |
| 18:35:42 | Leeds | I assume only one wakeup can be set in the RTC? So something at a higher level needs to manage a queue? atd would probably be the right place for that... |
| 18:35:47 | a7r | nikos: what do you mean? |
| 18:36:05 | a7r | Leeds: exactly. |
| 18:36:42 | nikos | a7r: Most UNIX scheduling daemons (like crond, atd) store the list of jobs on the filesystem, and files on the filesystem are editted to schedule jobs. Making a lot of FS edits on a handheld seems like a poor design idea. |
| 18:36:59 | jg | nikos: it isn't that frequent.... |
| 18:37:45 | Leeds | nice things about filesystems: (potentially) non-volatile, editable with text-editor (or similar)... |
| 18:37:50 | a7r | nikos: if it's going to do that, it's going to happen in /var.. and /var should be almost entirely RAMFS. |
| 18:37:53 | nikos | jg: I feel like it would be more frequent on a PDA than the average desktop or server. |
| 18:38:19 | jg | Nah.... The schedular app doesn't get played with that often... |
| 18:38:23 | nikos | a7r: I think there are more wrinkles to it, but let's set it aside for now. |
| 18:38:25 | jg | And it needs to go into flash anyway. |
| 18:38:32 | jg | And it is a journalling file system.... |
| 18:39:03 | a7r | nikos: if you've got an issue w/ a real specific part, your best bet is to show an example, so we can fix it. |
| 18:39:05 | nikos | I will write up my thoughts in an email at some point. |
| 18:39:09 | a7r | nod. |
| 18:39:35 | Leeds | jg: I think the point is that if you're setting alarms for (for example) all your meetings, you could be changing them quite often. |
| 18:39:35 | a7r | edwardam: hey.. |
| 18:39:53 | jg | Leeds: not my experience... |
| 18:39:53 | edwardam | hey .... I just got back from the city ... Had to install a tape drive and see that package off. ... |
| 18:40:26 | a7r | When it comes down to it.. lets code with what we've got, and see where we can go w/ it. |
| 18:40:28 | keithp | Leeds: but we need non-volatile storage for the alarms so that they're preserved across reboot. I like the idea of not needing the app running for it to receive alarms though. |
| 18:40:36 | nikos | a7r: good point. |
| 18:40:45 | Leeds | jg: not my experience - I stick post-its on my monitor... :-) |
| 18:41:14 | a7r | OKay.. you guys wanna talk window managers? |
| 18:41:24 | edwardam | what did I miss ? |
| 18:41:30 | keithp | I'm chatting with the ion author via email this morning. |
| 18:41:33 | nikos | edwardam: I'll send you a log |
| 18:41:35 | a7r | edwardam: I'll send out a backlog. |
| 18:41:44 | edwardam | cool |
| 18:41:57 | a7r | keithp: What'd he/she have to say? |
| 18:42:32 | keithp | Interested in hacking, but needs some direction on what we need. We're talking about how to get apps docked. |
| 18:42:41 | edwardam | a7r: We should not drop ion for blackbox and vice - versa IMHO |
| 18:43:29 | a7r | edwardam: That's fine.. but I think ion is more the direction that things should be going.. although it needs major hacking. |
| 18:43:32 | keithp | I'm not sure; I think we need to focus on a handheld-specific WM. Not to *disallow* other wms, but I think BB is the wrong direction. |
| 18:43:57 | nikos | I agree, after playing with ion for a little while I think it has some promise. |
| 18:43:58 | keithp | And BB is C++ while ion is C. |
| 18:44:02 | edwardam | a7r: any reason why? (I'm not challenging the statement, just wondering what your and everyones thoughts are) |
| 18:44:04 | a7r | keithp: My only issue is w/ ion and multi-windowed apps.. I wish there was a way you could have it be smart about placing windows for apps taht need them. |
| 18:44:36 | keithp | I think there's enough ICCCM stuff for that to be made workable; app opens new window and ion automatically splits current pane. |
| 18:44:49 | a7r | edwardam: ion is setup to give you an easier way to manage your screen realestate.. which the iPAQ doesn't have much of. blackbox is dependent on libstdc++ which sucks. |
| 18:45:05 | a7r | keithp: Hmm... |
| 18:45:15 | edwardam | a7r: agreed. (I played with ion before doing my version of the blackbox hack) |
| 18:45:54 | nikos | a7r: I had issues with multi-window apps as well, I'm beginning to feel that new apps for handhelds need to be designed to handle that internally (tabbed dialogs, etc.) |
| 18:45:59 | a7r | keithp: docking and some way of setting up sticky apps would be nice to add. |
| 18:46:18 | Kero | nikos: apps should definitely be PDA-aware. |
| 18:46:31 | edwardam | does ion support multiple desktops/views ? |
| 18:46:33 | keithp | My idea for docking was that ION place docked apps in the titlebar of one of the frames; you could drag the dock around. |
| 18:46:44 | nikos | There does need to be workable support for mutli-windows apps however. |
| 18:46:53 | a7r | edwardam: Yup. |
| 18:46:54 | edwardam | keithp: define dock in this scenario |
| 18:47:07 | edwardam | a7r: cool ... I forgot |
| 18:47:32 | keithp | edwardam: a "dock" is an undecorated area of the screen holding a collection of small apps (clocks, launcher menus). |
| 18:47:35 | a7r | keithp: Hmm.. I'd like it more along the lines of just a mini-titled frame. |
| 18:47:55 | edwardam | keithp: okay ... just wanted to make sure I was one the same page |
| 18:47:57 | Kero | who needs titles on their frames anyway? |
| 18:48:07 | keithp | a7r: I like the notion of sharing a title bar; you could stick it in its own frame if you like. |
| 18:48:08 | a7r | Kero: they're good for control. |
| 18:48:25 | Kero | control, yes. |
| 18:48:25 | keithp | Kero: and we need a place to put the keyboard widget anyway. |
| 18:48:30 | a7r | keithp: nod.. that's cool, my only beef would be someone split a title bar in 2, where would the docked apps go? |
| 18:48:31 | Leeds | fscking unstable PPPoverATMoverUSB driver - someone fancy sending me a few minutes of log? |
| 18:48:36 | jg | we could just use the ICCCM icon window stuff for docking, and let the apps provide the window.... |
| 18:48:48 | a7r | jg: amen. |
| 18:48:54 | nikos | Leeds: One of us will put the whole thing up at some point. |
| 18:48:57 | keithp | jg: yes, the apps provide the window, the WM just reparents to the dock. |
| 18:49:02 | Kero | is going to configure the window-borders of ion away |
| 18:49:07 | jg | Yup. Very easy scheme... |
| 18:49:40 | a7r | anyhow got a link to vlad's app launcher that he wrote in Python a while back? |
| 18:49:48 | keithp | a7r: when the frame was split, the dock could stay physically in the same location; gravitating to whichever pane could hold it. |
| 18:50:19 | edwardam | a7r: hmmm. An app launched is probably pretty easy to re-write ... |
| 18:50:21 | Morph | hmm..cworth is away |
| 18:50:26 | a7r | keithp: Nod. |
| 18:50:33 | a7r | edwardam: nod, but this one actually worked well. |
| 18:50:53 | edwardam | a7r: hah... :-) ... Never seen it. |
| 18:51:44 | keithp | jg: I just reread -- 'icon windows'? Hmm. That could work, but I'm afraid I don't quite know how you'd get input to them. Icon windows aren't usually expecting mouse clicks. |
| 18:51:55 | jg | why not? |
| 18:51:59 | jg | Just windows... |
| 18:52:12 | wabbit | A UI suggestion -- make one of the buttons pop up the menu / list of running apps. Hidden otherwise. |
| 18:52:21 | keithp | jg: yeah, but usually the WM steals the clicks to manage the icon. |
| 18:52:35 | salo | can someone tell me how restrictive 32mb of ram ends up being ? |
| 18:52:39 | keithp | wabbit: ion places hidden titles in a line at the top of the frame. Could change that to a menu when it got too full. |
| 18:52:40 | Kero | wabbit: you are right, there are five buttons left to use and abuse. |
| 18:53:01 | nikos | anyone seen the transparent pallettes of morphic Squeak? That could be very handy on a handheld. |
| 18:53:17 | Kero | nikos: the wht of the what? |
| 18:53:19 | keithp | nikos: I haven't written the translucent window extension yet. |
| 18:53:39 | wabbit | I'm thinking the farthest right button (up arrow) would be a good choice for both landscape and portrate mode. |
| 18:53:47 | nikos | Forget that thought for now, I'll bring it up again at a later date. |
| 18:54:14 | Leeds | we shouldn't rely on being able to reserve buttons for wm/system stuff - apps will want them at least some of the time. The record and power buttons are probably okay... |
| 18:54:17 | salo | any comments on 32 mb ram ? |
| 18:54:31 | a7r | salo: hold on a sec until this meeting is over. |
| 18:54:32 | jg | salo: TBD.... |
| 18:54:37 | salo | oh meeting ! sorry |
| 18:54:41 | nikos | Leeds: I agree, they shouldn't be reserved, but it should be an option. |
| 18:55:15 | a7r | OKay.. lets get some code written.. I know cworth has hacked on ion a bit.. |
| 18:55:16 | Leeds | so there should always be a non-hard-button way of getting at functionality... |
| 18:55:25 | a7r | keithp: do the ion guys have any docking plans already? |
| 18:55:32 | wabbit | Leeds: Agreed -- however, make it a configurable option. Also, perhaps have some sort of "agreement" such that if an app takes over a button, it provides a means of passing controll to the menu/doc list. |
| 18:55:46 | Kero | Leeds: we can develop a policy of using two buttons for WM and three for apps. |
| 18:55:49 | keithp | a7r: he's thought about it a bit, wants to be able to make the dock smaller than full-width/full height though. |
| 18:55:59 | Kero | apps need to be iPAQ aware anyway when they rely on those buttons. |
| 18:56:28 | jg | Kero: There are keysyms defined for those buttons: eg "Calendar" |
| 18:56:35 | a7r | keithp: Nod.. makes sense. |
| 18:56:54 | a7r | keithp: the title bar would be good for that then.. on the iPAQ it might be too small for the icons. |
| 18:56:56 | Kero | jg: yes, but they are still iPAQ specific |
| 18:56:57 | Leeds | I've done some Palm development - that's where I'm coming from |
| 18:57:02 | keithp | a7r: especially on the ipaq; I'd like to share the titlebar and keep everything else for apps. |
| 18:57:12 | jg | Nope: they are generic keysyms... |
| 18:57:39 | jg | You can sometimes find such keys on keyboards, and often on various PDA's. |
| 18:57:46 | keithp | Leeds: it's also nice to expose the UI through the screen so there isn't any magic hidden functionality. |
| 18:57:48 | Kero | jg: hm, okay. |
| 18:57:50 | a7r | keithp: nod. |
| 18:57:52 | wabbit | Leeds: Yes, but there's *always* the "Home" button on the Palm to get gain control. |
| 18:58:27 | Leeds | wabbit: and maybe mapping the record button on the iPAQ to something like that would be nice - it doesn't seem as obviously useful to other apps |
| 18:59:01 | edwardam | Re: Buttons. Don't confuse the user. They should do what their icons say. |
| 18:59:13 | Leeds | As an example - the gameboy emulators I've played with want a four-way pad and four buttons... |
| 18:59:17 | edwardam | Now for now that doesn't matter much... But I think it will later on... |
| 18:59:29 | a7r | Guys, lets table this.. produce some patches, and we can all test it out. |
| 18:59:33 | jg | Remember that you can assign multiple keysyms to the same key. |
| 19:00:15 | Leeds | jg: then you get into who has priority over the keypress - the system or the app... |
| 19:00:19 | nikos | a7r: Other topics? |
| 19:00:22 | edwardam | Leeds: the ipaq's pad can only go one way at once ... |
| 19:00:31 | keithp | I'll work with Valkonen Tuomo and see if I can't get him excited. |
| 19:00:31 | a7r | Anything else you guys want to talk about? |
| 19:00:34 | Morph | edwardam: the buttons should do different actions depending on what app is in use. |
| 19:00:47 | Leeds | edwardam: I know :-( It's a pity for games... |
| 19:00:58 | edwardam | Morph: then don't label them :-) |
| 19:01:11 | a7r | Going once.. |
| 19:01:18 | nikos | Going twice... |
| 19:01:22 | edwardam | sold! |
| 19:01:27 | nikos | Last chance |
| 19:01:27 | a7r | to the lady in the red dress. |
| 19:01:31 | nikos | Anybody? |
| 19:01:32 | Leeds | I'l buy that for a dollar! |
| 19:01:34 | Morph | looks at nikos |
| 19:01:36 | edwardam | For $500.00 |
| 19:01:45 | keithp | I've got resizing working; I'll have rotation by Monday. |
| 19:01:46 | nikos | Meeting is adjourned |
| 19:01:46 | edwardam | I want my $2.00! |
| 19:01:51 | a7r | OKay, this is done.. I'll send out the log to familiar@ |
| 19:02:04 | nikos | Sorry |
| 19:02:14 | Leeds | keithp: great! :-) |
| 19:02:18 | a7r | werd.. thanks for showing up, guys. |
| 19:02:31 | keithp | ttatf. |
| 19:02:59 | Leeds | have a nice day, American folks... |
| 19:03:17 | wabbit | What, we Canadians don't count? 9-) |
| 19:04:20 | Kero | and Europeans, and.... |
| 19:05:28 | Leeds | it's 9 or 10 pm in Europe - it's getting dark out. Have a nice night, Europeans and Africans, and a nice day, Eastern Asians :-) |
| 19:05:29 | edwardam | and Autralians ... (No wait ... I'm an American) |
| 19:05:32 | Morph | a7r: I think the default gtk theme thats on there needs some minor mods. |
| 19:05:41 | edwardam | Morph: I second that :-) |
| 19:05:41 | Morph | s/on there/in familiar/ |
| 19:05:46 | jg | I third that... |
| 19:05:53 | jg | Fonts too small, screen way too dark... |
| 19:05:56 | a7r | Heh, you guys have no style.. what do you think needs changing? |
| 19:06:05 | Morph | it looks good other than text box is too dark. |
| 19:06:10 | edwardam | colors (too dark) fonts (a little too small) |
| 19:06:10 | a7r | OKay. |
| 19:06:12 | Morph | I think it other than that. |
| 19:06:26 | Leeds | I like the font size - gets a good amount of text on screen |
| 19:06:28 | a7r | edwardam: come up w/ a better one, and let me take a look at it. |
| 19:06:52 | edwardam | a7r: Okay. I'll play a bit with the current stuff.... |
| 19:07:03 | a7r | Morph: you just wanna the color of the text itself? Make it brighter? |
| 19:07:24 | edwardam | a7r: So ... We needs a familiar.themes.org now. :-) |
| 19:07:33 | a7r | edwardam: haha |
| 19:08:09 | Leeds | anyone for a theme switching GUI? :-) |
| 19:08:23 | Morph | a7r: No, the background color of the text boxes. |
| 19:08:44 | a7r | Morph: nod. |
| 19:08:45 | Morph | a7r: http://gareth.wiked.org/1.jpg <-- see that? |
| 19:08:51 | Kero | Leeds: user switching first, theme-switching second :-) |
| 19:09:21 | nikos | Is there some sort of 'Kill' stroke for ion? |
| 19:09:29 | nikos | ion/fstroke |
| 19:09:32 | a7r | Morph: yeah,.. fear the directions to my house. :> |
| 19:09:38 | Morph | :) |
| 19:09:50 | Morph | Huge party at a7r's tomorrow! |
| 19:10:14 | edwardam | just need tickets to CA ... |
| 19:10:27 | Kero | which city is that? |
| 19:10:30 | Morph | edwardam: nikos is flying everyone out. |
| 19:10:37 | nikos | Uh, yeah, whatever |
| 19:10:37 | Kero | hm, which /continent/ is that? |
| 19:10:38 | Leeds | it's only a 12 hour flight... |
| 19:10:39 | a7r | Morph: we need to plan the West Coast Handheld Hackfest. |
| 19:10:47 | Morph | a7r: Yeah. |
| 19:10:52 | a7r | Kero: North America, US, CA, Santa Barbara |
| 19:10:58 | keithp | You can have a hackfest during the XFree86 conference if you like. |
| 19:11:06 | a7r | keithp: when/where is that? |
| 19:11:09 | Morph | a7r: I'll need your herman miller chair and a raised platform. |
| 19:11:13 | keithp | November, in Oakland during ALS. |
| 19:11:14 | a7r | Morph: haha |
| 19:11:14 | Kero | a7r: thanks for the invitation, but I have to say no... |
| 19:11:34 | a7r | keithp: Hmmm.. we should definitely do something, then. |
| 19:11:39 | Leeds | European hackfest? :-) |
| 19:11:41 | keithp | a7r: you're going to be there giving a talk in any case. |
| 19:11:54 | a7r | keithp: Hahaha, damn, what's my topic? :> |
| 19:12:11 | Morph | a7r: hmm..if you change the color of the text box background, you'll have to change the text color too. |
| 19:12:12 | keithp | a7r: topic is your problem, my problem is filling the schedule. |
| 19:12:23 | a7r | keithp: werd. |
| 19:12:48 | keithp | a7r: please fill out an abstract at usenix.org... |
| 19:12:55 | a7r | keithp: will do. |
| 19:12:57 | Morph | a7r: you could talk about "How not to get lost and mugged in Las Vegas" |
| 19:13:00 | Kero | Leeds: why not? |
| 19:13:14 | nikos | a7r: I will be getting first draft install bootldr toasting WinCE instructions by Tuesday at the latest. |
| 19:13:30 | keithp | Morph: or my 50 favorite sushi orders. |
| 19:13:36 | a7r | nikos: OKay,.. I'm going to do the v0.4.1 release before then, so we'll have to use those in v0.5. |
| 19:13:37 | Leeds | Kero: are there that many of us? |
| 19:13:40 | Morph | keithp: haha yeah. |
| 19:13:48 | edwardam | HackFest during LWE? |
| 19:13:48 | Kero | Leeds: dunno, two already ;-) |
| 19:13:53 | nikos | a7r: When on v0.4.1? I can try to get it faster. |
| 19:14:03 | Kero | Leeds: but there are plenty iPAQs in Europe. |
| 19:14:05 | keithp | Ellie young says there's good sushi within walking distance of ALS this year. |
| 19:14:06 | a7r | nikos: Probably Sunday.. so I can test it tonight. |
| 19:14:17 | a7r | keithp: rock, you still gonna take me out for a beer and sushi? ;> |
| 19:14:24 | nikos | a7r: I'll see what I can do. |
| 19:14:29 | Kero | Leeds: and a lot os ppl using them to hack on, I guess. |
| 19:14:34 | edwardam | dammit .... I gotta get ready to go to dinner with another couple .... Why does my wife keep thinking I LIKE people? ... |
| 19:14:34 | keithp | is going to take a *lot* of people out for sushi. |
| 19:14:43 | Leeds | Kero: tangent is somewhere near London - I keep trying to persuade people to come to my LUG so we can have a BOF :-) |
| 19:15:06 | a7r | keithp: killer. |
| 19:15:06 | edwardam | Anyone going to be around tommorow? |
| 19:15:07 | Morph | edwardam: throw good at them during dinner, that'll convince her. |
| 19:15:11 | Kero | Leeds and which country/city would that be? |
| 19:15:20 | Leeds | Kero: London, UK |
| 19:15:21 | edwardam | Morph: Throg good? |
| 19:15:23 | edwardam | err |
| 19:15:27 | edwardam | Morph: Throw good? |
| 19:15:31 | Kero | hm, /me has never been to London :-) |
| 19:15:36 | Morph | edwardam: s/good/food/ |
| 19:15:38 | Kero | Sounds like a good reason :-) |
| 19:15:38 | Leeds | edwardam: long day? :-) |
| 19:15:43 | edwardam | Morph: ahhh ... |
| 19:15:54 | Morph | edwardam: it made sense on my side. |
| 19:16:07 | edwardam | Leeds: nah ... I just really wanted to spent it working on hh.org/ipaq stuff ... But I had to go to work .. and now to dinner/movie with these people... |
| 19:16:19 | edwardam | anyway ... later... |
| 19:16:24 | edwardam | gotta be there by 5 .. |
| 19:16:26 | Kero | bye! |
| 19:16:49 | Leeds | Kero: at some point, I'll be doing a talk on iPAQ stuff at the LUG - I accidentally gave half of one last year... :-) |
| 19:17:25 | Kero | cute, keep me posted, keep /us Europeans/ posted. |
| 19:17:32 | edwardamAWAY | is away: I'm busy |
| 19:17:41 | Kero | might drop by, .nl is close to London anyway. |
| 19:17:51 | Leeds | I was down to talk about Palm and Linux, but I'd bought my iPAQ three days earlier, and that somehow became more interesting than how to write Palm software with Linux... |
| 19:18:11 | Kero | :-) |
| 19:19:27 | Leeds | seriously - if you're interested, there's a pretty good hackers conference at the end of June in Manchester - we've got a talk on 'Linux on PDAs' and a talk by David Woodhouse on JFFS... |
| 19:19:39 | Kero | Leeds: url? |
| 19:20:26 | Leeds | http://www.ukuug.org/events/linux2001/ - I've been to the past two and I'll be at this one. I'm currently waiting to hear from my manager's manager if my company will pay for me - they did the past two years |
| 19:21:21 | Leeds | plus one or two other talks as well :-) |
| 19:22:06 | Kero | will have to bribe his group-leader to be able to go there. |
| 19:22:28 | Kero | Doesn't really fit in my work, though. |
| 19:22:46 | Leeds | well, the conference is pretty (very!) cheap, but the travel and hotel make it expensive. |
| 19:22:48 | a7r | You know, I think Familiar needs an LWE and ALS booth. |
| 19:23:45 | Kero | Leeds: hotels are always expensive. |
| 19:23:45 | Leeds | a7r: you're right - there should be plenty of interest by LWE, given the way development is going... |
| 19:23:55 | Kero | Travel is always doable |
| 19:24:07 | Morph | a7r: with a jungle theme? |
| 19:24:33 | a7r | Morph: nah... we need a 200% size version of Orv with his pants on fire. |
| 19:24:41 | Morph | a7r: HAHAHA |
| 19:24:49 | Leeds | Kero: I just had a thought - my cousin is studying in Manchester and I doubt she'll be using her place then... Hmmm |
| 19:26:37 | Kero | looks in his agenda and sees he ''ought'' to go to a local conference (organized by direct colleagues) |
| 19:26:44 | Kero | *ponder* |
| 19:27:19 | Morph | a7r: with real flames shooting out. |
| 19:27:51 | a7r | Morph: works for me. |
| 19:27:59 | Kero | Leeds: that conference wasn't too interesting past time, though the invoted speakers were good. |
| 19:28:05 | a7r | we would also need to be able to sell iPAQs pre-installed w/ Familiar on the show floor. |
| 19:28:20 | Morph | Yup...$5000 each. |
| 19:28:31 | Leeds | plus support contracts :-) |
| 19:28:36 | Kero | heh :-) |
| 19:28:43 | a7r | Leeds: I've already started offering that. |
| 19:28:53 | Morph | a7r: are you pretty happy with the familiar name? |
| 19:29:01 | a7r | Morph: Yup.; |
| 19:29:16 | Leeds | Kero: The UKUUG conference will be interesting - was pretty hardcore last time, looks less hardcore this time. Good curries and drinking too :-) |
| 19:29:29 | Leeds | a7r: you've got customers?!?!? |
| 19:29:38 | Morph | a7r: I think a spin off distro is in order. exactly like familiar but called familiar one. |
| 19:29:42 | a7r | Leeds: Yup. |
| 19:29:46 | a7r | Morph: Hahaha |
| 19:29:53 | Leeds | cool :-) |
| 19:30:11 | a7r | I was thinking of even offering phone support. |
| 19:30:24 | Morph | disconnects his phone |
| 19:30:26 | a7r | haha |
| 19:30:33 | Morph | ``Who is this?`` |
| 19:30:35 | a7r | routes all the calls to Morph's mom's 976 number. |
| 19:30:50 | Morph | note to self, bring baseball bat to SB tomorrow. |
| 19:30:53 | Leeds | you need a European support center :-) |
| 19:31:02 | a7r | Leeds: haha, seriously. |
| 19:31:40 | a7r | Morph: You need to kick my ass about seeing that lawyer.. I haven't done it yet. |
| 19:31:44 | Leeds | nah - it's cool. support-supported free software development and all that |
| 19:31:48 | Morph | http://www.google.com/search?q=cache:CbaN4SLAzaU:dcine.dyndns.org/xbsfm/xbsfm+python+GdkColor&hl=en |
| 19:31:52 | Morph | a7r: OH I will. |
| 19:32:00 | Morph | ## XBSFM v0.01 ## |
| 19:32:01 | Morph | # A No-Bullshit File Manager for X |
| 19:32:01 | Morph | haha |
| 19:32:13 | a7r | haha, nice. |
| 19:34:06 | Morph | wow..this isnt bad. |
| 19:34:51 | Leeds | it uses emacs :-( |
| 19:34:53 | Morph | snaps a screenshot |
| 19:36:06 | Morph | http://gareth.wiked.org/2.jpg |
| 19:36:39 | a7r | ah |
| 19:36:50 | Morph | ah? |
| 19:37:17 | a7r | cool looking. |
| 19:42:14 | a7r | Morph: send me a test mail, real quick, |
| 19:42:39 | Morph | sent. |
| 19:42:44 | a7r | thanks. |
| 19:42:52 | a7r | haha |
| 19:43:18 | Morph | :D |
| 19:44:28 | a7r | Morph: what do you want to BBQ tomorrow? |
| 19:44:35 | Morph | hmm |
| 19:44:44 | a7r | I'm thinking a tritip. |
| 19:44:50 | Morph | well I was thinking we could try something different and BBQ food. |
| 19:45:02 | Morph | tritip works. |
| 19:45:07 | a7r | we're not eating deep fried Twinkies like last time. |
| 19:45:14 | a7r | when're you gonna come up? |
| 19:45:37 | Morph | Good. sick twisted fried twinkie loving freak. |
| 19:45:54 | Morph | Umm...not sure. 11? |
| 19:46:32 | a7r | Okay.. we'll make a run over to CostCo around then, and snag some lunch. |
| 19:47:49 | Morph | coo |
