![]() |
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
Quote:
|
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
Quote:
I use this both to capture going fullscreen or normal screen, but also for screen rotations. I agree that the forcerotation was a hack. And I was able to get rid of that by adding setAttribute(Qt::WA_Maemo5AutoOrientation, true); But I don't need another signal/slot to figure out whether I am in portrait or landscape mode (I just care about the window ize). So thanks for the feedback. Davy |
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
Quote:
does not compile for MeeGo ('WA_Maemo5AutoOrientation' is not a member of 'Qt'). So I had to '#ifdef Q_WS_MAEMO_5' that instruction. The latest build of today is available on http://davy.preuveneers.be/phoneme/public/maemo/deb/ Though on the N9, I don't think you will see any auto-rotation. There seems to be an approach to wrap QWidgets in a QML project to support auto-rotation. http://www.developer.nokia.com/Commu...d-N9-qt-Widget I will first have a look at that before I go and restart rewriting the UI frontend. Davy |
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
I am just running Opera on my N900 with this, and every version works beautifully for me, with few exceptions.
|
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
Quote:
When I am back home I will post some other Maemo5 specifics for fullscreen that might boost performance even further. |
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
Quote:
|
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
Quote:
or landscape mode, i.e. I don't need the window size to decide if I am in landscape or portrait mode. I need the windows size for other purposes. Let me try to explain this: The phoneME backend is responsible for rendering a midlet in a virtual framebuffer, i.e. a 16-bit RGB buffer of size width*height. The Qt4 frontend then draws this buffer (after wrapping it in a QPixmap). If the width or height changes (after going full screen or after rotation), I get a Qt4 window resize event, and pass along the new width and height to the phoneME backend so it can update its RGB buffer accordingly. Furthermore, since phoneME is drawing in a virtual framebuffer, it only needs to know what the width and height of the framebuffer is, not whether it is running in portrait or landscape mode. Basically, the Qt4 front-end is only responsible for displaying a 16-bit RGB buffer and for redirecting all pointer and keyboard events to the phoneME backend. The phoneME backend informs the Qt4 front-end when the 16-bit RGB buffer has changed so that the front-end can repaint it again. Next to that the front-end also notifies the backend about window size changes, and can also draw text on the RGB buffer using the local font (if you are not using the monospace bitmap built-in font). The phoneME backend does not use any Qt4 at all. Anyway, I am looking forward to any tips you may have to further improve the full screen drawing performance. Cheers, Davy |
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
Another request for N9 owners:
In my latest meego build available from http://davy.preuveneers.be/phoneme/public/maemo/deb/ I added some sound feedback for MIDP alerts. As the N9 emulator does not seem to be producing any sound, could you check if you hear anything when running the microemu demo midlet (Alert->Alarm alert etc). You are supposed to hear some wav samples from /usr/share/sounds/ui-tones/ snd_default_beep.wav snd_warning.wav snd_information.wav snd_query.wav snd_warning_strong.wav Thanks, Davy |
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
Quote:
|
Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
My God!!! You added the sound support?!?!?!
Oh God!!! !!!!!!A M A Z I N G!!!!!!! thx thx thx thx thx!!!!!!!!!!!! U made my day!!!! |
All times are GMT. The time now is 10:32. |
vBulletin® Version 3.8.8