Re: [MeeGo-dev] MNotification can't show notification
On 06/23/2011 09:43 AM, Andy Ross wrote: On 06/23/2011 12:55 AM, Liu, Wei Zhi wrote: $dbus-send –print-reply –dest=com.meego.core.MNotificationManager /notificationmanager com.meego.core.MNotificationManager.addNotification uint32:0 uint32:0 string:’test’ Is "test" a valid notification type? Try the longer form of addNotification which allows you to specify message strings. I'm guessing this is the "type" entry? If so then using some arbitrary value will just result in our display of the notification falling back to a default layout. You should be able to use a type "we-dont-need-no-stinken-type" and the notification will still work, but with a default layout using a generic icon. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MNotification can't show notification
On 06/23/2011 12:55 AM, Liu, Wei Zhi wrote: Hi, I am trying to show some warning info via sending dbus message to MNotificationManager, but I can’t find the popup notification. Who can give me some hints? The Meego image I installed: MeeGo tablet 1.2 Dbus command I used: $dbus-send –print-reply –dest=com.meego.core.MNotificationManager /notificationmanager com.meego.core.MNotificationManager.addNotification uint32:0 uint32:0 string:’test’ Thanks, Lewis You should see small indicator in the statusbar indicating that there is a new notification, and a quick banner that slides out with the text of the notification for just a second. After that you can drag down on the statusbar to open a UI containing past notifications that are still active. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] A problem to click the GestureArea via TDriver API.
Looking through all that i'm still not seeing anything that stands out and says it actually sends touch events instead of mouse events. These are two different subsystems in Qt. On 06/22/2011 07:04 PM, Tang, Shaofeng wrote: Hi Rusty, Yes, TDriver is a generic driver which provides access to Qt software for test automation harnesses. For more information, you can refer to its' WIKI https://projects.developer.nokia.com/Testabilitydriver/wiki/introduction_to_tdriver and for testing our MeeGo QML application, we are also preparing the auto-ux-testlib. Till now, 16 automatic BAT test cases for meego-ux-settings, meego-app-browser, meego-app-im and meego-app-emails are implemented and tested on pinetrail image which was built on May 17. If you are interested in it, they are available on https://meego.gitorious.org/meego-quality-assurance/auto-ux-testlib also a WIKI page is available on http://wiki.meego.com/Quality/QA-tools/QmlUITestlib Currently, when I try to update them for the latest pinetrail image built on Jun 17, all of them are blocked by the GestureArea except a test case for meego-app-calculator. I suppose MouseArea is still used in calculator, so. Best Regards Shao-Feng -Original Message- From: Lynch, Rusty Sent: Wednesday, June 22, 2011 10:29 PM To: Tang, Shaofeng Cc: petri.kiiski...@jidokatech.com; meego-dev@meego.com; meego...@lists.meego.com Subject: Re: [MeeGo-dev] A problem to click the GestureArea via TDriver API. On 06/22/2011 01:57 AM, Tang, Shaofeng wrote: Hello Petri, and all QML experts We meet a problem to click the GestureArea via TDriver API( all of tap, long_tap, and hold don't work for GestureArea). Could you give us some suggestion for it? Does this TDriver send touch events? Are you able see any of the Qt examples for gestures work? --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] A problem to click the GestureArea via TDriver API.
On 06/22/2011 01:57 AM, Tang, Shaofeng wrote: Hello Petri, and all QML experts We meet a problem to click the GestureArea via TDriver API( all of tap, long_tap, and hold don't work for GestureArea). Could you give us some suggestion for it? Does this TDriver send touch events? Are you able see any of the Qt examples for gestures work? --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Modifying Meego theme
The window transition animation is not controlled by a theme. On 06/10/2011 08:47 AM, Vivek Talwar wrote: Hi All Does anybody know how to modify or switch off the Meego application transition theme for meego tablet version 1.2.80 running on a netbook (lenovo S10-3t). Is there any configuration file for the same or mcompositor takes care of this? Which module source code needs to be referred for same? Thanks and Regards, Vivek Talwar From: Vivek Talwar Sent: Monday, May 23, 2011 6:54 PM To: Adrian Yanes; meego-dev@meego.com Subject: RE: [MeeGo-dev] Modifying Meego theme Hi Adrian, We need to change to theme for tablet version on lenovo S10-3t hardware. The tablet version we are using is "meego-tablet-ia32-pinetrail-1.2.80.0.20110503.2" Thanks and Regards, Vivek Talwar From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of Adrian Yanes [ext-adrian.ya...@nokia.com] Sent: Monday, May 16, 2011 7:00 PM To: meego-dev@meego.com Subject: Re: [MeeGo-dev] Modifying Meego theme Can we change default theme in meego for changing the way meego launch any new application? Can we make any custom theme or disable theme in meego? Can you specify which kind of hardware? (tablet, handset, laptop?), nowadays we have a bit different styles system on them. Cheers, Adrian. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines CONFIDENTIAL AND PROPRIETARY INFORMATION NOTICE: The information contained in and/or attached to this e-mail is Confidential and Proprietary Information of frog design Inc. and its operating companies and subsidiaries. This information is intended only for the confidential use of the person(s) designated above. If this message has reached a person or persons not designated above, you are hereby notified that you have received this document in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you are not a designated recipient, please notify frog design Inc. immediately by reply e-mail and delete the original message together with any and all attachments. "DISCLAIMER: This message is proprietary to the Aricent Group and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. The Aricent Group accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] QSystemStorageInfo::logicalDriveChange signal does not work
On 06/09/2011 03:18 PM, David Boosalis wrote: Not much is written about this signal (QsystemStorageInfo::logicalDriveChange)) I was hoping to get a notice in my app via this signal when I put in a USB stick on a Meego 1.2 device, but it is not the case. Has anybody else used this class and signal, is there another way to do this besides listening for a DBus event ? A few months ago when we had a need for this in meego-ux, we ended up having to create a QAbstractListModel subclass that pulled data from the udisk dbus interface. If you ended going down that path then you could lift the implementation from: https://meego.gitorious.org/meego-ux/meego-ux-components/trees/master/src/models Today nothing is using this model so it's possible some bit rot has set in, but i don't think so. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] KCal-EDS: Support local calendar creation
On 06/09/2011 05:44 AM, Ohly, Patrick wrote: On Do, 2011-06-09 at 13:10 +0100, Dumez, Christophe wrote: Could you please review the attached patch that implements local calendar creation in KCal-EDS? The apps need to call EStorage::localStorage(KCalCore::IncidenceBase::IncidenceType type, const QString&id, bool create) instead of defaultStorage(KCalCore::IncidenceBase::IncidenceType type) to get a local calendar storage. If the "create" parameter is set to false and the local storage identified by "id" does not exist, the method will fail and return a NULL pointer. The ECal uri is generated from the id provided by the caller as follows: "local:". Looks good to me. Emma, this is meant to be used in the Clocks app. Rusty, Ross, note that the created databases are not registered in gconf and thus can't be discovered via libebook. That may or may not be desirable. For the Clock app, we certainly don't want Evolution to show the calendar with the "private" events. But how is the alarm notification going to find the private database? One possibility is that we establish the convention that local:clock is the "Clock database", similar to local:system which already (as defined by EDS) is the system calendar. Then the alarm service can simply watch these two databases, either because its hard-coded or configured somewhere. Using the local:clock (and also local:task) convention sounds like a fine solution to me. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Who app/service has used alarmd already?
On 05/31/2011 01:57 AM, Chang, Ziv wrote: Hi, The meego-ux-daemon will listen the "Alarm" signal from D-Bus (path=/com/meego/Alarm, interface=com.meego.Alarm, signal=Alarm). Then meego-ux-dameon may play the appropriate audio by soundUri. I would like to know who app/service has used alarmd already? For which purpose? So I can classify the audio source into different audio group in resource policy. Nobody is using this yet since I'm still hooking up the pieces, but we we: * alarm clock alarms * todo notification alarm * calendar appointment alarms meego-ux-daemon will be the process exposing these. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Top Application in Meego Tablet
On 05/16/2011 11:06 PM, Vivek Talwar wrote: Hi All, I have some queries on Meego's Top Application. Qt/Qml top applications in Meego tablet version are behaving differently. In meego tablet, the top application is taking a short span of time say around 1-2 second while displaying which is little annoying. Although such behavior is not in any netbook or handset version of meego. I have some queries regarding same below: I'm not understanding the question. Are you talking about /usr/bin/top, or the foreground application (i.e. what ever app is on the top of the window stacking order)? And 'taking a short span of time'? --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] virtual keyboard
On 04/22/2011 12:29 PM, Michael Hasselmann wrote: On Fri, 2011-04-22 at 12:13 -0700, Mark S. Townsley wrote: It looks like the virtual keyboard will automatically show up/available for any text input. For example, I have an QML app and the virtual keyboard shows up automatically under my TextInput area during run time. Is this assumption correct (virtual keyboard is available automatically for any text input fields)? Yes, it is correct. But I keep thinking that this concept really only works out for small form factors (such as handset UX). For tablet UX and bigger (say, on the desktop), the Qt default of "first touch to focus, and second touch to bring up VKB" feels better. But then again, I am no user interaction designer ... actually the vkb is only activated when an input gains focus. If you write your app such that a given element automatically has focus then you will see the vkb open as soon as you open the app, but if you don't then the user has to touch the input area. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Who's maintainer of .spec file.
That would be Todd Brandt (cc'ed). Todd... please update your package meta data. On 04/20/2011 12:01 AM, zhu wrote: Hi , Here is the bug report in https://bugs.meego.com/show_bug.cgi?id=16379 It belongs meego-app-video package. But I don't find the meego-ux relative package maintainer in http://wiki.meego.com/Packaging/Maintainers. Thanks -zhu On 20 April 2011 14:46, wrote: Hi, They're part of the packaging material on OBS. You can download the src.rpm and submit the patch through: - this mailing list - a bug report on bugzilla.meego.com - contact the maintainer if listed in http://wiki.meego.com/Packaging/Maintainers cheers, Fathi From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] on behalf of ext zhu [lady...@cuteqt.com] Sent: Wednesday, April 20, 2011 9:27 AM To: meego-packag...@meego.com; meego-dev@meego.com Subject: [MeeGo-dev] Who's maintainer of .spec file. Hi, If I want submit a patch to .spec file , where can I submit it. I didn't find .spec in any package from meego.gitorious.org , I would like to know where .spec files are maintained. Thanks -zhu ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] how to return to main panel
On 04/18/2011 03:04 PM, Mark S. Townsley wrote: Hi: I am doing some development with the MeeGo tablet image. It looks like the panel is responsive to the "Window Start" key from my keyboard and will pop up a panel chooser. That is a convenient way for me to go back to the main UI panel from any application. Is there a sure way for me to bring up this panel chooser or go back to the UI panel if and when the "Window Start" key is not available or when I actually want to trigger to "go back to main panel" operation from my application? From your app just minimize your window. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Ux / QML List view does not work correctly when containing items with variable size
On 04/15/2011 03:52 AM, jeremias bosch wrote: Hello all, in context of our peregrine project we are wanting to have "message items" which are handled in a list. We have the case that the size of the item is not known before we rendered the item. (It size also might alter on the fly, i.e. when a image is getting send to the user and it got loaded after transfer the box should be resize) In this cases the size (height) of the items are not calculated correctly / dynamic. Is there a plan / option to cover this within the meego ux, I know its a problem in standard qml components but I had expected it working better when having meego ux. I think its a general issue which will be also going to appear on other usecases when using a list. Does someone have a working solution or is it only possible to get solved by completely reimplementing the list view and everything? Can we expect this from meego ux? I do not know of anything in any of the apps that are hitting this issue, and as a result I don't think anyone is working on this. If you haven't already then please file a bug with the upstream Qt project. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Can MTF application use QWidget?
On 04/13/2011 07:55 PM, Chen, Zhang Z wrote:
Forwarding to meego-dev
*From:* meego-sdk-boun...@meego.com
[mailto:meego-sdk-boun...@meego.com] *On Behalf Of *Pai, Cary
*Sent:* Thursday, April 14, 2011 10:14 AM
*To:* meego-...@meego.com
*Subject:* [MeeGo-SDK] Can MTF application use QWidget?
Hi, All,
I have created a MTF application, but when I run the application with
the QPushButton add into MApplicationPage, it will have the
segmentation fault, why MTF can’t add the QWidget based item? The code
I wrote are as below :
int main(int argc, char *argv[])
{
MApplication a(argc, argv);
MApplicationWindow w;
MApplicationPage p;
QPushButton* but = new QPushButton("test");
p.scene()->addWidget(but);
p./appear/(&w);
w.show();
return a.exec();
}
Since the p.scene() is QGraphicsScene why it will have the error on
runtime?
Your attempting to mix QGraphics programing with QWidget programming.
It is possible to wrap a QWidget for use in a QGraphicsView, but it
comes at a cost and is usually the wrong answer.
For example... if you wanted to add button into an MTF based app, just
use MButton (or whatever the name of the associated button class is.)
I would advise sitting down and reading through all the QGraphicsView
programming documentation and tutorials that come with Qt. Once you
comprehend QGraphicsView then MTF programming will make a lot more sense.
--rusty
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] X11 between Meego 1.1 and Meego 1.2
On 04/12/2011 11:34 AM, Gabriel M. Beddingfield wrote: On Tue, 12 Apr 2011, Mark S. Townsley wrote: I have an application that ran fine under Meego 1.1 using a netbook. When I switch it over to Meego 1.2, it seg fault. There are some OpenGL code inside my app. For 1.2 MeeGo has switched from OpenGL to GLESv2. If your application doesn't fit into the GLESv2 subset... this could be your problem. Also, the GLESv2 drivers aren't as widely-used as the OpenGL drivers... so you may have uncovered a bug. A backtrace would tell you more, though. :-) Also... if you didn't recompile the gl code (even if it fits in the subset) then you will fail. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] meego table screen saver
On 04/11/2011 08:48 PM, Mark S. Townsley wrote: Hi I am running the meego table release. The screen saver is nice but I want to turn it off at times. I look under settings but cannot find relevant settings. Is there a way to do so? I looked under /etc/X11 but did not see anything either. I am just now adding support for controlling the timeout via a gconf key, which will allow us to add a settings entry. Also... just in case you are asking as an app developer, I am about to add a merge request to meego-ux-components that adds a new Window.inhibitScreenSaver boolean property which will inhibit/enable the screen saver while the specific application is in the foreground. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Window Manager Issues (Handset and Tablet)
On 04/11/2011 07:33 AM, Gabriel Beddingfield wrote:
Hi Rusty,
On Sat, Apr 9, 2011 at 11:53 AM, Rusty Lynch wrote:
On 04/09/2011 06:52 AM, Gabriel M. Beddingfield wrote:
On the latest daily builds for Handset and Tablet there are
no title bars (including app switcher button and app close
button). Will there be any? Nor do apps get automatically
expanded to fit the screen. Will they be?
I.e. are there plans one way or the other?
First... the easy one all normal toplevel windows should be made
fullscreen by the window manager, from my observations of the version of
meegotouch-compositor in Trunk, this is happening (where the easiest example
to test is to open the terminal.) If you are not seeing this for one of
your apps then we need to file a bug on the window manager.
Thanks. This is a Good Thing. (However, I had one app that didn't
get full-screened -- so I had doubts about it. Now I know it's a Bug
To Be Filed.)
Now for the harder discussion. Looks like we have a design mismatch between
what meego-ux is attempting to accomplish (which, btw, is not tablet
specific... I just happen to be on the hook to deliver this for customers
that are making tablets), and what the original MTF style handset was
attempting to accomplish.
And since MeeGo UX is the Johnny-Come-Lately that just sort of showed
up one day with no design docs and no discussion -- seems like it
should be a little more aware of the fact that it's breaking the
Handset.
For the specific example of window decoration, the meego-ux approach makes
demands on the device manufacturer that there must be hardware home button
of some form or fashion. This button must be visible to the OS, and the OS
must be able to detect the difference between press and press-n-hold (and oh
by the way... if you make that just look like a normal key then it makes it
much easier to get the device up and running.)
OK. This is mostly good, IMHO. However, shouldn't there be some way
to support devices that don't have buttons? This is a new
requirement. (However, in my case this is just a hypothetical -- my
device has a button that appears as a normal keyboard keypress.)
When the home button is pressed, you go to the homescreen. If you
press-n-hold on the homescreen, then we open a task switcher. From the task
switcher you can switch between active task, or close specific tasks.
I haven't figured out how to close a task from the device switcher.
Can anyone explain it?
press-n-hold on one of the app icons to trigger a context menu, where
one of the options in the context menu is 'close'.
So... with this approach, no applications should waste screen space on a
home button or a close button. Everyone runs edge to edge, direct rendered
(except perhaps when we are doing window to window transitions or
compositing a system level overlay like the task switcher on top of the
app), all the time.
OK, that makes sense.
I'm open to ideas, but I think it would be a mistake to compromise the
ability to make competitive devices where from day one the device
manufacture is targeting the specific design approach taken in the meego-ux.
Agreed... a little communication with the community goes a long way,
though. :-)
One example that came up on an IRC discussion is to extend the basic
Window{} implementation add things like a home button when the device theme
ask for it (without the application developer needing to do anything.)
Another idea for non-qml apps that i haven't discussed is instead of just
nuking the decorator, add a runtime config to decide if to use a decorator
Why not use the X11 window hints for this? (You know, like the
frameless window hint... or something akin to that.)
The point is to not make the applications have to know if showing a
decorator is a good idea for the specific device that their app is
running on. If your app is the only app showing the decorator, then it
just makes your app look second rate, like it doesn't really fit.
or not, and if so then which one. Then the MTF style handset could still
have it's broken decorator (at least broken on any meego image i have ever
That's the thing... they had /just/ fixed it on the images I tried --
and then it got ripped out by the MeeGo UX.
I never saw it really work on any Intel device (where work means you
stop seeing crash reports when corewatcher is configured to submit to
the server without asking.)
...which is why people are asking, "Sine the MeeGo UX is shamelessly
breaking the Handset UX... is the Handset UX officially cancelled or
something?"
3. In the Tablet UX there's currently no way to close apps
like chrome except to reboot.
The idea is that for the most part we do like android and iphone, where
users shouldn't need to 'c
Re: [MeeGo-dev] Window Manager Issues (Handset and Tablet)
On 04/09/2011 06:52 AM, Gabriel M. Beddingfield wrote:
On the latest daily builds for Handset and Tablet there are
no title bars (including app switcher button and app close
button). Will there be any? Nor do apps get automatically
expanded to fit the screen. Will they be?
I.e. are there plans one way or the other?
First... the easy one all normal toplevel windows should be made
fullscreen by the window manager, from my observations of the version of
meegotouch-compositor in Trunk, this is happening (where the easiest
example to test is to open the terminal.) If you are not seeing this
for one of your apps then we need to file a bug on the window manager.
Now for the harder discussion. Looks like we have a design mismatch
between what meego-ux is attempting to accomplish (which, btw, is not
tablet specific... I just happen to be on the hook to deliver this for
customers that are making tablets), and what the original MTF style
handset was attempting to accomplish.
For the specific example of window decoration, the meego-ux approach
makes demands on the device manufacturer that there must be hardware
home button of some form or fashion. This button must be visible to the
OS, and the OS must be able to detect the difference between press and
press-n-hold (and oh by the way... if you make that just look like a
normal key then it makes it much easier to get the device up and running.)
When the home button is pressed, you go to the homescreen. If you
press-n-hold on the homescreen, then we open a task switcher. From the
task switcher you can switch between active task, or close specific tasks.
So... with this approach, no applications should waste screen space on a
home button or a close button. Everyone runs edge to edge, direct
rendered (except perhaps when we are doing window to window transitions
or compositing a system level overlay like the task switcher on top of
the app), all the time.
Yes, this does present a problem when you take some existing device,
designed for something like Windows 7, and run a meego-ux based image on it.
I'm open to ideas, but I think it would be a mistake to compromise the
ability to make competitive devices where from day one the device
manufacture is targeting the specific design approach taken in the meego-ux.
One example that came up on an IRC discussion is to extend the basic
Window{} implementation add things like a home button when the device
theme ask for it (without the application developer needing to do
anything.)
Another idea for non-qml apps that i haven't discussed is instead of
just nuking the decorator, add a runtime config to decide if to use a
decorator or not, and if so then which one. Then the MTF style handset
could still have it's broken decorator (at least broken on any meego
image i have ever tried), and we could even turn on a hopefully working
decorator when running on something like one of the existing convertible
netbooks that don't have any buttons accessible when flipped.
These features are important because:
1. If someone develops an app for the netbook, then they
won't know that they're supposed to draw their own
title bar and exit button.
As mentioned before this is easy... no need for anyone to render a
window manager style toolbar.
2. Our company provides a lot of 3rd party, non-meego-api,
Xlib apps with our devices. These apps were not
written for phones, and are expecting the WM to provide
the buttons to exit the application. We would rather
not have to repackage mcompositor to get mdecorator
back.
again... no need.
3. In the Tablet UX there's currently no way to close apps
like chrome except to reboot.
The idea is that for the most part we do like android and iphone, where
users shouldn't need to 'close' an app, but a thirdparty utility could
be create that closes apps and then the task switcher also presents
a view for "closing" active applications (but this isn't a display of
all processes just what we want to expose to the user.)
4. These established MeeGo UI guidelines are now broken:
http://meego.com/developers/ui-design-guidelines/handset/meego-basics
(specifically the switcher and comments on fullscreen)
A different design philosophy. I am hopeful we can find a way to make
mcompositor serve both needs. If not then perhaps we have to have two
versions of the package (with different patches) or just fork
mcompositor (which i really don't want to do.)
Yes, I realize that mdecorator is buggy and even (at some
level) a broken concept. But I'm not really even talking
about mdecorator... I just need the basic WM functionality.
understood. hopefully my explanation above made sense, and for the more
sticky corner cases we can find a way to just make this work.
--rusty
___
MeeGo-dev m
Re: [MeeGo-dev] running the meego tablet UX image on Medfield
On 04/07/2011 06:23 PM, Pei Lin wrote: 2011/4/7 Rusty Lynch: On 04/07/2011 08:27 AM, Stylianou, Costas wrote: Is there a home or back button mapped on the Medfield iCDK, I have no way coming out of the app that I’m in? The last I heard somebody (firmware??) was mapping one of the existing buttons to be a home key. Note that with this UI you only need a home button. Press-n-hold on that key will trigger the task switcher as long has the hardware enables press-n-hold (unlike the exopc). Home key is "win" key in the keyboard, it will put all active apps in to background. There is another "Menu" key in the keyboad which can pop-up the task switcher, press-n-hold on the app icon can give select menu to open/close. Note that we only listen to the menu key as a developer convenience feature. Device makers should have a home key that supports both press and press-n-hold so that our UI can map press to 'go home' and press-n-hold to 'open task switcher'. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] running the meego tablet UX image on Medfield
On 04/07/2011 08:27 AM, Stylianou, Costas wrote: Is there a home or back button mapped on the Medfield iCDK, I have no way coming out of the app that I’m in? The last I heard somebody (firmware??) was mapping one of the existing buttons to be a home key. Note that with this UI you only need a home button. Press-n-hold on that key will trigger the task switcher as long has the hardware enables press-n-hold (unlike the exopc). --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] how to run meego-ux's meego-app-camera on MeeGo 1.2 Netbook?
On 04/05/2011 01:31 PM, Niels Mayer wrote: I got a little farther with bringing up meego-ux camera on Netbook 1.2 "alpha". After seeing various warnings regarding missing gstreamer components and failures in meego-app-music and meego-app-video related to dbus message parse failures, I decided to upgrade this highly updated 2/22/11 image to the latest "base" packages from Trunk: Just realized we are still using a work around in the image creation process. There is a bug for Qt Mobility bug for this, but I don't recall the number so cc'ing Iain for the answer. But... the gst camera bin doesn't play nicely with the Qt Mobility Video widget. In the ks file we: rm /usr/lib/gstreamer-0.10/libgstcamerabin.so ... which means on each update the file comes back (which is how i remembered since i just did a massive Trunk:Testing update and the camera app stopped working.) --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] meego tablet on viewpad 10
On 04/05/2011 01:40 AM, 陈鲍孜 wrote: > > Aha, the mouse can work even though there is no cursor. > > So, to support my touch screen, does the work relate to device driver > or userspace library outside kernel. I’d like to help if possible. > > You need a fix for the device driver... specifically the driver needs to support XInput2 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-qa] Bugzilla changes for tablet user experience open sourcing
We still need a component for meego-app-browser. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Locking Screen orientation in MeeGo
On 04/04/2011 04:51 PM, Stylianou, Costas wrote: Hi All, Thanks for your responses so far. The Window of the meego-ux-components has the following behavior: If you leave the orientation property as it is, the Window will use all 4 orientation as provided by the qApp. If you set the orientation to a value, e.g. landscape, the Window will only respond to landscape and inverted landscape. I did not come up with a use cases where a lock to only one orientations is usefull (except on handsets for the dialer, maybe). On clearing of the Property, the Window will again respond to all changes. In the Qt 4.7.2 documentation it mentions various Qt API's to lock screen orientation, will these be implemented MeeGo, i.e., will there be platform specific code for these? Qt::WA_LockPortraitOrientation: //Locks the widget to a portrait orientation, ignoring changes to the display’s orientation with respect to the user// Qt::WA_LockLandscapeOrientation: //Locks the widget to a landscape orientation, ignoring changes to the display’s orientation with respect to the user// Qt::WA_AutoOrientation: //Causes the widget to change orientation whenever the display changes orientation with respect to the user// hmm this is the first I've heard of this. perhaps a troll can shed light on this. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] how to run meego-ux's meego-app-camera on MeeGo 1.2 Netbook?
On 04/03/2011 04:27 PM, Niels Mayer wrote: After doing $ zypper ar http://download.meego.com/live/devel:/meego-ux/Trunk/devel:meego-ux.repo $ zypper zypper clean --all ; zypper --gpg-auto-import-keys refresh $ zypper in meego-app-camera meego-app-video meego-app-photos meego-app-notes meego-app-im meego-app-email meego-app-conacts meego-app-calendar meego-app-calculator meego-app-browser meego-app-clocks meego-ux-panels meego-ux-panels-photos meego-ux-panels-friends meego-ux-panels-music meego-ux-panels-mytablet meego-ux-panels-video meego-ux-panels-web meego-ux-panels-meta-tablet meego-ux-appgrid meego-ux-content meego-ux-content-socialweb which also installs dependencies: meego-handset-sound-theme meegolabs-ux-components meego-qml-launcher meego-ux-media meego-ux-media-models meego-ux-theme mkcal mlite qtgst-qmlsink telepathy-farstream I attempt to launch these apps with $ meego-qml-launcher --app which looks for /usr/share//main.qml e.g. meego-qml-launcher --opengl --fullscreen --app meego-app-calculator meego-qml-launcher --opengl --fullscreen --app meego-app-calendar meego-qml-launcher --opengl --fullscreen --app meego-app-camera meego-qml-launcher --opengl --fullscreen --app meego-app-clocks meego-qml-launcher --opengl --fullscreen --app meego-app-contacts meego-qml-launcher --opengl --fullscreen --app meego-app-email meego-qml-launcher --fullscreen --opengl --app meego-app-im meego-qml-launcher --opengl --fullscreen --app meego-app-music meego-qml-launcher --opengl --fullscreen --app meego-app-notes meego-qml-launcher --opengl --fullscreen --app meego-app-photos meego-qml-launcher --opengl --fullscreen --app meego-app-tasks meego-qml-launcher --opengl --fullscreen --app meego-app-video meego-qml-launcher --opengl --fullscreen --app meego-ux-appgrid meego-qml-launcher --opengl --fullscreen --app meego-ux-app-photos meego-qml-launcher --opengl --fullscreen --app meego-ux-panels meego-qml-launcher --opengl --fullscreen --app meego-ux-settings Although many of the simple tablet-ux apps work on the Lenovo s10-3t running 1.2 netbook "alpha", the one I really want to re-use (for http://code.google.com/p/ytd-meego/wiki/CitizenJournalismWithYoutubeDirectForMeego ) is meego-app-camera. Unfortunately, when I run it, I get the following: -- is this a bug or am I dong something wrong ? ... $ meego-qml-launcher --opengl --fullscreen --app meego-app-camera Adding Master Pointer: Virtual core pointer ( 2 ) Skipping non-Touch device: Virtual core XTEST pointer ( 4 ) Adding ATTACHED touch device: Cando Corporation Cando 10.1 Multi Touch Panel with Controller ( 11 ) Skipping non-Touch device: SynPS/2 Synaptics TouchPad ( 14 ) loaded the Generic plugin Loaded the MeeGo sensor plugin Request for interface not granted... Request for interface not granted... Warning: Object::connect: No such signal QXIMInputContext::inputMethodAreaChanged(QRect) Warning: Object::connect: No such signal LauncherApp::localeSettingsChanged() Warning: Object::connect: (sender name: 'meego-qml-launcher') Warning: Object::connect: No such signal LauncherApp::windowListUpdated(QList) Warning: Object::connect: (sender name: 'meego-qml-launcher') Debug: Instantiating VolumeControlPrivate Debug: Settings* Debug: Flash Mode: 0 Debug: Capture Mode: 0 Debug: "/dev/video0" "Lenovo EasyCamera" Debug: "/dev/video0" "Lenovo EasyCamera" Debug: Setting camera to "/dev/video0" Debug: Camera caps: 64 Debug: Supported maximum optical zoom 1 Debug: Supported maximum digital zoom 10 Debug: Metadata is not available Debug: Audio input: "alsa:null" - "Discard all samples (playback) or generate zero samples (capture)" Debug: Audio input: "alsa:pulse" - "PulseAudio Sound Server" Debug: Audio input: "alsa:default" - "Default" Debug: Audio input: "alsa:front:CARD=Intel,DEV=0" - "HDA Intel, CONEXANT Analog Front speakers" Debug: Audio input: "alsa:surround40:CARD=Intel,DEV=0" - "HDA Intel, CONEXANT Analog 4.0 Surround output to Front and Rear speakers" Debug: Audio input: "alsa:surround41:CARD=Intel,DEV=0" - "HDA Intel, CONEXANT Analog 4.1 Surround output to Front, Rear and Subwoofer speakers" Debug: Audio input: "alsa:surround50:CARD=Intel,DEV=0" - "HDA Intel, CONEXANT Analog 5.0 Surround output to Front, Center and Rear speakers" Debug: Audio input: "alsa:surround51:CARD=Intel,DEV=0" - "HDA Intel, CONEXANT Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers" Debug: Audio input: "alsa:surround71:CARD=Intel,DEV=0" - "HDA Intel, CONEXANT Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers" Debug: Audio input: "pulseaudio:" - "PulseAudio device." Debug: Default source: "alsa:null" Debug: Using default resolution Debug: Using default FPS Debug: Codec: "video/theora" Debug: Codec: "video/mpeg2" Debug: Codec: "video/mpeg1" Debug: Codec: "video/mjpeg" Debug: Codec: "video/VP8" Debug: Codec: "video/h261" Debug: Container
Re: [MeeGo-dev] MeeGo Tablet/Unified UX Licensing
On 04/02/2011 02:38 PM, Robin Burchell wrote: Hi Rusty, On 02/04/11 22:11, Rusty Lynch wrote: On 04/02/2011 12:57 PM, Robin Burchell wrote: Hi, Whilst working on meego-ux-components[0], I happened to notice there seems to be quite a bit of confusion over licensing. > The project is LGPL. The files marked as Apache were moved over from meegolabs and were supposed to have their license headers corrected (so just an oversight), and it was also just an oversight not to apply the license header to the *indicator* files. OK. There are some other files in the tree also lacking headers, I would try make a list, but I figure that's just duplicating the work of whoever fixes this. Can I ask why that single project is differently licensed? We wanted to match the license used by Qt components to make it easier evolve the implementation with qt components. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Tablet/Unified UX Licensing
On 04/02/2011 12:57 PM, Robin Burchell wrote: Hi, Whilst working on meego-ux-components[0], I happened to notice there seems to be quite a bit of confusion over licensing. Some of the code is licensed under LGPL: burchr@virgin:~/code/meego/meego-ux-components(master+)% git grep -i LGPL | cut -d':' -f1 | sort | uniq | wc -l 95 A small fraction under APLv2: burchr@virgin:~/code/meego/meego-ux-components(master+)% git grep -i Apache | cut -d':' -f1 | sort | uniq | wc -l 4 And still other files that don't have any licensing or copyright information attached at all, for instance: src/components/*indicator* Furthermore, the tree contains no LICENSE file. Can someone please clarify the licensing situation with this, and the rest, of the new UX code? The vast majority of it that I have come across in other projects for the UX seems to be Apache v2, so I guess this has been a mistake by whoever maintains meego-ux-components. [0]: https://meego.gitorious.org/meego-ux/meego-ux-components/ The project is LGPL. The files marked as Apache were moved over from meegolabs and were supposed to have their license headers corrected (so just an oversight), and it was also just an oversight not to apply the license header to the *indicator* files. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Locking Screen orientation in MeeGo
On 04/01/2011 08:45 AM, Stylianou, Costas wrote: > I hope someone can advise me the recommended way of doing a screen lock in MeeGo after using QtMobility API to detect screen orientation. Are you asking how to trigger the lockscreen UI, or lock the orientation of your app (like a video player might want to force the view into landscape mode while playing a video clip?) > The latter, lock screen orientation to either landscape or portrait. We don't do a low level xrandr rotation of the screen, so rotation totally handed inside the application or the toolkit used by the application. So... if you have a traditional Qt application or even a QML app that isn't using a component library like meego-ux-components that automatically does scene rotations for you, then your code would have to explicitly rotate the the view (speaking generically here since this could apply to any app using who knows what UI technology) which means the concept of orientation locking would be something your code would need to implement. We are in the process of migrating our QML based code to all use MeeGo.Components instead of MeeGo.Labs.Components since MeeGo.Components is better positioned to work correctly with qt-components, but as i now review Window i see that we seem to be missing the concept of an orientation lock that we currently have in MeeGo.Labs.Components. Christian or Ben... is there something I am missing or do we still need to add a mechanism to lock the orientation? In the labs version of Window I had a orientationLocked boolean property, so apps would: scene.orientationLocked = true; scene.orientation = someorientation; I'm not sure if the qt-components definition of a window has some other way of dealing with this. Note that we will not be able to migrate the video player, app grid, and lockscreen till we have orientation locking supported. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Locking Screen orientation in MeeGo
On 04/01/2011 02:36 AM, Stylianou, Costas wrote: Hi, I hope someone can advise me the recommended way of doing a screen lock in MeeGo after using QtMobility API to detect screen orientation. Are you asking how to trigger the lockscreen UI, or lock the orientation of your app (like a video player might want to force the view into landscape mode while playing a video clip?) --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] tablet user experience source is now open...
On 03/31/2011 03:27 AM, Robin Burchell wrote: Hi, On 31 March 2011 11:24, Alberto Mardegan wrote: Is there a mailing list specifically for this project? I don't think so. Admittedly, I've been mostly just using #meego on IRC/gitorious for my work on it so far :) Wouldn't it be in more or less the same boat as accounts& SSO? (Start here, spin it off if it gets sufficient volume) Personally I would be fine with using the existing meego development mailing list using some kind of prefix to help sort my inbox. If we end up flooding the list then we can always create a new mailing list. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH] Fix orientation to match change QML orientation fixes.
On 03/28/2011 10:23 AM, Foster, Dawn M wrote: On Mar 28, 2011, at 7:45 AM, Rusty Lynch wrote: On Friday I pushed all the UX related source repositories to gitorious @ https://meego.gitorious.org/meego-ux, with the plan of taking advantage of the merge request mechanism for reviewing/accepting incoming patches. Please convert this (and the other related patches) to merge request and give me a chance to try out the merge request mechanism. Hi Rusty, We should talk about this. We have a process that people are being asked to follow for patches that doesn't include merge requests. http://meego.com/about/contribution-guidelines If we need to change the process, I'm ok with it, but we need to talk about this across the entire meego project and figure out when we want merge requests vs. patch submissions. In this case the gitorious repos are upstream, so we are still following the guidelines. If anything I was really just clarifying that there now is an upstream project since unless somebody happen to be watching gitorious, they would have no idea that pushing upstream is an option. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH] Fix orientation to match change QML orientation fixes.
On Friday I pushed all the UX related source repositories to gitorious @
https://meego.gitorious.org/meego-ux, with the plan of taking advantage
of the merge request mechanism for reviewing/accepting incoming patches.
Please convert this (and the other related patches) to merge request and
give me a chance to try out the merge request mechanism.
--rusty
On 03/26/2011 02:26 PM, Robin Burchell wrote:
Signed-off-by: Robin Burchell
---
application.cpp |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/application.cpp b/application.cpp
index 1de036e..878c08a 100644
--- a/application.cpp
+++ b/application.cpp
@@ -90,7 +90,7 @@ Application::Application(int& argc, char ** argv, bool
opengl) :
m_homeActive(false),
m_homePressTime(0),
m_haveAppStore(QFile::exists("/usr/share/applications/com.intel.appup-tablet.desktop")),
-m_foregroundOrientation(2),
+m_foregroundOrientation(1),
m_notificationDataStore(NotificationDataStore::instance()),
m_notificationModel(new NotificationModel),
m_lastNotificationId(0)
@@ -148,7 +148,7 @@ Application::Application(int& argc, char ** argv, bool
opengl) :
MGConfItem *landscapeItem = new
MGConfItem("/meego/ux/PreferredLandscapeOrientation", this);
if (!landscapeItem || landscapeItem->value() == QVariant::Invalid)
{
-m_preferredLandscapeOrientation = 1;
+m_preferredLandscapeOrientation = 0;
}
else
{
@@ -158,7 +158,7 @@ Application::Application(int& argc, char ** argv, bool
opengl) :
MGConfItem *portraitItem = new
MGConfItem("/meego/ux/PreferredPortraitOrientation", this);
if (!portraitItem || portraitItem->value() == QVariant::Invalid)
{
-m_preferredPortraitOrientation = 2;
+m_preferredPortraitOrientation = 1;
}
else
{
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Video API's
On 03/04/2011 11:12 AM, Soussi, Slim wrote: Hi All, I would like to know what APIs are available for Video decoding acceleration on MeeGo Tablets? Can we access VAAPI? Can we access OpenMax IL? What is the kernel that will be on the future MeeGo tablets? This will depend on what hardware platform you are talking about. For Intel devices we have people creating Moorestown, Oaketrail, and Pinetrail based devices with Moorestown and Oaktrail having the same hardware decode capabilities but Pinetrail having a very different solution (or no solution, depending on the OEM.) Moorestown/Oaketrail is enabled via vaapi (with gstreamer elements wrapping vaapi.) Most app developers will have no need to do anything other then use the Qt/Mobility API. If the app needs to build an exotic pipeline then they can directly work with gstreamer, and if the app already has it's own concept of a pipeline infrastructure then the app could choose to directly talk to VAAPI. Some pinetrail based tablets (like the WeTab/ExoPC) have a third party hd video decoder. There is no such support for this in meego. I have no idea if somebody is planning to add support, but some kind of linux solution exist since this is integrated into the Linux that comes on WeTab. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] package install cause the screen orientation can't work
On 03/03/2011 01:47 AM, Jia-Chi Lai wrote:
2011/3/3 Jia-Chi Lai <mailto:jackie09050...@gmail.com>>
2011/3/3 Jia-Chi Lai mailto:jackie09050...@gmail.com>>
2011/3/2 Rusty Lynch mailto:rusty.ly...@intel.com>>
On 03/02/2011 12:50 AM, Jia-Chi Lai wrote:
hi~
I build the qt-mobility package on OBS and install
the rpm files of the package.
then I launch the setting application but the screen
orientation can't work.
I also build orientation-contextkit-sensor package and
install it.
the home screen can't launch
Are there any trick of install those rpm?? why the
screen orientation can not work after I install the
rpm built by myself??
I have no idea what hardware you running on, but mobility
depends on a backend that actually retrieves the sensor
data (like the sensor framework.) If that doesn't work
then mobility doesn't have a chance.
You __shouldn't__ need orientation-contextkit-sensor since
the libqtsensors1 package does the translation of
contextkit to QSensor's for you, but the reason
orientation-contextkit-sensor exist is because I was
having issues getting the translation to happen (and up
till a couple of months ago libqtsensors1 would even
segfault on initialization.)
but I use 2011.03.01 release tablet image which include both
libqtsensors1 rpm and orientation-contextkit-sensor rpm in it
and the screen is work fine.
but I just use the both two rpm get from public repo, and
built with OBS, then use command line "rpm -Uvh
orientation-contextkit-sensor " "rpm -Uvh qt-mobility
libqtsensor1 "
to install those rpm. but the screen can't work.
It's strangedo you have any idea??
How could I do to make the screen orientation work again??
Remove i/usr/lib/qt4/plugins/sensors/libqtsensor_meego.so and
install orientation-contextkit-sensor? or any idea??
I tried to remove the
/usr/lib/qt4/plugins/sensors/libqtsensor_meego.so and screen
orientation can work now...seen the qt-mobility works now.
thanks a lot.^^
With that said... if you know contextkit values are being
published for orientation changes, then you can install
orientation-contextkit-sensor and manually remove
Note... orientation-contextkit-sensor
i/usr/lib/qt4/plugins/sensors/libqtsensor_meego.so.s just a
work around while figuring out why the libqtsensor_meego.so
sensor plugin is borked on some systems. Ideally
orientation-contextkit-sensor would not exist.
--rusty
hi~
I have a question...
if the orientation-contextkit-sensor would not exit in meego, why the
need to store the sensor information into contextkit?? such like
Screen.TopEdge, Position.Shaky,Position.Stable.
Which component will use those information??
The plugin you deleted should be doing the conversion from contextkit to
QSensor. For some reason it doesn't work on some platforms. This is
just a matter of a temporary work around before the root cause for the
real bug is worked out.
--rusty
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Should I use MeeGo Touch Framework or Qt Framework for MeeGo tablets
On 03/02/2011 04:52 AM, Gabriel M. Beddingfield wrote: On Wednesday, March 02, 2011 01:51:51 am Ville M. Vainio wrote: On Wed, Mar 2, 2011 at 1:13 AM, Gabriel M. Beddingfield wrote: On Tue, 1 Mar 2011, Victor Vu wrote: Is MeeGo Touch Framework here to stay? Yes. Is this based on some new information that hasn't been shared elsewhere? MTF is widely understood to be deprecated for third party use. The OP's question didn't specifically ask about 3rd party use. However, if you read the rest of my e-mail... I *did* add a very strong indication that it's deprected for 3rd party use. The original question was simply asking about which components are safe for application development. While MTF covers many things, the actual GUI library (i.e. deriving your application class from MApplication, using MButtons and all the other QGraphicsObject/QGraphicsWidget derived classes) should not be recommended (3rd party or otherwise.) Of course... the libs are there so there is nothing stopping you from using them, but you better strap yourself in tight and follow each change in libmeegotouch because it's going to be a bumpy ride. If you are deeply involved in libmeegotouch then this might not be a big deal to you. However, the MTF includes things like mcompositor, mdecorator, duicontrolpanel, etc... These are fundamental parts of the Handset UX, the IVI UX, and the Tablet UX. So, if the MTF is scheduled for termination... then I missed a memo somewhere. This is what I have come to hate about our lumping so many technologies into one term. MTF covers a lot of stuff that is really of no concern to the guy just trying to write an application. There are some areas in addition to the GUI classes that effect app developers (like how you insert your application settings into the system wide settings app), but I expect most of these will be smoothed out with a QML components library. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] package install cause the screen orientation can't work
On 03/02/2011 12:50 AM, Jia-Chi Lai wrote: hi~ I build the qt-mobility package on OBS and install the rpm files of the package. then I launch the setting application but the screen orientation can't work. I also build orientation-contextkit-sensor package and install it. the home screen can't launch Are there any trick of install those rpm?? why the screen orientation can not work after I install the rpm built by myself?? I have no idea what hardware you running on, but mobility depends on a backend that actually retrieves the sensor data (like the sensor framework.) If that doesn't work then mobility doesn't have a chance. You __shouldn't__ need orientation-contextkit-sensor since the libqtsensors1 package does the translation of contextkit to QSensor's for you, but the reason orientation-contextkit-sensor exist is because I was having issues getting the translation to happen (and up till a couple of months ago libqtsensors1 would even segfault on initialization.) With that said... if you know contextkit values are being published for orientation changes, then you can install orientation-contextkit-sensor and manually remove /usr/lib/qt4/plugins/sensors/libqtsensor_meego.so. Note... orientation-contextkit-sensor is just a work around while figuring out why the libqtsensor_meego.so sensor plugin is borked on some systems. Ideally orientation-contextkit-sensor would not exist. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Opportunity for collaboration: Bringing KWin to MeeGo
On 02/18/2011 09:30 AM, Martin Gräßlin wrote: Hello MeeGo developers, first let me introduce myself. My name is Martin Gräßlin, I am an active member of the KDE community and currently maintainer of the KDE Plasma window manager and compositor KWin. KWin is the reason why I am writing to you today. Over the last months the KWin team has been working on porting our compositor to OpenGL ES 2.0 with EGL and OpenGL 2 with GLX. Today we announced [1] that the porting effort is finished, the source code imported into git master and the next KDE Platform release will include a compositor supporting OpenGL ES 2.0 and on the desktop default to OpenGL 2. I would like to offer KWin for inclusion in MeeGo and become a participant in the MeeGo project. Personally, I think that KWin would be an excellent sollution for the use cases MeeGo faces, particularly across the wide variety of device form factors. MeeGo is bringing Linux to many of the same places that we have been working on bringing KWin to, and so it feels like an excellent and natural opportunity to work together. Let me just outline some of the advanced features KWin provides: * more than 12 years experience in the field of window management * as a window manager rock solid, feature complete and very fast * ICCCM and EWMH compliant * more than three years experience in OpenGL based compositing and even longer support for XRender based compositing * an easy to use plugin system for compositing effects. Right now we are shipping more than 40 effects * support for plugin based (Qt/C++) window decorations as well as various theme engines * only window manager as part of a desktop shell which empraces Qt technology * support of advanced window management functionality such as window tabbing and window tiling * JavaScript based scripting engine * many, many more Has anyone tried to package this for meego yet? What additional deps does this introduce? --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Are there any methods to setContentType for the QML component(TextInput or ...).
You can use the 'inputMethodHints' property on TextInput to do what you
are looking for. For example...
TextInput {
... all the normal prop settings ...
inputMethodHints: Qt.ImEmailCharactersOnly
}
See the Qt documentation for Qt::InputMethodHints for a list of all the
hints. I'm not sure why the QML input components documentation does talk
about this, but the implementation is in place in the version of Qt in
MeeGo trunk.
--rusty
On 02/18/2011 01:28 AM, danny wrote:
> Hi,
> Thanks very much for your quick reply, but I thought it's not what I want.
>
> The content type could also be such as M::EmailContentType or
> M::PhoneNumberContentType etc., not only the basic type.
>
> --
> Best Regards,
>
>
> At 2011-02-18 16:54:33，zhu wrote:
>
> >Hi,
> >
> >Does "validator" work for you ?
> >http://doc.qt.nokia.com/4.7/qml-textinput.html#validator-prop
> >TextInput{
> > validator: IntValidator{bottom: 11; top: 31;}
> > focus: true
> > }
> >
> >/zhu
> >
> >2011/2/18 danny :
> >> Hi all,
> >>
> >> In the MTF , we could set the content type for MTextEdit by:
> >>
> >> MTextEdit *edit = new MTextEdit();
> >> edit->setContentType(M::NumberContentType);
> >>
> >> I try to find it in the QML related documents, but failed at the end. So I
> >> come here to ask are there any methods to set the content type for the
> >> TextInput component in QML?
> >>
> >> Thanks very much in advance.
> >> --
> >> Best Regards,
> >>
> >>
> >>
> >>
> >> ___
> >> MeeGo-dev mailing list
> >> MeeGo-dev@meego.com
> >> http://lists.meego.com/listinfo/meego-dev
> >> http://wiki.meego.com/Mailing_list_guidelines
> >>
>
>
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] How can i detect power button press
First a warning not all buttons are connected to the system in the same manner. If you lucky the platform exposes the button as an input device mapped to a key. Ok... now if you are lucky enough to have the power button for your specific device mapped to some key, you can use XGrabKey from a process inside the user session but without active keyboard focus (like a homescreen running in the desktop.) This isn't a Qt mechanism but a low level XLib call. On a linux workstation run 'man XGrabKey' to learn all about it. --rusty On 01/24/2011 05:51 PM, zhu wrote: I think the question is " How to get the keypressevent when the application is not active(don't have the focus widget) " On Tue, Jan 25, 2011 at 9:41 AM, Zhang, Zheng wrote: Write a Qt application, get keyPressEvent(QKeyEvent* event). event->key(). From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Zheng, Huan Sent: Monday, January 24, 2011 4:44 PM To: meego-dev@meego.com; meego-commun...@meego.com community Subject: [MeeGo-dev] How can i detect power button press Hi, dear developers How can I detect power button press? And further more, how can I detect the button press that I’m interested in? Thanks! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] changing application and Meego UI home orientation
On 11/10/2010 07:18 AM, john pratss wrote: hi all, Is there any configuration file in meego 1.1 handset image that needs to be changed which changes the Meego UI home and applications screens or orientation permanently to portrait mode. Are you saying you want to lock all UI's into a specific mode, regardless of what the orientation sensors are reporting, and regardless of what the specific app wants to do? If so then you could always limit available orientations via the target configuration file located in /usr/share/meegotouch/targets/. You stack will have one a specific target set via a gconf key (or which i don't recall the path off the top of my head), and then libmeegotouch will use that config to load the config from /usr/share/meegotouch/TARGET.conf. Inside that file you will see a section called "[allowedOrientations]" with a list of valid angles for keyboardOpen and keyboardClosed. You "could" (seems a bit hacky, but for what ever purpose you are trying to achieve this you could) just limit the number of valid angles to 0 and 0. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How MeeGo handset UX knows the battery status?
On 10/08/2010 10:04 PM, Tzeng, Tonny wrote: Hi MeeGo experts, Which API should be or will be used to detect the battery charging status in the MeeGo handset image from application perspective? Should this go through contextkit? or any Qt APIs? Apologize if this is a FAQ. ;) There are a set of contextkit keys named Battery.* that publish information about the battery. http://maemo.gitorious.org/maemo-af/contextkit/blobs/master/spec/core.context Using the above URL, just scroll down till you get to the battery section to find out what keys are available. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [meego-packaging] QtMobility has branched
On 10/05/2010 01:18 AM, alex.blas...@nokia.com wrote: -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Rusty Lynch So... if I'm reading this correct then we are skipping past the entire mobility 1.1 stabilization and immediately pushing the bleeding edge work which will eventually become mobility 1.2? I fear that this is going to cause havoc on application development process if we see constant breakage on a very critical set of API's. How about we push in the mobility 1.1 beta into Trunk, followed by beta?/rc?/final-release, and then hold off on pushing in 1.2 till the code is a bit further along (like the first technical preview or beta release?) Perhaps host a sandbox for the cutting edge mobility-1.2-hasn't-hit-tp-yet for those that really need it? In principle I kind of agree with Rusty but the practical implications may ruin this. The Mobility 1.2/master branch is going to be open battleground and regressions are to be expected. Where I see the problem is on the backend side of things. A lot of our Mobility API's will only get their Meego backend during the Mobility 1.2 development phase. Hence a push of 1.1 libraries may bring the API to Meego but the backend may not exist yet. The question becomes what is more important. Having the library/API early without a potential backend or having only those libraries which work already (the ones kind of working already are: Bearer, SFW, Sensors, Messaging, Versit - biggest gap would be Positioning, Contacts, Organizer) In any case QMF should not be a problem. Mobility 1.1 and 1.2 use the new QMF headers already. Perhaps we can pull in mobility 1.2 a bit earlier then we would pull in the tip of a project, but before the 1.1 has even been released? Do we already have a significant body of additional backends in existence today in the tip of master that the backend developers feel is ready to be used? If these new back-ends are not yet in place (or in place but not usable) then I would ask that we hold off for a bit longer and for now integrate the 1.1-beta. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [meego-packaging] QtMobility has branched
On 10/04/2010 01:17 AM, fathi.bou...@nokia.com wrote: Hi Alex branched 1.1 QtMobility today, so the 'master' branch of the mobility repo will contain the workings of QtMobility 1.2, which will add support for Meego. http://qt.gitorious.com/qt-mobility/qt-mobility QtMobility 1.2 is targeted for MeeGo 1.2. From the packaging point of view, we'll skip 1.1.x and upcoming Trunk packages will based on master branch. QtMobility packages based on master branch are ready in our staging area. These packages requires QMF 2010w36. Please be advised, several renaming changes have been made to QMF. These changes are unfortunately source and binary incompatible and will require software dependent on QMF to be updated. Please see below for details: - libmessageserver -> libqmfmessageserver - libqtopiamail -> libqmfclient - qtopiamailfile -> qmfstoragemanager These changes are illustrated in this commit: http://qt.gitorious.org/qt-labs/messagingframework/commit/d3640202abeced192a89ec57b90fdb30e1aa551b From a MeeGo packaging point of view: pkgconfig(qtopiamail) -> pkgconfig(qmfclient) So... if I'm reading this correct then we are skipping past the entire mobility 1.1 stabilization and immediately pushing the bleeding edge work which will eventually become mobility 1.2? I fear that this is going to cause havoc on application development process if we see constant breakage on a very critical set of API's. How about we push in the mobility 1.1 beta into Trunk, followed by beta?/rc?/final-release, and then hold off on pushing in 1.2 till the code is a bit further along (like the first technical preview or beta release?) Perhaps host a sandbox for the cutting edge mobility-1.2-hasn't-hit-tp-yet for those that really need it? --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] libmeegotouch development location?
On 07/06/2010 04:31 PM, Robin Burchell wrote: Hi, First: excuse the cross-post, I'm doing this purely because meego-touch-dev@ seems to not be getting any traffic at all, so, it's a just-in-case it isn't working. Please keep replies on meego-touch-...@. I'm a little curious about where the correct location for libmeegotouch (previously libdui) development is. There are now two enlistments on Gitorious: - http://qt.gitorious.org/maemo-6-ui-framework/ - http://meego.gitorious.org/meegotouch Both of which seem quite lively based on recent activity. Hopefully someone can clarify this for me. All activity on the libdui repo has stopped, with the last commit providing a message that all activity has moved to the libmeegotouch URL: http://qt.gitorious.org/maemo-6-ui-framework/libdui/commit/29c37d8113a8eec168e10aa751c0a8b3e067015e ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] DBus tutorials
On 06/23/2010 04:39 AM, Patrick Ohly wrote:
On Wed, 2010-06-23 at 11:35 +0100, ronan.maclave...@nokia.com wrote:
Do the DBus bindings for Qt (QDbus) work on MeeGo? It has some nice
features like an interface compiler (qdbusxml2cpp).
That depends on the content of the XML interface definition and how it
is installed.
How we do it in SyncEvolution is:
* .xml files go into /usr/share/dbus-1/interfaces/ as part of the
development package.
* These files need
elements for the more complex types.
* dbus-binding-tool for glib-dbus does not like annotations in
specifications, so we filter out the annotations when
building the GTK sync-ui.
But I'm far from being an expert on this. I don't know whether all
projects with D-Bus interfaces already have the necessary QDBus
annotations.
This only happens when the signature is more complex then what
qdbusxml2cpp understands. I've created a bunch of proxies for such
things as udisks and libsocialweb, and I have found a few of signatures
that confused the tool, but so for nothing that i needed (i.e. i just
comment out the method/signal in the xml and re-run the tool.)
So far I've hit:
* a(ssxa{ss})
* a{ss}
* a(td)
* a(ssbbbu)
...but i haven't filed a Qt bug yet.
--rusty
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] multimedia architecture
On 06/22/2010 08:37 AM, Ross Burton wrote: On Tue, 2010-06-22 at 08:22 -0700, Arjan van de Ven wrote: > same reason we needed a gst-clutter "abstraction" for Moblin; to > make it easier to display/play simple media inside an application > that uses the MeeGo apis.. and minimize the work an app developer > needs to do Actually clutter-gst contains new elements that bridge Clutter and GStreamer, no abstractions. The Qt API solves a similar problem for rendering video into a QGraphicsWidget contained in a QGraphicsView (much like a clutter-gst actor displayed in a clutter scene.) For the simple case where you don't need to construct a specialized pipeline then playing a video in a QGraphicsView is brain-dead easy. If this is all an app needs (like an app for browsing and playing movie trailer feeds from yahoo or apple), then the app developer doesn't really need to know or care about the rest of the media stack. So... with that said... I haven't heard any real requirements from the original post, so I have no idea which route is the best choice for this specific problem. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] app component model
On 03/25/2010 12:18 PM, Robinson Tryon wrote: On Thu, Mar 25, 2010 at 2:21 AM, Mr. Todorov Todor wrote: > Hello Meego people, I would like to ask what is the community > opinion about using open binder in Meego > http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.html > > The "OpenBinder" license for the project is listed here: http://www.angryredplanet.com/~hackbod/openbinder/docs/html/License.html (oh boy, license proliferation...) As far as I can tell this license has not been reviewed by OSI, FSF, or debian-legal. At first glance I didn't see anything to indicate that the license wouldn't be deemed open/free, but I only glanced at it. If there's any interest in this software, one of the first things to do is to make sure that this license is a FOSS license. The first step before really considering this kernel module is to have it accepted into Linus' git tree. The license is just one of the things that will get a lot of scrutiny from a public LKML review. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Context provider (Connecting to deprecated signal)
On 03/23/2010 11:02 PM, Zhang, Xing Z wrote:
Hi Marius:
I am trying to write a provider for properties “Screen.TopEdge” and
“Screen.IsCoevered”. When provider starting, it complains “Connecting
to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)”.
From the contextkit-commander, TopEdge/IsCoverded show UNKNOWN and no
provider listed in last column.
I use C-API of libcontextprovider, the code is quite simple:
const char* screen_group[] = {
"Screen.TopEdge",
"Screen.IsCovered",
NULL,
};
context_provider_init (DBUS_BUS_SESSION,
"com.intel.meego.provider");
context_provider_install_group ((char**)screen_group, TRUE,
screen_group_cb, NULL);
…..
context_provider_set_string ("Screen.TopEdge", "top");
/* set others when properly */
I am not sure what “deprecated signal” means. Does it indicate
TopEdge/IsCoverded properties are not valid to contextkit? If so,
what replacements for them?
one more thing, will context-commander monitor runtime change of each
property? I assume it will.
I don't think the warning has anything to do with the content (i.e. your
specific signal), but to the
/QDBusConnectionInterface/::/serviceOwnerChanged/ method provided by
dbus. I can see that qt4 is taking advantage of this deprecated method
all over the place, and causing this warning from many applications.
--rusty
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
