Re: Installation report for UNR 20090324 on Acer Aspire One
Anmar Oueja wrote: Hello Matt: Thanks for the evaluation. Please see my response in-line. On Tue, Mar 24, 2009 at 6:59 AM, Matt Zimmerman m...@ubuntu.com wrote: Is the netbook-remix project an appropriate place to file UNR bugs, or should they always be filed on Ubuntu packages instead? Both? Please file bugs in the Ubuntu project and tag them with ubuntu-unr tag. It's probably best to file directly in the Ubuntu project as Anmar suggested. But the netbook-remix LP project (or the unr superproject) is certainly appropriate as well for filing bugs. Many community users of unr file bugs here for the Hardy based versions of unr released by the OEM team, and many still do for the Jaunty version. It has acted as the upstream bug tracker for unr. Going forward it's important to make sure appropriate bugs entered in the unr LP project get marked Also effects distribution - Ubuntu so that the distro team knows about them. Bill Cheers -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Hildon 2.0 tasks on Ubuntu wiki
Per today's IRC meeting, I moved the Hildon 2.0 task list to the Ubuntu wiki at: https://wiki.ubuntu.com/MobileAndEmbedded/Hildon2.0 Tollef to make assignments.. Bill-- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Hildon 2.0 Release
We are very close to v2.0 already and I don't think the merge will be too bad. I haven't seen any new features that would be too significant, and moving to 2.0 would be a good idea. Bill On Jan 17, 2008, at 1:22 PM, Spencer, Bob wrote: 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 -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Moblin-applets status
The spec has been updated with topics from today's discussion at UDS. See the Issues section at http://wiki.ubuntu.com/MobileAndEmbedded/ Utilities On Nov 1, 2007, at 10:57 AM, Brandt, Todd E wrote: Very short update: Held a review of the moblin-applets feature set through the moblin mailing list and the overwhelming response was that we have way more features than we need. Thus, this week I've been chopping the applets down to the bare minimum of features for use on a mobile device. Also am working on the creation of a ventral libmoblin-dev and libmoblin runtime library that applications and applets can use to get the up-to-date list of all the gconf keys and their settings that we use, and am working to add in macros for icon and desktop theme functions that mirror their gtk equivalents. - | Todd Brandt - Intel Oregon | |Linux for Mobile Internet Devices (MID)| | 2111 W NE 25th Ave| |Hillsboro, OR 97124 JF1-235| |---| | Of all the things I've lost, I miss | |my mind the most - Mark Twain | - -- 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: Suggestion about interface
I like the buttons, but worry about them taking up too much screen real estate. We should definitely test on a 800x480 res screen and see how usable the application is. Maybe a good compromise would be to size the buttons to the minimal size needed by the average finger so they are not bigger than they need to be. Also, maybe some of the non-critical buttons can be removed as it feels kind of cramped horizontally right now. 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. claws_q1-1.JPG claws_q1-2.jpg -- 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: 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. Sure, I can post a description of my proposed changes on the hildon mailing list and see what they think. 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). Are you referring to opening a bug in Launchpad to discuss this, or in upstream's bugzilla? -- 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
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? 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
Re: Moblin and Gnome
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. I would think (hope) in the case of GNOME, they would be very interested in the hildonized mobile ui for some of their components, as they have commited to support GNOME Mobile http:// www.gnome.org/mobile/. That project looks like it's still very early stage, but we should certainly coordinate with them as it sounds like it's inline with our vision. 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 I agree. Maybe you guys could post on the GNOME mobile list (mobile- [EMAIL PROTECTED]) to propose some of these ideas. -- 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=id Category= ? MobileOrder=index (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 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=id Category= ? MobileOrder=index (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
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
