Re: Replacement for gnudoku
On Apr 15, 2008, at 4:37 PM, Loïc Minier wrote: > I dropped gnudoku from the ubuntu-mobile seed as it was removed from > Debian and later Ubuntu; the comment for the removal was that it > was a > request of the maintainer (RoM) and because better alternatives > existed. > > Does anyone have an alternative to suggest? There is a Sudoku implementation in gnome-games: http://live.gnome.org/GnomeSudoku Steve -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Poulsbo Beta 6 gfx drivers in the PPA
Hi all, The Ubuntu Mobile PPA now contains functional Poulsbo Beta 6 gfx drivers for Hardy. Kernel bits are in the linux-ubuntu-modules package, and userspace bits are in libdrm2 and xserver-xorg-video-psb. Steve -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Missing package
Hi Tero, That package wasn't included in gutsy/LPIA because of a packaging oversight. There's a gutsy/LPIA version available in the Ubuntu Mobile PPA: http://launchpadlibrarian.net/10864242/gstreamer0.10- plugins-bad-multiverse_0.10.5-1%7E710um1_lpia.deb Ubuntu Mobile PPA: https://edge.launchpad.net/~ubuntu-mobile/+archive Steve On Jan 25, 2008, at 12:48 PM, Tero Saarni wrote: > Hi, > > I'm missing gstreamer0.10-plugins-bad-multiverse on Gutsy multiverse > for lpia architecture. Could it be restored or is it removed for a > reason? > > -- > Tero > > -- > 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
Tracking delta between i386 and LPIA arches
Hi, For the Ubuntu Mobile effort we have a new arch - LPIA - that's essentially the same as i386. One of the problems we've run into is that package updates sometimes build for i386 but not LPIA, so the LPIA version of the package is either out of date or missing. Two examples from gutsy: The x264 package built for i386 but FTBFS for LPIA. The freetype1 package got stuck on a dependency wait for LPIA, while the i386 version built fine. We (the folks working on Ubuntu Mobile) would like to make sure this doesn't happen in the future; is there a good way for us to track the delta between i386 and LPIA? I found http://qa.ubuntuwire.com/ftbfs but that doesn't give a concise diff of the two architectures. Any advice would be much appreciated. Thanks, Steve -- 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"
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 way to navigate between screens. * Applications run as a singleton (can't have multiple copies of the app running) * Instant feedback - Any interaction with the UI results in visual/ audio feedback within 200ms, which is the upper limit of what's necessary for the appearance of 'instant'. For a tactile device like a MID, it's important that widgets act like physical objects. Delayed reactions remind the user that they're on a computer. * Applications shouldn't require a mouse cursor for functionality. This means hovering + tooltips are out. * Applications shouldn't require right-clicking for any significant functionality - right-clicking is awkward if the user is holding the device in one hand and using their other hand to navigate (I'd like to see right-click abolished entirely). * Error messages should suggest a course of action to the user. Steve On Oct 25, 2007, at 12:39 PM, 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. > > 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? > > 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
Re: USB Client Status for October 24, 2007
Don, To expand on what Kyle wrote, here is the specific use case we think is most important for USB client support on the MID platform: Use case: * MID is already turned on; plug the MID directly into my PC via USB cable * MID's data (videos, music, photos, etc) are visible in the file manager on my PC. They appear on the PC as either as separate volumes or as directories in a single volume * Using the file manager on the PC, add/remove files on the MID * Unplug the MID from the PC, enjoy the movie I just copied to it It's our understanding that Intel is supporting this case through the file-backed storage gadget. Some questions: 1) Is Intel patching the file-backed storage gadget to expose the client's ext3-formatted filesystem to the host as a FAT filesystem (requiring ext3<-->FAT translation[1])? If not, what is the plan to expose files contained by that FAT image to applications on the MID? 2) Consider the case where I have a MID with 4GB total storage, and I want to copy a 2GB movie to it. How will the file-backed storage gadget handle this situation? The MID doesn't have enough storage for 2 copies of the movie (one in the FAT image and one in the MID's native ext3 filesystem). 3) The blueprint and your status report both mention host-side utilities. Are those utilities required for file sharing, or are they used exclusively for sharing the MID's network connection? 4) The blueprint and your status report both mention Samba for file sharing/transfer. How is Samba relevant to USB Client? When plugged into a PC via USB, will the MID appear as a network share? If so, will it also appear as a FAT device? Why present the user that choice? [1] I think it's possible to implement FAT<-->ext3 translation, so that parts of the MID's filesystem are exposed to the host as one or more FAT volumes even though they're ext3 underneath. The qemu emulator project already has some code that does this - it exposes the host's filesystem to the guest OS as a FAT device. See http:// fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC24 Steve On Oct 24, 2007, at 12:03 PM, Kyle Nitzsche wrote: > Hi, > > Yes, Linux on the MID uses ext3 file system. > > I've chatted with some folks here and my question boils down to use > cases. > > One use case is the MID plugs into the USB Host, say a PC, in order > to copy files to the PC. This is arguably an important use case for a > MID. > > Does your group's work support this? The issue seems to be exposing > the ext3 file system to a device that doesn't understand it. (It > might be possible to do an on-the-fly FAT emulation.) > > An other use case, which may not be quite as important, is letting > the MID see the the PC's file system and copy files onto the MID, > although it is not clear to me if this is USB client functionality. > > cc:ing the list. > > Thanks, > Kyle > > > On Oct 24, 2007, at 11:25 AM, Johnson, Donald K wrote: > >> >> Honestly, I don't know. >> >> Could you give me a description of the failure case? >> Then I can track down somebody who might know and ask them. >> >> My guess is that: >> - Linux on the MID is using ext3 file system >> - An external USB device with a FAT file system is mounted >> - Since I believe Linux can handle FAT file systems just mounting >> the >> FAT >>file system should not be a problem. >> - So I'm guessing the problem is that the device with the FAT file >> system >>is shared, and the problem is with sharing FAT? >> >> Or is it something else entirely? >> >> Don J. >> >>> -Original Message- >>> From: Kyle Nitzsche [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, October 24, 2007 6:51 AM >>> To: Johnson, Donald K >>> Subject: Re: USB Client Status for October 24, 2007 >>> >>> Hi Don, >>> >>> Am I correct in thinking that Samba solves the problem of >>> inconsitency between the MID's ext3 file system with respect to FAT >>> file system device? >>> >>> Many thanks, >>> Kyle Nitzsche >>> >>> On Oct 23, 2007, at 9:08 PM, Johnson, Donald K wrote: >>> USB Client external availability still November 5, 2007 USB Client Features, from internal release note: Drivers: 1) Support USB2.0 spec to enable Poulsbo USB client hardware. 2) Support USB Mass Storage class to expose mass storage device. 3) Support USB CDC-EEM class and RNDIS spec to expose >>> Ethernet device. 4) Support interoperation with both Linux an Windows host PC of VFAT/FAT32 file systems in mass storage device condition. 5) Support interoperation with both Linux and Windows PC with CDC-EEM/RNDIS compatibility. Utilities: 6) Utility automatically start DHCP server to allocate IP >>> addresses in host and client if static IP is not chosen. 7) User can specify directories to share with host through GUI utility. 8) Samba server is automatically started in client utility to share selected folders. 9
Re: Suggestion about interface
Hi Jason, Using icons instead of text for buttons is certainly an option. I went with text because it's clear and creating a meaningful, unambiguous icon can sometimes be difficult (especially given the space constraints in the interface). When I worked at Pepper we had the same discussion about webmail. We found that our users wanted a real email client - though people will use webmail, many prefer a real mail client for a variety of reasons. Reading/composing offline is one; others include immature web clients (though they're getting better), lack of webmail availability, familiarity/comfort with a 'real' mail client, and the ability to check more than one account at the same time with the same interface. Steve On Oct 16, 2007, at 2:17 PM, Cassezza, Jason wrote: > > Agreed. Could even go a step further and make the common "send", > "reply", "forward" etc button just icons vs. spelling it out > (especially > if there's ever a plan to release in other languages). My big > question > is why not just assume people that will use web email (and there is > data > to show that the target Gen-Y user doesn't even use email anymore > BTW). > But with so many services like Gmail, Hotmail, Yahoo mail, etc - is > the > purpose of implementing an actual email client app to satisfy > reading/composing "offline"? > > -jason > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rusty > Lynch > > But... I really like that mock-up. > > --rusty -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Suggestion about interface
Hi Adilson, Definitely keep the buttons! Some devices won't have a stylus, so it's important that the UI of each app be usable with just a finger. Our experience is that even on devices with a stylus, users will often try to use their fingers (and get frustrated if a widget is too small). Something else to note about the buttons in Claws - the tiny triangle buttons next to the Get Mail and Compose buttons are too small for use with a finger, especially on a small screen. That functionality will have to be moved or removed. Steve On Oct 15, 2007, at 7:55 PM, Adilson Oliveira wrote: > Hi. > > In my Q1 claws-mail currently looks like the images attached. As > you can > see, it has the buttons yet. Do you think I should remove them or not? > On a large device like the Q1 it is fine, actually, easier to use but > I'm not sure about smaller screens so I would like your opinions. > > []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
RE: What about a shutdown/hibernate button?
On Sep 20, 2007, at 7:00 AM, "Levinson, Aaron N" wrote: > There are various arguments that can be made for hibernation on > MIDs. I > think there will be some users that use their MIDs irregularly, > perhaps > once or twice per day. If there are, say, 12 hours between uses, then > the standby draw and subsequent need to charge more often might be > considered more inconvenient than hibernating and having to deal > with a > short reboot. One pattern could be that the device sleeps for an hour > of inactivity and then hibernates after this hour has expired. In our experience, consumers (and pundits!) love an instant-on capability. Instant needs to be instant - we found that even a 5sec delay while waking from sleep can be frustrating for users. MIDs are about convenience. A true instant-on capability will make these devices more convenient to people, and therefore more likely to be used. If hibernate can provide that experience then I'm all for it, but my experience with hibernate (mostly on Windows, to be sure) is that it can be frustratingly slow. I'm not an expert on the MID hardware, but our past experience suggests that this class of device should be able to sleep for >1 week on a full charge. For the target market, the convenience of an instant-on capability will greatly outweigh the inconvenience of the slight extra power draw during sleep. The hybrid sleep/hibernate approach is an interesting idea. Apple took it one step further - write an image to disk as if going to hibernate, then they go to sleep. If the battery runs down and sleep can't be maintained, the system wakes from the stored image. The user can always expect to resume to a consistent state, and most of the time resume will happen instantaneously. Steve -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Ubuntu-mobile Digest, Vol 5, Issue 14
On Sep 13, 2007, at 7:00 AM, "Johnson, Charles F" wrote: > - Current Poulsbo 2D driver insisting on EXA 2.2 even though > xserver 1.3 > includes EXA 2.1. So EXA initialization fails. > Possible work around is to have a "psb" specific version of EXA. Hi Charles, There's a patch to allow building against either EXA 2.1 or EXA 2.2: Patch: https://www.moblin.org/bugzilla/attachment.cgi?id=3 Moblin Bug: https://www.moblin.org/bugzilla/show_bug.cgi?id=129 Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg- video-psb/+bug/137346 The patch was incorporated in xserver-xorg-video-psb 0.2.1-1ubuntu3, which was released last week. It doesn't require a psb-specific version of EXA. Steve -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Claws, HTML mail
Hi, Claws is missing a several features that are important for a consumer- oriented mail client: * No HTML rendering by default, and it looks like the dillo/gtkhtml2 plugins aren't scheduled for inclusion * Can't compose HTML/enriched/richtext messages * Limited inline image/attachment support * text/enriched and text/richtext messages are displayed as plaintext Is anyone working on Claws or its plugins to fix these limitations? Steve -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
