[09:10] <Mithrandir> derjoerg: don't ask to ask; just ask your question.
[09:21] <derjoerg> OK, I tried to install (PXE) 7.04 on an embedded system with AMD Geode LX processor and a CF-card (PRIMARY SLAVE). The installation went well and I had the following partitions /dev/hdb1 - root-filesystem and /dev/hdb5 as swap. When I reboot the system GRUB is displayed (console) and the loading-process starts, but at the end I only see "ALERT! /dev/hdb1 does not exist. Dropping a shell!" and a BusyBox starts. When I start the rescue-mode over PXE
[09:21] <derjoerg> -card as /dev/hdb1 and make a chroot to it.
[09:22] <derjoerg> So I think, the installer and the rescue-system loads specific modules, which the "normal" boot doesn't
[09:23] <derjoerg> Does anybody have an idea, which module(s) I can load (/etc/modules) so that I can correctly use ubuntu?
[10:33] <derjoerg> Nobody an idea, which ide-modules are loaded during installation?
[10:37] <Mithrandir> hm, unsure.  You might have more luck in #ubuntu-installer
[10:42] <derjoerg> Mithrandir: Ok, thanks :-(
[01:40] <K3nto> is anybody available to help me out with obex?
[02:19] <amitk_> K3nto: This channel is for ubuntu for mobile devices such as tablet PCs, MIDs, UMPCs; not for ubuntu with mobile phones. Try #ubuntu
[02:20] <mdz> Mithrandir: xulrunner needs building on lpia.  are we still on manual for some reason?
[02:21] <mdz> derjoerg: I believe the installer explicitly loads some modules which are expected to be loaded automatically during boot.  the best place to take your problem is to the kernel team (and file a bug report on linux-source-2.6.20 with lspci)
[02:23] <Mithrandir> mdz: no, we're on full auto
[02:24] <Mithrandir> build rescored, it'll be built next
[02:40] <mdz> Mithrandir: once that's built, ubuntu-mobile should be installable on lpia again
[02:41] <Mithrandir> except it ftbfs
[02:41] <Mithrandir> I'll poke it
[02:44] <doko> mdz: why does mobile need xulrunner? Shouldn't it use midbrowser?
[02:44] <Mithrandir> doko: gtkmozembed
[02:45] <doko> Mithrandir: firefox-dev does provide that
[02:46] <mdz> doko: ->asac, I'm just looking at what's installable
[02:46] <mdz> doko: mobile-basic-flash depends on libxul0d
[02:46] <mdz> which is from xulrunner
[02:46] <mdz> and is independent of midbrowser
[02:48] <mdz> http://launchpadlibrarian.net/8915774/buildlog_ubuntu-gutsy-lpia.xulrunner_1.8.1.4-2ubuntu2_FAILEDTOBUILD.txt.gz
[02:48] <mdz> (when did we start using launchpadlibrarian.net?)
[02:48] <Mithrandir> been a while
[02:48] <mdz> js.o: In function `GetLine':
[02:48] <mdz> /usr/bin/ld: js: hidden symbol `readline' isn't defined
[02:48] <mdz> /usr/bin/ld: final link failed: Nonrepresentable section on output
[02:49] <Mithrandir> needs older gcc for now
[02:52] <doko> that is fixed with the current midbrowser build (currently building). mobile-basic-flash should b-d on that
[02:52] <asac> doko: mobile-basic-flash needs some work in order to run with midbrowser (or firefox) as its just a panel applet (and thus cannot tweak LD_LIBRARY_PATH) ... i talked to intel about that, but iirc nobody is really working on that atm
[02:52] <asac> given that cwong in on holiday
[02:53] <doko> asac: hmm, so apply the same fix to xulrunner (and firefox) as we did for mibrowser?
[02:54] <Mithrandir> I'm doing a test build of that now.
[02:54] <asac> doko: well i would hate to do that as i actually would like to give a reason to do the work needed to make that work happen ... but if its a blocker right now we can do that.
[02:55] <asac> Mithrandir: take the patch out of midbrowser
[02:55] <asac> force-no-pragma-visibility-for-gcc-4.2_4.3
[02:55] <asac> ok lunch
[02:55] <Mithrandir> asac: ok, that's the right fix?
[02:55] <Mithrandir> asac: rather than using gcc 4.1?
[02:55] <asac> yes
[02:55] <Mithrandir> ok, cheers.
[03:07] <kyleN> Hi Bob
[03:13] <Mithrandir> hi kyle, bob
[03:15] <kyleN> Hi Mithrandir
[03:17] <kwwii_> hi bob, kyle, tollef
[03:21] <kyleN> good morning, at least from my perspective ;)
[03:28] <kyleN> kwii, I am taking a look at your comments. thx.
[03:29] <kyleN> kwwii, do you know whether slicer includes extracted file distribution?
[03:30] <kyleN> and, can you describe more the tool you proposed to make the "metatheme"?
[03:33] <doko> asac, Mithrandir: midbrowser did scucessfully build.
[03:41] <asac> re
[03:45] <asac> doko: there is something wierd going on ... 
[03:45] <asac> doko: http://launchpadlibrarian.net/8881777/buildlog_ubuntu-gutsy-i386.midbrowser_0.1.6a-0ubuntu3_FULLYBUILT.txt.gz
[03:45] <asac> search for -fvisibility
[03:45] <asac> there not a single match
[03:45] <asac> while http://launchpadlibrarian.net/8916005/buildlog_ubuntu-gutsy-lpia.midbrowser_0.1.6a-0ubuntu3_FULLYBUILT.txt.gz ... is built as expected
[03:47] <doko> hmm ...
[03:47] <doko> looking at PR26905
[03:48] <doko> checking For gcc visibility bug with class-level attributes (GCC bug 26905)... yes
[03:48] <doko> checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no
[03:48] <asac> crazy
[03:49] <asac> apparentyl our gcc is only fixed on lpia?
[03:49] <doko> any reason why this fails? that was fixed one year ago and is in the 4.2 branch
[03:49] <doko> asac: yes, let me look at 4.1, fc does have a backport to 4.1
[03:49] <asac> hmm ... we have gcc-4.1 everywhere expect on lpia right?
[03:49] <doko> yes
[03:50] <asac> i think it would be worth to have it as firefox should be a lot faster with visibility hidden according to bsmegdberg
[03:54] <kwwii> kyleN: I assume that at some point in the build process the sliced files are automatically copied to the right place
[03:54] <kyleN> that would make it hard for the designer to check his work in situ as he goes, wouldn't it? maybe we could add a makefile for that
[03:55] <kwwii> kyleN: I think that some graphical client which allows one to pick the template file(s) and other parts ...it could perhaps show some kind of preview as well
[03:55] <kwwii> kyleN: actually, I guess that some makefile is what copies the pics to the right place now
[03:56] <kyleN> kwwii, do you agree that a thrid party designer would want to copy his files into a working target? or is that beyond their scope?
[03:56] <kyleN> hi horace
[03:56] <kwwii> kyleN: I think that is the only real way to test it
[03:57] <horaceli> hi, kyleN
[03:57] <horaceli> is bspencer here?
[03:57] <bspencer> horaceli: hello
[03:57] <kwwii> one hard thing about doing this artwork is the resolution of the devices...just looking at the pics on a normal computer is not enough
[03:57] <horaceli> hi, kwwii.
[03:58] <kwwii> hi horaceli
[03:58] <kwwii> morning bob
[03:58] <kyleN> if they run xypher and a target from image-cretor, is that enough for the artist to check his work?
[03:58] <kwwii> kyleN: for some test it would be enough, but in the end it needs to be done on a device I think
[03:58] <bspencer> kyleN: mostly, except for color depth issues on the device I'd guess
[03:59] <kwwii> bspencer: the size (dpi) is important too
[03:59] <kyleN> hmm, if they are actually developing a theme for a real device, maybe they can create a real image with image creator and boot the device with it to check their artwoork
[03:59] <kwwii> kyleN: that is exactly how I am doing it now
[04:00] <bspencer> kwwii: you got a Q1 finally?
[04:00] <kyleN> when I launch xypher, I set the dpi...
[04:00] <kwwii> bspencer: yepp, arrived yesterday
[04:00] <kwwii> so I stayed up late last night tweaking things :-)
[04:00] <kwwii> and in doing so broke two of my toes :p
[04:00] <kyleN> lol
[04:00] <bspencer> really?
[04:00] <horaceli> should the artwork support different resolutions?
[04:00] <kyleN> horace, I don't think so 
[04:00] <bspencer> I do  :)
[04:01] <kwwii> yes, it has to
[04:01] <kyleN> because the theme would be for a specific device with a known resolution
[04:01] <kwwii> every device might have a different resolution
[04:01] <bspencer> not true.  Each device might have variable res.  besides orientation 
[04:01] <kyleN> ok.
[04:01] <bspencer> (not true to Kyle)
[04:01] <horaceli> yep, like screen rotation.
[04:01] <bspencer> and it would also be nice for a theme to span multiple devices if possible
[04:02] <kwwii> zooming, when we have that might be a problem as well
[04:02] <kwwii> bspencer: I am guessing that at least certain parts will be reused from device to device
[04:02] <bspencer> mm, not sure how zooming would work
[04:02] <bspencer> so how does a theme handle multiple res ?
[04:03] <bspencer> all graphics have to be stretchable in the right direction
[04:03] <kwwii> right, scalable or tile-able, depending on the situation
[04:03] <doko> asac: what's the problem jsut explicitely building with 4.2? I really don't want a 1800 line backport ...
[04:04] <bspencer> so I don't have an agenda for our theme chat.  What should we cover, and how to proceed.
[04:04] <kyleN> I would like to cover certain things...
[04:04] <kyleN> ;)
[04:04] <kwwii> I guess we should talk about the best formats to use, and roughly what we need to change
[04:05] <horaceli> and the schedule to create a first UME theme package.
[04:05] <horaceli> as a sample?
[04:05] <kwwii> horaceli: yes, good point
[04:05] <kyleN> that's good, horaceli
[04:05] <horaceli> I am happy everyone cares about this. :-)
[04:06] <asac> doko: ... i am unsure if its ok to build firefox with not-default gcc
[04:06] <kyleN> I think some of my topics from my emails should be discussed
[04:06] <doko> asac: why?
[04:06] <kyleN> for example: what's the expecation for themeing an app for ume
[04:07] <kyleN> what's the expectation for the thrid party theme designer (can he test his theme)
[04:07] <kwwii> well, until we have some mechanism to switch themes the only way to test it is going to be to replace pics and build an image
[04:07] <asac> doko: so its ok? (firefox shouldn't have any problems from what i see)
[04:08] <bspencer> test:  replace pics and restart Xephyr
[04:08] <kyleN> kwwii, yes, so why not give him the licer and a makfile?
[04:08] <horaceli> kyleN, I am not sure if we will cover every app theme. like we may cover some built-in apps.
[04:08] <kyleN> (darn typos)
[04:08] <kwwii> kyleN: sure, the slicer is there already (alhtough it needs work)
[04:09] <bspencer> ok.  let's talk about that first:  what needs to be done with the tools
[04:09] <kyleN> can a designer be expected to use slicer? is it too hard?
[04:09] <horaceli> but for other third-party applications, they might create their own theme, right?
[04:09] <bspencer> horace and I could work on the tools, while Ken works on the pics
[04:09] <kwwii> kyleN: right now it is probably too hard
[04:09] <horaceli> kyleN, it is not too hard.
[04:09] <kyleN> if slicer is too hard,maybe we need to make it esaier?
[04:09] <kyleN> sorry, I misunderstood...
[04:09] <horaceli> and actually designers could take a sample Makefile ans just create their artwork.
[04:09] <kwwii> horaceli: yeah, third party apps might add their own stuff like icons, splash screen images, and special artwork for special widgets, etc.
[04:10] <horaceli> and use the Makefile to do slicing.
[04:10] <doko> asac: it's a stable release (4.2.1), so the only thing that can go wrong are packages b-d on firefox-dev and using the default gcc. we should see these build failures easily. otoh changing the compiler at this point of time?
[04:10] <kwwii> horaceli: sure, just changing the existing artwork is easy - edit the pic
[04:10] <kwwii> horaceli: but changing sizes or such is a bit harder
[04:10] <horaceli> kwwii. yep. that could be
[04:11] <bspencer> how can we update slicer to handle multiple res ?
[04:11] <horaceli> the picture size and position in template could be configurable in layout config file.
[04:11] <bspencer> or is that just a matter of making the right graphics?
[04:12] <horaceli> and for slicer tool, I read its source code, it should just read the information from the config file, and then slice the template
[04:12] <kwwii_> bspencer: the only way I know to do that would be to do it all in svg and then export to different sizes (although that will not always work right either)
[04:12] <horaceli> so if some picture size and postion changed, updating the layout file should be ok.
[04:12] <asac> doko: probably not before tribe-5 :) ... no seriously, I will think about it ... but I think we should just stick to no use visibility hidden for gutsy
[04:13] <bspencer> kwwii_ so after the graphics have been sliced there will exist muliple versions of graphics in the "theme" directory for each resolution posibility?
[04:13] <bspencer> currently Hildon can inteligently stretch the panel graphics by duplicating them
[04:13] <bspencer> so if the graphics are dithered in the right direction it looks nice
[04:14] <horaceli> bspencer, that should be icon theme. as far as I know, hildon theme image only support single resolution.
[04:14] <kwwii_> bspencer: we could come pretty close to that - as long as the svg's are pretty simple and can be rendered with something running on the build server and/or one exported pics beforehand for every size
[04:14] <bspencer> perhaps we should organize the pieces of a theme that will be resized in a certain section of the template.png so artists know they will be stretched.
[04:14] <kyleN> different version of each image file for each resolution. there ren't that many possible resolutions adn it it known at build time what they are
[04:15] <kwwii_> bspencer: yeah, it would help to know which pieces are stretched, which ones tiled, etc
[04:15] <kwwii_> kyleN: agreed
[04:15] <kyleN> is stretching going to look good enough for a serious UME product?
[04:15] <doko> asac: make it conditional for lpia/other
[04:15] <kwwii> kyleN: that was my worry as well
[04:15] <kwwii> for some thing it will work for others not
[04:15] <bspencer> kyleN:  by stretching I meant dupllicating a graphic, not really stretching it
[04:16] <kwwii> ok, I call that tiling :-)
[04:16] <kyleN> I think for a real product they would know the resolutions they would need in advance and be willing to create all needed graphics that fit well
[04:16] <kwwii> one just has to be sure that the pic in question is suitable to be tiled
[04:16] <kyleN> and, that the list of app would be known in advance too
[04:16] <bspencer> the most complex scenario is a device has 2 resolutions, with two orientations for each (vert and horiz).  1024x600 and 800x480, for example.
[04:17] <kwwii> kyleN: what about third party apps that are installed afterwards?
[04:17] <kyleN> that's up to the user, whether themeing extends to that, well, that's extra credit
[04:17] <kyleN> the thing that is needed is coherent theme of everythign at build time
[04:18] <kyleN> and, a clear 'theme api" for apps: this is how you UMEize the app to fit themeing
[04:18] <kwwii> right, as well as having the infrastructure available for third party apps to put their pics in a decent location
[04:18] <kwwii> exactly
[04:19] <bspencer> it'd be nice to have a doc that explained this
[04:20] <bspencer> so what has to be changed in the slicer?
[04:20] <kyleN> so, should we define the tools and procedure from the point of view of a designer an on the app theme api?
[04:20] <kwwii> yes, we should write docs while creating the first themes
[04:20] <kwwii> bspencer: nothing more than sizes and locations
[04:21] <bspencer> how can we figure out what are all the graphics needed for a theme?
[04:21] <kwwii> bspencer: the first revisions will probably just use the same stuff we have now I guess, and we will see where we need to change things after that
[04:21] <horaceli> yep, then tools might be reusable. we could just change the layout file.
[04:21] <kwwii> bspencer: by looking at what each pic does after being cut up
[04:21] <bspencer> k
[04:21] <kyleN> there's a lot to do
[04:21] <kwwii> bspencer: and by making a list of other graphics used and their purpose which are not included in the template
[04:22] <bspencer> horaceli: something I've noticed is that some apps show a border around the window, some do not
[04:22] <kwwii> kyleN: no doubt :-)
[04:22] <kyleN> bspencer, yes a lit of what is in the template.
[04:22] <horaceli> bspencer, I should remove the border by default.
[04:22] <kyleN> for example: NOT boot splash images?
[04:22] <bspencer> in general our apps are currently not too well behaved or consistent
[04:22] <horaceli> but for toolbar widget, its theme still has border now
[04:22] <kwwii> bspencer: I think that is how nokia showed the difference between windows and pop-ups
[04:23] <bspencer> kwwii: I think it is ok to have a border, but our apps are mixed
[04:23] <kwwii> ouch
[04:23] <bspencer> and the ones with borders are ugly (only right and bottom border)
[04:23] <bspencer> so it is a framework issue
[04:24] <bspencer> we'll also have headaches if we deviate too much from Hildon because we'll be merging with them.  So we should think about how our changes can be accepted by the Hildon project
[04:24] <kyleN> if its windows and popups, isn't that controlled by matchbox theme?
[04:24] <horaceli> I think currrently one possible way to tell what images are used in theme is to read through the gtkrc, and gtkrc.maemo-af-desktop as well as matchbox theme.xml
[04:24] <kyleN> we shouldn't deviate from hildon unless necessary, but how much of theming is iIN hildon anyway?
[04:25] <kyleN> i would like to propose that themeing CAN include gtk images, but that is extra credit
[04:25] <kwwii> bspencer: I'll ask tigert to look in on this so we can work out issues like that, or at least have a good starting point to discuss it with others
[04:25] <kyleN> that the template.png MUST include all desktop specific images and icons and CAN optionally iknclude gtk images
[04:25] <bspencer> kyleN:  all the references to the graphics is in the Hildon-desktop code
[04:25] <bspencer> so we have to use the same graphics names, or update the Hildon code
[04:25] <kwwii> horaceli: yeah, but that gtkrc stuff is nasty
[04:26] <kyleN> bspencer, so your "mb_" image names are hard coded in hildon?
[04:26] <kwwii> kyleN: I am really against including icons in the template
[04:26] <horaceli> bspencer, I think graphics names are used in gtkrc file.
[04:26] <horaceli> and in Hildon code, it just set style name or something.
[04:27] <kwwii> horaceli: right, that is how I understood it as well
[04:27] <bspencer> horaceli: yeah
[04:27] <kyleN> kwwii, why against desktop-specific icons in the template?
[04:27] <horaceli> kwwii, yes, you are right. I will try tomorrow to see if I could write a script to collect the png list in gtkrc.
[04:27] <bspencer> I didn't mean the file name -- just that the theme file matched a value in code.  If that file isn't there it is a problem.
[04:28] <kyleN> the gtkrc files used to be named in the xinitrc file
[04:28] <kwwii> kyleN: because updating them is harder
[04:28] <kyleN> why is it harder?
[04:28] <bspencer> I don't see icons in the current themes
[04:28] <kwwii> because the existing icon themes are not in that format
[04:29] <kwwii> bspencer: they are not, now (and I'd like to keep it that way)
[04:29] <kwwii> so everytime a theme changes one has to tweak it into that file
[04:29] <kyleN> I am thinking from the point of view a thrid party trying to design a theme, one way is simpler than many ways
[04:29] <bspencer> are we talking about putting icons in the template.png, or something else?
[04:29] <bspencer> I don't think icons should be part of the template.png
[04:29] <kyleN> bspencer: yes that is the topic
[04:29] <kwwii> bspencer: yes, we are talking about putting icons in template.png
[04:30] <kwwii> :-)
[04:30] <bspencer> why not have them in the icons-related folder 
[04:30] <kwwii> exactly
[04:30] <bspencer> didn't we chat about that?  /usr/share/icons/<theme>
[04:30] <bspencer> and hicolor as the backup
[04:30] <kyleN> that's fine, I just want it to be easy to communicate to a real thrid party designer
[04:30] <kwwii> yes, exactly
[04:30] <horaceli> yep, I agree with bspencer
[04:30] <kyleN> how do they know the list of valid icons, jusgt evey single one in there?
[04:30] <kwwii> icons should really be the only thing that is not included in the template though
[04:30] <bspencer> so 3rd party designer steps are what then?
[04:31] <horaceli> 'cause the designer who create theme might not be the one who create the icon right?
[04:31] <kwwii> 1) edit the template 2) edit gtkrc 3) edit icons
[04:31] <bspencer> why #2?
[04:31] <kwwii> because it also includes some line thickness, centering, and colors, I think
[04:31] <bspencer> what are they changing in the gtkrc file?
[04:31] <kyleN> is #2 extra credit, and why wouldn't the designer create the icon?
[04:31] <doko> asac: no chance for a backport
[04:32] <bspencer> kwwii: ok.  ugh.  gtkrc editing is tedious
[04:32] <kwwii> for instance, if I change the current them to black, there will stil be lots of white stuff showing up
[04:32] <bspencer> kwwii: good point
[04:32] <kwwii> bspencer: yeah, I know (and hate it)
[04:32] <bspencer> desktop backgrounds -- are they part of the theme?
[04:32] <kwwii> I have just been using bash to change color values
[04:32] <bspencer> (e.g. plankton includes a default one)
[04:32] <kyleN> bspencer: YES
[04:32] <bspencer> but not part of the template.png
[04:32] <bspencer> ?
[04:33] <kwwii> yes, it should be a part of the metatheme
[04:33] <horaceli> kyleN, I am not sure , like on currrent gnome desktop. gtk theme is seperated with icon theme.
[04:33] <kwwii> horaceli: right, gtk has become flexible enough to have it seperate
[04:33] <bspencer> I don't think plankton's default background is part of their template.png
[04:33] <bspencer>  /usr/share/backgrounds
[04:33] <bspencer> not in the theme/images folder
[04:34] <kwwii> it can now define spacing between colors and then figure out the exact color itself (allowing one to simply change colors on a running machine)
[04:34] <kyleN> mobile-basic-flash specifies the background
[04:34] <bspencer> so we would have icons /and/ backgrounds separate from the template.png
[04:34] <kwwii> and probably any splash screens
[04:35] <bspencer> ok.  
[04:35] <bspencer> so are all of these part of the same debian theme package?
[04:35] <kyleN> I am not sure why we want to separate all of this stuff from template.png. it makes it harder and harder to track and communicate with thrid-party designers
[04:35] <kwwii> bspencer: they should be but are not at this time, that is why I suggest making a metatheme which pulls in all these pieces
[04:36] <bspencer> kyleN:  I don't know if the backgrounds should be separate, I'm just saying I don't see it in the current Hildon plankton template.png
[04:36] <kwwii> it is not in it now
[04:36] <kwwii> but I do not see what we win by putting it in that way
[04:36] <kyleN> I think we should focus on keeping it simple and manageable, which to me means one approach to graphical themeing
[04:36] <kwwii> we cannot then include different wallpapers
[04:37] <bspencer> kwwii: metatheme:  sounds good.  It might be nice to have a "theme checker" that validates a theme.  (some day)
[04:37] <asac> Mithrandir: in case you didn't do ... you have to update the 99_configure.dpatch patch for xulrunner after adding in the patch i gave you (note: its autoconf2.13 your have to run) ... xulrunner doesn't run autotools during build.
[04:37] <kwwii> most will want to include several wallpapers so that the user has a choice
[04:37] <kwwii> bspencer: nicest would be to have a GUI app to plug in all these pieces and create such a metatheme
[04:37] <horaceli> in the way that we put all these images into one theme package, a designer who is going to create a hildon theme would have to provide background, splash screen and icon theme too
[04:38] <kwwii> then the artist only sees one interface for creation
[04:38] <kwwii> horaceli: right
[04:38] <kwwii> and the usplash will always be a pain, no matter what
[04:38] <kyleN> that sounds promising
[04:38] <horaceli> will that be a bit complicated for the designer?
[04:39] <kwwii> I do not think so, we just need to keep the number of different pieces down to a minimum
[04:39] <kwwii> and document this stuff very well
[04:39] <horaceli> also user would probably like to change their own background image
[04:39] <horaceli> so maybe seperate background image is better, what do you think?
[04:39] <kwwii> horaceli: and pick their own colors as well
[04:40] <kwwii> although that is probably secondary
[04:40] <bspencer> kwwii: how do they pick colors ?
[04:40] <horaceli> kwwii, right
[04:40] <horaceli> I sometimes do that. :-)
[04:40] <bspencer> can a theme support different colors?
[04:40] <asac> Mithrandir: at best let me do it ... the patch has a bug (for non lpia archs) ... so i will upload midbrowser + xulrunner + firefox with a new version today.
[04:40] <kwwii> bspencer: yes, the gtkrc can be flexible enough to handle that
[04:40] <bspencer> default font colors -- or border colors?
[04:40] <kyleN> sure. matchbox themes and gtkrc styles support colors
[04:40] <bspencer> k
[04:41] <bspencer> startup splash -- is that part of the theme package?
[04:41] <bspencer> I was thinking it was separate
[04:41] <kyleN> it is a part of the theme, absolutely
[04:41] <kwwii> it probably should be
[04:41] <bspencer> because you might have a device with a "Ubuntu" startup splash, but the user can't change that
[04:41] <kyleN> not user-settable themes though
[04:41] <bspencer> or more particularly another company logo
[04:41] <kwwii> bspencer: right, it is only change by root
[04:42] <kyleN> set at build time never to change
[04:42] <kwwii> it will probably be set at build time and not changeable afterwards (without skills)
[04:42] <bspencer> ok... what is a "user-settable" theme vs a normal theme ?
[04:42] <kyleN> usesr settable and normal are different
[04:42] <bspencer> is there one theme package, or a theme for startup splash and the normal theme.
[04:42] <kyleN> i doubt users will ever set gtk stuff for example
[04:42] <kwwii> there is a default theme which is shipped, some of that is settable by the user
[04:43] <kyleN> user settable may be limited to colors and backgrounds
[04:43] <kwwii> or one could make the whole metatheme switchable, as nokia does now
[04:43] <bspencer> ok.  you mean user-settable is a UI-supported change-at-runtime thing
[04:43] <kwwii> bspencer: exactly
[04:43] <kyleN> b spencer, yes
[04:43] <bspencer> we should identify that too
[04:44] <kyleN> let's make a list of exactly what we think a build-time default theme consists of
[04:44] <bspencer> so I can start making those changes.   maybe that is in the control panel theme changer utilities
[04:44] <kyleN> boot splash images, right?
[04:44] <kwwii> the usplash seems like the only thing that should not be changed by the user to me
[04:45] <kwwii> sa more often than not it is pure branding
[04:45] <kyleN> yes, but it is a part of the theme that a third party would want to set, right?
[04:45] <kwwii> s/sa/as
[04:45] <kwwii> kyleN: yes
[04:45] <kyleN> what else, desktop background, right?
[04:45] <bspencer> I have to stretch my thinking.  Before I thought the user would change a theme by replacing which /usr/share/themes/<theme> folder was used.  But there are more options than that
[04:45] <kwwii> theoretically they will want to change everything, I guess
[04:46] <bspencer> so if the user downloads a new theme package, then that package might have a different uplash image in it?
[04:46] <kyleN> no, not everything
[04:46] <kyleN> not layout
[04:46] <kwwii> bspencer: no, that would need root rights to change the usplash
[04:46] <kwwii> I would avoid that 
[04:46] <bspencer> ok... so break the pieces up for me
[04:46] <kyleN> so desktop background is or is not a part of the graphical theme? yes, i think
[04:47] <kwwii> the usplash is the only thing that a third-party theme (installed and selectable by the user) should not include I think
[04:47] <horaceli> so in that case, should we seperate usplash from the theme package?
[04:47] <bspencer> kwwii: ok.  that makes sense.  usplash = multiple splash files that show during boot (bios, kernel load, X startup)
[04:47] <kwwii> horaceli: no, that will still be part of what others will change, but that will not be a part of theme which is installable on top of the existing default theme
[04:48] <bspencer> kwwii: ok, that's where I get lost.
[04:48] <bspencer> how to overlay one theme on default theme
[04:48] <kyleN> horaceli, I am looking at it differently. I look at it from the point of view of communicating with the third party designer, not switching themes at run time. so the uboot splash images are a part of the graphical theme
[04:48] <kwwii> kyleN: right
[04:48] <bspencer> and how and end user downloads a new theme, but not the usplash, etc.   (this is in addition to making changes inside an existing theme like colors, font, etc)
[04:49] <horaceli> kyleN. I see. just considering installation, I have the same question with bob, how to overlay a new theme on a default one.
[04:49] <kyleN> good questions, but I think usplash is not changeable
[04:49] <kwwii> a new theme would replace parts of the existing theme (by installing the necessary pieces and then pointing to them in some preference
[04:50] <kwwii> my idea was to have one package which an artist from a vendor can download and start changing instead of him/her having to find all the pieces themeselves
[04:50] <kyleN> kwwii, is that your metatheme idea? can you please elaborate?
[04:51] <kwwii> so the usplash is seperate from the metatheme 
[04:51] <kwwii> the metatheme would contain all the pieces except the usplash
[04:52] <kwwii> it could be one package including the usplash, only at build time the usplash is not put into the metatheme but rather put where in seperately
[04:52] <bspencer> right now when I change themes it is all contained in one folder.  If I want to change anything, I have to change everything
[04:52] <kwwii> bspencer: but that does not change the usplash, or?
[04:53] <bspencer> no, because right now usplash isn't in the themes folder :)
[04:53] <kyleN> themes are spit into theme and icont theme folders now, not all in theme
[04:53] <bspencer> but I'm not doing it intelligently now
[04:53] <kyleN> is the "package" more complicated than necessary? more complicated for example than a template.png with documentation?
[04:54] <bspencer> but let's say there is a debian package with a /usr/share/themes/<theme> folder, /usr/share/icons/<theme>  and /usr/share/backgrounds/<themebk.png>     Where is the usplash stuff and how does the process of changing themes work?
[04:54] <kwwii> it seems like we need 1) a total theme package (all artwork that a company will want to change for their device) and 2) a method for installing "themes" (everything except the usplash) in a running system
[04:54] <kyleN> kwwii: YES
[04:54] <kyleN> and I think we need to define 1) 
[04:55] <kwwii> so 1) would create a 2) +  an usplash and set it all as default
[04:55] <kyleN> personally, i think 1) includes icons, because a vendor will want it to
[04:55] <bspencer> kwwii: yes, and 3) a UI mechanism to allow the user to change parts of an installed theme (colors and font), or change to a new theme altogether
[04:55] <kwwii> bspencer: right
[04:56] <kyleN> and, we need to define how applications implement a UME theme
[04:56] <bspencer> horaceli: note:  when we're done you should talk with martin about how he is doing the usplash stuff and make sure we are in sync.
[04:56] <bspencer> kyleN:  "implement" ?  or use?
[04:56] <horaceli> bspencer, ok
[04:56] <kwwii> bspencer: btw, you need to add a new config file for the current stuff so that the pic does not get scaled as it does now
[04:56] <kyleN> how to port an app to UME that supports our themeing approach
[04:57] <bspencer> kyleN:  right.
[04:57] <bspencer> kwwii: where does that happen now?  
[04:57] <bspencer> kwwii: how do I do that? 
[04:58] <kwwii> bspencer: in the usplash package there is a config file...it is really easy to understand. basically it looks like we just need to add the needed resolution pic
[04:58] <kwwii> bspencer: I can look into it as I created the current version
[04:58] <bspencer> kwwii: ok.  I haven't looked at that package
[04:58] <kyleN> I have been trying to define 1) total artwork to theme. There does not seem to be agreement whether this includes icons or not. can we address this point?
[04:59] <bspencer> theme :   a debian package with a /usr/share/themes/<theme> folder, /usr/share/icons/<theme> and /usr/share/backgrounds/<themebk.png> 
[04:59] <bspencer> the theme is created from a template.png and a set of icons and backgrounds
[04:59] <bspencer> icons and backgrounds are included in the theme packgae, but are not part of the template.png
[04:59] <kyleN> bspencer, ok. what is the list of required icons?
[04:59] <kwwii> bspencer: exactly, as well as the gtkrcs
[04:59] <kwwii> which would be in /usr/share/themes/<theme>
[05:00] <bspencer> right.   and also matchbox/theme.xml 
[05:00] <kwwii> yupp
[05:00] <bspencer> also included in <theme> folder
[05:00] <bspencer> kyleN:  no idea :)
[05:00] <kyleN> I agree. how do we know the list of all icons that must be themed?
[05:00] <bspencer> (about icons)
[05:00] <kyleN> ok. 
[05:00] <kyleN> ;)
[05:00] <bspencer> let's think about it
[05:00] <kwwii> kyleN: for anyone who is going to take existing icons from any other project it will be more work to paste new versions into the template file
[05:01] <kyleN> that takes care of what I call the "desktop theme" now, how about the applilcation theme api?
[05:01] <bspencer> kyleN:  wait
[05:01] <kyleN> ok
[05:01] <bspencer> I want to talk about icons
[05:01] <kyleN> ok
[05:01] <kwwii> basically the apps are themed just as the desktop is...the only thing they might want to add is extra icons and perhaps a splash screen
[05:01] <bspencer> what icons does a theme include?  Does it include application icons or just those present in the framework?
[05:02] <kyleN> and by the way, the background is currently set by mobile-basic-flash plugin, which doesn't seem right
[05:02] <Mithrandir> kwwii: worst case as for resolutions> some of those devices have VGA out, like the Q1..
[05:02] <kwwii> icon themes include all app icons as well (third party apps put their icons in hicolor)
[05:02] <kyleN> kwii: yes
[05:02] <kwwii> Mithrandir: ouch, good point
[05:03] <kyleN> someone has to figure out if icon themeing actually works now
[05:03] <Mithrandir> kwwii: I'm not sure if and how we should handle that
[05:04] <bspencer> kwwii: app icons -- how does a theme know about apps?  do gnome themes do this?
[05:04] <bspencer> kyleN: yeah, we are working on that.  mobile-basic-flash should  pick up the default background 
[05:04] <kyleN> brb -- bathroom break
[05:04] <kwwii> bspencer: the app looks for the icons in the heirarchy...apps installed by the user add their icons to the right places in that list
[05:05] <kwwii> Mithrandir: not sure if there is any easy way to do that
[05:05] <bspencer> Mithrandir: how about this:  it just looks really ugly :)
[05:05] <kwwii> :p
[05:05] <Mithrandir> bspencer: that's non-ideal. :-)
[05:06] <bspencer> it would be nice to have a device to take to presentations and hook up to the projector
[05:06] <kwwii> we should implement a feature where the usplash only does one fixed size/ratio and then pads everything around it to a given color (probably black)
[05:06] <bspencer> so is that 640x480?
[05:07] <bspencer> kwwii: sure.  centered image
[05:07] <kwwii> exactly
[05:07] <kwwii> having a fullscreen splash was a feature at the time :-)
[05:08] <bspencer> we want to have a fullscreen splash right up until the UI homescreen is displayed
[05:08] <bspencer> this involves 3 images
[05:08] <kwwii> at this time, yes it is at least three images
[05:08] <kwwii> background, throbber_fore and throbber_back
[05:09] <kwwii> but that is also changeable (although you have to know C to change that)
[05:09] <horaceli> kyleN, kwwii, bspencer, I am a bit lost in the topic. so will icons as well as backgrounds be included in template.png?
[05:09] <kwwii> we should probably just keep the usplash as simple as possible
[05:10] <kwwii> horaceli: I would rather that they stay seperate
[05:10] <kyleN> horaceli, the feeling seems to be no they won't be included. but if not, i am not sure how the designer knows the list of icons he has to theme
[05:10] <horaceli> kwwii, I agree with you
[05:10] <kwwii> we need a good list of icons and their purposes (often the name of the icon gives it away)
[05:10] <bspencer> horaceli: not in template.png... but included in the debian theme package
[05:10] <kyleN> again, I am thinking about communicating this stuff to vendors.
[05:10] <bspencer> yes, we need a list of icons to include
[05:11] <kwwii> one point: when I say icons, I do not mean the arrows and such used on the widgets
[05:11] <kwwii> all of those small pieces should be in the template
[05:11] <kyleN> yes, lets define icons better
[05:11] <bspencer> which is what I'm not sure about -- what applications are "most important" and included in a theme
[05:11] <bspencer> is the browser theme in the theme?
[05:11] <bspencer> email, chat, camera, bob's-foo-app
[05:12] <Mithrandir> kwwii: feature> usplash already supports that, by design.
[05:12] <kyleN> is the browser theme a special case (since it is much more complicated)?
[05:13] <bspencer> icon = standard icons, not widget graphics
[05:13] <kwwii> icons as I see them are images used to represent either: actions, mimetypes, apps, devices, emblems, emotes, filesystems, places, status, categories and animations
[05:13] <bspencer> 32x32, 64x64, svg, etc.
[05:13] <kyleN> kwwii, you took that from the freedesktop icon theme standards didn't you ;)
[05:13] <bspencer> yeah.  so someone should write the list of icons needed.
[05:13] <kyleN> are they ALWAYS square?
[05:13] <kwwii> kyleN: yepp, although looking back filesystems should not be there I guess
[05:14] <kwwii> kyleN: yes, always
[05:14] <kwwii> although animations might not need to be
[05:14] <kyleN> ok, then the current applications toolbar button background is not an icon
[05:14] <kwwii> kyleN: it should be, and it should be square to fit in with the rest
[05:14] <kyleN> (the one that looks like a miniature screenshoot of the desktop)
[05:15] <kwwii> although that might be a point of discussion as it look pretty neat to have a non-square icon there
[05:15] <kwwii> much more like MS
[05:15] <kyleN> is there a usage difference between icons and non icons?
[05:15] <kyleN> like, icons are on widgets, non icons are not?
[05:16] <bspencer> kyleN: the current app icon isn't 48x48?
[05:16] <kwwii> some icons are used on widgets (like the "ok" and "cancel" icons)..the arrows and checks and such are not icons
[05:16] <kyleN> why are the arrows and checks not icons?
[05:17] <bspencer> kwwii: right
[05:17] <kwwii> erm, note that when I saw they are square that does not mean that the whole square is filled with colorfull pixels
[05:17] <kyleN> the mb_apps_menu.png is 48 x 42
[05:17] <kwwii> kyleN: because they normally only use one size and are often much smaller than the other icons (like 8x8 or 10x10)
[05:18] <kwwii> and logically they belong to the widget theme, not the icon theme
[05:18] <kwwii> visually as well
[05:18] <kyleN> hmmm
[05:18] <kyleN> by widget theme you mean gtk
[05:18] <kwwii> yes
[05:19] <kyleN> which means they aren't in /usr/share/icons bu in /usr/share/themes...
[05:19] <kwwii> if the gtk theme defines a checkbox, the check that is shown on that should not be changeable with the icon theme as it might no longer fit with the rest of the widget theme
[05:19] <kwwii> right
[05:19] <kyleN> kwwii, right
[05:20] <kyleN> that's good because it limits the number of basic themable icons
[05:20] <kyleN> (gtk images are themeable, but that's extra credit ;)
[05:20] <kwwii> right :-)
[05:20] <kwwii> changing the background and the icons will be the main tweaks for most I guess
[05:21] <kyleN> and the colors...
[05:21] <kwwii> and the usplash...
[05:21] <kwwii> ;-)
[05:21] <kyleN> themeing has two parts: build/design time, and user change time. the two are not identical sets of things
[05:21] <kwwii> yepp
[05:21] <kyleN> i would like us to get really specific about which parts fall into which categories
[05:22] <kyleN> boot splash; built theme, not user changeable, right?
[05:22] <kwwii> right
[05:22] <kyleN> desktop background, built theme and user changeable, right?
[05:22] <kwwii> right
[05:23] <kyleN> desktop icons (which includes all icons that ship with the product) build theme and maybe someday user changeable, right?
[05:23] <kwwii> right
[05:24] <kyleN> gtk themes (styles and images) build theme and probably not user changeable in the real world anytime soon, right?
[05:24] <kwwii> probably only the color will be changeable soon
[05:25] <kyleN> ok, would that be done by modifying the actual gtkrc files, or just there in memory representation?
[05:25] <kyleN> (or some other way...)
[05:25] <kyleN> matchbox theme: built, not user changeable, right?
[05:26] <kwwii> no the gtkrc would not be changed, only some definition of the base colors would be changed
[05:26] <kwwii> the matchbox theme, like gtk, would only change colors
[05:26] <kyleN> isn't the base definition IN the gtkrc file?  but this is a detail
[05:26] <kwwii> we might have to simply offer several color variations (in gtk and matchbox config files)
[05:27] <kwwii> much like nokia does now
[05:27] <kyleN> OK, i think gtrc files have inheritance rules so you can have multiple definitions of the same thing...
[05:27] <kyleN> so that roughly a definition of what is graphical themeable, now, how about packaging/tools for the designer
[05:28] <kwwii> at this time, you change the pics you want to change and wait for a developer to include it in the build
[05:28] <kyleN> yes, but I am thinking about making it doable for a vendor. 
[05:28] <kwwii> having some simple GUI app to select pics (and check sizes at the same time) would be nice
[05:29] <kwwii> then you do not need a check list
[05:29] <kwwii> but I guess we are a long way from that 
[05:29] <kyleN> yes, but that is user settable themes, I mean how to design/implement the default theme(s) for a third party who might want to use UME
[05:30] <bspencer> kyleN: I think he was talking about a tool that thrd party would use to create a theme
[05:30] <kyleN> does that include slicer, or is it a replacement?
[05:30] <bspencer> in addition
[05:30] <kwwii> aside from the usplash there is little difference between user created themes and third party themes except that third party themes will be set as default at build time I think
[05:30] <kyleN> can we try to define this more, i still don't quite get it
[05:31] <kyleN> kwii, ok. what is given to a third party theme designer to enable them to get to work?
[05:32] <kwwii> right now, the packages with the pics are given and instructions on what each pic does and the process/tool for cutting up the template, I guess
[05:32] <kyleN> I don't know what you mean, sorry for being thick. What packages with pics?
[05:32] <kwwii> the source code packages
[05:33] <horaceli> kwwii, kyleN. I am going offline. it is quite late in PRC.
[05:33] <kwwii> what we could do would be to seperate the actual pics into sub-packages
[05:33] <kyleN> that seems like too much to give to a designer. 
[05:33] <horaceli> thanks for the chat
[05:33] <kwwii> horaceli: cool, sleep well, see you soon
[05:33] <kyleN> thanks a lot for your thoughts horaceli
[05:33] <horaceli> is you have any summary, please send email to me.
[05:33] <horaceli> s/is/if
[05:33] <kyleN> ok, I'll try
[05:34] <kyleN> sub-packages? explain further please
[05:34] <bspencer> what is the minimum we can give a 3rd party:   template.png, control file (how to split up template), a list of required icons, and 1 sample background image
[05:34] <kyleN> two possibilities on the table; bspencers, and kwii's. pros and cons?
[05:35] <kwwii> kyleN: our ways are the same, really
[05:35] <kwwii> the wording is different
[05:35] <kyleN> ok
[05:35] <kyleN> does this enable the designer to tryout his theme with relative ease
[05:35] <kwwii> not really
[05:35] <bspencer> "relatively"
[05:35] <kyleN> that seems like a problem
[05:35] <kwwii> hehe
[05:36] <bspencer> because we need a way to package his results
[05:36] <kwwii> they would submit their stuff to some build process and then test it in an image
[05:36] <bspencer> I don't know if the slicer does packaging, right?  That is a non-automated step
[05:36] <kyleN> right. how about: thye have image-creator. we also provide a build file to move the images into the target
[05:36] <kyleN> wouldn't that work?
[05:36] <kwwii> we could make a script to copy the pics to the right location but at this time the image-builder needs to get it's stuff from servers
[05:37] <kyleN> maybe we can assume they have image-creator adn have made a project and target
[05:37] <bspencer> but if they are tweaking a theme, we could document how they would get it setup with a target and Xephyr
[05:37] <kwwii> kyleN: they would also need a full local source tree
[05:37] <kyleN> that's a "prerequisite" to theme creation
[05:37] <kyleN> why would they need the source tree?
[05:37] <bspencer> kwwii: what are you talking about "source tree"  :)
[05:37] <kwwii> bspencer: can image-biulder work with local sources?
[05:38] <bspencer> kwwii: no.  But after you create an image you can replace files manually in your target file system (on the workstation)
[05:38] <bspencer> without needing a device
[05:38] <kwwii> bspencer: ahhh, right...that would work
[05:38] <kyleN> manually, or with a makefile we provide 
[05:38] <kwwii> we simply need a script to copy the files to the chroot in the right places
[05:38] <kyleN> right, no source tree needed
[05:39] <kyleN> ok, so the we create a theme sdk package that includes all of this
[05:39] <kwwii> a series of makefiles would do that...they would just need to keep the same directory stucture
[05:39] <kyleN> the theme sdk dicates the dir structure
[05:39] <kyleN> dictates
[05:40] <kwwii> right
[05:40] <kyleN> how much work is this theme sdk package?
[05:40] <kyleN> to create
[05:41] <kyleN> assuming we've figued out the icon list and so forth...
[05:41] <kwwii> once we know which parts are what, it shouldn't be too much work I guess
[05:42] <kwwii> documenting it will be the most work I think
[05:42] <kyleN> I can probably help out there, assuming adequate communications
[05:42] <kwwii> as we are not radically changing anything in the process, just moving small parts
[05:43] <kyleN> can the theme sdk also apply to themeing apps that are a part of theu build?
[05:44] <kyleN> or is that really all in the app's source code
[05:44] <kwwii> kyleN: as of now, other apps will not have that much themeing of their own (an icon or two, a splash screen perhaps)
[05:44] <kwwii> if things are different it will be on a source code level
[05:44] <kyleN> kwwii, yes, I agree
[05:44] <kwwii> and that is beyond simple themeing
[05:44] <kyleN> what are the big pieces of work that need to be done, can we make a list?
[05:46] <kwwii> seperate the parts, document while changing them, make it easy to test with a script or such
[05:46] <bspencer> I hate to suggest it, but #1) go through and identify all the graphics that are needed and map this to the Hildon code so we know where each pixel is being used.
[05:46] <kwwii> bspencer: yeah, good point
[05:46] <kyleN> 1) identify all "desktop" images
[05:47] <bspencer> there are 500 of them
[05:47] <bspencer> currently
[05:47] <kyleN> 2) identify all desktop icons
[05:47] <kwwii> and figure out which images are really used in code, which are doubled, etc.
[05:47] <kyleN> 500 USED ones?
[05:47] <bspencer> and somewhere we need to identify how, where, and which graphics will be "tiled"
[05:47] <kwwii> I can easily imagine that
[05:48] <kwwii> luckily the tiling and such only occurs in the template stuff and should be defined as such in the gtkrc
[05:48] <bspencer> kyleN:  540 image in plankton.  Once we're done we'll probably be similar
[05:48] <bspencer> kwwii: right, and tiling is limited to certain areas, like panel backgrounds
[05:49] <kyleN> that's a lot, if that's not managed somehow to deleted outdated images, themeing gets harder andharder to do 
[05:49] <kyleN> is it feasible to programmatically require new themed images get registered somehow?
[05:49] <kwwii> kyleN: right, but I do not see a way around that
[05:50] <kwwii> we just need to keep the sdk up to date once it is ready
[05:50] <kyleN> programmatically or through work-flow rules
[05:50] <kwwii> but once a company changes the context or functionality of an app they will need to add and change things anyway
[05:51] <kyleN> a master list of themed images and an automated process to find new non-registered ones and send appropriate hate mail perhaps? ;)
[05:51] <kyleN> kwwii, so each vendor has to amintain their own sdk? interesting
[05:52] <kwwii> kyleN: no, they will need to change ours according to their own needs probably
[05:52] <kwwii> if they add some app with a new action it will necessarily need a new icons to describe that functionality
[05:52] <kyleN> i suspect they'll have there own code (derived from us) and won't want to change "ours" 
[05:53] <kyleN> their, I meant
[05:53] <kwwii> sa we cannot make pics for every possible purpose in advance without knowing their intentions
[05:53] <kwwii> like, if they add a plugin, it will need new icons - no way around that I think
[05:54] <kyleN> right, but why can't they do that to their own repository?
[05:54] <kwwii> they could, but if that new app or plugin replaces one of ours they will need to also remove the icons they no longer need as well
[05:55] <kyleN> in other words, any third party that would actually build a product would want to keep this to themselves, without breaking licenses of course
[05:55] <bspencer> I have to go.  I'll follow up with your guys in email.  thanks a lot
[05:55] <kyleN> thanks a lot bob!
[05:55] <kwwii> have fun bob
[05:56] <kyleN> kwwii, would they "have to" remove unused icons?
[05:56] <kwwii> kyleN: I don't think it matter whether they keep it to themselves or not
[05:56] <kwwii> kyleN: they might want to if it comes down to the size of the harddrive or such
[05:56] <kwwii> but they do not have to
[05:56] <kyleN> yes
[05:57] <kwwii> but their pics should stay in their tree only, and not influence ours
[05:58] <kyleN> so the sdk covers ume standard graphical themeing, but vendors can further customize and that is up to them how to do it?
[05:58] <kwwii> yes, that is pretty much how I see it
[05:59] <kwwii> I mean, adding pics to the right places, perhaps removing some...not much more than that on the artwork side
[05:59] <kyleN> what is needed to better define the app theme "api"?
[05:59] <kwwii> if they add apps, if will be included with the app source...but if it is in the base system it will be more than that
[06:00] <kwwii> we need to define where people should install their pics so that they are used with their apps
[06:00] <kyleN> right
[06:00] <kwwii> and so that they do not randomly pick places to put pics
[06:00] <kyleN> right
[06:01] <kyleN> is the icon theme for apps well defined now, or are their holes. I don't know exactly how it works even after reading the standard and poking aournd
[06:01] <kyleN> "there" i meant ;)
[06:02] <kwwii> the icon theme for apps fits directly into the normal icon theme, with the exception that an app can add a pic in it's own dir and use that before defaulting back to the normal theme
[06:03] <kwwii> they both have the same structure
[06:03] <kyleN> ok, so for example. foo app results in /usr/shar/icons/foo/32x32/(folder)/file?
[06:04] <kyleN> or is it /usr/share/icons/(theme)/32x32/foo/file?
[06:05] <kyleN> the latter, i suppose... 
[06:05] <kwwii> no, foo app would either add icons upstream to /usr/shar/icons/<THEME> and add it's app icon to /usr/share/icons/hicolor
[06:06] <kwwii> if it does not go into the main theme, it would be included in the /usr/share/apps/<APPNAME>/images 
[06:06] <kyleN> i see. upstream to support multiple themes, hicolor to support no theme default
[06:06] <kwwii> right, the icon loader always defaults back to hicolor
[06:07] <kwwii> at this time, I think it only uses hicolor anyway
[06:07] <kwwii> as no special theme is defined
[06:07] <kwwii> or included
[06:07] <kyleN> yes, in other words, icon themeing isn't turn on yet
[06:07] <kwwii> exactly
[06:07] <kyleN> i think we covered a lot of ground
[06:08] <kwwii> yes, we are definitely further than we were two hours ago ;-)
[06:08] <kyleN> is it your sense that folks generally agree with the details we articulated in the lst phase of the conversation?
[06:08] <kyleN> last phase
[06:08] <kwwii> yes
[06:08] <kyleN> I will attempt a concise summary and email the parties
[06:08] <kwwii> killer - thanks :-)
[06:08] <kyleN> corrections/comments welcome/appreciated as always ;)
[06:08] <kwwii> great
[06:09] <kyleN> gotta go - cheers
[06:09] <kwwii> time for me to cook dinner
[06:09] <kwwii> see you
[06:49] <asac> Mithrandir: xulrunner and mibrowser wait approval ... please let them through
[06:51] <Mithrandir> accepted
[07:07] <bspencer> Mithrandir: you alive and kicking?
[07:07] <bspencer> Mithrandir: I want to push they keyboard a little to get something functional and pretty for some upcoming presentations.
[07:07] <Mithrandir> bspencer: alive and kicking> yes, but not very present
[07:07] <bspencer> Mithrandir: what do I need to get the automatic-launch functionality working (you said you saw)
[07:08] <Mithrandir> it should be working now if you're using the package from Ubuntu
[07:08] <bspencer> just the matchbox keyboard -- or somehitng else?
[07:08] <Mithrandir> just matchbox-keyboard
[07:08] <bspencer> k.  I'll try.  thx
[07:08] <Mithrandir> Version: 0.1+svn20070815-0ubuntu4
[07:08] <Mithrandir> that one should work fine
[07:50] <Charliefjohnson> Mithrandir: Did you see my email concerning the daily build ??  
[08:08] <mdz> Mithrandir: I have, and will follow up with Tollef
[08:09] <rob_> Mithrandir / amitk_ : is there something up with the apt repos ? i'm getting unmet dependencies on the linux-image-ume package when attempting to create a target image for the crown beach platform
[08:09] <Charliefjohnson> mdz: Thanks Matt.
[08:21] <agoliveira> bspencer: Hi Bob. There yet?
[08:24] <bspencer> there
[08:25] <bspencer> agoliveira, hello
[08:25] <agoliveira> bspencer: Cool. Can you refresh my memory about the expected support for VoIP? I'm looking for alternatives to Ekiga.
[08:26] <bspencer> agoliveira, keep looking :)
[08:26] <bspencer> we are looking at voip to add to our chat application (Telepahty based)
[08:27] <agoliveira> Ah...
[08:27] <bspencer> but are still in the very early stages.
[08:27] <bspencer> just have one guy doing that
[08:27] <bspencer> and the chat app still has lots of work before it is ready doing the basic stuff
[08:27] <bspencer> but per Rob (Telepahty guy) it should be straightforward to add it
[08:27] <agoliveira> Have you seen this one: http://tapioca-voip.sourceforge.net/wiki/index.php/Landell
[08:28] <agoliveira> bspencer: or http://tapioca-voip.sourceforge.net/wiki/index.php/Ereseva
[08:28] <agoliveira> Both are based on Telepathy
[08:29] <agoliveira> Tapioca, actually which is a frameowork based on it.
[08:29] <bspencer> I haven't seen that
[08:30] <agoliveira> bspencer: You should :) Anyway, should I keep looking for something or can I assume that you will take care of this with your IM application?
[08:32] <bspencer> well, we like your tips if you have them.  We'll try to get something wiggling but it will be new code, nothing stable like we might find
[08:33] <agoliveira> bspencer: I don't have any, unfortunately, but those. I don't feel confortable using Ekiga if I can avoid as it's big and there's no hildon support on it.
[08:33] <bspencer> agreed
[08:33] <agoliveira> bspencer: Let me give a shot on those little guys above and see what happens.
[08:33] <bspencer> k
[08:36] <Mithrandir> Charliefjohnson: mdz followed up on that, I see.  I'm hoping we can have them building again tomorrow.
[08:37] <Charliefjohnson> Mithrandir : Did you pick up your Menlow yet ?
[08:38] <Mithrandir> Charliefjohnson: yes, it's safely under my desk now.
[08:38] <Mithrandir> I could possibly have had the images working today, were it not for debootstrap having a bug which broke the image creator.
[08:42] <Charliefjohnson> Mithrandir: OK. Great
[09:02] <amitk_> rob_: details of the unmet dependencies?
[09:02] <mjg59> agoliveira: I've just uploaded haze. Mission-control and empathy have both been updated to cope.
[09:03] <mjg59> So that should provide a solid MSN and AIM implementation.
[09:03] <agoliveira> mjg59: Cool.
[09:04] <agoliveira> mjg59: Could you please take a look how difficult would be to hildonize Pimlico's contacts?
[09:05] <mjg59> Yeah, will do
[09:05] <mjg59> I suspect it'll involve writing a new UI to get it to a decent level
[09:05] <mjg59> But I'll check with the OH guys
[09:06] <agoliveira> mjg59: Nice. Thanks.
[09:07] <mjg59> agoliveira: OH say "Hahahahaha"
[09:08] <agoliveira> mjg59: I don't know if I like this... :)
[09:08] <mjg59> Looks like they've had to rewrite it for openmoko
[09:08] <agoliveira> mjg59: Oh great...
[09:09] <agoliveira> mjg59: As dates and tasks already have a hildon interface I assumed it wouldn't be difficult to do it with contacts
[09:09] <mjg59> agoliveira: Quite different apps, sadly
[09:10] <mjg59> It's basically a matter of writing a new ui from scratch
[09:11] <agoliveira> mjg59: In this case we maybe consider fall back to GPE.
[09:12] <mjg59> I'll check into it. It might well not be too bad
[09:12] <agoliveira> mjg59: Well, take a look at this anyway please. If it's really this time consuming we'll see what to do.
[09:12] <mjg59> It's really just a matter of writing a new layout for the widgets
[09:12] <mjg59> I'd guess a few hours, but not too many
[09:13] <agoliveira> mjg59: If you think that's the case, go for it if you can.
[09:14] <Mithrandir> agoliveira: uh, falling back to GPE wouldn't have solved anything, firstly because I don't believe they use evolution-data-server, secondly because gpe doesn't seem to use hildon.
[09:14] <agoliveira> GPE 2.8 does;
[09:15] <agoliveira> Mithrandir: and, I didn't say we should do it, I was considering the options like it's better than nothing.
[09:16] <Mithrandir> uh, no, it doesn't.
[09:17] <agoliveira> Sorry, let me be more explicit, it does not use evolution-data-server but it does have hildon suport.
[09:17] <Mithrandir> http://www.linuxtogo.org/gowiki/GPERoadmap doesn't list any hildon libraries.
[09:17] <agoliveira> * Improved support for the Maemo platform (gpe-timesheet, gpe-filemanager,  gpe-calendar, Starling) 
[09:18] <agoliveira> The first stable release of GPE for the Maemo environment is now available.  GPE for Maemo includes the following applications: gpe-calendar, gpe-contacts,  gpe-todo, gpe-timesheet, gpe-filemanager, starling (audio player) and  gpesyncd.  The most important changes since 2.7 are:      * A heavily improved gpe-calendar and related libraries     * Improved import/export and synchronisation support     * Starling - a new audio playe
[09:19] <agoliveira> It was released about 2 weeks ago.
[09:22] <agoliveira> Mithrandir: Strange they don't have anything in the link you posted. There's been was some patches for hildon support for some time already IIRC.
[09:22] <Mithrandir> GPE doesn't use hildon.  Some GPE apps have hildon UIs too, which is something entirely different.
[09:23] <agoliveira> Mithrandir: Ok, I'm not arguing about this minucia I just said that it could be an alternative.
[09:24] <Mithrandir> mjg59: last I talked with OH, they talked about a doing a rewrite of contacts.
[09:24] <Mithrandir> (last being at guadec)
[09:24] <mjg59> Mithrandir: Yeah, it's been done
[09:24] <mjg59> But no hildon UI yet
[09:24] <Mithrandir> which would make hildonising it quite simple, at least so they claimed.
[09:25] <mjg59> It's basically mechanical
[09:25] <mjg59> But probably still ~2000 lines of code
[09:25] <Mithrandir> ugh, ok.
[09:25] <Mithrandir> that's a bit.
[09:25] <Mithrandir> even for SMOP.
[09:25] <mjg59> Mostly not from scratch
[09:25] <mjg59> A lot of it can be cribbed from the vanilla or openmoko code
[09:27] <Mithrandir> still a bit of work.
[09:27] <agoliveira> So, what should we do? Add a hildon interface to the current code or poke the guys to see if their timetable fits us?
[09:27] <Mithrandir> they weren't going to do it themselves, short-term?
[09:27] <mjg59> Nope
[09:27] <mjg59> Not without a contract
[09:27] <mjg59> Nokia have something that works already, so no great incentive for the moment
[09:28] <Mithrandir> ok..
[09:28] <Mithrandir> how much work do you think it'll be to fix it up?
[09:29] <agoliveira> mjg59: And it's based on GPE iiRC.
[09:30] <mjg59> Mithrandir: I suspect a small number of hours
[09:36] <Mithrandir> mjg59: if you want to work on it, please.
[09:37] <mjg59> Mithrandir: Probably be next week
[09:38] <Mithrandir> sounds good to me.
[09:39] <rusty_> Mithrandir, fset installation is broken at the moment.  The linux-image-generic fails because it can not install linux-ubuntu-modules-2.6.22-10-generic
[09:39] <rusty_> or maybe i should be pinging amitk_ 
[09:39] <rusty_> just a heads up... i'm guessing the apt repository is in flux
[09:39] <Mithrandir> rusty_: could well be, we're having some trouble with the current batch of kernels.  We're working on it.
[09:40] <agoliveira> mjg59: Cool. I'll continue with the other stuff. fbreader is an a** to compile.
[09:43] <agoliveira> Just found this: http://live.gnome.org/Vala Looks interesting.
[09:44] <agoliveira> Here's a simple hildon application: http://live.gnome.org/Vala/HildonSample
[09:52] <agoliveira> mjg59: You told me you prepared a hildon interface fro Cheese? Where is it? Upstream?
[09:52] <mjg59> agoliveira: Not yet
[09:52] <mjg59> Still a couple of issues to fix up
[09:52] <agoliveira> mjg59: Ok, just checking.
[09:56] <amitk_> rusty_: Hmm.. How does it find 2.6.22-10? That failed to build
[10:34] <rusty_> amitk_, the linux-image-generic package dependencies call for linux-ubuntu-modules-2.6.22-10-generic
[10:55] <amitk_> rusty_: buggy kernel upload. Being worked on.
[10:55] <lucasr> hei all
[10:55] <lucasr> how are things progressing? :-)
[11:17] <bspencer> lucasr, good -- we got control panel working now with small workaround
[11:17] <lucasr> bspencer, cool
[11:18] <bspencer> we (I) need to have a chat with hildon-libs list about things we've done wrt Hildon
[11:18] <bspencer> and talk about how these could get upstream
[11:18] <bspencer> lucasr, what is your timeframe for freezing code for Sept release?  Are changes slowing down already/
[11:18] <bspencer> we've been debating when to re-sync with the latest Hildon 
[11:19] <lucasr> bspencer, we're mostly in bugfixing mode now
[11:19] <lucasr> bspencer, we're already slowing down on the real changes
[11:19] <bspencer> lucasr, i figured so.
[11:31] <rob_> amitk_, this was the error i was getting from apt-get: The following packages have unmet dependencies:
[11:31] <rob_>   linux-image-ume: Depends: linux-image-2.6.22-10-ume but it is not installable
[11:31] <rob_>                    Depends: linux-ubuntu-modules-2.6.22-10-ume but it is not installable
[11:31] <rob_> E: Broken packages
[11:35] <kylem> yes, they're broken, i'm working on it, should be fixed in an hour or so.
[12:07] <rob_> kylem, thanks
[12:11] <kylem> np
[12:12] <kylem> hopefully it will build fast...