Re: What about a shutdown/hibernate button?
On 9/19/07, Adilson Oliveira <[EMAIL PROTECTED]> wrote: > I believe the idea is to keep the devices on, hibernating when not in > use, but to have some way of forcing the this behavior and power down > the device is not a bad idea either I guess. Why? The user shouldn't have to care. If she stops using the device, it should suspend (to RAM) and after a timeout, automatically hibernate (if supported). Press the power button and we are back in action. And for those long trips, where you really want to switch it off, use the power button. /Amit -- 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 Wed, Sep 19, 2007 at 12:03:15PM -0700, Levinson, Aaron N wrote: > There are various arguments that can be made for hibernation on MIDs. The strongest argument against is that the existing implementation of hibernation on Linux is riddled with design flaws. While it works much of the time, I wouldn't recommend it be part of the required functionality of a product. -- 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
Re: Run-time keyboard issue encountered while porting maemo VNC viewer to MIDs (mostly solved)
Levinson, Aaron N escreveu: > It appears that the problem stems from having a VNC viewer connected to > the display. When I encountered the problem, I was accessing my desktop > via a VNC viewer. This was the cause of the KeyPress/KeyRelease pairs, > and when I hold down a key on the actual keyboard connected to the > desktop without a VNC viewer connected, I am seeing the behavior that I > expect. If a VNC viewer is connected to the display (that is, x11vnc is > running on :0), the problem also occurs even if a key is pressed on the > actual keyboard connected to the desktop. Once the remote VNC viewer is > disconnected, the problem goes away, and it will start up again when a > remote VNC viewer is reconnected. This latter part seems pretty odd, > but perhaps the VNC server (x11vnc) is doing something to alter the > behavior of the X server when a VNC viewer is connected. Aaron, It's a long shot but maybe you could try to find some clues here: http://www.nomachine.com/sources.php I used to work for this company long time ago, exactly handling foreign protocols loke VNC and RDP and I don't recall to have done anything about this on VNC code but if the problem is there, this surely was handled by NX in some way. []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: Run-time keyboard issue encountered while porting maemo VNC viewer to MIDs (mostly solved)
It appears that the problem stems from having a VNC viewer connected to
the display. When I encountered the problem, I was accessing my desktop
via a VNC viewer. This was the cause of the KeyPress/KeyRelease pairs,
and when I hold down a key on the actual keyboard connected to the
desktop without a VNC viewer connected, I am seeing the behavior that I
expect. If a VNC viewer is connected to the display (that is, x11vnc is
running on :0), the problem also occurs even if a key is pressed on the
actual keyboard connected to the desktop. Once the remote VNC viewer is
disconnected, the problem goes away, and it will start up again when a
remote VNC viewer is reconnected. This latter part seems pretty odd,
but perhaps the VNC server (x11vnc) is doing something to alter the
behavior of the X server when a VNC viewer is connected.
Aaron Levinson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Levinson,
Aaron N
Sent: Tuesday, September 18, 2007 11:04 AM
To: ubuntu-mobile@lists.ubuntu.com
Subject: Run-time keyboard issue encountered while porting maemo VNC
viewer toMIDs
I've been working on porting the maemo VNC viewer application (at
https://garage.maemo.org/projects/vncviewer/ ) for use on MIDs, and I've
run up against a run-time issue with the keyboard auto-repeat capability
in the X server, and I was hoping that someone on this list might be
able to further diagnose the cause of the problem.
One of the features of the VNC viewer is to scroll the main window by
holding down the hardware direction keys, a feature that also exists in
the Opera port for the Nokia Internet tablets. For example, by holding
down the Down button, instead of sending successive down key presses to
the VNC server, it scrolls down the local VNC viewer window, thereby
scrolling the display. This feature utilizes the following behavior:
when a hardware key is held down, the GTK Widget is signaled with repeat
key press signals until the hardware key is released, at which point the
GTK widget is signaled with a single key release signal. The signals at
the GTK Widget layer come from the GDK layer, which has setup an X event
handler. When the X event handler gets the KeyPress or KeyRelease
events, it translates these into the GDK_KEY_PRESS or GDK_KEY_RELEASE
GDK events, respectively, and these are later translated into the
appropriate signals by the GTKWidget class.
Unfortunately, instead of getting repeated KeyPress X events and a final
KeyRelease event, I am seeing KeyPress/KeyRelease event pairs when a
hardware key is held down. I investigated this problem further, and it
appears to be caused by the X server, which I think is demonstrated by
an examination of the relevant GDK code.
The KeyRelease X event handler is implemented in gdkevents-xll.c as
follows:
case KeyRelease:
if (window_private == NULL)
{
return_val = FALSE;
break;
}
/* Emulate detectable auto-repeat by checking to see
* if the next event is a key press with the same
* keycode and timestamp, and if so, ignoring the event.
*/
if (!display_x11->have_xkb_autorepeat && XPending
(xevent->xkey.display))
{
XEvent next_event;
XPeekEvent (xevent->xkey.display, &next_event);
if (next_event.type == KeyPress &&
next_event.xkey.keycode == xevent->xkey.keycode &&
next_event.xkey.time == xevent->xkey.time)
{
return_val = FALSE;
break;
}
}
translate_key_event (display, event, xevent);
break;
I debugged through the code (by building GTK with debugging), and it
turns out that display_x11->have_xkb_autorepeat is 1, so it never gets
into the if statement block. display_x11->have_xkb_autorepeat is set in
gdkdisplay_x11.c, as follows:
XkbSetDetectableAutoRepeat (display_x11->xdisplay,
True,
&detectable_autorepeat_supported);
GDK_NOTE (MISC, g_message ("Detectable autorepeat %s.",
detectable_autorepeat_supported ?
"supported" : "not supported"));
display_x11->have_xkb_autorepeat =
detectable_autorepeat_supported;
The interesting part here is the XkbSetDetectableAutoRepeat function.
The man page for XkbSetDetectableAutoRepeat states the following:
"Auto-repeat is the generation of multiple key events by a keyboard when
the user presses a key and holds it down. Keyboard hardware and
device-dependent X server software often implement auto-repeat by
generating multiple KeyPress events with no intervening KeyRelease
event. The standard behavior of the X server is to generate a KeyRelease
event for every KeyPress event. If the keyboard hardware and
device-dependent software of the X server implement auto-repeat by
generating multiple KeyPress events, the device-independe
Re: UME menlow_full Daily Breakage Update?
Canonical made a lot of info public (not that it wasn't already!) about building UME today. Its all published on the IDF content site if anyones interested. https://intel.wingateweb.com/us/catalog/catalog/catalog.jsp (scroll down to the bottom for the Ultra Mobile presentations.) Expect a new crowd of interested Q1 Ultra owners soon! Keep up the great work! Steve On 9/19/07, Colin Watson <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 19, 2007 at 08:51:01AM -0700, Charles Johnson wrote: > > I'm seeing no difference in the 20070919 menlow_full daily build. > > Did the kernel update occur ? > > > http://people.ubuntu.com/~ubuntu-archive/moblin-build-logs/gutsy/menlow_full/ > indicates that the daily builds aren't happening. Tollef would be the > best person to chase that down. > > If you're talking about the unionfs bug, though, this is still under > investigation; upstream don't have a fix either so we're trying to come > up with one ourselves. This is also blocking the Ubuntu desktop CDs so > it is a very high priority indeed. > > -- > Colin Watson [EMAIL PROTECTED] > > -- > Ubuntu-mobile mailing list > Ubuntu-mobile@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile > -- Steve Paine Carrypad - Promoting UMPCs through UMPCportal.com Bonn, Germany. -- 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?
>-Original Message- >From: [EMAIL PROTECTED] [mailto:ubuntu-mobile- >[EMAIL PROTECTED] On Behalf Of Matt Zimmerman > >On Wed, Sep 19, 2007 at 11:20:49AM -0700, Levinson, Aaron N wrote: >> Hibernate would be great, but I'm not aware of hibernate functionality >> on Linux, only on Windows. Is hibernation planned for MIDs? > >What's unclear is whether the power and usage profiles of these devices >require hibernation: if standby draw is low enough, it shouldn't be >necessary. 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. Plus, there are green (environmental) implications to sleep vs. hibernate. More and more consumers are assigning a higher priority to green and energy-saving options when they purchase new products. Hibernation is a greener option than sleep, and if shutdown/hibernation are handled properly in hardware, there might be little or no power draw when the device is off. Aaron Levinson -- 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 Wed, Sep 19, 2007 at 11:20:49AM -0700, Levinson, Aaron N wrote: > Hibernate would be great, but I'm not aware of hibernate functionality > on Linux, only on Windows. Is hibernation planned for MIDs? In Ubuntu, we use Linux swsusp (software suspend) to provide hibernate functionality. This relies on a swap partition which can be detected and accessed from early userspace (initramfs), but I see no reason why it would not be possible to apply to MIDs. What's unclear is whether the power and usage profiles of these devices require hibernation: if standby draw is low enough, it shouldn't be necessary. -- - mdz -- 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?
Levinson, Aaron N escreveu: > Based on how people are using the Nokia Internet tablets, many of them > let the device go to sleep rather than shutting it down. It takes some > time to power-up and reboot the device, so for many users, it is > preferable to let the device go to sleep, even if it is a light sleep > that is drawing from the battery. On the Nokia Internet tablets, there > is a special hardware button that pops up a menu that provides various > options, such as locking the device, putting it into "airplane" mode > (Bluetooth and wireless are disabled), and shutting down the device. > This might also be a reasonable approach for MIDs. This button is also > used to turn the device on (after being shutdown), and holding the > button down for several seconds will cause the device to instantly > shutdown, which is useful in case of a freeze. That's the kind of approach I was thinking (I have a N770 myself) and I agree that's the expected behavior of the user. > > Hibernate would be great, but I'm not aware of hibernate functionality > on Linux, only on Windows. Is hibernation planned for MIDs? > I'm not aware about the power management specs from the top of my head but I believe so. []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: What about a shutdown/hibernate button?
Based on how people are using the Nokia Internet tablets, many of them let the device go to sleep rather than shutting it down. It takes some time to power-up and reboot the device, so for many users, it is preferable to let the device go to sleep, even if it is a light sleep that is drawing from the battery. On the Nokia Internet tablets, there is a special hardware button that pops up a menu that provides various options, such as locking the device, putting it into "airplane" mode (Bluetooth and wireless are disabled), and shutting down the device. This might also be a reasonable approach for MIDs. This button is also used to turn the device on (after being shutdown), and holding the button down for several seconds will cause the device to instantly shutdown, which is useful in case of a freeze. Hibernate would be great, but I'm not aware of hibernate functionality on Linux, only on Windows. Is hibernation planned for MIDs? Aaron Levinson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adilson Oliveira Sent: Wednesday, September 19, 2007 9:54 AM To: ubuntu-mobile@lists.ubuntu.com Subject: What about a shutdown/hibernate button? I believe the idea is to keep the devices on, hibernating when not in use, but to have some way of forcing the this behavior and power down the device is not a bad idea either I guess. []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: home plugin and marquee plugin action items
Ian wrote: > Ola, > >> I think we had talked about using the "Category" field as well > In the context of maemo, Categories field refers to the Status Bar > and it has three values...permanent, conditional and temporal. > Permanent plugins are shown well, permanently I guess. Conditional > and temporal plugins are shown only when some condition is met. > > https://stage.maemo.org/svn/maemo/projects/haf/branches/maemo-af-desktop /restart/hildon-status-bar/hildon-status-bar-main.h > > >> but aside from an XPCOM extension that provided a javascript method >> to C code, > > Just a request.If this method is chosen that it also includes the > ability to do a: > > from xpcom import components > > With the PyXPCOM binding we can write application code in Python, > compile it in XPCOM and make it available like a C++ component in the > app framework. > Note taken. >> Top-left icon will be updated and will take you home. No drop-down >> menu. > So in this case Hildonize Step 2 in the tutorial > https://help.ubuntu.com/community/UMEGuide/ApplicationDevelopment/Portin gAnAppToUME > will no longer be necessary?. > No, there are two drop-down menus in the top-left corner. We are discussing the far-top-left menu, not the application-specific drop-down menu that drops down when you click the window title. This will still exist. 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
Re: UME menlow_full Daily Breakage Update?
On Wed, Sep 19, 2007 at 08:51:01AM -0700, Charles Johnson wrote: > I'm seeing no difference in the 20070919 menlow_full daily build. > Did the kernel update occur ? http://people.ubuntu.com/~ubuntu-archive/moblin-build-logs/gutsy/menlow_full/ indicates that the daily builds aren't happening. Tollef would be the best person to chase that down. If you're talking about the unionfs bug, though, this is still under investigation; upstream don't have a fix either so we're trying to come up with one ourselves. This is also blocking the Ubuntu desktop CDs so it is a very high priority indeed. -- Colin Watson [EMAIL PROTECTED] -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
What about a shutdown/hibernate button?
I believe the idea is to keep the devices on, hibernating when not in use, but to have some way of forcing the this behavior and power down the device is not a bad idea either I guess. []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: UME menlow_full Daily Breakage Update?
Charles Johnson escreveu: > Guys - We are having potential customers ask us for demos of the latest > builds of UME. While I realize that daily builds are untested and may > be broken, my concern here is that they stay broken for so long. Can't you use the image-creator? []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: UME menlow_full Daily Breakage Update?
Guys - We are having potential customers ask us for demos of the latest builds of UME. While I realize that daily builds are untested and may be broken, my concern here is that they stay broken for so long. --Charlie On 9/19/07, Adilson Oliveira <[EMAIL PROTECTED]> wrote: > > Charles Johnson escreveu: > > Can we raise the priority of this ?? The daily build has been broken > > for as least a week. > > Hi. > > I can't do much directly but I'll poke around and make sure Tollef is > aware of that. > > []s > > Adilson. > -- Charles Johnson Intel Corporation, Inc. [EMAIL PROTECTED] [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: UME menlow_full Daily Breakage Update?
Charles Johnson escreveu: > Can we raise the priority of this ?? The daily build has been broken > for as least a week. Hi. I can't do much directly but I'll poke around and make sure Tollef is aware of that. []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: UME menlow_full Daily Breakage Update?
Can we raise the priority of this ?? The daily build has been broken for as least a week. --Charlie On 9/19/07, Charles Johnson <[EMAIL PROTECTED]> wrote: > > I'm seeing no difference in the 20070919 menlow_full daily build. > Did the kernel update occur ? > > --Charlie > > On 9/15/07, Amit Kucheria < [EMAIL PROTECTED]> wrote: > > > > A fix has been reportedly found and pushed to the tree. It should be > > fixed on Monday. I will keep you posted. > > > > Regards, > > Amit > > > > On 9/15/07, Johnson, Charles F <[EMAIL PROTECTED]> wrote: > > > Can someone give me an update on the problem with the daily build of > > > menlow_full not installing ?? When do we expect a fix ? > > > > > > Charles Johnson > > > Ultra-Mobility Group > > > Platform Software Engineering > > > Intel Corporation > > > [EMAIL PROTECTED] > > > > > > -- > > > 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 > > > > > > -- > Charles Johnson > Intel Corporation, Inc. > [EMAIL PROTECTED] > [EMAIL PROTECTED] -- Charles Johnson Intel Corporation, Inc. [EMAIL PROTECTED] [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: UME menlow_full Daily Breakage Update?
I'm seeing no difference in the 20070919 menlow_full daily build. Did the kernel update occur ? --Charlie On 9/15/07, Amit Kucheria <[EMAIL PROTECTED]> wrote: > > A fix has been reportedly found and pushed to the tree. It should be > fixed on Monday. I will keep you posted. > > Regards, > Amit > > On 9/15/07, Johnson, Charles F <[EMAIL PROTECTED]> wrote: > > Can someone give me an update on the problem with the daily build of > > menlow_full not installing ?? When do we expect a fix ? > > > > Charles Johnson > > Ultra-Mobility Group > > Platform Software Engineering > > Intel Corporation > > [EMAIL PROTECTED] > > > > -- > > 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 > -- Charles Johnson Intel Corporation, Inc. [EMAIL PROTECTED] [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: home plugin and marquee plugin action items
Ola, > I think we had talked about using the "Category" field as well In the context of maemo, Categories field refers to the Status Bar and it has three values...permanent, conditional and temporal. Permanent plugins are shown well, permanently I guess. Conditional and temporal plugins are shown only when some condition is met. https://stage.maemo.org/svn/maemo/projects/haf/branches/maemo-af-desktop/restart/hildon-status-bar/hildon-status-bar-main.h > but aside from an XPCOM extension that provided a javascript > method to C code, Just a request.If this method is chosen that it also includes the ability to do a: from xpcom import components With the PyXPCOM binding we can write application code in Python, compile it in XPCOM and make it available like a C++ component in the app framework. > Top-left icon will be updated and will take you home. No drop-down > menu. So in this case Hildonize Step 2 in the tutorial https://help.ubuntu.com/community/UMEGuide/ApplicationDevelopment/PortingAnAppToUME will no longer be necessary?. []'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: home plugin and marquee plugin action items
> > On Sep 19, 2007, at 7:11 AM, Tollef Fog Heen wrote: > >> * Bill Filler >> >> | > I like getting rid of the duplicate .desktop files. >> | > How about just adding a "MobileId=" field to the >> | > /usr/share/applications/ >> | > (and not a new section) >> | >> | Works for me. So the logic would be if a "MobileId" field >> existed, the >> | app would be added to the UI? >> >> Any reason not to use the already existing OnlyShowIn/DontShowIn >> fields? > > I wasn't aware of those fields and that could work, but we still > need an ID field, which is the key used to look up the application > to launch. If there was an existing ID field in the .desktop file, > we could simply use that and then use the OnlyShowIn field to > control whether it showed up in the mobile ui. Maybe the following > could work: > > ApplicationId=some unique id - This field is the unique id for the > app and used as lookup key for the app from the ui > OnlyShowIn=Mobile - This field controls whether or not the app is > shown in the mobile ui > -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
IRC meeting tomorrow
Good morning I would like to remind you that tomorrow, at 1600 UTC we are going to have our weekly meeting. Please, remember to send your reports with your spec status ASAP so we can program our agenda. Best regards Adilson. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Small change on the games list
Hi. I've changed the gnome-sodoku for gnudoku because gnome-sudoku is a part of a big package called gnome-games and would be complicated to separate just this one or have the whole package hildonized right now and both provide the same net result. []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: home plugin and marquee plugin action items
> > I like this but I want it to go away as soon as the application window > is displayed, which requires yet another notification to be sent or > something. Apps such as calc and notepad currently show the banner > you > mention but it sits there for 3-5 seconds, long after the app started > and even after closing it :) > I believe I have it implemented the way you are describing. The home plugin puts up the banner prior to execing the app, then listens for notifcation from the hd-wm for either a "entry_info_added" signal or "entry_info_stack_change" which get fired when the application gets displayed, at which point the banner gets torn down. The banner that you are describing in calc and notepad are different and I think they are controlled by the "StartupNotify" (true/false) setting in the desktop file (not sure about this). They seem fairly useless as the app is running already. > > >> >> I need to generalize all of my changes to the home plugin (as there >> are some customer specific things that wouldn't be appropriate to >> moblin) and then I plan to send you guys a patch for possible >> inclusion. I'm hoping to have this done by the end of the week. I >> should probably first merge with your latest changes, so just let me >> know when you commit them. >> > > OK, but we like these goodies too. > I might need to ping you for some git help. I git cloned mobile-basic- flash and commited my changes locally. At this point I just want to do a diff between my tree and your stuff without merging, but not sure of the command. > > OK. .desktop files in /usr/share/applications should include > MobileId= > Category= ? > MobileOrder= (optional) > If "MobileId" is not present, the application is not displayed in the > home screen > If MobileOrder is not included, then the home screen determines the > order > Sounds good. > Category should be mandatory. Is "Category" the right field? > Actually I think it's "Categories" based on some of the .desktop files that I have looked at. > OK. It would be nice to give the user a few options wrt marquee > contents: > - functionality of top-left icon: home, apps, running apps, > none (if hardware has home button) > > That would be very cool, even if was just a configuration setting that had to be manually set to start. > Bill -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: home plugin and marquee plugin action items
These are Bob Spencer's comments: >> Rusty found a few things applications need to do and should send out >> >> this info.) Mainly applications are responsible for putting themselves to the top. So there are 4 things I know of: - X-osso entry in .desktop file - call osso_initialize() at start of program - have a service file - listen for notificaiton to put itself to the top of window stack Rusty said he had some code for the calc that would show us the light. > Agreed that the status line is a hack but will do for October. > > OK, closed for now. TBD: >> I added a couple of new methods: >> launchAppFromId (id) >> launchAppFromPath (full-path-to-app) >> The exising should be deprecated (but is still there): >> launchApp(index) >> >> These are already checked in, along with the change for apps w/id > 10 > One other "feature" I added that might be of interest is a banner > that gets displayed when the app is launched and gets torn down once > the app is fully visible. Some apps take a long time to launch and > this was intended to give the user feedback that something is > happening. It uses the hildon-banner-show-animation() method to > accomplish this. > > I like this but I want it to go away as soon as the application window is displayed, which requires yet another notification to be sent or something. Apps such as calc and notepad currently show the banner you mention but it sits there for 3-5 seconds, long after the app started and even after closing it :) >>> - Eliminate the need to have .desktop files in /usr/share/mobile- >>> basic-flash/applications. ... >>> >>> OK. .desktop files in /usr/share/applications should include MobileId= Category= ? MobileOrder= (optional) If "MobileId" is not present, the application is not displayed in the home screen If MobileOrder is not included, then the home screen determines the order Category should be mandatory. Is "Category" the right field? >>> Marquee Panel: >>> >>> > I think that would be an improvement. Our customer, for whatever > reason (probably habit), still wants the drop-down menu with the > extras menu, but we will enable this functionality only for them. > The key thing here is getting the .service file stuff working so that > you can get back to the instance of your running app from the home > screen. > > OK. It would be nice to give the user a few options wrt marquee contents: - functionality of top-left icon: home, apps, running apps, none (if hardware has home button) Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: home plugin and marquee plugin action items
> > I think that passing information on the status line is a little bit > of a hack, but aside from an XPCOM extension that provided a > javascript > method to C code, it is good enough for now and seems to be > getting the job done. I tried launching apps with parameters and it > worked fine. So for now and October release let's stick to the way it > works now > and we can readdress this later. > Agreed that the status line is a hack but will do for October. Another longer term solution that we were thinking of would be to modify gtkmozembed to add a new signal that the home plugin could listen for instead of the js_status signal, but this would require maintaining mods to gtkmozeembed which might not be ideal. Another possible solution we kicked around was to use a DOMListener in the home plugin and have the html/javascript modify the DOM in a way that would cause the listener to be triggered. I think this could actually work quite nicely without mods to gtkmozembed, but would take a bit of work to get it right. > > Suggestions welcome. I tested that the existing index version still > works and uses launchAppFromId(id) but I didn't try the other yet. > This looks good. Another scenario we needed to solve was launching a control panel plugin from the Flash movie (the movie wants to directly launch Network Config, Bluetooth Config, etc..). I added a launchPlugin(pluginName) method to the javascript and home-plugin. The impl uses osso to launch the plugin and it works pretty well. One other "feature" I added that might be of interest is a banner that gets displayed when the app is launched and gets torn down once the app is fully visible. Some apps take a long time to launch and this was intended to give the user feedback that something is happening. It uses the hildon-banner-show-animation() method to accomplish this. I need to generalize all of my changes to the home plugin (as there are some customer specific things that wouldn't be appropriate to moblin) and then I plan to send you guys a patch for possible inclusion. I'm hoping to have this done by the end of the week. I should probably first merge with your latest changes, so just let me know when you commit them. > > I like getting rid of the duplicate .desktop files. > How about just adding a "MobileId=" field to the > /usr/share/applications/ > (and not a new section) > Works for me. So the logic would be if a "MobileId" field existed, the app would be added to the UI? > > I'm not sure how to handle sorting of the applications wrt > configuration. > A few options include: no sorting in the UI, adding "MobileOrder=<>", > or other. > I think we had talked about using the "Category" field as well (looks like the hildon control panel code uses this scheme). This could give us a grouping mechansim. Maybe the rule could be the UI groups by category and sorts based on name within the category. Sorting/ Grouping code code be borrowed from the hildon-control-panel package perhaps as it's implemented this way. > > >> - Bob, I believe you were compiling a list (a couple of IRC meetings >> ago) of home-plugin features that would be common to both Flash and >> non-Flash home-plugins. I don't have this list or a transcript of the >> meeting, do you? >> > > I didn't find it, but I'll look more. > I think it was on 8.30.2007 on the ubuntu-mobile list but I can't find a transcript either.. > > >> >> Marquee Panel: >> - What are your plans regarding navigating from an application back >> to the home screen? Currently there is no way to do this. >> >> > Top-left icon will be updated and will take you home. No drop-down > menu. Comments welcome here. > No left/right app nav. > I think that would be an improvement. Our customer, for whatever reason (probably habit), still wants the drop-down menu with the extras menu, but we will enable this functionality only for them. The key thing here is getting the .service file stuff working so that you can get back to the instance of your running app from the home screen. The main thing I find useful in the maemo ui is the task manager (drop down that shows the list of running apps) because it makes it easy to see what is active and to get back to it. One idea might be to make the top-left icon a drop down again, but this time it would be the task manager. The first item in the drop down would always be the "Home" so there is an easy way to get home. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
home plugin and marquee plugin action items
These are Bob's reply to my initial query, originally done through email but posting now for general discussion.. > Bob and Rusty, > I wanted to follow up on the action items that were assigned to us > from last weeks UME Status meeting. I think the following issues need > to be resolved with regards to the home plugin and marquee panels and > would like to know your thoughts. > > Home Plugin: > - Agree on and merge changes from Pepper to support a generic event > mechansim to pass data to and from Flash based home plugin. These > changes are specified in document I sent to you a few weeks ago. We > are have implemented some of it already, but it is not yet complete. > We should discuss what needs to change in the design. > I think that passing information on the status line is a little bit of a hack, but aside from an XPCOM extension that provided a javascript method to C code, it is good enough for now and seems to be getting the job done. I tried launching apps with parameters and it worked fine. So for now and October release let's stick to the way it works now and we can readdress this later. Our HTML version of the UI will also use this same mechanism to get the application list and launch apps. > > One thing in particular that I think needs to be addressed is the > start_app() function. The way it's currently implemented in Moblin, > you need to pass it the index of the app. The only way for the Flash > movie to know the index is if the app is dynamcially added to the > Flash movie via the add_application function. This is a problem for > Flash movies that don't support dynamic apps. The customer we are > working with has a predefined set of apps that are not dynamically > added to the movie. The movie needs to be able to launch an app based > on a name, path, or id because it won't have an index. > Could we add a start_app() that takes an applicationId as the > argument? > I added a couple of new methods: launchAppFromId (id) launchAppFromPath (full-path-to-app) The exising should be deprecated (but is still there): launchApp(index) Suggestions welcome. I tested that the existing index version still works and uses launchAppFromId(id) but I didn't try the other yet. > The applicationId would be a unique identifier for the app > and would need to be defined in the .desktop file. I'm not sure if > there is already some sort of identifier attribute in the .desktop > file that we could use. I think this would be a better solution than > using an index. > > - Eliminate the need to have .desktop files in /usr/share/mobile- > basic-flash/applications. Instead, couldn't we use the standard > desktop files in /usr/share/applications and simply add a [Mobile > Desktop] entry in these? Seems like a more standard way to go and > would eliminate having two copies as currently required for the osso > activation stuff (see bug #106 https://www.moblin.org/bugzilla/ > show_bug.cgi?id=106). > > I like getting rid of the duplicate .desktop files. How about just adding a "MobileId=" field to the /usr/share/applications/ (and not a new section) I'm not sure how to handle sorting of the applications wrt configuration. A few options include: no sorting in the UI, adding "MobileOrder=<>", or other. > - Bob, I believe you were compiling a list (a couple of IRC meetings > ago) of home-plugin features that would be common to both Flash and > non-Flash home-plugins. I don't have this list or a transcript of the > meeting, do you? > I didn't find it, but I'll look more. > > Marquee Panel: > - What are your plans regarding navigating from an application back > to the home screen? Currently there is no way to do this. > > Top-left icon will be updated and will take you home. No drop-down menu. Comments welcome here. No left/right app nav. > - There was some discussion on the mailing lists about enabling the > default maemo layout for the UI. What is the status of this? > I haven't looked into that, but it could be possible. It would take some amount of configuration work as we change a few things that prevent the window decorations from matchbox from being displayed in lieu of the marquee. Bob -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
