=== vivijim [n=vivijim@200.184.118.132] has left #ubuntu-mobile [] === dantalizing [n=dan@wsip-70-184-147-28.ga.at.cox.net] has joined #ubuntu-mobile === sabotage is now known as sabotage_afk === px [n=px@unaffiliated/px] has joined #ubuntu-mobile === dantalizing_ [n=dan@wsip-70-184-147-28.ga.at.cox.net] has joined #ubuntu-mobile === dantalizing__ [n=dan@wsip-70-184-147-28.ga.at.cox.net] has joined #ubuntu-mobile === vivijim [n=vivijim@201.32.145.37] has joined #ubuntu-mobile === javamaniac [n=gerardo@pwnd.gerardo.com.ve] has joined #ubuntu-mobile === horaceli [i=chatzill@nat/intel/x-9f72169f9899c764] has joined #ubuntu-mobile === wasikevin [n=tw917509@221-169-13-105.adsl.static.seed.net.tw] has joined #ubuntu-mobile === vivijim [n=vivijim@201.32.145.37] has joined #ubuntu-mobile === Peter_ubuntu_2 [i=Peter@nat/intel/x-d7d477928377d285] has joined #Ubuntu-mobile === Starting logfile irclogs/ubuntu-mobile.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #ubuntu-mobile === Topic for #ubuntu-mobile: http://wiki.ubuntu.com/MobileAndEmbedded | https://wiki.ubuntu.com/MobileAndEmbedded/FAQ === Topic (#ubuntu-mobile): set by mdz at Thu Aug 16 15:19:37 2007 [09:10] derjoerg: don't ask to ask; just ask your question. === guardian [n=Guardian@mar44-1-87-90-32-28.dsl.club-internet.fr] has joined #ubuntu-mobile [09:21] 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] -card as /dev/hdb1 and make a chroot to it. [09:22] So I think, the installer and the rescue-system loads specific modules, which the "normal" boot doesn't [09:23] Does anybody have an idea, which module(s) I can load (/etc/modules) so that I can correctly use ubuntu? === tko_ [n=tkomulai@jabber.hst.ru] has joined #ubuntu-mobile === seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-mobile === tko_ [n=tkomulai@jabber.hst.ru] has left #ubuntu-mobile [] === tko_ [n=tkomulai@jabber.hst.ru] has joined #ubuntu-mobile === wasikevin [n=tw917509@221-169-13-105.adsl.static.seed.net.tw] has joined #ubuntu-mobile [10:33] Nobody an idea, which ide-modules are loaded during installation? [10:37] hm, unsure. You might have more luck in #ubuntu-installer [10:42] Mithrandir: Ok, thanks :-( === seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-mobile === seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-mobile === seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-mobile === agoliveira [n=adilson@200.146.40.166.adsl.gvt.net.br] has joined #ubuntu-mobile === wasikevin [n=tw917509@125-228-237-59.dynamic.hinet.net] has joined #ubuntu-mobile === K3nto [n=kent@cable-66-103-40-160.dyn.personainc.net] has joined #ubuntu-mobile [01:40] is anybody available to help me out with obex? === asac_ [n=asac@debian/developer/asac] has joined #ubuntu-mobile === cprov [n=cprov@canonical/launchpad/cprov] has joined #ubuntu-mobile [02:19] 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] Mithrandir: xulrunner needs building on lpia. are we still on manual for some reason? [02:21] 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] mdz: no, we're on full auto [02:24] build rescored, it'll be built next === K3nto [n=kent@cable-66-103-40-160.dyn.personainc.net] has left #ubuntu-mobile [] [02:40] Mithrandir: once that's built, ubuntu-mobile should be installable on lpia again [02:41] except it ftbfs [02:41] I'll poke it [02:44] mdz: why does mobile need xulrunner? Shouldn't it use midbrowser? [02:44] doko: gtkmozembed [02:45] Mithrandir: firefox-dev does provide that [02:46] doko: ->asac, I'm just looking at what's installable [02:46] doko: mobile-basic-flash depends on libxul0d [02:46] which is from xulrunner [02:46] and is independent of midbrowser [02:48] http://launchpadlibrarian.net/8915774/buildlog_ubuntu-gutsy-lpia.xulrunner_1.8.1.4-2ubuntu2_FAILEDTOBUILD.txt.gz [02:48] (when did we start using launchpadlibrarian.net?) [02:48] been a while [02:48] js.o: In function `GetLine': [02:48] /usr/bin/ld: js: hidden symbol `readline' isn't defined [02:48] /usr/bin/ld: final link failed: Nonrepresentable section on output [02:49] needs older gcc for now [02:52] that is fixed with the current midbrowser build (currently building). mobile-basic-flash should b-d on that [02:52] 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] given that cwong in on holiday [02:53] asac: hmm, so apply the same fix to xulrunner (and firefox) as we did for mibrowser? [02:54] I'm doing a test build of that now. [02:54] 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] Mithrandir: take the patch out of midbrowser [02:55] force-no-pragma-visibility-for-gcc-4.2_4.3 [02:55] ok lunch [02:55] asac: ok, that's the right fix? [02:55] asac: rather than using gcc 4.1? [02:55] yes [02:55] ok, cheers. === bspencer [n=chatzill@c-67-189-100-207.hsd1.or.comcast.net] has joined #ubuntu-mobile === etrunko [n=edulima@200.184.118.132] has joined #ubuntu-mobile [03:07] Hi Bob [03:13] hi kyle, bob [03:15] Hi Mithrandir [03:17] hi bob, kyle, tollef === wasikevin [n=tw917509@125-228-237-59.dynamic.hinet.net] has joined #ubuntu-mobile [03:21] good morning, at least from my perspective ;) [03:28] kwii, I am taking a look at your comments. thx. [03:29] kwwii, do you know whether slicer includes extracted file distribution? [03:30] and, can you describe more the tool you proposed to make the "metatheme"? [03:33] asac, Mithrandir: midbrowser did scucessfully build. === dantalizing [n=dan@n128-227-5-37.xlate.ufl.edu] has joined #ubuntu-mobile [03:41] re === bspencer [n=chatzill@c-67-189-100-207.hsd1.or.comcast.net] has joined #ubuntu-mobile [03:45] doko: there is something wierd going on ... [03:45] doko: http://launchpadlibrarian.net/8881777/buildlog_ubuntu-gutsy-i386.midbrowser_0.1.6a-0ubuntu3_FULLYBUILT.txt.gz [03:45] search for -fvisibility [03:45] there not a single match [03:45] while http://launchpadlibrarian.net/8916005/buildlog_ubuntu-gutsy-lpia.midbrowser_0.1.6a-0ubuntu3_FULLYBUILT.txt.gz ... is built as expected [03:47] hmm ... [03:47] looking at PR26905 [03:48] checking For gcc visibility bug with class-level attributes (GCC bug 26905)... yes [03:48] checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no [03:48] crazy [03:49] apparentyl our gcc is only fixed on lpia? [03:49] any reason why this fails? that was fixed one year ago and is in the 4.2 branch [03:49] asac: yes, let me look at 4.1, fc does have a backport to 4.1 [03:49] hmm ... we have gcc-4.1 everywhere expect on lpia right? [03:49] yes [03:50] i think it would be worth to have it as firefox should be a lot faster with visibility hidden according to bsmegdberg === vivijim [n=vivijim@200.184.118.132] has joined #ubuntu-mobile [03:54] kyleN: I assume that at some point in the build process the sliced files are automatically copied to the right place [03:54] 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] 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] kyleN: actually, I guess that some makefile is what copies the pics to the right place now [03:56] 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? === horaceli [i=chatzill@nat/intel/x-2b16ec25c5ea1d02] has joined #ubuntu-mobile [03:56] hi horace [03:56] kyleN: I think that is the only real way to test it [03:57] hi, kyleN [03:57] is bspencer here? [03:57] horaceli: hello [03:57] 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] hi, kwwii. === bspencer rubs his eyes [03:58] hi horaceli [03:58] morning bob [03:58] if they run xypher and a target from image-cretor, is that enough for the artist to check his work? [03:58] kyleN: for some test it would be enough, but in the end it needs to be done on a device I think === ian_brasil [n=ian@dasasob.nokia.com] has joined #ubuntu-mobile [03:58] kyleN: mostly, except for color depth issues on the device I'd guess [03:59] bspencer: the size (dpi) is important too [03:59] 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] kyleN: that is exactly how I am doing it now [04:00] kwwii: you got a Q1 finally? [04:00] when I launch xypher, I set the dpi... [04:00] bspencer: yepp, arrived yesterday [04:00] so I stayed up late last night tweaking things :-) [04:00] and in doing so broke two of my toes :p [04:00] lol [04:00] really? [04:00] should the artwork support different resolutions? [04:00] horace, I don't think so [04:00] I do :) [04:01] yes, it has to [04:01] because the theme would be for a specific device with a known resolution [04:01] every device might have a different resolution [04:01] not true. Each device might have variable res. besides orientation [04:01] ok. [04:01] (not true to Kyle) [04:01] yep, like screen rotation. [04:01] and it would also be nice for a theme to span multiple devices if possible [04:02] zooming, when we have that might be a problem as well [04:02] bspencer: I am guessing that at least certain parts will be reused from device to device [04:02] mm, not sure how zooming would work [04:02] so how does a theme handle multiple res ? [04:03] all graphics have to be stretchable in the right direction [04:03] right, scalable or tile-able, depending on the situation [04:03] asac: what's the problem jsut explicitely building with 4.2? I really don't want a 1800 line backport ... [04:04] so I don't have an agenda for our theme chat. What should we cover, and how to proceed. [04:04] I would like to cover certain things... [04:04] ;) [04:04] I guess we should talk about the best formats to use, and roughly what we need to change [04:05] and the schedule to create a first UME theme package. [04:05] as a sample? [04:05] horaceli: yes, good point [04:05] that's good, horaceli [04:05] I am happy everyone cares about this. :-) [04:06] doko: ... i am unsure if its ok to build firefox with not-default gcc [04:06] I think some of my topics from my emails should be discussed [04:06] asac: why? [04:06] for example: what's the expecation for themeing an app for ume [04:07] what's the expectation for the thrid party theme designer (can he test his theme) [04:07] 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] doko: so its ok? (firefox shouldn't have any problems from what i see) [04:08] test: replace pics and restart Xephyr [04:08] kwwii, yes, so why not give him the licer and a makfile? [04:08] kyleN, I am not sure if we will cover every app theme. like we may cover some built-in apps. [04:08] (darn typos) [04:08] kyleN: sure, the slicer is there already (alhtough it needs work) [04:09] ok. let's talk about that first: what needs to be done with the tools [04:09] can a designer be expected to use slicer? is it too hard? [04:09] but for other third-party applications, they might create their own theme, right? [04:09] horace and I could work on the tools, while Ken works on the pics [04:09] kyleN: right now it is probably too hard === matt_c_ [n=mcroydon@137.147.45.66.cm.sunflower.com] has joined #ubuntu-mobile [04:09] kyleN, it is not too hard. [04:09] if slicer is too hard,maybe we need to make it esaier? [04:09] sorry, I misunderstood... [04:09] and actually designers could take a sample Makefile ans just create their artwork. [04:09] horaceli: yeah, third party apps might add their own stuff like icons, splash screen images, and special artwork for special widgets, etc. [04:10] and use the Makefile to do slicing. === ian_brasil [n=ian@dasasob.nokia.com] has joined #ubuntu-mobile [04:10] 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] horaceli: sure, just changing the existing artwork is easy - edit the pic [04:10] horaceli: but changing sizes or such is a bit harder === matt_c_ [n=mcroydon@137.147.45.66.cm.sunflower.com] has joined #ubuntu-mobile [04:10] kwwii. yep. that could be === kwwii_ [n=kwwii@p549545DC.dip.t-dialin.net] has joined #ubuntu-mobile [04:11] how can we update slicer to handle multiple res ? [04:11] the picture size and position in template could be configurable in layout config file. [04:11] or is that just a matter of making the right graphics? [04:12] 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] 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] so if some picture size and postion changed, updating the layout file should be ok. [04:12] 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] 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] currently Hildon can inteligently stretch the panel graphics by duplicating them [04:13] so if the graphics are dithered in the right direction it looks nice [04:14] bspencer, that should be icon theme. as far as I know, hildon theme image only support single resolution. [04:14] 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] 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] 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] bspencer: yeah, it would help to know which pieces are stretched, which ones tiled, etc [04:15] kyleN: agreed [04:15] is stretching going to look good enough for a serious UME product? [04:15] asac: make it conditional for lpia/other [04:15] kyleN: that was my worry as well [04:15] for some thing it will work for others not [04:15] kyleN: by stretching I meant dupllicating a graphic, not really stretching it [04:16] ok, I call that tiling :-) [04:16] 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] one just has to be sure that the pic in question is suitable to be tiled [04:16] and, that the list of app would be known in advance too [04:16] 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] kyleN: what about third party apps that are installed afterwards? [04:17] that's up to the user, whether themeing extends to that, well, that's extra credit [04:17] the thing that is needed is coherent theme of everythign at build time [04:18] and, a clear 'theme api" for apps: this is how you UMEize the app to fit themeing [04:18] right, as well as having the infrastructure available for third party apps to put their pics in a decent location [04:18] exactly [04:19] it'd be nice to have a doc that explained this [04:20] so what has to be changed in the slicer? [04:20] so, should we define the tools and procedure from the point of view of a designer an on the app theme api? [04:20] yes, we should write docs while creating the first themes [04:20] bspencer: nothing more than sizes and locations [04:21] how can we figure out what are all the graphics needed for a theme? [04:21] 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] yep, then tools might be reusable. we could just change the layout file. [04:21] bspencer: by looking at what each pic does after being cut up [04:21] k [04:21] there's a lot to do [04:21] bspencer: and by making a list of other graphics used and their purpose which are not included in the template [04:22] horaceli: something I've noticed is that some apps show a border around the window, some do not [04:22] kyleN: no doubt :-) [04:22] bspencer, yes a lit of what is in the template. [04:22] bspencer, I should remove the border by default. [04:22] for example: NOT boot splash images? [04:22] in general our apps are currently not too well behaved or consistent [04:22] but for toolbar widget, its theme still has border now [04:22] bspencer: I think that is how nokia showed the difference between windows and pop-ups [04:23] kwwii: I think it is ok to have a border, but our apps are mixed [04:23] ouch [04:23] and the ones with borders are ugly (only right and bottom border) [04:23] so it is a framework issue [04:24] 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] if its windows and popups, isn't that controlled by matchbox theme? [04:24] 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] we shouldn't deviate from hildon unless necessary, but how much of theming is iIN hildon anyway? [04:25] i would like to propose that themeing CAN include gtk images, but that is extra credit [04:25] 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] that the template.png MUST include all desktop specific images and icons and CAN optionally iknclude gtk images [04:25] kyleN: all the references to the graphics is in the Hildon-desktop code [04:25] so we have to use the same graphics names, or update the Hildon code [04:25] horaceli: yeah, but that gtkrc stuff is nasty [04:26] bspencer, so your "mb_" image names are hard coded in hildon? [04:26] kyleN: I am really against including icons in the template [04:26] bspencer, I think graphics names are used in gtkrc file. [04:26] and in Hildon code, it just set style name or something. [04:27] horaceli: right, that is how I understood it as well [04:27] horaceli: yeah [04:27] kwwii, why against desktop-specific icons in the template? [04:27] 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] 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] the gtkrc files used to be named in the xinitrc file [04:28] kyleN: because updating them is harder [04:28] why is it harder? [04:28] I don't see icons in the current themes [04:28] because the existing icon themes are not in that format [04:29] bspencer: they are not, now (and I'd like to keep it that way) [04:29] so everytime a theme changes one has to tweak it into that file [04:29] 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] are we talking about putting icons in the template.png, or something else? [04:29] I don't think icons should be part of the template.png [04:29] bspencer: yes that is the topic [04:29] bspencer: yes, we are talking about putting icons in template.png [04:30] :-) [04:30] why not have them in the icons-related folder [04:30] exactly [04:30] didn't we chat about that? /usr/share/icons/ [04:30] and hicolor as the backup [04:30] that's fine, I just want it to be easy to communicate to a real thrid party designer [04:30] yes, exactly [04:30] yep, I agree with bspencer [04:30] how do they know the list of valid icons, jusgt evey single one in there? [04:30] icons should really be the only thing that is not included in the template though [04:30] so 3rd party designer steps are what then? [04:31] 'cause the designer who create theme might not be the one who create the icon right? [04:31] 1) edit the template 2) edit gtkrc 3) edit icons [04:31] why #2? [04:31] because it also includes some line thickness, centering, and colors, I think [04:31] what are they changing in the gtkrc file? [04:31] is #2 extra credit, and why wouldn't the designer create the icon? [04:31] asac: no chance for a backport [04:32] kwwii: ok. ugh. gtkrc editing is tedious [04:32] for instance, if I change the current them to black, there will stil be lots of white stuff showing up [04:32] kwwii: good point [04:32] bspencer: yeah, I know (and hate it) [04:32] desktop backgrounds -- are they part of the theme? [04:32] I have just been using bash to change color values [04:32] (e.g. plankton includes a default one) [04:32] bspencer: YES [04:32] but not part of the template.png [04:32] ? [04:33] yes, it should be a part of the metatheme [04:33] kyleN, I am not sure , like on currrent gnome desktop. gtk theme is seperated with icon theme. [04:33] horaceli: right, gtk has become flexible enough to have it seperate [04:33] I don't think plankton's default background is part of their template.png [04:33] /usr/share/backgrounds [04:33] not in the theme/images folder === phanatic [n=phanatic@dsl54009C02.pool.t-online.hu] has joined #ubuntu-mobile [04:34] 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] mobile-basic-flash specifies the background [04:34] so we would have icons /and/ backgrounds separate from the template.png [04:34] and probably any splash screens [04:35] ok. [04:35] so are all of these part of the same debian theme package? [04:35] 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] 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] 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] it is not in it now [04:36] but I do not see what we win by putting it in that way [04:36] I think we should focus on keeping it simple and manageable, which to me means one approach to graphical themeing [04:36] we cannot then include different wallpapers [04:37] kwwii: metatheme: sounds good. It might be nice to have a "theme checker" that validates a theme. (some day) [04:37] 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] most will want to include several wallpapers so that the user has a choice [04:37] bspencer: nicest would be to have a GUI app to plug in all these pieces and create such a metatheme [04:37] 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] then the artist only sees one interface for creation [04:38] horaceli: right [04:38] and the usplash will always be a pain, no matter what [04:38] that sounds promising [04:38] will that be a bit complicated for the designer? [04:39] I do not think so, we just need to keep the number of different pieces down to a minimum [04:39] and document this stuff very well [04:39] also user would probably like to change their own background image [04:39] so maybe seperate background image is better, what do you think? [04:39] horaceli: and pick their own colors as well [04:40] although that is probably secondary [04:40] kwwii: how do they pick colors ? [04:40] kwwii, right [04:40] I sometimes do that. :-) [04:40] can a theme support different colors? [04:40] 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] bspencer: yes, the gtkrc can be flexible enough to handle that [04:40] default font colors -- or border colors? [04:40] sure. matchbox themes and gtkrc styles support colors [04:40] k [04:41] startup splash -- is that part of the theme package? [04:41] I was thinking it was separate [04:41] it is a part of the theme, absolutely [04:41] it probably should be [04:41] because you might have a device with a "Ubuntu" startup splash, but the user can't change that [04:41] not user-settable themes though [04:41] or more particularly another company logo [04:41] bspencer: right, it is only change by root [04:42] set at build time never to change [04:42] it will probably be set at build time and not changeable afterwards (without skills) [04:42] ok... what is a "user-settable" theme vs a normal theme ? [04:42] usesr settable and normal are different [04:42] is there one theme package, or a theme for startup splash and the normal theme. [04:42] i doubt users will ever set gtk stuff for example [04:42] there is a default theme which is shipped, some of that is settable by the user [04:43] user settable may be limited to colors and backgrounds [04:43] or one could make the whole metatheme switchable, as nokia does now [04:43] ok. you mean user-settable is a UI-supported change-at-runtime thing [04:43] bspencer: exactly === boggle [n=spindler@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-mobile [04:43] b spencer, yes [04:43] we should identify that too [04:44] let's make a list of exactly what we think a build-time default theme consists of [04:44] so I can start making those changes. maybe that is in the control panel theme changer utilities [04:44] boot splash images, right? [04:44] the usplash seems like the only thing that should not be changed by the user to me [04:45] sa more often than not it is pure branding [04:45] yes, but it is a part of the theme that a third party would want to set, right? [04:45] s/sa/as [04:45] kyleN: yes [04:45] what else, desktop background, right? [04:45] I have to stretch my thinking. Before I thought the user would change a theme by replacing which /usr/share/themes/ folder was used. But there are more options than that [04:45] theoretically they will want to change everything, I guess [04:46] so if the user downloads a new theme package, then that package might have a different uplash image in it? [04:46] no, not everything [04:46] not layout [04:46] bspencer: no, that would need root rights to change the usplash [04:46] I would avoid that [04:46] ok... so break the pieces up for me [04:46] so desktop background is or is not a part of the graphical theme? yes, i think [04:47] the usplash is the only thing that a third-party theme (installed and selectable by the user) should not include I think [04:47] so in that case, should we seperate usplash from the theme package? [04:47] kwwii: ok. that makes sense. usplash = multiple splash files that show during boot (bios, kernel load, X startup) [04:47] 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] kwwii: ok, that's where I get lost. === boggle [n=spindler@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-mobile [04:48] how to overlay one theme on default theme [04:48] 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] kyleN: right [04:48] 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] 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] good questions, but I think usplash is not changeable [04:49] 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] 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] kwwii, is that your metatheme idea? can you please elaborate? [04:51] so the usplash is seperate from the metatheme [04:51] the metatheme would contain all the pieces except the usplash [04:52] 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] 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] bspencer: but that does not change the usplash, or? [04:53] no, because right now usplash isn't in the themes folder :) [04:53] themes are spit into theme and icont theme folders now, not all in theme [04:53] but I'm not doing it intelligently now [04:53] is the "package" more complicated than necessary? more complicated for example than a template.png with documentation? [04:54] but let's say there is a debian package with a /usr/share/themes/ folder, /usr/share/icons/ and /usr/share/backgrounds/ Where is the usplash stuff and how does the process of changing themes work? [04:54] 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] kwwii: YES [04:54] and I think we need to define 1) [04:55] so 1) would create a 2) + an usplash and set it all as default [04:55] personally, i think 1) includes icons, because a vendor will want it to [04:55] 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] bspencer: right [04:56] and, we need to define how applications implement a UME theme [04:56] 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] kyleN: "implement" ? or use? [04:56] bspencer, ok [04:56] 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] how to port an app to UME that supports our themeing approach [04:57] kyleN: right. [04:57] kwwii: where does that happen now? [04:57] kwwii: how do I do that? [04:58] 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] bspencer: I can look into it as I created the current version [04:58] kwwii: ok. I haven't looked at that package [04:58] 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] theme : a debian package with a /usr/share/themes/ folder, /usr/share/icons/