RE: Image Creator platforms
Loic, thanks for the info Rob, Can you let me know if there are any images you use regularly. Given the feedback, Remove the following platforms: Mccaslin-lpia Mccaslin-lpia-fedora Mccaslin-lpia-ubuntu-hardy-ppa Mccaslin-lpia-ubuntu-hardy-ppa-snapshot Menlow-lpia Menlow-lpia-ubuntu-hardy Menlow-lpia-ubuntu-hardy-ppa Menlow-lpia-ubuntu-hardy-ppa-snapshot Still in question (keep for now): Mccaslin-lpia-ubuntu Menlow-lpia-moblin2 Keep: Menlow-lpia-ubuntu-hardy-jax10-snapshot1 Mccaslin-lpia-ume Menlow-lpia-ume Netbook-lpia-moblin2 Bob Loïc Minier wrote: On Thu, Sep 04, 2008, Spencer, Bob wrote: Image creator that you build from upstream source (git clone http://moblin.org/repos/tools/moblin-image-creator.git) has lots of platforms in the list and I think many of them are no longer needed and even useless. Here's the list. Mccaslin-lpia Menlow-lpia = Gutsy based, I guess nobody wants these Mccaslin-lpia-fedora (= I never used it for obvious reasons :-P) Hmm I don't have this one: Mccaslin-lpia-ubuntu = no idea These are the old platforms for hardy: Menlow-lpia-ubuntu-hardy Mccaslin-lpia-ubuntu-hardy-ppa Mccaslin-lpia-ubuntu-hardy-ppa-snapshot Menlow-lpia-ubuntu-hardy-ppa Menlow-lpia-ubuntu-hardy-ppa-snapshot = these were used against ahrdy, hardy + ppa and snapshot of these, but now we promote packages from there to the new archive.mobile.ubuntu.com (*-ume) so we don't use these and I don't expect anyone to, they might work though Mccaslin-lpia-ume Menlow-lpia-ume = that's the final platforms we used for hardy and continue to base hardy images on Menlow-lpia-moblin2 Netbook-lpia-moblin2 (= moblin 2 stuff) Menlow-lpia-ubuntu-hardy-jax10-snapshot1 Recent addition I recommend we trim this to: Mccaslin-lpia-fedora (Samsung Q1 ultra build of Moblin2 (RPM)) Mccaslin-lpia-ubuntu-hardy-ppa (Samsung Q1 ultra, latest UME w/PPA (DEB)) Menlow-lpia-moblin2 (Jax10/Menlow build of Moblin2 (RPM)) Menlow-lpia-ubuntu-hardy-ppa (Jax10/Menlow build of UME (DEB)) Netbook-lpia-moblin2 (EeePC/Netbook build of Moblin2 (RPM)) I would mostly care that you keep the *-ume ones instead of the above DEB ones. Cheers, -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Hildon application porting question
Is there a way to setup configure.ac so that it automatically sets the USE_HILDON flag if building for LCIA? I know how to set up a configure.ac that will check for --enable-hildon flag, but for UME I thought I recall that if LCIA arch then always USE_HILDON. I don't know exactly how to do this or if we ever decided on a standard. Here's the doc I'm following / updating: http://moblin.org/toolkits/basicDevGuides/simpleApp/toolkits_DevGds_simpleApp_GTKApp.php configure.ac = AC_ARG_WITH( hildon, AC_HELP_STRING( [--with-hildon], [build the hildon user interface (default=yes)] ), [ if test $withval = no then build_hildon=false else build_hildon=true fi ], [ build_hildon=true ] ) if test $build_hildon = true then PKG_CHECK_MODULES( HILDON, hildon-1, ... Thanks, Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Hildon Desktop Icon Visibility Proposal
Ian Lawrence wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ola, PROPOSAL The ability to switch the visibility of desktop icons without needing to alter the .desktop file MOTIVE Currently on UME the icons are all together in /usr/share/applications. If I alter an icon to OnlyShowIn (the current preferred method) when I pull a new version of the software it will ask me if I want to use the new .desktop file or continue with my version. This is rather confusing IMO. The ideal would be to have a specific directory for Hildon such as /usr/share/applications/hildon-apps everything that I want to show (make visible) is in this directory which could be symlinked to /usr/share/applications Perhaps even better would be something in the users home directory like: ~/.hildon-apps/ as this would stop the requirement for editing system archives CURRENT CONFUSING SITUATION For example, cheese does not have OnlyShowIn but it appears in hildon ...others also do not have OnlyShowIn and do not appear..it seems that there is some special implementation (a.k.a hack) for ubuntu mobile Two gconf keys: /desktop/hildon/htmlhomeplugin/ /onlyshowin_filterCheck OnlyShowIn value in .desktop. If _False_ then every .desktop is shown. /onlyshowin_ignoreAlways show these apps, even if they don't have OnlyShowIn. Cheese is in this list. Eventually this key should go away when everyone is a good citizen. POSSIBLE BLOCKERS The xdg spec doesn't currently provide such a feature I believe I'm not sure if a subdirectory is OK. We do want to remain freedesktop.org compliant. Bob just an idea anyway, abracos Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIRVDjZXia3Con1vcRAm/dAJ9eJJCVzfMeMyczIrmnHTt0m2fmBgCfYPXv cC4pQTyRCQnZa7ij/fjrENU= =zQrC -END PGP SIGNATURE- -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Java development
I've successfully installed sun-java5-jre on the latest Hardy-PPA image. It seems to work fine with my one test of a game I downloaded. I haven't gotten around to writing an interface to put Java (or QT or Flash) menu items in the drop-down list so that it looks integrated into the system and I don't know of any finger-scrolling enhancements for Java apps. For now if you make the application not have any menu and put your toolbar at the bottom it should tie into the general layout OK. Good luck! Bob Beno, Tal wrote: Hi, What Java distribution will work on UME (J2SE/J2ME)? Are there UI extensions that I should work with to make it like Hildon or based on it? Any extensions concerning the touch screen functionality? I am a n00b so I might be asking the wrong questions ... all I want to do is understand where to start when considering the development of a Java application under UME. Thanks, Tal -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Changed packages in ppa since last snapshot
I don't fully understand the list. Are we only supposed to describe the
differences between the two versions? If so then I have no comment because the
versions on the right were all made after my latest checkin.
Loïc Minier wrote:
As requested by Chris during IRC meeting, here's what I know about
version changes between last snapshot of ppa and current ppa:
gstreamer-dbus-media-service: 0.1.17-1-0ubuntu5 !=
0.1.17-upstream-0ubuntu1~804um1
hildon-theme-mobile-basic: 0.37-0ubuntu1 != 0.37-0ubuntu2~804um1
For example, I can tell you the importance of 0.36 and 0.37, but not ~804um1
libdrm: 2.3.0.16-0ubuntu1~804um1 != 2.3.0.16-0ubuntu1~804um2
mobile-basic-flash: 0.44-0ubuntu3 != 0.44-0ubuntu4
Horace updated recently for i18n, but not the last checkin.
moblin-image-creator: 0.44+repack-0ubuntu7~804um1 !=
0.44+repack-0ubuntu8~804um1
treb: 0.12 != 0.14
ubuntu-meta: 1.103~804um9 != 1.103~804um10
ume-config-common: 0.12-1-0ubuntu0 != 0.12-1-0ubuntu1
xserver-xorg-video-psb: 0.13.0ubuntu1~804um1 != 0.13.0ubuntu1~804um4
gstreamer-dbus-media-service, hildon-theme-mobile-basic,
mobile-basic-flash: misc cleanups and added MD5 sums (lool)
moblin-image-creator: important fixes with /boot handling (lool);
need an additional menu.lst fix in progress (lool); need to be
updated on the build hosts before building the next images
treb: bug fixes (agoliveira)
ubuntu-meta: updated to include vinagre, update-manager-hildon
(StevenK) from the new seed (vinagre added to seed by StevenK, u-m-h
by Emmet)
ume-config-common: no idea, please check
v12 was important for theming. SteveK updated last (see attched email
description)
xserver-xorg-video-psb, libdrm: ship psb headers in the libdrm-dev
package instead of the xorg video driver (bryce)
--
Loïc Minier
---BeginMessage---
Hi,
I've uploaded a new version of moblin-applets to the PPA, since
0.66-0ubuntu3 fails to install if the ume user doesn't exist -- I now
guard that block checking if /home/ume exists first. Further, ume.ume is
a bad idea, since usernames are more than able to use '.' in them, so
ume:ume is a much better idea.
I also cleaned up the postinst and postrm scripts, since it looked like
the init script calls were just taken from other scripts instead of
letting debhelper (more specifically, dh_installinit) handle it. How
I've done that is by removing those blocks, and replacing it with
#DEBHELPER#, which debhelper scripts will use to add pieces to the
install/removal scripts, and changing the dh_installinit calls in
debian/rules to accommodate those changes, since neither init script is
installed using defaults.
This package should also be patched to use dh_gconf, instead of calling
gconftool-2 in the postinst.
Also, you don't need to explicitly Depend on libmokoui2-0, that drops
out of ${shlibs:Depends} when the package is built.
Thanks,
--
Steve
Wrong is endian little that knows everyone but.
- Sam Hocevar
--- moblin-applets-0.66/debian/changelog~ 2008-05-27 04:56:13.0 +1000
+++ moblin-applets-0.66/debian/changelog 2008-05-27 14:51:11.0 +1000
@@ -1,3 +1,13 @@
+moblin-applets (0.66-0ubuntu4) hardy; urgency=low
+
+ * Clean up the postinst and postrm scripts.
+- Add set -e.
+- Add #DEBHELPER# tags, and remove bits that look to be autogenerated.
+- Guard the user ume gconf bits in the postinst.
+ * Add -u to the dh_installinit calls.
+
+ -- Steve Kowalik [EMAIL PROTECTED] Tue, 27 May 2008 14:50:37 +1000
+
moblin-applets (0.66-0ubuntu3) hardy; urgency=low
* chown -R ume.ume /home/ume/.gconf so user can read it
--- moblin-applets-0.66/debian/postinst~ 2008-05-27 04:56:57.0 +1000
+++ moblin-applets-0.66/debian/postinst 2008-05-27 14:00:29.0 +1000
@@ -1,4 +1,6 @@
-#! /bin/sh
+#!/bin/sh
+
+set -e
gconf-schemas --register \
apps_moblin_settings_daemon_default_editor.schemas \
@@ -8,24 +10,6 @@
desktop_moblin_keyboard.schemas \
desktop_moblin_screen.schemas
-if [ -x /etc/init.d/moblin-applets ]; then
- update-rc.d moblin-applets defaults 10 21 /dev/null
- if [ -x `which invoke-rc.d 2/dev/null` ]; then
- invoke-rc.d moblin-applets start
- else
- /etc/init.d/moblin-applets start
- fi
-fi
-
-if [ -x /etc/init.d/moblin-system-daemon ]; then
- update-rc.d moblin-system-daemon defaults 99 21 /dev/null
- if [ -x `which invoke-rc.d 2/dev/null` ]; then
- invoke-rc.d moblin-system-daemon start
- else
- /etc/init.d/moblin-system-daemon start
- fi
-fi
-
gconftool-2 --type bool --set /desktop/gnome/background/draw_background true
gconftool-2 --type string --set /desktop/gnome/background/picture_options centered
gconftool-2 --type string --set /desktop/gnome/background/picture_filename /home/ume/background.jpg
@@ -35,14 +19,19 @@
gconftool-2 --type string --set /desktop/gnome/background/color_shading_type solid
gconftool-2 --type string --set
RE: Please help to review i18n support in marquee-plugins
2) Do you expect the application name also to be displayed translated in the Starting appname popup? The app name should be in the .desktop file. For example: Name = App Name Name[fr] = French Name Name[ja] = Japanese Name ... So you should see the banner fully i18n, including the name. Bob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kyle Nitzsche Sent: Wednesday, May 14, 2008 2:30 PM To: Li, Horace Cc: ubuntu-mobile@lists.ubuntu.com; Loïc Minier; Steve Kowalik; [EMAIL PROTECTED] Subject: Re: Please help to review i18n support in marquee-plugins Hi Horace, I tested mobile-basic-flash i18n. It worked! * We need a zh_TW (Chinese/TW) translation first * so I created the po file manually * translated it into Chinese * created the mo file manually * switched to that locale And the Starting app pop-up displayed in Chinese. (Not the app name, just the Starting part.) Two questions: 1) How does one add new locales to the package so that when the package is built with debuild the new po file is created if it doesn't already exist? (As mentioned, I know how to do it manually.) 2) Do you expect the application name also to be displayed translated in the Starting appname popup? Cheers, Kyle On May 12, 2008, at 1:55 AM, Li, Horace wrote: Hi, All, I have added i18n support in marquee-plugins and mobile-basic-flash, following GNU 'gettext' utilities specification. Marquee-plugins has a patch to integrate the change, while mobile-basic-flash has been modified in source package directly. Currently, only zh_CN translation script is included, which can be taken as a sample. There are only few messages that need to be translated in marquee-plugins mobile-basic-flash. The patch is attached in the mail, and it is based on latest marquee-plugins-0.22_0ubuntu2, which is at Ubuntu Hardy PPA. If possible, please help to review the patch and if okay, we can add it in next release. You could also get the patch from http://moblin.org/repos/users/horace.li/65_internationalization-support.patch Any comments are welcome. Thanks in advance, Horace 65_internationalization-support.patch -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Boot time +8sec with freedesktop.org changes
FYI: with the latest freedesktop.org changes, we see +8sec bootup time increase (shortened to +6sec by Horace). Some notes below. Bob From: Kleen, Andi - Checksum is difficult -- either you risk not catching a change in some extreme cases or have to read everything again to compute it. - Timestamp assumes your time never goes backwards and device time never gets reset (in practice likely a dangerous assumption) If you trust the time stamps or add some way to have a always monotonic time stamp (e.g. include the inode generation number) it's still difficult. There were some attempts like trying to implement inheriting mtime that flows up a directory which might work (but still has the time stamp problem). There were various other ideas I heard over time, but none really good. Another approach was to use a fuse file system that then transparently updates caches as files are written, but that also has some issues. The basic flaw is that the freedesktop standard doesn't include a program to run to update the cache. -Andi From: Spencer, Bob +7sec! Let's see if we can maintain freedesktop.org compliance and leverage caching to get our time back 1sec. Ideas: - checksum of file name/sizes in /usr/share/applications, if no change then go to cached version - try to simplify / optimize loading code . Maybe we are reading applications.menu file multiple times? Load it once. - see if a smaller /etc/xdg/menus/applications.menu could improve time - look into the gnome_menus code to see why it is taking so long. In 8sec you could start every app on the MID. Parsing a few text files should be trivial. Bob From: Kleen, Andi Distributions have spent a lot of effort in the past in trying to make the freedesktop icons/menu spec boot fast and the general conclusion was that it is hopeless with the standard without major infrastructure changes (like serious file system/VFS support) That was with spinning hard disks where seeks cost more, but i suspect it is not that different on SSDs. The only sane way would be probably to go to some other format for the standard applications and only support freedesktop for optional addons. -Andi From: Yang, Lei A Horace, Does the gnome-menu interface read the .desktop files every time? Can we add some cache file to store the list for next boot up? We may use some mechanism that just read the .desktop files which later than the cache file. Thanks, Lei Y From: Li, Horace Hi, All, Thanks Fan Martin for taking lots of effort to narrow down the time consumption issue. This afternoon, I am debugging into mobile-basic-flash source, and the root cause is that changing the way to build up application list increased the booting time almost 7 seconds. The main purpose of changing the way is to get Moblin aligned to freedesktop.org menu specification, which is part of MCT. I added a timer in three mobile-basic-flash versions to record elapsed time to build up applications list in different way. Three versions are a fast one, which is 0.33, a slow one, which is the latest 0.43, and a revised slow one, which is based on 0.43. In Mobile-Basic-Flash 0.33, we read through each particular desktop file, which are bundled with Mobile-Basic-Flash, by using Glib Key-value file parser interface. While in Mobile-Basic-Flash 0.43, we read through general gnome desktop files stored in /usr/share/applications by using gnome-menu interface and filter those that are not intended to be showed up on Moblin. Using gnome-menu interface will take result in a deep loop to traverse each sub menu directories and their items. Time elapsing differences are list below. MBF 0.33 MBF 0.43 MBF0.43 Rev building up app list (seconds) 0.873257 8.02833 6.04591 It seems like a side-effect to align to freedesktop.org menu specification, and I am open to discuss on the solution. :-) Thanks, Horace -- Ubuntu-mobile mailing list Ubuntu-mobile
RE: Boot time +8sec with freedesktop.org changes
Perhaps a light-weight daemon that uses inotify to listen for changes to /usr/share/applications and then update the cache. That seems easier than requiring changes to debian packages, but it would be running all the time and new packages are installed less frequently. Bob From: Bastian, Waldo Sent: Friday, April 18, 2008 2:21 PM To: Spencer, Bob Cc: Li, Horace; Kleen, Andi; Banginwar, Rajesh; 'ubuntu-mobile@lists.ubuntu.com' Subject: RE: Boot time +8sec with freedesktop.org changes Like Andi says, the basic flaw is that the freedesktop standard doesn't include a program to run to update the cache, so let's fix that. I would add a cache and instate the rule that whoever makes changes in these directories needs to run the cache-update program. You may even be able to tell the debian package system to do that for you, whenever a package installs something there. If you give it a generic name (xdg-update-application-cache) and symlink it to a moblin specific implementation (e.g. moblin-update-application-cache) then the desktop distributions can adopt it as well and make it call gnome and KDE specific versions of the same. Cheers, Waldo -- Intel Corporation - Hillsboro, Oregon Ultra Mobility Group - Platform Software Architecture Tel: +1 503 264 6237 - Mobile: +1 503 703-7327 From: Spencer, Bob Sent: Friday, April 18, 2008 2:01 PM To: ubuntu-mobile@lists.ubuntu.com Cc: Li, Horace; Kleen, Andi; Bastian, Waldo; Banginwar, Rajesh Subject: Boot time +8sec with freedesktop.org changes FYI: with the latest freedesktop.org changes, we see +8sec bootup time increase (shortened to +6sec by Horace). Some notes below. Bob From: Kleen, Andi - Checksum is difficult -- either you risk not catching a change in some extreme cases or have to read everything again to compute it. - Timestamp assumes your time never goes backwards and device time never gets reset (in practice likely a dangerous assumption) If you trust the time stamps or add some way to have a always monotonic time stamp (e.g. include the inode generation number) it's still difficult. There were some attempts like trying to implement inheriting mtime that flows up a directory which might work (but still has the time stamp problem). There were various other ideas I heard over time, but none really good. Another approach was to use a fuse file system that then transparently updates caches as files are written, but that also has some issues. The basic flaw is that the freedesktop standard doesn't include a program to run to update the cache. -Andi From: Spencer, Bob +7sec! Let's see if we can maintain freedesktop.org compliance and leverage caching to get our time back 1sec. Ideas: - checksum of file name/sizes in /usr/share/applications, if no change then go to cached version - try to simplify / optimize loading code . Maybe we are reading applications.menu file multiple times? Load it once. - see if a smaller /etc/xdg/menus/applications.menu could improve time - look into the gnome_menus code to see why it is taking so long. In 8sec you could start every app on the MID. Parsing a few text files should be trivial. Bob From: Kleen, Andi Distributions have spent a lot of effort in the past in trying to make the freedesktop icons/menu spec boot fast and the general conclusion was that it is hopeless with the standard without major infrastructure changes (like serious file system/VFS support) That was with spinning hard disks where seeks cost more, but i suspect it is not that different on SSDs. The only sane way would be probably to go to some other format for the standard applications and only support freedesktop for optional addons. -Andi From: Yang, Lei A Horace, Does the gnome-menu interface read the .desktop files every time? Can we add some cache file to store the list for next boot up? We may use some mechanism that just read the .desktop files which later than the cache file. Thanks, Lei Y From: Li, Horace Hi, All, Thanks Fan Martin for taking lots of effort to narrow down the time consumption issue
RE: How to change desktop look?
Check in /usr/share/mobile-basic-flash/applications If there are more than 1 .desktop file, then this is where you should place your .desktop file for it to show up on the home screen. The icons would go into /usr/share/mobile-basic-flash/icons We are trying to get this updated as it was the old mechanism, but I don't know the status of that update. The MP3 problem may be due to a missing gstreamer codec? But I assume that you can play mp3's with mplayer already... Hm. -- not sure. Bob Dustin Spicuzza wrote: Spencer, Bob wrote: Nice screen shot. Thanks, I'm definitely excited about using UME in my car. Love the touchscreen-friendly interface. :) Assuming you have a fairly recent drop of UME, new applications (like your GPS app) should: 1) install a .desktop file into /usr/share/applications 2) install an icon into /usr/share/icons/hicolor/size/type (e.g. /usr/share/icons/hicolor/64x64/apps/mygps.png) If #1 is done correctly, the app should show up in the UI. If #1 and #2 are done, it will also have the right icon :) Ok... now, looking at /usr/share/applications , there are a million different things there. Now, for example, on my desktop, there is an icon labeled Instant Messenger. So, I execute the following in that directory: grep -R Instant Messenger * No results. I have noticed the presence of hildon related directories however... $ ls | grep hildon hildon-control-panel hildon-control-panel.desktop hildon-home hildon-marquee hildon-navigator hildon-status-bar Now, I also have galculator on my desktop... so I make a copy of the galculator.desktop in /usr/share/applications, and change the Name to Galculator II, and name the file galculatorII.desktop. Restart the desktop... no results. So.. I was thinking that /usr/share/applications had something to do with it, but it seems that there is more than meets the eye here. There are also .desktop files in /etc/hildon-desktop ... however, following their contents to wherever always seem to inevitably point to some .so files, which is leading me to believe that its hardcoded somewhere. So. any good thoughts? Before going too much further, I should point out that since I'm running this on what is (for all practical purposes) a normal PC, I have the UME stuff installed side-by-side with ubuntu-desktop (I have GDM launch the desktop for me with autologin enabled). I can't imagine that makes too much of a difference, but I also realize that its not really supported too... Once this gets solved.. we're definitely going to need to put it into the UME Wiki somewhere. Hope that helps for what you're trying to do. As for playing MP3's (from your blog), what errors are you facing? The songs needs to go into ~/media/audio. Yep. It shows up in the UI, but complains about mp3 files in particular. I installed the normal mp3 stuff... however, that didn't fix that error. I haven't really looked into fixing this in any serious way yet however, since I'm working on getting roadnav to look/work nicely in UME. It may be related to having ubuntu-mobile installed side-by-side with ubuntu-desktop too.. not sure. Thanks! Dustin -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: How to change desktop look?
Nice screen shot. Assuming you have a fairly recent drop of UME, new applications (like your GPS app) should: 1) install a .desktop file into /usr/share/applications 2) install an icon into /usr/share/icons/hicolor/size/type (e.g. /usr/share/icons/hicolor/64x64/apps/mygps.png) If #1 is done correctly, the app should show up in the UI. If #1 and #2 are done, it will also have the right icon :) Hope that helps for what you're trying to do. As for playing MP3's (from your blog), what errors are you facing? The songs needs to go into ~/media/audio. MP3's should work fine. Are they showing up in the UI and not playing, or not showing up at all? Bob Dustin Spicuzza wrote: Hey, So I can't figure out how to add new applets or remove old applets from the hildon-desktop display. While it looks very nice (see http://www.virtualroadside.com/blog/index.php/2008/04/05/ubuntu-mobile-s creenshot-on-my-carputer/ for screenshot), I don't really need the non-working apps, since they don't work. And, I would love to add my GPS application (which is finally *almost* ready to be used with a touchscreen, thanks to hildon support in wxWidgets) to the desktop... but can't figure that out. I get to a deadend when I get to /usr/share/applications/hildon-home ... which points to a library. Thanks! Dustin -- Innovation is just a problem away -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: taking screenshots of UME on a Samsung Q1
I've use the gnome-screenshot From terminal (connected to network): $ apt-get install gnome-utils $ gnome-screenshot Bob Loïc Minier wrote: On Wed, Mar 26, 2008, Rob Lifford wrote: Is there a screen capture utility installed by default with UME (I'm assuming to be run from the terminal)? If not, any recommendations on which to install that'd be easiest to get running in this environment? xwd is probably installed in your env; try xwd -root root.xwd; you may also install imagemagick and use it's import utility for example. -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Adobe Flash on MID Linux
Andrew, Thanks for your interest. It is possible to run a flash application on either Red Flag's MIDINUX or Ubuntu's Mobile and Embedded distribution, both of which are targeted toward Intel MID hardware. For ongoing help I recommend you join us at one of the following: IRC: irc.freenode.org, channel #moblin irc.freenode.org, channel #ubuntu-mobile Mail: [EMAIL PROTECTED] ubuntu-mobile@lists.ubuntu.com I added a few answers to the things I know below. Lucas Rocha wrote: Hi Andrew, I suggest you to contact Leonid Zolotarev ([EMAIL PROTECTED]), from the browser team at Nokia, to know more information about Flash here. Br, --lucasr Em Ter, 2008-03-25 às 17:42 -0400, ext Andrew Opala escreveu: Hi guys, Sorry for the unsolicited email, but I found your email addresses on some source code I was reviewing for answers. I would like to port(transfer) a Flash-based (Flash 9) application to the MID Linux platform that runs on Intel devices, but I realized there are lots of questions that I can't find answers to. I currently have no device in mind just the platform. - under Linux/MIDINUX what version of Flash is supported? - is the flash integration only through the Mozilla browser or can the application run stand alone? I would recommend a simple stand-alone GTK app that uses a GtkMozEmbed plugin to render the Flash content. I've written this for demos if you are interested. Alternatively you could put together a similar application using something like WebKit. I've not done this to date. Adobe has announced AIR which would allow you to run Flash outside the browser environment, but it is not available for Linux yet. Bob - is there an extended API to reach device capabilities such as the hard disk or link local application? I think if you put the correct Flash security file on the system during install of your application that you'll be able to access local resources. - what other relevant Linux/MIDINUX mobile platform issues are there such as design guidelines I will not send you any further emails nor will I include everyone on my responses. If you do not respond to this email I will not be sending any more. Any other help in finding the answers like online forums that have some substance to them or books, pdfs, YouTube videos of available devices, etc. or people to contact would be greatly appreciated. I am looking at the North American market first - then maybe Asia. Thanks a lot for your help. -Andrew -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Moblin Supported devices (from RE: [Moblin Dev] RE: Moko finger scroll widget is broken in Hardy PPA)
The devices supported are Menlow-platform and Mcasslin-platforms. The Samsung Q1 Ultra is a Menlow-platform-based device which we use for development. Mcasslin-platform devices are in prototype phase and due out this summer. Bob jonathan swan wrote: Hey guys sorry for firing off an unrelated email but I was wondering if some on could point me to the supported devices for ubuntu mobile. Just starting out learning about this stuff any help much appreciated. Best regards, Jonathan Swan. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: FW: Hildon 2.0 Release
We are already at a version very close to v2.0 I'm not sure if the magic isn't already there. Or do you know that they added significant features very late? I mean we updated just 6 weeks ago. Bob Adilson Oliveira wrote: Spencer, Bob escreveu: Perhaps we should review the differences and see how invasive they are and if we should move to this latest release. If I want to make the alarm clock work the way we were discussing yesterday, yes. []s Adilson. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: how to run as ume user in Xephyr?
John, Do you think defaulting to user ume is OK? It has an advantage for me in that I can setup my home environment including adding media content and it will be the same on the Q1. I think we talked about this once and decided against it, but I can't remember why. Bob Kyle Nitzsche wrote: Thanks for the info, Loic. If it were made more straightforward (maybe even the default), folks would be more likely to run as ume user in Xephyr target, which might help unearth bugs. Kyle On Jan 17, 2008, at 7:16 AM, Loïc Minier wrote: Hi Kyle, On Wed, Jan 16, 2008, Kyle Nitzsche wrote: Anyone know how to launch target in Xephyr as ume user, not root? This is something I do regularly, but which is very hackish. First, I have an ume user on my host; it has uid 1001. Second, the ume user is usually created by ume-config-common in the targets but with first available uid of 1000. I change this uid in /etc/passwd and /etc/group in the /targets/image/fs chroot. Third, I'm fixing the Xephyr startup to run as ume: - I install xserver-xephyr manually as root - I start dbus manually in the chroot as root and comment this out of the ume-xephyr-start script - I make sure that /tmp is bind mounted (image-creator does this automatically I think) as well as /home (for Xauthority) CAUTION: if you bind mount /home, make sure you unmount it before removing your target, or you could cause image-creator to rm -rf your home This works well for me, but should be made more easy. Also, this doesn't plug the current hole that Xephyr is run with -ac in the script, but that's not an issue on single user systems. -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Apps Criteria -- 3 levels
A good review, thanks. Loïc Minier wrote: Thanks for your lists! 1 Bronze Level (minimum to be linked from moblin.org) 1.1 Build and Install 1 Compiles cleanly 2 Buildable in target environment with autogen, configure, make 4 Contains installable .deb package(s) = Replace with Builds Debian Policy compliants packages with no more build-deps than those of the dev SDK. Good. 3 Shows up in UI 6 Screenshot available So only graphical apps? I can clarify when applicable 5 Installs cleanly in target environment Packages install cleanly in... perhaps 1.2 Hildon Application (Bronze) 3 For applications that can be built for Mobile and non-Mobile environments, check for LPIA architecture in configure and define USE_HILDON flag to use in code for Hildon version. example I kind of want to group Hildon-related changes in one area, even though it is a build topic. I think you should move this to 1.1 and require packages to build under the lpia architecture. Regardless of grouping, I should require LPIA compat. I don't think you should recommend checking for lpia to enable USE_HILDON. You should just rely on the package build rules to do the right thing. I would only keep C source code specific to the Hildon libs should be protected by #ifdef USE_HILDON which should be defined by the build system. OK, I like that. 4 Register with libosso. example 5 Create DBUS service file example Mandatory? For UI apps it is in order to get the application to behave as a singleton. 6 Singleton behavior. Registered with libosso for startup. Correctly brings its window to the top when requested. example Having a window is mandatory? I'll add when appropriate 7 Have correct .desktop file format and contents example Might want to refer to the freedesktop standard + required fields. Right.. Actually Hildon is not freedesktop compliant (I don't think). I need to follow up on exactly where they are or aren't and clarify. Thanks for the reminder. 2 UI works on 800x480 and 1024x600 2.a Can read text on both resolutions suggested font sizes Apps should use the system's default font size, no? True. And readable is subjective anyway. I can't read the Sony UX screen at default resolution. Perhaps a better wording would be: Text is displayed at system default size and is not inappropriately or unexpectedly cut off 2 Silver Level 2 Supports the following DBUS / OSSO messages: list example What for?? I was thinking of examples like the browser should support notification to load URL. This comes from an interested App via DBUS msg. We need to look at all the useful dbus / osso messages and make this clearer or remove. 4 Recommended - Consistent mechanism to notify apps to go Full Screen and non-full screen An example of a dbus message. I believe all apps should listen for the same message to go to/from full screen mode. - Xephyr supported by apps Ability to run the application in Xephyr on the desktop. What do you mean with these two? Thanks! -- Loïc Minier Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Handwriting recognition support in Ubuntu Mobile?
Michael, We have only discussed handwriting but haven't done any real investigation into this area. I like what I see. If we get some time we'll check it out. I wonder how well the keyboard and handwriting apps work inside a matchbox single-app-at-a-time window manager. Bob Michael Levin wrote: Hello! I was recently informed of the existence of this project and I was wondering what the plans were for handwriting recognition on penabled mobile devices (PDAs). The launchpad blueprints page suggests changes to onBoard but I didn't see anything relating to handwriting recognition. I'm asking because two months ago I released my project, CellWriter, a grid-entry handwriting recognition panel under the GPL. It was developed for use on tablet PCs but I've had users successfully run it on PDAs. CellWriter requires per-writer training and being grid-based is not as immediately usable as pre-trained full sentence recognition systems. However, it does have the advantage of being able to learn users' individual handwriting style and is able to generate any Unicode character, letting users write in their native language. Source and an Ubuntu/Debian package are available on my website: http://risujin.org/cellwriter/ If you find CellWriter to be at all useful, please let me know and I'd be happy to support it and make any changes necessary for it to integrate with your systems. -- Michael Levin [EMAIL PROTECTED] -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Gtk 2.12 and tap n hold
Thanks Ian, This is the work I was referring to. From reviewing the thread again, it sounds like there is a tap-n-hold patch that Nokia has created which needs to be applied to Gtk 2.12 (2.10.12). This would mean having two versions of GTK, or having USE_HILDON in upstream GTK. Adilson, I'm asking you because I am assuming you are the maintainer of the Hildon code in Ubuntu-mobile. Maybe that's just cause you did much of the initial work. Cheers, Bob Ian Lawrence wrote: Hi there was a discussion a while back about this https://lists.ubuntu.com/archives/ubuntu-mobile/2007-May/000246.html []'s Ian On Nov 22, 2007 8:34 AM, Adilson Oliveira [EMAIL PROTECTED] wrote: Spencer, Bob escreveu: Adilson, Did we bottom-out on Tap and Hold functionality? I forget where we left that. I believe that Gtk 2.12 does not have this functionality without a Nokia patch. Currently there is no such functionality in our images. I usually discourage its use by applications, but we still need this for ease of porting maemo applications. Hi. I don't know why you asked me but here it goes :) I consulted with the rest of the team and we agreed that we can do that as upstream don't gave any clues about it yet but we can't give you any dates yet as our schedule for the next months is being finished. []s Adilson. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Gtk 2.12 and tap n hold
Adilson, Did we bottom-out on Tap and Hold functionality? I forget where we left that. I believe that Gtk 2.12 does not have this functionality without a Nokia patch. Currently there is no such functionality in our images. I usually discourage its use by applications, but we still need this for ease of porting maemo applications. Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: hardy images - known issues
4) The touchscreen is completely uncalibrated. Loic, Did you find calibration values that work? That would help others at least start using this image. It would also help the calibration guys. Bob Loïc Minier wrote: Hi, I updated MIC to pull from hardy + the ubuntu-mobile hardy ppa; with the new images I had the following issues: 1) sudo and other programs aren't happy with the generated hostname as it's not listed in /etc/hosts; proposed fix: have a first boot setup taking place the first time the system starts and generating /etc/hosts + /etc/hostname; perhaps we can check how the alternate installer boots and what it generates after debootstrap. The workaround I'm using is to change /etc/init.d/hostname.sh to not fiddle with the hostname and I'm setting /etc/hostname and /etc/hosts manually to a value I picked. https://bugs.launchpad.net/bugs/163798 2) X wont start as /etc/X11/X points to /bin/true instead of /usr/bin/Xorg; workaround is to ln -sf /usr/bin/Xorg /etc/X11/X. I was told this was probably a known bug which is fixed in Debian. https://bugs.launchpad.net/bugs/163806 3) I saw some no such file on /dev/dri and /dev/dri/card0 which I did not get on gutsy for some reason; glxinfo reports direct rendering, so I didn't report that. glxgears reports some 125 FPS; my laptop does 800 FPS with the vesa driver, so I find the performances quite bad. 4) The touchscreen is completely uncalibrated. I managed to get the calibration program to run, but the generated values don't work for me. I think this is the result of mixing the patch from Pepper with the new upstream release which fixes the same thing differently; I don't know who the original author is, but would appreciate if he could have a look. :) https://bugs.launchpad.net/bugs/163850 I'm interested to discuss proposed fixes for the above bugs or whether you consider the above issues bugs at all. :) This means that images generated with the new MIC will be more or less broken until we fix the issues in the relevant packages; as this is not a direct MIC issue, I will upload it to hardy and I plan to upload a similar MIC pulling from gutsy + ubuntu-mobile gutsy ppa in the gutsy ppa. I'll do so as soon as I can sync my git with the upstream one. The images of hardy will probably be quite unstable for a while. Bye, -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Enabling Simplified Chinese Pinyin input method on Ubuntu Mobile withSCIM
That's great. Good details. Any chance you could put how big these packages are? For example, if I follow your steps, how much larger will myimage be? Just trying to keep a handle on size, esp with the font pkgs which can be large. Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kyle Nitzsche Sent: Thursday, November 15, 2007 8:37 AM To: ubuntu-mobile@lists.ubuntu.com Subject: Enabling Simplified Chinese Pinyin input method on Ubuntu Mobile withSCIM I wrote a wiki page that explains how to enable entering Simplified Chinese from a USA keyboard using SCIM and Pinyin in Ubuntu Mobile. Also covers adding the required font. Additional (untested) info for Traditional Chinese using SCIM and Chewing. https://wiki.ubuntu.com/MobileAndEmbedded/SCIMInputMethod Kyle -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Criteria for App Mobilization
I added them. Bob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kyle Nitzsche Sent: Friday, October 26, 2007 12:58 PM To: Robison, Clayne B Cc: ubuntu-mobile@lists.ubuntu.com Subject: Re: Criteria for App Mobilization That's great. Can you add them to the wiki page: https://wiki.ubuntu.com/MobileAndEmbedded/UserApplicationCriteria That way they won't get lost in email list archives. Kyle On Oct 26, 2007, at 3:51 PM, Robison, Clayne B wrote: I agree with everything that Steve said below. A few more things: 1) Network connectivity: Applications should be network connection aware, allowing the user to be connection agnostic. I.e. internet/network based apps should function as well as possible regardless of whether or not there is a connection to their backend data, performing automatic synchronization when network connection is available. This may mean some amount of caching and prefetch to anticipate non-connected states. For example, an e-mail app allows someone to work perfectly well offline-composing, reading and managing mail-and then automatically synching once a connection to the server is available. Users should NEVER have to press some button that says Sync Now, Go Offline or Go Online. 2) Storage space awareness: Because many of the devices we are targeting are going to have limited storage space, all applications that store data on the device should be aware of this limitation and be prepared to handle the inevitable. I recognize that this criteria juxtaposes #1, which requires networked apps to prefetch and cache, and assumes limitless local persistent storage. 3) System CPU and Memory resources: Many of our target devices will also have limited CPU and Memory resources, and much of the software that is currently installed by default (e.g. the System Monitor) are currently VERY resource intensive. Applications that know they need lots of CPU and/or memory (e.g. video playback) should sniff out the current playing field and warn the user if CPU/memory usage is already so high that performance may be hampered. Ideally, we wouldn't have this hardware restraint, or OS would do this for apps, but I don't think we're to that point yet. 4) Power: Mobilized applications should recognize that battery life is a major goal for these platforms, and that they have a responsibility to play nicely. At a minimum, calls that prevent the system from sleeping, or the screen from blanking should be used judiciously. Applications should also handle the backup and sleep/exit events generated by OSSO/D-bus to prevent their own data loss. Those applications that are beginning a process that may need some time to complete (e.g. file download) should calculate whether there is enough power to complete the operation. All applications should handle the battery-low event to allow the user to take appropriate action (e.g. notify your chat buddy that you might disappear). 5) Screen: While it is true that all dialogs must fit on 800x480 resolution, they should also not be so small that they cannot be read on devices with native 1024x600 resolutions. More criteria: * Applications load + save data automatically - user doesn't have to remember to save data * Filesystem is hidden from the user. Users should never need to know a filename, they should only interact with data + metadata (thumbnails for the image viewer, song/artist name for music, from/to/ subject headers in email, etc). - This means no traditional open/save dialogs - Attach file dialogs need to present a friendly list of objects to attach (thumbnails or metadata) - If the user has to be presented a list of files, the list must only include relevant files. Things like /usr and .xyz files must always be excluded. * # of configuration options is minimized. Applications should come preconfigured with intelligent defaults. Options should only be included if they're easily understood by the computer-phobic or if they're likely to be useful to a large minority of users. * # Featureset should be minimized. Applications like Claws have dozens of menu items, most of which aren't useful to our target market. * # of dialogs is minimized * All screens and dialogs must fit onscreen (800x480) * All screens and dialogs must render properly (no overlapping widgets, no text spilling out of buttons, no text offscreen, no popup menus that aren't wide enough to read the content of the menu, etc). * Dialogs must be positioned centered and fully onscreen. The user should never have to move a dialog to see its contents * Applications with multiple screens (such as a tabbed browser) must present an easy + obvious
Xephyr w/GL support
Bryce, Can you help us get xserver-xephyr with GL support as the default for ubuntu-mobile? We are doing most our debugging on the desktop and moving to OpenGL-enabled applications. What can we do to help? http://dodji.blogspot.com/2007/10/xephyr-xvideo-and-gl-has-landed.html Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
FW: hildon-desktop statubar.conf file
fyi. Lucas Rocha wrote: Hi Bob, Em Seg, 2007-10-15 às 16:27 -0700, ext Spencer, Bob escreveu: When we add new statusbar plugins we're required to append an entry to /etc/hildon-desktop/statusbar.conf . We don't want the plugin pkg to edit these files owned by hildon-desktop but it is inconvenient to go back and update hildon-desktop project each time a new plugin is made. We're looking for a good way to allow new plugin packages to be installed and visible in the statusbar without having to modify hildon-desktop. One suggestion was to use some folder like statusbar.d (similar to /etc/apt/sources.list.d) for additional configuration additions. Another was to just have some entry in /etc/hildon-desktop/statusbar.conf like [*] which would put all the /usr/share/hildon-status-bar/* plugins not already listed. This scenario may also be desireable for any container where plugin order and size are not required. Bob Do you mean that you want new statusbar plugins to be automatically loaded? If so, you can just add X-Load-New-Plugins=1 to your Statubar container section in desktop.conf. Let me know if I missed something. Cheers! --lucasr -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Criteria for App Mobilization
Levinson, Aaron N wrote: A good starting point might be the Hildon UI Style Guide, available at http://test.maemo.org/community/hildon_ui.html . I'm not sure why this document is no longer available from www.maemo.org, but it provides various guidelines on how a Hildonized GUI application should behave. Aaron Levinson Yes, we ported that guide: https://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuide https://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuide?action=AttachFile do=gettarget=MID+Application+UI+Design+Guide.pdf Bob -Original Message- From: [EMAIL PROTECTED] [mailto:ubuntu-mobile- [EMAIL PROTECTED] On Behalf Of Cassezza, Jason Sent: Thursday, October 25, 2007 11:45 AM To: Spencer, Bob; Kyle Nitzsche; ubuntu-mobile@lists.ubuntu.com Subject: RE: Criteria for App Mobilization How much detail would we want to include in the list? For example, we could (and possibly, at some point, should) talk to things like: - Icon guidelines - Minimum application menu requirements (assuming any app needs at least some menu, even just to access settings, etc) - Other look and feel requirements (how much can/do we dictate?) Just random thoughts. -jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer, Bob Sent: Thursday, October 25, 2007 10:36 AM To: Kyle Nitzsche; ubuntu-mobile@lists.ubuntu.com Subject: RE: Criteria for App Mobilization Kyle Nitzsche wrote: Hi, We've been talking in Lexington about whether it would be helpful to develop a list of criteria for assessing the status of an application that has been added to Ubuntu Mobile Core. Yes, I like this a lot. The app might not be considered fully mobilized if items on the list are not done. Mobilization criteria might include: --Hildonization --UI works at 800x480 --UI works for finger touch (no small buttons) --Set up for translation --Consistent with theme framework --More? -- Not butt ugly. (This last requirement might exclude most of our current work) Thoughts? Kyle -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Image building taking hours. Normal?
We setup a local system to mirror deb http://us.archive.ubuntu.com/ubuntu/ gutsy main restricted universe Now on a fast system you can create an image in about 10mins (some have claimed 4mins, but we haven't had an official olympic race) It stinks to postpone a test or development because building takes so long. It is this sort of problem that plagues large projects like OpenOffice. Bob Ian Lawrence wrote: Hi, Using the image builder on 7.1 but its taking hours (and hours) to build an image. Have I got a local issue or is 4 hours (and counting) normal? It took me @ 8 hours to create a project before I created a local mirror server...this process is explained here: http://umeguides.net/C/ch03s06.html HTH []'s Ian -- http://ianlawrence.info -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
UI and Apps Status
UI Hildon Desktop:We wanted the latest hildon-destkop code from upstream into gutsy and worked to get this to happen, but in the 11th hour we weren't able to verify and fix all the issues. Many thanks to Loic Minier for his help getting together. We did updated hildon-desktop to add some small patches to show the volume and brightness controls in the statusbar. We are now in a position to relook at hildon-desktop and do some cleanup, etc. Grid-layout / HTML: HTML version of UI in gutsy is simple but functional. Still needs rework to remove the mobile-basic-flash/applications directory and add a MobileApp category (or something similar) in the normal .desktop file Clutter Home Screen: Moving forward and will get some focus this week. Still has too many bugs to be usable. Theme: See status in Peter's email. Apps Media Viewer: Working version into gutsy with some new graphics. Our misunderstandings of how theming and images should work have delayed a more beautiful solution, but we're making headway. Still fixing many bugs and misunderstandings in how we want it to look/behave. Suggestions welcome on media player. Design and Look/Feel: If we are going to have applications with a common look/feel, simple ,finger-friendly navigation, and be polished and professional looking (NOT open source application look), we are going to need to dedicate real time to improve core applications. We need to agree how to get to this stage. Until then our collection of apps looks quite ad hoc. Overall, a big thanks to Matthew Garrett who patiently helped us get our components into gutsy. We are planning ahead now so we don't require such last-minute help in the next release. Bob From: Spencer, Bob Sent: Thursday, October 11, 2007 8:54 AM To: 'ubuntu-mobile@lists.ubuntu.com' Subject: UI and Apps Status Another JIT status report UI Grid-layout / html Home Screen: Working now. Recognizes theme and background change. Requires hildon-theme-mobile-basic for button button background graphics. Still to be done: - Set the default theme as this UI reads the theme from gconf and currently UME default theme is the non-existent Human theme. - show some small animated gif when application is launching - listen for notification when application has completed launching to turn off animation - Request upload into gutsy If you install the latest mobile-basic-flash package from moblin.org you will get this UI by default. Clutter Home Screen: Have got it working on my Q1 after getting the hardware accel driver. Clutter 0.4+ libraries have been included in gutsy Current issues: - Touch screen isn't sensitive enough to give me the light iPhone touch feeling. I often have to use my fingernail to grab the objects - UI is jerky. When you try to roll the objects left/right they stall, then burst. - actor objects often get misplaced and then bunched at the beginning - location highlight at the bottom of the screen is misplaced - big animation look a little to Apple-MAC like. We'd like to get it to look more like a rolling ring of icons - the /etc/xdb/menus/*.menu file doesn't match well with our applications. We need to add a MobileApp category to applications and filter them for showing on the home screen - when launching the applications the code to detect if it was successfully launched is imperfect Theme: Chatted with Ken about theme. He is highly frustrated with our current status and apparent miscommunication. Need to resolve how to get something in the short term and then fix the long term process issues. Bug with current flash UI: We found and fixed the performance but with the flash UI. Media Viewer: Have new graphics we are trying to put into application/UI. Many new features working now including thumbnail view. Other comments: - I built LPIA build again this and still no Hildon Claws. We put a couple of guys on this to try and get a last-minute upgrade of basic features and it would be nice if we could see the Hildon version in our images. From last week's To Do: 1) Get Grid-layout UI usable. Any day now. I assumed it would be yesterday but ran into small bugs around changing the background repeatedly. Should checkin today. (Done) 2) Make sure we resolve the performance bug. Hopefully this goes away with the non-flash UI. We will still try to resolve, but it will fall to a lesser priority. (Done) 3) Go through remaining UI elements and finish bug fixing for gutsy launch. Mainly: marquee needs tweaking, theme needs to be completed. (Still in progress) 4) Start work to get clutter UI to a usable state so people can start commenting and we can discuss the exciting post-gutsy future of the home screen! (Lots of work ahead) Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe
RE: patch for hildon-desktop
Bill, upstream for hildon is usually here for hildon-desktop stuff: [EMAIL PROTECTED] (fyi) bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Loïc Minier Sent: Friday, October 12, 2007 11:56 AM To: Bill Filler Cc: ubuntu-mobile@lists.ubuntu.com Subject: Re: patch for hildon-desktop On Fri, Oct 12, 2007, Bill Filler wrote: Those are great suggestions and I have implemented some of them already. I think maybe the containers to hide/show should probably come out of gconf rather than be hardcoded. I will work on a new patch that incorporate these changes and get it to you soon. Great! I don't know whether it's an option for you to discuss this directly with upstream: they might have similar or contradictory plans on the subject, so it would certainly be a good idea to have them in the loop. Do you think we could discuss the evolutions in a bugzilla bug report against upstream's hildon-desktop? I guess we would only need to check first whether the patch applies to their pristine sources (I only applied it to the ubuntu tree). -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
UI and Apps Status
Another JIT status report UI Grid-layout / html Home Screen: Working now. Recognizes theme and background change. Requires hildon-theme-mobile-basic for button button background graphics. Still to be done: - Set the default theme as this UI reads the theme from gconf and currently UME default theme is the non-existent Human theme. - show some small animated gif when application is launching - listen for notification when application has completed launching to turn off animation - Request upload into gutsy If you install the latest mobile-basic-flash package from moblin.org you will get this UI by default. Clutter Home Screen: Have got it working on my Q1 after getting the hardware accel driver. Clutter 0.4+ libraries have been included in gutsy Current issues: - Touch screen isn't sensitive enough to give me the light iPhone touch feeling. I often have to use my fingernail to grab the objects - UI is jerky. When you try to roll the objects left/right they stall, then burst. - actor objects often get misplaced and then bunched at the beginning - location highlight at the bottom of the screen is misplaced - big animation look a little to Apple-MAC like. We'd like to get it to look more like a rolling ring of icons - the /etc/xdb/menus/*.menu file doesn't match well with our applications. We need to add a MobileApp category to applications and filter them for showing on the home screen - when launching the applications the code to detect if it was successfully launched is imperfect Theme: Chatted with Ken about theme. He is highly frustrated with our current status and apparent miscommunication. Need to resolve how to get something in the short term and then fix the long term process issues. Bug with current flash UI: We found and fixed the performance but with the flash UI. Media Viewer: Have new graphics we are trying to put into application/UI. Many new features working now including thumbnail view. Other comments: - I built LPIA build again this and still no Hildon Claws. We put a couple of guys on this to try and get a last-minute upgrade of basic features and it would be nice if we could see the Hildon version in our images. From last week's To Do: 1) Get Grid-layout UI usable. Any day now. I assumed it would be yesterday but ran into small bugs around changing the background repeatedly. Should checkin today. (Done) 2) Make sure we resolve the performance bug. Hopefully this goes away with the non-flash UI. We will still try to resolve, but it will fall to a lesser priority. (Done) 3) Go through remaining UI elements and finish bug fixing for gutsy launch. Mainly: marquee needs tweaking, theme needs to be completed. (Still in progress) 4) Start work to get clutter UI to a usable state so people can start commenting and we can discuss the exciting post-gutsy future of the home screen! (Lots of work ahead) Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Mobile-media
Rusty Lynch wrote: On Mon, 2007-10-08 at 07:07 +0100, Matthew Garrett wrote: I chatted to Bob about this briefly on Friday, but thought I'd mail the list to make sure that I don't end up doing anything unexpected. I've been looking into uploading gstreamer-dbus-media-service and mobile-player. I've got everything working and building happily, but there's a few changes I'd like to make: 1) Rename org.gnome.MobileMediaService to org.moblin.MobileMediaService - using Gnome's namespace for an interface that isn't part of Gnome doesn't sound like the best plan to me. I thought we did this already... yea, this needs to be fixed. Got it. ...and I believe moblin-media doesn't yet have MobileMediaService as an install dependency. 2) Adapt mobile-player to use directories in ~ rather than /usr/share for user information. Right now it wants to write files to /usr/share, which isn't going to work now that we're not running as root. Either it needs to be able to deal with the concept of merging multiple data sources (one read-only and another read-write) or we can just move everything into the user home directory. The downside of the simple approach is that it makes it harder to provide example data. I'm not much of a Python person, so I'm not so keen on implementing the more difficult side of things. If that can get worked out, it would be great. I meant to write a bug on this but never followed through. Perhaps the right approach for providing some minimal sample media would be to install the files in /usr/share, but then have the player copy over the sample media when it runs for the first time as a given user (i.e. when it constructs the media database in ~/.something-or-another.) Sounds like a simple solution. So to recap: 1) moblin-media package will contain a few samples (recommend: 2 pics, 1 song (short), 1 video) 2) when run, moblin-media will check for ~/media/ folder (any reason to hide it with .media?) 2a) if no ~/media folder, then create ~/media/photo, ~/media/video, ~/media/music and copy over sample content Question: If we were to create a separate moblin-media-sample-content package, where would it install its contents? How would these get into ~/media for the installing user given that installation is always done as root? (noob question) 3) Possibly rename mobile-player to moblin-player or moblin-media? This would be more consistent with the naming of the other packages. I like moblin-media. Anyone else? moblin-media Already in the works. Other than that, I don't see any showstoppers. As long as there's agreement on these, I'll get it into gutsy this week. -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
xserver configuration
In order to view clutter/OpenGL-based home screen's inside Xephyr, we need Xephyr compiled to support 3D/glx. Has someone on this list done that or have any pointers? I pulled the xorg-server code and will be trying to do this. Any tips would be great. Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Moblin and Gnome
Tollef Fog Heen wrote: * Spencer, Bob Lastly, perhaps we could agree on some standards for branching existing projects. For example #ifdef tag, for code, Makefile.am, configure.in, etc. Then we could easily go to a project and find where/if someone else had added mobile-device-specific changes. tag = MID or UME or HILDON or MOBILE (My vote is MID) In the style of autoconf, I suggest we use #ifdef USE_HILDON -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are Sounds good to me. Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Moblin and Gnome
Bill Filler wrote: I believe for Network Admin and Date/Time settings, Todd was planning on providing a patch to gnome-system-tools for the UI changes necessary for running in the hildon environment. But I'm not sure about all of the other control panel applets. Todd, does it make sense to do this for all the control-panel applets so that it's easier to stay in sync with upstream, rather than forking and having the code live in moblin? In the short term the UI changes are minimal while we get our feet on the ground, but eventually there might be radical changes. For example, the standard Linux keyboard configuration tool might have 40 options today while a simplified MID UI might only expose 5. In another world, I looked at Claws for the first time with the new LPIA build. It is so cluttered with controls and menus that it makes my MID feel very small. I agree with Matt that we should always attempt to push changes upstream. Non-UI changes seem like a no-brainer. In time upstream component owners might have to decide if they want to support a Hildon-esque UI in addition to their standard UI which could be more than a few #define's. Lastly, perhaps we could agree on some standards for branching existing projects. For example #ifdef tag, for code, Makefile.am, configure.in, etc. Then we could easily go to a project and find where/if someone else had added mobile-device-specific changes. tag = MID or UME or HILDON or MOBILE (My vote is MID) Bob On Oct 3, 2007, at 8:17 AM, Matt Zimmerman wrote: On Fri, Sep 21, 2007 at 02:36:04PM -0400, Pat McGowan wrote: When custom versions of gnome based components are created, is it the intention to manage these as patches upstream in gnome, for example in the gnome mobile project? If not, what is the plan to sync these customizations with upstream changes? As far as development in Ubuntu goes, our intention is to merge upstream anything which can be reasonably generalized. Regarding the Moblin components derived from GNOME, I believe Todd Brandt is the person to ask about their plans. Hopefully the changes can be merged upstream (maybe with a --with-hildon configure option or similar). -- - mdz -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/ listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
C/J/K fonts and UME
Using the bottom of the http://news.google.com page for reference, I found the following packages are needed for browsing sites containing multibyte languages. (I don't know how to verify if the characters are correct, but at least they are not garbage). Are these packages we want to include in the default image, or require the user to install after? Chinese/Japanese: ttf-arphic-uming 21 MB Indian:ttf-indic-fonts-core 1.3 MB Korean: ttf-unfonts-core (Korean) 13MB (ttf-unfonts-extra has more variations for Korean) This is an additional 35.3 MB. Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: patch for mobile-basic-flash
Bill Got it. Will try to get to it very soon. Bob Bill Filler wrote: Bob, Attached is a patch file for mobile-basic-flash that adds the following functionality. Please let me know if you have any questions. Bill * added support for hide/show marquee based on gconf settings: When enabled via the appropriate gconf setting, this feature allows the marquee panel to be dynamically hidden when the home plugin screen is shown and displayed when an application is shown. This also requires mods to hildon-desktop, and I will be submitting those patches shortly as well. * added support for custom flash movie name based on gconf settings: If a custom flash movie filename is specified via gconf, it will now be loaded by the flash_home.html, otherwise the default movies will be loaded. * added support for enabling specific events based on gconf settings: Code has been added that will read in gconf settings that specify events to be monitored by the home plugin and propagated to the flash movie. Default implementations have been provided for network state change events and battery events. I attempted to move the impl code into their own files but ran into problems, so all the code currently lives in the main .cpp file, but would be nice to move at some point. * modified support for app launching by name, path, index or mobileId (not complete) Added support to both flash_home.html and mobile-basic-home- plugin.cpp to support launching applications based on the following parameters: launchAppFromName(name) - find app with specified Name from .desktop file and launch launchAppFromPath(path) - execute the specified command path launchAppFromIndex(index) - current method of using index to launch app launchAppFromId(id) - this is stubbed out to support launching from the MobileId parameter that we discussed adding to the .desktop files TODO: Bob, you'll need to modify src/gui.as to call launchAppFromIndex () rather than launchAppFromId(), as you guys are currently using the index. The flash movie will need to be regenerated as well. I tried to do this, but had problems with the flash movie, so that's why I didn't do it. * added start_plugin() function that gets called from flash movie to launch plugins Added support to launch plugins from the flash movie via the launchPlugin(name) javascript method. * added launching banner when launching app: Shows a banner in the center of the screen as soon as app launch starts and it sticks around until the application is shown on the screen -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
FW: Hildon Input Method is released (fwd)
FYI Levinson, Aaron N wrote: Hi Bob, Looks like some of the Hildon Input Method stuff has been open-sourced--maybe this includes some useful stuff for Intel MIDs. Aaron -Original Message- From: Aaron Levinson [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 8:29 AM To: Levinson, Aaron N Subject: Hildon Input Method is released (fwd) -- Forwarded message -- Date: Fri, 07 Sep 2007 18:05:29 +0300 From: Mohammad Anwari [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Hildon Input Method is released Salaam, (Sorry to cross posting) Today we are releasing the Hildon Input Method. The part we are opening are the input method framework, common UI part and plugin system plus a plugin example. They are released in LGPL version 2.1 (for the framework and the common UI part) and BSD (for the plugin example). Check our (new) homepage: http://live.gnome.org/Hildon/HildonInputMethod Enjoy. ___ maemo-developers mailing list [EMAIL PROTECTED] https://lists.maemo.org/mailman/listinfo/maemo-developers -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Missing .xinitrc: Launching the UI inside of Xephyr in the Target?(Was: Monday Breakage)
Matthew Garrett wrote: On Fri, Aug 24, 2007 at 04:49:02PM -0700, Spencer, Bob wrote: Matthew Garrett wrote: By the way - never do this on any computer connected to the internet, especially if your X server is configured to listen for TCP connections. Thanks -- can you give me a secure good replacement? I tried $ xhost +localhost but couldn't get the target terminal to connect. A somewhat (though not perfectly) safer way of doing this is to launch Xephyr in your host system with the -ac argument. This disables access control for Xephyr, which should let you connect from inside the target chroot. Anyone with access to your system will be able to watch anything you do inside the Xephyr session, but that's much less likely to cause you security issues. We did this originally, but with the new xinit script we are not able to run the UI inside Xephyr run from the workstation terminal. The command we run now is: xinit /etc/X11/xinit/xinitrc -- /usr/bin/Xephyr :2 -host-cursor -screen 1024x600x32 -dpi 96 -ac Suggestions on how to fix this back to the previous way would be nice and not require us to re-install Xephyr every time we make a target. Bob Ideally, generate an authentication file inside the development environment and then run Xephyr with the -auth argument to tell it to use that authentication file. That way there's a shared secret between the clients and Xephyr, which prevents any information leakage. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Missing .xinitrc: Launching the UI inside of Xephyr in the Target?(Was: Monday Breakage)
Sean Sosik-Hamor wrote: Greetings, What is the new official way to launch the UI inside of Xephyr in the Target now that .xinitrc no longer exists? I read over the Monday Breakage thread but it doesn't seem like there's a definitive process yet. On the workstation, enable access to display: $ xhost + In a target terminal, install Xephyr and launch UI: # apt-get install xserver-xephyr # export DISPLAY=:0 # /etc/init.d/dbus start # xinit /etc/X11/xinit/xinitrc -- /usr/bin/Xephyr :2 -host-cursor -screen 1024x600x32 -dpi 96 -ac I updated http://moblin.org/howto_app-dev.html already. I'll update the other today. Bob * Monday Breakage: http://www.moblin.org/pipermail/dev/2007-August/ 000352.html Also, will someone be updating the docs on Moblin.org now that they're out of date? * http://moblin.org/howto_create-image.html Sean Sosik-Hamor Systems Administrator Pepper Computer, Inc. w: www.pepper.com e: [EMAIL PROTECTED] p: 781-862-2500 x 207 -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: How to call a python plugin in UI
ping -- were you able to successfully launch your app? I'd love to see a screenshot of your application running. Bob Ian wrote: Ola, Mobile player is also a python application. Maybe it's not the best way to launch python application, but it can be a reference. 1. create an exe file under /usr/bin -- mobile-player #!/bin/sh Cd /usr/share/mobile-player Python media_gui.py 2. add mobile-player in *.desktop file Exec=mobile-player Type=Application ... 3. add mobile-player in conf.xml app id=6 title=Media Player desc=Mobile media player icon=icons/media.png path=/usr/bin/mobile-player / this is valuable information...thanks []'s ian -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: mockups
Hey Ken, Been on vacation for 2wks and just catching up. Kenneth Wimer wrote: On Friday 20 July 2007 16:28:18 Bill Filler wrote: Ken, The screens look good. See my comments below: On Jul 20, 2007, at 7:11 AM, Kenneth Wimer wrote: On Friday 20 July 2007 08:52:32 you wrote: snip Thanks for the pictures :) Glas you like them :-) A few questions: * Is Settings part so important that has to be always available? Is it about device settings or application settings? I think for the short term it is a stretch to try and modify all applications to consistently export their app-specific settings to a separate place. But I think the system-wide settings are good. For example, the browser should use the system network settings and not have its own configuration. Bob This is one of the major questions. Should we have a global settings app in which all settings are stored for all apps or should we have some settings tool available per app. Apple does it mainly with the global settings iirc and it gets kinda annoying. The Pepper Pad seemed to do it better with the important per-app settings available in the app itself. On the Pepper Pad there are global settings which apply to the overall system (i.e. wifi, date/time, power mgmt, etc..) and then app specific settings. The way you have the UI designed with the Settings button always visible, perhaps when you are viewing the Home/ Applications screen the Settings would take you to the system wide settings page and when you are in an application, the Settings would take you to the app specific settings page. Exactly. I wasn't sure how to visually differintiate between the system wide settings and the per app settings nor if it is necessary. * How one switches between an active application and applications view? * How one swtiches between applications? Another great idea which I realized in advance would be popular :p Note also that there are no close or minimize buttons on the open apps. The idea behind is this: The home button always has a way to get to the apps page where one can pick an app, start it, restart/rechoose it. Note that in this version there are also no menus. Everything you see shows up fullscreen, although some things in the status bar will be an almost fullscreen overlay (which one could argue is just an associated pop-up and therefor really a menu). Using a task switcher menu turns out to be just as many steps, and more confusing that keeping things flat and simple. Again, this is an idea and I'm not really sure if it is possible to realize such functionality. Seems like this model could work, but would add a few steps for some operations. If I understand correctly, if I'm in an app and I want to close it, I would have to do 1)click home button 2)click apps button from home page 3) select my app 4) press stop/restart. That's a lot of steps which would be eliminated if you had a close button somewhere in the marquee. Or maybe you never really close an app because it gets hibernated when not using it so that's not an issue? The original idea was to never have to close or minimize an app. Not sure how saving document changes would work. Regarding switching between running apps, wouldn't using a task switcher directly from the marquee (i.e. a drop down menu listing the running apps) be one less step than clicking home-apps-select app? I've tried to stay away from using any menus, as on smaller devices they are hard to touch and in high contrast lighting hard to see. Praticaly speaking we might have to use such a menu. Earlier mockups show such a menu so I am leaving it out for now. Also, if an app had multiple open views, how do you navigate between views within the application? There should be some indication of the open views within an app and a way to navigate them. depending upon how the apps work this might very well be a problem which could be solved by tabs (just like the browser issue). * Browser does not seem to have tabs, it would be very interesting to see how it's gonna look with tabs (tabs seem to be quite popular demand (https://bugs.maemo.org/show_bug.cgi?id=1695) also UI Style Guide page suggest browser would have tabs). Erm, I knew I forgot something. Naturally, I will be adding tabs :-) Probably applications and settings stuff was outlined elsewhere, in this case apologize for my ignorance and kindly ask to provide me with a link where I could read more about it... No worries, you've noticed the major issues - here would be a good place to discuss them Ken -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/ listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: How to call a python plugin in UI
If I understand, you've created a statusbar plugin. The statusbar has a feature that allows it to show a 2nd row of icons if the original area fills up. The conf.xml file shows the icon for the application. This is independent of the statusbar. If you want your statusbar to appear you need to do the following: - place your statusbar plugin library in /usr/share/hildon-desktop - add an entry to /etc/hildon-desktop/statusbar - add a .desktop file in /usr/share/hildon-status-bar (from memory, excuse mistakes). Now, if you are talking about something else altogether I apologize for my misinterpretation. Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Sent: Saturday, July 28, 2007 7:40 AM To: ubuntu-mobile@lists.ubuntu.com Subject: How to call a python plugin in UI Hi, I have my plugin appearing in the UI marquee. My conf.xml looks like (look at the last line): snip apps app id=2 title=XTerm desc=X Terminal Emulator icon=icons/xterm.png path=/usr/bin/uxterm -sl 1000 -fa Monospace -fs 10 / app id=3 title=Mousepad desc=Mousepad icon=icons/mousepad.png path=/usr/bin/mousepad / app id=4 title=Calculator desc=gcalctool icon=icons/calc.png path=/usr/bin/gcalctool / app id=5 title=Browser desc=Mobile Browser icon=icons/browser.png path=/usr/bin/mobile-browser / app id=6 title=Media Player desc=Mobile Media Player icon=icons/media.png path=/usr/bin/mobile-player / app id=7 title=TBD Chat desc=Chat Application icon=icons/empathy.png path=/usr/bin/empathy / app id=8 title=TBD Camera desc=Camera App icon=icons/camera.png path= / app id=9 title=Control Panel desc=Control Panel icon=icons/controlpanel.png path=/usr/bin/controlpanel / app id=10 title=Location Services desc=Geographic Information Framework icon=icons/geoclue.png path=/usr/bin/python /usr/lib/hildon-desktop/geoclue.py / /apps /snip but this does not execute my plugin. What should the command be for a python plugin? As an observation: This marquee is going to become very long if every application added has an icon and it will take a long time to scroll for the user to find what she is looking for []'s Ian -- http://ianlawrence.info -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Home applet development in Xephyr
Great news. Thanks a lot! We've had this extra download xserver from Bryce step in our how-to-create-an-image documentation for a few weeks now. Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bryce Harrington Sent: Thursday, July 26, 2007 8:18 AM To: ubuntu-mobile@lists.ubuntu.com Subject: Re: Home applet development in Xephyr On Thu, Jul 19, 2007 at 10:24:47PM +0200, Tollef Fog Heen wrote: * Bryce Harrington | I can attempt an ugly hack-around but I'm hoping someone can suggest | a better approach? We have temporarily disabled Composite support in the X server. This doesn't solve the problem, but it works around it for now. A correction to the patch pointed out by Johan Bilien has fixed the composite issue seb128 had found, and it works properly both for me and seb, so this fix is uploaded. Please re-enable Composite support, and to a quick verification that the clipping patch still provides the desired behavior. Bryce -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Desktop plug-in location in UME
Lynch, Rusty wrote: You are looking at the plug-ins installed by the marquee-plugins package. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Sent: Tuesday, July 24, 2007 10:51 AM To: ubuntu-mobile@lists.ubuntu.com Subject: Desktop plug-in location in UME Ola, I am trying to work out the best way to write plug-ins for UME and I have written a python plugin for Hildon Desktop which works ok in pyphantom, the IDE. On maemo (scratchbox) I would put the python plug-in code inside: /usr/lib/hildon-desktop/ and put the the desktop file in: /usr/share/applications/hildon-home/ and this will then work. I am working inside the Moblin image so I looked in: targets/target/fs/usr/lib/hildon-desktop/ to place the file. I found some other plug-ins this folder, for example libclockplugin.a libclockplugin.la libclockplugin.so I do not know what these extensions are (apart from the .so) and Ubuntu says they are KDE ark packages but even with this tool i cannot view them Anyone some idea how I can look at them? This is the correct place to put a plug-in? The same folders apply for plugins in Moblin. The libraries you see are in the marquee-plugins package. Source available at: $ git clone http://www.moblin.org/repos/projects/marquee-plugins.git I'm not sure about python support for plugins in Ubuntu mobile yet. (It may be there, I'm just not sure of the status). Bob []'s Ian -- http://ianlawrence.info -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
