[01:09] <persia> ian_brasil: Firefox was pulled by midbrowser in some of the earlier images, but the recommends chain that brought it should be gone.  I suspect you've started with an old enough image to still have it.  Try purging it, or pull a new image.
[03:05] <StevenK> persia: http://paste.ubuntu.com/47308/
[03:06] <persia> StevenK: This is (loosely) based on applications.menu?
[03:06] <StevenK> persia: Incredibly loosely.
[03:07] <persia> Right.  Since the applications.menu from gnome-menus needs modification, and m-b-f doesn't respect <DefaultMergeDirs/> let's start with applications.menu
[03:08] <persia> Just above where it has <!-- Accessories submenu --> add a section for <!-- Home submenu ==>
[03:08] <persia> s/=/-/g
[03:09] <persia> This contains <Menu> containing <Name>, <Directory>, and <Include>
 contains a bunch of <Filename> links
[03:10]  * StevenK digs up {applications,settings}.menu
[03:10] <persia> Also, there needs to be a /usr/share/desktop-directories/home.directory, but this can be incredibly sparse, as we don't use the Comment or Icon or GenericName or anything.
[03:11] <persia> Basically home.directory only needs [DesktopEntry], Type=Directory, Encoding=UTF-8, and Name=Home
[03:12] <StevenK> persia: Thinking about including all this stuff in -default-settings, too
[03:12] <persia> That means m-b-f needs to Depend on -default-settings.
[03:13] <StevenK> Hm.
[03:13] <StevenK> We need to upload m-b-f anyway
[03:13] <persia> Right.  That's why I think it belongs in m-b-f :)
[03:16] <StevenK> Do we want to kill any menus from applications.menu?
[03:16]  * persia looks
[03:19] <persia> I'd rather not have the "Extras" menu
[03:19] <StevenK> That doesn't exist in applications.menu :-)
[03:19] <persia> Multimedia is mostly empty, but I'm guessing that we'll want audio/video stuff there.
[03:20] <persia> Development is mostly empty, but it won't be if someone wants to do development.
[03:20] <persia> So, Extras is the only one I want to kill, and you can't do it with the XML.
[03:21] <StevenK> src/mobile-basic-home-plugin.c:                         i->cat = g_strdup ("Extras");
[03:21] <StevenK> Ah ha.
[03:22] <StevenK> That line has "if (!i->cat)" before it
[03:22] <persia> Does that mean "Extras" is a catch-all for anything not shown elsewhere?
[03:22] <persia> That is actually useful, although ideally we won't actually present it.
[03:23] <StevenK> I guess it means Extras is a catch-all for anything that doesn't define a category
[03:23] <StevenK> For example, it currently has Menu Editor, copa_ap_cp_name, OpenJDK Java 6 Runtime and Panel Manager
[03:27] <persia> Right.  OpenJDK Java 6 Runtime should go away, as should copa_ap_cp_name
[03:28] <persia> I'll take another look at Menu Editor and Panel Manager
[03:34] <persia> Menu Editor goes away with no longer depending on gnome-menus for {applications,settings}.menu
[03:34] <StevenK> Ah, neat.
[03:34] <StevenK> A few other things should drop out, too
[03:35] <persia> Panel Manager comes from matchbox-panel-manager
[03:36] <persia> How much of matchbox do we really use?  Could we get away with just installing matchbox-window-manager?
[03:38] <StevenK> I have no idea. Try it? :_)
[03:38] <persia> It looks to me like that's a spurious dependency in ubuntu-mid-default-settings : it ought depend on matchbox-window-manager, rather than matchbox.
[03:38] <persia> I'll try it;
[03:41] <persia> Seems to work.  Updating ubuntu-mid-default-settings
[03:44] <StevenK> I think I have the m-b-f changes too
[03:44] <persia> Excellent.  Have you looked at hildon-desktop to drop copa_ap_cp_name ?
[03:45] <StevenK> That's hildon-control-panel
[03:45] <StevenK> We use that :-/
[03:47] <persia> Do we use copa_ap_cp_name?  Does anyone else?  Is there any reason to ship the .desktop file?
[03:48] <StevenK> It runs controlpanel
[03:48] <StevenK> Maybe we just want to give it a category and fix the name
[03:49] <persia> That works too :)
[03:52] <StevenK> No Home with my new m-b-f
[03:52] <persia> What do you have for applications.menu?
[03:53] <StevenK> I have to head off about nowish. Shall I put my source up?
[03:53] <persia> Please push it.  I'll fiddle, and see if I can get it to have Home.
[03:55] <StevenK> persia: http://people.ubuntu.com/~stevenk/mobile-basic-flash_0.44-0ubuntu2.dsc
[03:57] <persia> At some point we probably ought to tell germinate about -mid :)
[05:05] <StevenK> persia: Any news?
[05:06] <persia> StevenK: Nope.  Just redownloaded the images, and upgraded them.  Booting now to fiddle.
[05:07] <persia> (or once the squashfs finishes)
[05:08] <persia> (and actually got distracted by upstream VLC showing up)
[05:08] <StevenK> persia: On real hardware?
[05:08] <persia> No.  Virtual.  While I don't have any disks to fiddle with the installer right now, the live image boots.
[05:09] <StevenK> Ahh
[05:22] <persia> StevenK: Where was that gconf key in which the categories to be displayed were listed?
[05:22] <StevenK> persia: /apps/marquee-plugins/categories or so
[05:25] <persia> Hrm.  Putting it there shows "Home" as an option in the menus, but the contents aren't the Home menu :/
[05:25] <StevenK> What are the contents?
[05:25] <persia> Whatever the last shown menu contained.
[05:25] <StevenK> Odd.
[05:26] <persia> Indeed.  It appears that it puts it in the menu, but then doesn't actually display the contents.
[05:27] <persia> Hmm.  I wonder if it's that "home.directory" != "Home.directory".
[05:27]  * persia tries other things.
[05:28] <StevenK> Mm. Maybe.
[05:30] <persia> Grumble.  I'm not finding the defaults file for gconf, so have to set it *each* time.
[05:31] <persia> Gah!  It's m-b-f being even more non-XDG-compliant.
[05:32] <StevenK> \o/
[05:33]  * persia dislikes debugging non-crashes, as there's no handy stacktrace
[05:43] <StevenK> persia: Sprinkle abort(); into the code? That would give you a stack trace ....
[05:43]  * StevenK chuckles
[05:44] <persia> StevenK: Found it.  It's around line 922.  Notice the lack of anything parsing <Filename>
[05:44] <persia> StevenK: Yes, but it still means I need to find the right function.  Just getting a random stacktrace doesn't help so much.
[05:44] <StevenK> persia: I see that.
[05:44] <persia> I much prefer to read code when I have a map telling me what is important to read :)
[05:45] <StevenK> I'm guessing it needs to be patched. More. :-(
[05:45] <persia> StevenK: So as I see it, we have two choices: either add a check for <Filename> in the loop starting at line 928, or implement a hildon plugin for gnome-menus and drop this package entirely.
[05:46] <persia> Given that we're all sorts of frozen, I think it's a patch.
[05:46] <StevenK> Indeed
[05:46] <StevenK> Not sure how to crowbar Filename into it.
[05:46] <persia> Well, actually, I suppose you could implement Home in a different manner, but I'm kinda partial to the XDG menu definition format.
[05:47] <persia> I'm not sure either.  I think it needs entries in the hash table, but those all assume we're selecting based only on categories.
[05:48] <persia> On the other hand, I think the code is a little confusing.
[05:48] <StevenK> I've added the else case
[05:49] <persia> I think that the variable "category" actually means a given submenu.
[05:49] <persia> Excellent.  Does it work?
[05:50] <StevenK> Agreed. Nope, since I'm still in cdbs patch
[06:14] <persia> Hah.  Found it.
[06:19] <persia> StevenK: Do you know anything about bug #209870 ?
[06:20] <persia> (specifically the matchbox-window-manager task)
[06:30] <persia> So, the reason fvwm1 is in the daily images is bug #145517 (patch attached)
[06:37] <StevenK> Ah ha!
[06:41] <StevenK> persia: Can update-alternatives be run multiple times like that in the postinst?
[06:42] <persia> Multiple times?  You mean --slave?
[06:42] <StevenK> persia: Nope. You don't guard the update-alternatives run with configure or any other arguments
[06:43] <persia> Oh.  I just stole the code from fvwm1
[06:43] <persia> Let me look at a less deprecated example.
[06:44] <persia> Anyway, rerunning the same update-alternatives command should have no impact.
[06:44] <StevenK> I'd just rather it was only run on $1 == configure, personally
[06:44] <persia> OK.  Shall I fix that, or do you want to change it?
[06:44] <StevenK> Fix it and upload, I say
[06:45]  * persia can't upload
[06:45] <persia> fixing now ...
[06:46] <StevenK> You're seperated from your key, or matchbox is main?
[06:46] <persia> the latter.
[06:46] <persia> Anyway, new debdiff going up now...
[06:47]  * StevenK will happily upload it
[06:48] <persia> http://launchpadlibrarian.net/17637002/matchbox-window-manager_1.2-2ubuntu2.debdiff
[06:50] <StevenK> persia: Uploaded.
[06:51] <persia> StevenK: Thanks.  I'm up to 'p' in other package review.  Nothing else strikes me as quite so egregious as fvwm1 though :(
[06:51]  * StevenK looks at m-b-f code again
[06:52] <StevenK> persia: Suggestions? :-)
[06:52] <persia> What happened when you added the else clause?
[06:52] <StevenK> Nothing, since the else clause doesn't do anything yet
[06:53] <persia> RIght.  Hold on while I bring up that code again
[06:54] <persia> else {} starts on line 932?
[06:55] <StevenK> I added "else if (!strcmp ((gchar *)iter->name, "Filename"))" on line 931
[06:56] <persia> Before or after "continue" ?
[06:56] <persia> Also, why iter->name rather than iterchild->name ?
[06:57] <StevenK> Which continue?
[06:58] <StevenK> And everything else there is using iter->name, such as "else if (!strcmp ((gchar *)iter->name, "Include"))"
[06:58] <persia> I had "continue" on line 931.
[06:58] <persia> And for me, everything else is using iterchild->name
[06:59]  * persia tries debian/rules patch to see if that helps
[06:59] <persia> Nope.  no rule to make target 'patch'.
[07:00] <persia> So, I'm looking at source retrieved by dget http://people.ubuntu.com/~stevenk/mobile-basic-flash_0.44-0ubuntu2.dsc
[07:00] <persia> Should I be looking at something else?
[07:00] <persia> Should I do anything special to get the source in shape to compare?
[07:00] <persia> (debian/README.source is silent on the matter)
[07:00] <StevenK> I did cdbs-edit-patch <lala>
[07:00] <persia> RIght.  lala it is.
[07:01] <persia> OK.  That's the problem.
[07:02] <StevenK> Hm?
[07:02] <persia> We're looking at different code and passing back and forth line numbers.
[07:02] <persia> So, the loop that actually pulls in the Categories appears to start on line 933 (post-lala)
[07:03] <persia> Mind you, this will break, as it fails to recognise the negations in applications.menu, but wedging in a real XML parser would be fairly painful.
[07:04] <persia> So it's just going to skip over the negations.
[07:04] <persia> I think it's in that loop that we also want to pull the <Filename> entries.
[07:05] <persia> I'm just tracking through to figure out what m-b-f later does with c=>cat_table
[07:06] <persia> Lines 1040 and 1041 lead me to believe it's supposed to be interative
[07:08] <persia> Unfortunately, I'm not getting a good idea what the context is supposed to contain at the end.  Do you have a mental model for that?
[07:08] <StevenK> Not really
[07:12] <persia> Grumble.  The solution to buggy .desktop files was to delete the last four characters of an icon name if the icon string contains '.'.
[07:12] <persia> Not fixing the .desktop files, or anything.
[07:15] <persia> OK.  Found it.
[07:15] <persia> So, c->cat_table is a list of supported categories.
[07:15] <persia> It gets checked against the .desktop files on line 877.
[07:16] <persia> Since this is at several removes and indirections from parsing, there's no good way to pass the <Filename> hints.
[07:16] <StevenK> Argh
[07:17] <persia> So, either we fix m-b-f to do it right (actually parse the menus, and the .desktop files and construct something dynamically), or we build a hardcoded wedge in somewhere.
[07:17] <persia> (perhaps based on some configuration file)
[07:17] <StevenK> Which one is quicker? :-)
[07:18] <persia> Ummm...
[07:20] <persia> Well, if you know python reasonably well, and you know how to create a hildon-desktop plugin in python, there's a fairly simple API that lets you access gnome-menus from python.
[07:20] <persia> Probably 200 lines of code or so.
[07:21] <persia> If you know XML parsers well, and want to rip open m-b-f, parse against the DTD cleanly, and then use that to generate your icon sets, that's some fun in C.
[07:21] <persia> Probably about 400 lines, but a fair number are going to be comments and braces
[07:21] <StevenK> I know Python reasonably well, but I don't know how to create a hildon-desktop plugin in Python
[07:23] <persia> If you want to just stuff something in, add some extra logic checking some other configuration list around line 883 of m-b-h-p.c
[07:23] <persia> That's probably around 50-70 lines of C, but you'll have to operate within the context of m-b-f code, which means it will take longer than writing 50-75 lines from scratch.
[07:24] <persia> You probably want to extract most of that into a separate comparison function, just to keep the concerns separate.
[07:24] <StevenK> Sigh.
[07:24] <StevenK> I wonder if it's just quicker to just write something in Python
[07:25] <persia> I'm not sure.  Hence my lengthy answer to "Which one is quicker?" :)
[07:25] <StevenK> Hah, yes
[07:26] <StevenK> I'm not sure my C knowledge will stand up to hacking m-b-f either
[07:26] <persia> It's exceedingly indirect C.
[07:26]  * persia likes C as a *functional* language: it's a little odd when it's used as an object-oriented language
[07:35] <persia> StevenK: I came up with a fairly short hack-in model.
[07:35] <persia> insert around line 886
[07:35] <StevenK> Woot
[07:35] <StevenK> I was looking at writing a plugin in Python.
[07:36] <persia> You keep doing that.  I'll test my hack and see if it actually works.
[07:37] <persia> It's essentially setting a hardcoded list of names, and matching on i->name in a loop to artifically stuff i->cat = "Home" as duplicate entries.
[07:37] <persia> Erm.  Actually, that won't work, because it removes the entries from their regular locations.
[07:37]  * persia looks more
[07:38] <StevenK> Right. I've written the hildondesktop bits
[07:38] <StevenK> Where's the docs for the Python API into gnome-menus?
[07:39] <persia> http://bazaar.launchpad.net/%7Eogra/ograsac-desktop/launcher/annotate/3?file_id=launcher.py-20080602112229-01ljdznuwbnymvb5-2 might help on some of the python <-> gnome-menus bits.  Mind you, that code is *not* ready for production.
[07:39] <persia> Note the use of the xdg.Menu object.
[08:01]  * persia grumbles about the inconvenience of test cycles for non-native environments
[08:19] <persia> Right.  I'm not understanding the code well enough.  http://paste.ubuntu.com/47353/ ought to show the "Buttons" app in "Home" in m-b-f.
[08:20] <StevenK> Hm
[08:20] <StevenK> My Python app has broken my Q1
[08:21] <persia> Well then.  How broken is it?
[08:21] <StevenK> m-b-f still loads
[08:21] <StevenK> But I removed the desktop file for it
[08:21] <persia> Just purge it.  Your python app would be a complete replacement.
[08:27] <StevenK> Trying to tell if my one is working is not helping
[08:34] <StevenK> Hm.
[08:35]  * persia tries to extract xfce4 from the images
[08:43] <StevenK> Mine is not getting called.
[08:45] <persia> Right.  I'll try another hack with C then.
[08:45] <persia> By the way, how important do you think it is to be able to print from mousepad?
[08:46] <StevenK> I'm not sure. Why?
[08:46] <persia> Or rather, how important do you think it is to have the Xfce print manager to check on the status of printing from mousepad.
[08:46] <persia> Because if mousepad doesn't Recommend xfprint4 (already seeded by xubuntu-desktop, so no impact there), then we get to drop gtk2-engines-xfce, xfce4-icon-theme, xfce4-mcs-manager, xfce4-mcs-plugins, and xfprint4
[08:47] <persia> So, if you don't think it's important, I'll go double-check with the xubuntu folk, and drop the recommendation to a suggestion
[08:50]  * StevenK has brutally hacked the start up script to run hildon-desktop under strace
[09:01] <StevenK> Ah ha
[09:01] <StevenK> WARNING **: Unknown Plugin Loader type: python
[09:03] <persia> Right.  Let's hope this particular revision of lala does something useful then...
[09:06] <StevenK>         * src/Makefile.am: Removed support of python. Now it's splitted
[09:06] <StevenK>         * configure.ac: Removed python support.
[09:06] <StevenK> From the changelog
[09:06] <StevenK> of hildon-desktop, that is
[09:07] <persia> I see.  I wonder what "Now it's splitted" means.  Is there another useful package?
[09:07] <persia> somewhere in python-hildon perhaps?
[09:08] <persia> Hrm.  Maybe not.
[09:08] <StevenK> If anything python-hildondesktop
[09:09] <persia> That's not something I can find though.  Is that not in Ubuntu?
[09:10] <StevenK> https://code.edge.launchpad.net/~ubuntu-mobile/python-hildondesktop/ubuntu
[09:13] <persia> Nope.  That version of lala just broke it entirely.
[09:14] <persia> I see.  That's not in Ubuntu, and not in the PPA.
[09:15] <persia> Shall we fiddle with REVU, or wait for lool (who gets to make the decision wrt REVU anyway)
[09:16] <StevenK> I'm quickly building python-hildondesktop to see if that fixes it
[09:19] <StevenK> hildondesktop.c:988: error: implicit declaration of function 'hildon_home_area_set_batch_add'
[09:19] <StevenK> Bah
[09:23] <persia> Right.  m-b-f is smarter than I.
[09:24]  * StevenK gets python-hildondesktop to build
[09:26] <StevenK> python-hildondesktop doesn't help
[09:29]  * StevenK grumbles at m-b-f
[09:29] <StevenK> What was your last version of lala?
[09:33] <persia> My last version of lala was a sledgehammer: add 2 lines after line 908.  The first set i->cat, and the second appended i to c->app_list again.
[09:34] <persia> The result was that *every* file showed for *every* submenu, which was very much not what I was expecting.
[09:34] <persia> I even tried again after shutting down gconfd, and adjusting the .gconf configuration for the ubuntu user by hand to force inclusion of "Home" in the list.
[09:35] <persia> That's when I decided m-b-f was smarter than I.
[09:37] <StevenK> I think we want lool, at this point.
[09:38] <persia> Right.  So, invoking the magic token to match the filter:
[09:38] <persia> lool: m-b-f is broken in several ways, and we can't add a Home menu.  Trying to hack a quick replacement with python-hildondesktop didn't succeed.
[09:48] <lool> hmm
[09:49] <lool> I expect python stuff might be broken, and would like to receive test results
[09:49] <lool> I ripped off -fm bits from python-hildon, and that was a bit crude
[09:50] <StevenK> lool: The problem with the Python stuff is that hildon-desktop doesn't support Python plugins any more
[09:51] <lool> Concerning mbf, what's the matter?  You're trying to get the Home menu to work?
[09:52] <persia> lool: Right.
[09:52] <lool> What's the current WIP?  you told mbf to parse an additional file and to use the Home menu as the default?
[09:52] <persia> lool: Essentially, m-b-f doesn't actually implement the spec very well.  It conflates Categories with submenus.
[09:53] <persia> lool: We've gone far beyond that.  m-b-f can't parse anything except on a Categories basis.
[09:53] <lool> Well what mbf give you in the drop down are category filters so to speak
[09:53] <persia> The last hack was to try to force an additional hardcoded condition in the parse_desktop_files function, which didn't work.
[09:54] <persia> Right.  But we don't want category filters.  We want support for <Filename> or in the absence of that, some way to feed it a hardcoded list.
[09:54] <lool> Hmm right now it just skips over anything else than category
[09:55] <persia> Yep, and it does it in a way that only builds a category list, so injecting stuff there isn't very helpful.
[09:56] <persia> That category list is then examined in parse_desktop_files and used as a comparator when populating the menu hash.
[09:56] <persia> (specifically context->app_list)
[10:01] <lool> The stupidest thing is that mbf used to call into gnome-menus in the past
[10:01] <lool> as in API calls
[10:01] <ogra> persia, so whats your prob with grub-installer ? 
[10:02] <persia> ogra: No idea.  I need to get my virtual disks working, and troubleshoot it.
[10:02] <ogra> ah
[10:02] <lool> If I look at this honestly, I can only think that mbf's code to parse the menus is completely wrong; it's so wrong that I think it's fair to consider replacing mbf as you tried to do or replacing the menu parsing part
[10:02] <lool> If we replace the menu parsing part, we should go with the gnome-menus lib I guess
[10:03] <ogra> you need gnome-menus since it brings in the xdg parsing pieces
[10:03] <lool> ogra: Right now, mbf doesn't give a shit about xdg
[10:03]  * ogra can just point again to edubuntu-menus
[10:04] <ogra> hmm, right, you had that hardcoded defines 
[10:04] <lool> If you grep its C source for XDG, you're only going to find the two pathnames pointing at the menu files -- /etc/xdg
[10:04] <persia> ogra: Nope.  m-b-f only uses applications.menu and session.menu.  We copied those by hand, and mangled them.
[10:05] <persia> lool: StevenK reimplemented m-b-f in python today, but hildon-desktop won't load python modules.
[10:05] <ogra> bah
[10:06] <ogra> StevenK, did you have an opportunity to test the new hal-info on the Q1 ? 
[10:06]  * ogra isnt sure if he got all keycodes riht to behave like in hardy 
[10:07] <StevenK> ogra: I didn't, no, sorry
[10:08] <ogra> no hurry :)
[10:08] <StevenK> So now we get to reimplement m-b-f? :-(
[10:08] <ogra> the patch is in at least ... all keys and the joystink work i can shuffle codes aroubd 
[10:09] <ogra> (in case they are wrong)
[10:09] <ogra> sadly the kernel uses quirk keywords in hal, no keycodes 
[10:09] <ogra> thats why i'm unsure 
[10:10] <StevenK> persia: matchbox-window-manager is DEPWAITing on libxsettings-client-dev
[10:13] <persia> StevenK: Thanks for reading my mail for me :)  I'll go take a look.
[10:14] <StevenK> Heh
[10:18] <lool> StevenK: what was the issue with python modules?
[10:20] <StevenK> WARNING **: Unknown Plugin Loader type: python
[10:20] <StevenK> lool: ^
[10:20] <lool> StevenK: You had python-hildondesktop installed?
[10:21] <persia> StevenK: Well, it seems that someone arranged an MIR for it without actually promoting the dependencies.  It's been unbuildable for a while.  Shall we kick it back to universe?
[10:21] <StevenK> lool: Yes
[10:22] <StevenK> persia: I think that's the simplest way forward
[10:22] <persia> Right.  I'll check for demotion impact
[10:26] <lool> StevenK: Do you get any other error during hd startup?
[10:26] <persia> StevenK: bug #270824
[10:30] <StevenK> lool: To get that error I had to *strace* hildon-desktop
[10:30]  * StevenK moves to his archive-admin hat
[10:32] <lool> I think you missed an earlier error when loading python support
[10:32] <lool> Ok; /me needs to finish packing; it's unlikely that I fix this today
[10:33] <lool> I checked the module loading code in hildon-desktop, it's relatively straightforward so i'd look why python support doesn't work
[10:33] <StevenK> lool: I don't see that error
[10:34] <lool> And if we can't get python to work, we will have to revert back to gnome-menus for parsing
[10:34] <StevenK> I see very little in the strace output for Python
[10:35] <StevenK> persia: matchbox-window-manager demoted
[10:35] <persia> StevenK: Excellent.  I'll try some rebuilds.  See, this is why pushing stuff into main isn't always ideal :)
[10:36] <StevenK> persia: It was promoted for hardy
[10:36] <StevenK> It built then, too
[10:38] <persia> It *shouldn't* have built.
[10:38] <persia> Given that the same version was in gutsy, and there was no upload for hardy, I don't believe it ever was built against the main ogre restrictions.
[13:01]  * StevenK starts looking at hildon-desktop again
[13:02] <persia> Towards the goal of replacing m-b-f, or is this a new goal?
[13:05] <StevenK> persia: Replacing m-b-f
[13:07] <StevenK> persia: Reading hildon-desktop code about "WARNING **: Unknown Plugin Loader type: python"
[13:07] <persia> Bother.  libmatchbox has been manual-dependency-wait for the entire cycle because of excited MIRing
[13:08] <StevenK> It needs demotion love too?
[13:09] <persia> Indeed.  There are probably more.  I have the sense that the drive to promote a chunk of stuff to main was interrupted about half-way through.
[13:10] <persia> Looking at the history, it seems to be fallout from bug #209870
[13:14] <persia> StevenK: bug #270866
[13:49] <StevenK> persia: Help would be welcome, if you can.
[13:49] <persia> StevenK: OK.  gobby?
[13:50]  * persia isn't sure how to help
[13:50] <persia> Or do you mean just tracking the error, and finding out why Python doesn't load?
[13:51] <StevenK> The latter.
[13:53] <StevenK> Hm. python-hildondesktop should do it
[13:55] <persia> StevenK: Could you paste the .desktop for your module?
[13:55] <StevenK> Not easily
[13:57] <persia> OK.  I'll just try to imagine it :)
[13:57] <StevenK> http://paste.ubuntu.com/47438/
[13:57] <persia> Thanks.
[13:58] <StevenK> Ah ha
[13:59] <persia> ?
[13:59] <StevenK> There's a hildon-desktop-python-loader package too
[13:59] <persia> heh.  That sounds like just the ticket.
[14:03] <ogra> doesnt that .desktop need an Exec= line ? 
[14:03] <persia> ogra: Nope.  It's not a real .desktop file.  It's just a config file for a hildon-desktop module loader
[14:03] <persia> look for xdg complaince somewhere else
[14:04] <ogra> heh
[14:04] <persia> ogra: See http://pastebin.com/f23284f55 as an example from upstream 
[14:05] <ogra> so x-path would be the executable ? 
[14:06] <persia> Well, not quite.
[14:06] <persia> The plugin must be in e.g. /usr/lib/hildon-desktop/$(X-Path).py
[14:07] <persia> But it's not exactly executed.  It's loaded into the context.  While *everything* in hildon is run within the context, most things are specifically executed, rather than just loaded.
[14:08] <persia> The difference being that loading something won't necessarily run that something unless it's providing some feature for which a hook has been received.
[14:08] <persia> (which may depend on the activation of some event, or other initiation path)
[14:10] <persia> StevenK: You've seen https://stage.maemo.org/svn/maemo/projects/haf/trunk/python-hildondesktop/?  Seems to be a source package that provides both binary packages.
[14:11] <StevenK> It's in LP, too
[14:11] <StevenK> It's installed on my Q1 now
[14:11] <persia> and you successfully reimplemented m-b-f in under a day?
[14:12] <StevenK> I wouldn't call it a success reimplementation
[14:13] <StevenK> Still doesn't run yet
[14:13] <persia> Same or different error?
[14:14] <StevenK> It's loading the python code
[14:18] <persia> Excellent.  That's a step in the right direction, and ought give you more flexibility in debug output options.
[14:21] <StevenK> Ah ha.
[14:21] <StevenK> 'import hildondesktop' breaks
[14:22] <persia> \o/
[14:41] <StevenK> persia: This keeps breaking
[14:41] <persia> StevenK: define "this".
[14:42] <StevenK> persia: python -c 'import hildondesktop'
[14:42] <persia> Were you able to load your plugin?  Is it infrastructure code, or new code?
[14:42]  * StevenK merges from upstream
[14:47] <persia> The vcs-imports branch?
[14:48] <StevenK> Yes
[14:54] <persia> StevenK: I'm building 0.0.1-1ubuntu1 now for testing.  As I wait for pam_mount to time out, I'm remembering having import issues with update-manager-hildon
[14:54] <persia> Specifically, when I first packaged it, I didn't provide all the right python packaging hints for it to work cleanly.
[14:54] <persia> Could it be something like that ?
[14:54]  * persia has only a weak understanding of python packaging
[14:55] <StevenK> persia: Possibly
[14:55] <ogra> there is a wikipage :)
[14:55] <StevenK> persia: I'm getting unknown symbols
[14:55] <persia> ogra: Indeed.  I've read it *many* times.  I tried using it to review packages, and routinely found that PAPT members would find 17 things I'd missed.
[14:56] <persia> StevenK: Which symbol is unknown?
[14:56] <StevenK> persia: hildon_home_area_set_layout_mode is the latest one
[14:56] <StevenK> persia: There was one before that I removed.
[14:56] <StevenK> Which I reverted
[14:56] <persia> OK.  Are these expected python symbols, or bindings issues?
[14:57] <StevenK> I thought they existed, at least
[14:57]  * StevenK builds 0.0.2
[15:04] <StevenK> Woot
[15:04] <persia> 0.0.2 works?
[15:04] <StevenK> 0.0.2 doesn't display the same problem
[15:04] <persia> How many merge conflicts?
[15:04] <StevenK> 3
[15:04]  * persia merges
[15:04] <StevenK> All of them in debian
[15:05] <StevenK> It still doesn't work
[15:05] <StevenK> Oh, right
[15:05] <StevenK> That was the second problem I didn't fix
[15:05] <StevenK> python -c 'import xdg.Menu' fails
[15:06] <persia> ogra: ?
[15:06] <StevenK> persia: I don't have the module
[15:06] <StevenK> So I just to figure out which package I'm missing
[15:06] <persia> StevenK: Right.  ogra knows which module you need.
[15:08] <StevenK> python-xdg or so
[15:08] <StevenK> Which source is pyxdg. *of course*
[15:09] <ogra> right
[15:09] <ogra> import xdg.Menu
[15:09] <ogra> import xdg.Locale
[15:09] <ogra> import xdg.IconTheme
[15:10] <ogra> thats what i use in the ograsac launcher
[15:10] <StevenK> Right, so now I think the first line of my thing probably runs
[15:11] <persia> Isn't it a basic axiom that the py$(foo) source package generates the python-$(foo) binary package?
[15:12] <persia> StevenK: I got conflicts in changelog and control, but I don't see the third.
[15:12] <StevenK> Hm.
[15:12] <StevenK> But I don't get anything showing up
[15:14] <StevenK> persia: The third was due to my changing the hildon-dekstop*.install
[15:14] <StevenK> I hacked 0.0.1 to support python 2.4
[15:14] <StevenK> Er, 2.5
[15:14] <persia> OK.  I shan't worry then.
[15:17] <StevenK> Yay, progress
[15:17]  * StevenK gets a hello world button to appear
[15:17]  * ogra applauds
[15:18] <StevenK> I think I'm missing something in terms of the menu parsing code
[15:19] <StevenK> Ah ha.
[15:20] <StevenK> It doesn't work since /etc/xdg/menus/* has buggered off
[15:21] <persia> Oh.  You need gnome-menus back :)
[15:21] <StevenK> Yes.
[15:21]  * persia digs up the Home hints based on the assumption of proper XDG support
[15:21]  * ogra thought python-xdg depended on gnome-menus
[15:22] <persia> ogra: Shouldn't, as not everything XDG is GNOME
[15:22] <StevenK> It doesn't
[15:22] <ogra> ah, no there was a dep between gnome-menus and python-gmenu
[15:22] <persia> Hmm.  Do we want to use python-xdg or python-gmenu?
[15:24] <ogra> well, python-xdg shold suffice for a start 
[15:25] <ogra> i'm not sure it respects the menu editor changes though
[15:25] <StevenK> Hm
[15:28] <persia> Essentially python-xdg means we do it from scratch, and are responsible for the menus.  python-gmenu means that we inherit the menus from Desktop, and can modify as we like with /etc/xdg/menus/applications-merged/
[15:29] <persia> If we want to use the GNOME menu editor, we probably ought use python-gmenu.  If we're going to use python-xdg, we should populate /etc/xdg/menus/ manually.
[15:29] <ogra> XDG_CONFIG_DIRS is what you need
[15:29] <ogra> which is used by python-xdg
[15:29] <ogra> python-gmenu will just sit on top of it
[15:29] <persia> ogra: Bah.  XDG_CONFIG_DIRS should just be /etc/xdg/menus/
[15:29] <persia> Changing that is a hack.
[15:29] <persia> (and not in a good way)
[15:30] <ogra> nah
[15:30] <ogra> you can use it like the PATH variable 
[15:30] <ogra> and its supposed to be like that
[15:31] <ogra> XDG_CONFIG_DIRS="/my/weird/hildon/dir:/etc/xdg"
[15:31]  * persia clears throat, sucks teeth, clears throat, and fails to say anythign substantive
[15:32] <ogra> that way stuff gets merged automatically
[15:32] <persia> Yes, but one is intended to merge stuff with DefaultMergeDirs
[15:32] <persia> That's *why* DefaultMergeDirs exists.
[15:33] <persia> XDG_CONFIG_DIRS should *always* be /etc/xdg/menus/ for a FHS-compliant system, or people like me who have spent hundreds of hours reading the XDG specs will get very frustrated debugging things.
[15:35] <persia> (like the full day I spent trying to describe how to define a Home menu before I realised just how broken m-b-f was)
[15:35] <ogra> i didnt say you should drop /etc/xdg from it :)
[15:36] <ogra> just prepend the dirs you want stuff merged from
[15:36] <persia> Yes, but it's ^/etc/xdg/
[15:36] <persia> What do you have against DefaultMergeDirs?
[15:37] <ogra>  less /etc/xdg/user-dirs.conf
[15:37] <ogra> :)
[15:37] <ogra> nothing
[15:38] <persia> Yes, but that's so *users* can override stuff.  Not for us to touch.
[15:38] <ogra> thats a system file
[15:38] <persia> StevenK: In case you want it again, http://paste.ubuntu.com/47129/ should be the bits to make a Home menu with an XDG-compliant menu parser
[15:39] <persia> Obviously, /etc/xdg/menus/home.menu could be longer
[15:39] <StevenK> I'm trying to get it parse what I have so far
[15:39] <persia> The hacked applications.menu ?
[15:39] <StevenK> No, gnome-menus itself
[15:39] <persia> Oh.  Right.
[16:00] <StevenK> Right.
[16:00] <StevenK> I have a launcher that works. Ish.
[16:00] <StevenK> Looks like complete crap, too
[16:00] <ogra> yay
[16:00] <ogra> did you define the proper icon size ? 
[16:00] <StevenK> Icon support doesn't exist yet
[16:00] <ogra> oh
[16:01] <StevenK> Neither does scrolling
[16:03]  * StevenK will look more tomorrow
[16:08] <StevenK> I find it strange I can't close anything
[16:08] <persia> StevenK: Congratulations!
[16:15] <StevenK> persia, ogra: http://people.ubuntu.com/~stevenk/IMG_2091.JPG
[16:15] <ogra> wow, thats bling :)
[16:15] <persia> Cool!  Does the drop-down work to select menus?
[16:16] <StevenK> Nope
[16:17] <StevenK> Since that is set via dbus
[16:18] <StevenK> I need to shrink the text, and add icons
[16:19] <StevenK> Essentially, I want it to look like m-b-f
[16:19] <StevenK> Just without the crack
[16:22] <persia> StevenK: Very nice work.  Now that you have a menu, making icons is the easy bit.
[16:22] <persia> Plus, we'll get to unseed m-b-f for Alpha-6, which is one more step towards the light.
[16:23] <StevenK> I'm not happy with it yet
[16:23] <StevenK> So far it's only 38 lines of Python.
[16:25] <StevenK> Ah ha. I thought it looked wrong
[16:27]  * StevenK grumbles at Dath'Remar still being offline
[16:28] <ogra> is that all buttons?
[16:28]  * persia waits for another publisher cycle to *finally* build matchbox-window-manager
[16:28] <ogra> in a table 
[16:29] <ogra> StevenK, have a look at the iconview widget :)
[16:29] <ogra> instead of using a table with buttons
[16:29] <StevenK> ogra: Yeah, it's a table with buttons
[16:30] <ogra> well, in the end you probably resemble ograsac launcher heh
[16:30] <ogra> though your xdg handling might be saner
[16:30] <StevenK> Hehe
[16:31] <StevenK> My XDG handling is like 8 lines
[16:31] <ogra> heh, mine too
[16:31] <ogra> but mine parses the files directly as your m-b-f did ... it was a quick shot
[16:31] <StevenK> ogra: My plan was add icons to the buttons
[16:31] <ogra> i wouldnt use buttons
[16:31] <StevenK> And change the font on the buttons to be smaller
[16:32] <ogra> iconview looks cleaner 
[16:32] <ogra> and gtk has an oddbehavior that doesnt let you make buttons really transparent
[16:33] <ogra> an iconview can just carry a wallpaper
[16:33] <ogra> i stopped focusing on the icon stuff in ograsac launcher though and went for stacked eventboxes for a special smooth scroll mechanism
[16:34] <ogra> but i never finished that 
[16:34] <ogra> so my launcher isnt functional at all right now
[16:34] <ogra> but scrolls very sweet :)
[16:35] <ogra> i.e. translation the pixels of the full lenght of the launcher logarhitmically inot the screen size 
[16:36] <ogra> that way you dont have to lift your finger to scroll to top or bottom
[16:36] <ogra> screen top is launcher top, screen bottom is launcher bottom when scrolling
[16:38]  * ogra notices thats really hard to explain without showing it ... its pretty cool UI behavior though
[16:42] <ogra> StevenK, did you check if the menu editor actually influences the applist ? 
[16:43] <ogra> (i.e. does ~/config/*/*.menu get respected as it should)
[16:43] <StevenK> ogra: You never implemented the actual launching bit
[16:44] <ogra> i did in an old version 
[16:44] <StevenK> If so, that code isn't on Launchpad
[16:44] <ogra> but the eventbox is layered above the iconview and scrolledwin
[16:44] <StevenK> Revision 1 still has no .connect
[16:44] <ogra> oh, right
[16:44] <ogra> i ditched that to work on the eventbox stuff
[16:45] <StevenK> Heh
[16:45] <ogra> since it first needs to translate the eventbox coordinated to iconview coordinated
[16:45] <ogra> *coordinates
[16:45] <ogra> then the eventbox just needs to proxy a click event to the icon
[16:46] <StevenK> The finger scrolling stuff should be addable
[16:46] <ogra> well, if it works :)
[16:46] <StevenK> Adding a scrollbar is work for later, though
[16:46] <ogra> the prob is that an eventbox layered over your app will catch clicks 
[16:47] <ogra> so they dont reach the icons 
[16:47] <StevenK> Yes ...
[16:47] <ogra> thats the point where i had stopped with my launcher
[16:47] <ogra> i should probably finish that part and you can just use it 
[16:48] <persia> I'd rather start from StevenK's implementation, because it runs in the target environment, even if the other bits aren't quite as cool.
[16:49]  * StevenK goes to bed before he gets tempted to rewrite bits again.
[16:49] <ogra> persia, its pygtk
[16:49] <ogra> there is no target arch
[16:49] <persia> StevenK: wise decision
[16:49] <ogra> and i developed it inside a vbox ume install 
[16:50] <persia> ogra: Not "envionment" as architecture, but "environment" as hildon, and I thought ograsac was non-hildon.
[16:50] <ogra> no,, its not but the launcher is a plain pygtk app
[16:50] <StevenK> Mine isn't
[16:50] <StevenK> Mine is a Hildon Desktop python plugin
[16:50] <ogra> ah
[16:51] <persia> This is why I want to start from StevenK's launcher
[16:51]  * StevenK adds eight fixme items
[16:52] <StevenK> "# - Actually launching stuff"
[16:52] <persia> Bother.  It does need another publisher cycle.
[16:53] <ogra> StevenK, http://paste.ubuntu.com/47490/
[16:53] <ogra> that has the exec bit
[16:54] <ogra> (on_select())
[16:54] <ogra> surely needs improvement
[17:23] <ogra> oh, that launcher still works actually