RE: A patch for libhildon -- for auto-launch keyboard
Ross Burton wrote: > On Tue, 2007-08-14 at 15:23 +0100, Ross Burton wrote: >> In Poky we start the keyboard in the X session, and install the GTK+ >> input method (part of the matchbox-keyboard source) so that the >> keyboard is toggled as required. The keyboard is toggled via IPC >> between the input method and the keyboard, so you don't need to >> constantly kill and restart it. > > I should say that this approach means that the keyboard automatically > appears/disappears for *every* widget *automatically*, thanks to > using the support GTK+ already has for input methods. It is also the > same model as the Maemo approach, which at present is closed source > (although it is being opened at the moment). > > Ross What is required from the application in order to have the "automatic" behavior? Are the text input fields derived from a different class? What does "being opened at the moment" mean? I heard this a couple of months ago. 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: Using a Gutsy Install CD directly on Menlow-Crown Beach system
Bryce Harrington wrote: > If this is considered an important use case, this might be > something to > work towards for Gutsy+1, but I think it may be too late in the cycle > for Gutsy. > That's what I'm wondering, is there a real demand for this usage scenario? I'm not sure there is enough demand to merit the effort, thus one of the reasons I threw it out on the mailing list. In this particular case, as I mentioned in my previous email, I think we can accommodate the request by creating a custom image using image-creator which uses custom, or additional FSets for the particular need. -RobR -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Using a Gutsy Install CD directly on Menlow-Crown Beach system
On Wed, Aug 15, 2007 at 01:53:08PM -0700, Rhoads, Rob wrote: > Will it ever be possible to take the Gutsy Install CD and use it to > install the full Gutsy directly on a Menlow (e.g. Crown Beach) > platform's hard disk drive? This is a different usage scenario from > using a Menlow image created with moblin image-creator. > > The reason I ask is that I've got an engineer who tried this usage > scenario using the Tribe 4 CD and the install crashed in the middle. > (I'd guess it was because the install CD may not be using the UME kernel > which would cause problem on a Crown Beach.) I think we can accommodate > his needs for installing full Gutsy on a Menlow system with > image-creator, by either providing him with custom FSets (or showing him > how to create them) for creating menlow images which will suite his > needs. But I wanted to pick the collective brain on this type of usage > scenario. Aside from the kernel, there would also be the issue of having the installer detect and set up the -psb X driver. (This is why I was asking about how the xorg.conf is generated when we met last week.) Possibly it would load up the vesa driver, which the installer usually does when it doesn't know what else to do. If this is considered an important use case, this might be something to work towards for Gutsy+1, but I think it may be too late in the cycle for Gutsy. Bryce -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: mockups
On Wednesday 15 August 2007 23:08:24 Spencer, Bob wrote: > Hey Ken, > Been on vacation for 2wks and just catching up. Lucky you! I think my wife is ready to jump on a plane with my son and take a vacation without me this year. > 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: > >>> > >>> > 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 Agreed. I realized that the short time frame would not allow for everything I can draw on a canvas. Getting the system-wide settings decently done and trying, for instance, to make sure that the "settings starter" for each app are in the same place contextually would be a good start (ie. if we end up using menus, it would be in the same place in the same menu for every app). Another point that we would need to work on (probably longer-term as well) is making sure that each app-specific settings pop-up (or whatever) has the same layout, design and are functionaly comparable, etc. -- Ken -- 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: >>> >>> 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.c
Using a Gutsy Install CD directly on Menlow-Crown Beach system
Will it ever be possible to take the Gutsy Install CD and use it to install the full Gutsy directly on a Menlow (e.g. Crown Beach) platform's hard disk drive? This is a different usage scenario from using a Menlow image created with moblin image-creator. The reason I ask is that I've got an engineer who tried this usage scenario using the Tribe 4 CD and the install crashed in the middle. (I'd guess it was because the install CD may not be using the UME kernel which would cause problem on a Crown Beach.) I think we can accommodate his needs for installing full Gutsy on a Menlow system with image-creator, by either providing him with custom FSets (or showing him how to create them) for creating menlow images which will suite his needs. But I wanted to pick the collective brain on this type of usage scenario. +=+=+ Rob Rhoads mailto:[EMAIL PROTECTED] Software Architect Open Source Technology CenterOffice: 503-712-6675 Software Solutions Group mobile: 971-533-2451 Intel Corporation Hillsboro, Oregon USA -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Flash API support in mobile-flash-home-plugin
Ola, >> I have attached the diff as well as the flash movie action script >> source. The Flash movies (*.swf) files will need to be re- >> generated. They are too big to attach. >> > The .swf files I created from the patched .fla were only 60kb. Will try > this new version today. (attached flash_home.swf) This raises an interesting point. I would like to do some tests on the different memory overheads in loading both the Flash UI and one for example written in clutter. []'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
RE: How to call a python plugin in UI
Ola > ping -- were you able to successfully launch your app? > I'd love to see a screenshot of your application running. yes, it launched my app inside the browser using the bash script approach Cathy mentioned. It seems unfortunately not very robust at the moment but I am unsure whether this is to do with the calling mechanism itself or the actual geoclue backend. I will test it again soon as both geoclue [1] and pyphantom [2] are under heavy development. The tutorial and a screenshot (albeit a small one) is in the UME Guide [3]. I put it up on my blog too [4] []'s Ian [1] http://www.freedesktop.org/wiki/Software/GeoClue [2] http://pyphantom.garage.maemo.org/ [3] https://help.ubuntu.com/community/UMEGuide [4] http://ianlawrence.info/random-stuff/location-services-on-ubuntu-mobile -- 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
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 >> > 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: A patch for libhildon -- for auto-launch keyboard
* "Michael Dominic K." | Perhaps I'm not fully getting it, but how is that different than | standard gtk input methods stuff? It's not; I'm slowly beginning to understand how those bits fit together now. :-) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: A patch for libhildon -- for auto-launch keyboard
On Wed, 2007-08-15 at 17:35 +0800, Han, Jian wrote: > Hi, > You may try the matchbox-keyboard on moblin.org. > I have done some job on make matchbox-keyboard look pretty. > Waiting for your feedback^_^ > It would be good to see patches for this upstream. From the look of the shots Im guessing you've hacked the cairo backend ? And hopefully you've done that in a theme-able way rather than hard coding the look ? -- Matthew -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: A patch for libhildon -- for auto-launch keyboard
Hi; On Wed, 2007-08-15 at 09:37 +0200, Tollef Fog Heen wrote: > > Only problem is the keyboard ends up consuming quite a lot of screen > real estate, see http://err.no/tmp/DSC_5932.2.JPG for a picture. (The > resolution on that device is 1024x600.) > > I think we could manage to shave off a complete row of keys by > reducing the size of Home/PgUp/End/PgDn (or get rid of them > completely) and making a numpad there. > > Getting rid of the arrow keys also seems sensible - you have a touch > screen, which is much, much faster to use than using arrows. > Its basically just a case of creating a custom layout file, see the README in the matchbox-keyboard source. If this is not enough then it means tweaking the layout algorithm which is (though I've tried to make it generic) maybe a little preferred to smaller displays. As Ross mentions, the openmoko guys are known to be working on a number of improvements to matchbox-keyboard key to which is a proper themeing engine. See this thread; http://lists.o-hand.com/matchbox/0117.html and perhaps http://lists.o-hand.com/matchbox/0128.html . Another thing worth mentioning is hildon uses input windows in a slightly more complex way than a default matchbox wm build. I.e they build with --enable-alt-input-windows which essentially expects the input window to set it transiency to the window its inputing for. This is so matchbox knows if the target window is a dialog or an application window and then it behaves differently - for example an application window wont be resized (the keyboard is overlaid) and the resizing/repositioning of a dialog is also different. For this to work it needs support from both applications and the input window itself - and matchbox-keyboard does not currently do this. I do not 100% understand how its handled by the hildon input method infrastructure nor applications. A default matchbox build will just resize app and dialog windows (just as if the input window is a panel). Hope that all helps; -- Matthew -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: A patch for libhildon -- for auto-launch keyboard
On Wed, 2007-08-15 at 09:37 +0200, Tollef Fog Heen wrote: > This looks great; I have a test package, based off current SVN, > working here which I'll proceed to upload. Any take on whether I > should enable the panel applet as well? The panel applet is only really useful for non-GTK+ applications. I wrote it because in Poky we used to have rxvt as a terminal, but now I've written a vte based terminal it isn't required any more. I suggest you package it, but don't install it by default. > Only problem is the keyboard ends up consuming quite a lot of screen > real estate, see http://err.no/tmp/DSC_5932.2.JPG for a picture. (The > resolution on that device is 1024x600.) > > I think we could manage to shave off a complete row of keys by > reducing the size of Home/PgUp/End/PgDn (or get rid of them > completely) and making a numpad there. > > Getting rid of the arrow keys also seems sensible - you have a touch > screen, which is much, much faster to use than using arrows. Sounds reasonable to me. The OpenMoko people are also hacking on Matchbox Keyboard, which you might find interesting (see the matchbox list). I'll also ping Matthew, he might have some good ideas for compacting the layout. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: A patch for libhildon -- for auto-launch keyboard
* Ross Burton | In Poky we start the keyboard in the X session, and install the GTK+ | input method (part of the matchbox-keyboard source) so that the keyboard | is toggled as required. The keyboard is toggled via IPC between the | input method and the keyboard, so you don't need to constantly kill and | restart it. This looks great; I have a test package, based off current SVN, working here which I'll proceed to upload. Any take on whether I should enable the panel applet as well? Only problem is the keyboard ends up consuming quite a lot of screen real estate, see http://err.no/tmp/DSC_5932.2.JPG for a picture. (The resolution on that device is 1024x600.) I think we could manage to shave off a complete row of keys by reducing the size of Home/PgUp/End/PgDn (or get rid of them completely) and making a numpad there. Getting rid of the arrow keys also seems sensible - you have a touch screen, which is much, much faster to use than using arrows. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
