Re: detect window iconified/maximized in SDL
On Tue, 2009-03-24 at 22:23 +0100, ext W. de Hoog wrote: Hi, I would like to detect when an SDL application gets iconified. Than I can pause it to save power. In theory the SDL_ACTIVEEVENT should be generated and event.active should give me the info I need however I do not get these type of events. Anybody know of how to get the correct events or another way to detect the iconification? In Diablo, you can probably receive notification when WM_STATE changes to IconicState (WM_STATE is described in http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.3.1) somehow with SDL. In Fremantle, we are not using the iconic state and you need to track _MB_CURRENT_APP_WINDOW property on the root window to see if you are visible. I think SDL knows nothing of this property, but maybe the support could be added there... -Kimmo regards, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: detect window iconified/maximized in SDL
On Wed, 2009-03-25 at 09:14 +0100, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Tue, 2009-03-24 at 22:23 +0100, ext W. de Hoog wrote: Hi, I would like to detect when an SDL application gets iconified. Than I can pause it to save power. In theory the SDL_ACTIVEEVENT should be generated and event.active should give me the info I need however I do not get these type of events. Anybody know of how to get the correct events or another way to detect the iconification? BTW. another, perhaps a simpler, way with SDL is to track the FocusOut and FocusIn events. I think our pre-installed games do that. So when your window has the focus, run it, otherwise keep it paused. BR; Kimmo In Diablo, you can probably receive notification when WM_STATE changes to IconicState (WM_STATE is described in http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.3.1) somehow with SDL. In Fremantle, we are not using the iconic state and you need to track _MB_CURRENT_APP_WINDOW property on the root window to see if you are visible. I think SDL knows nothing of this property, but maybe the support could be added there... -Kimmo regards, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: detect window iconified/maximized in SDL
Hi,
From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org]
On Behalf Of Hamalainen Kimmo (Nokia-D/Helsinki)
On Wed, 2009-03-25 at 09:14 +0100, Hamalainen Kimmo (Nokia-D/Helsinki)
I would like to detect when an SDL application gets iconified. Than I
can pause it to save power. In theory the SDL_ACTIVEEVENT should be
generated and event.active should give me the info I need however I do
not get these type of events.
Note that it's not enough just to use SDL function to wait for events when it's
invisible / idle. SDL does 10Hz polling even when waiting for events which will
drain battery pretty soon. (I filed a bug about that for upstream SDL several
years ago, it's still not fixed, but there's a broken patch available.)
Because of this, in my own SDL code I use select() when the process should
be idle in RAM longer times without draining battery. You can get the SDL X
socket file descriptor like this:
--
/**
* Return the X connection socket or zero
*/
static int GetUISocket(void)
{
SDL_SysWMinfo info;
SDL_VERSION(info.version);
if (!SDL_GetWMInfo(info)) {
return 0;
}
return ConnectionNumber(info.info.x11.display);
}
Your program could use something like that also with an an explicit (user
invoked)
pause functionality.
- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: osso, muali , dbus and Qt closeEvent()s
Haloo! On Tue, 2009-03-24 at 18:49 +0100, ext David Greaves wrote: Kimmo Hämäläinen wrote: On Mon, 2009-03-23 at 14:44 +0100, ext David Greaves wrote: Hi Crossposting as I think this is a maemo-dev question of interest to Qt devs :) I am having a problem with my Qt applications and the osso window manager. Essentially the window manager is doing a sigkill which doesn't allow Qt to emit a closeEvent(). You mean D-Bus daemon is killing you 20-30s after you are D-Bus activated? No. I know about that one :) ah, and as I write this I see Antonio has solved it :) \o/ But we still have issues Maybe looking at this example helps: https://garage.maemo.org/svn/maemoexamples/tags/maemo_4.1/maemopad/ Yes, used that - happy with osso_initialize() I actually would like to know what osso_initialize() should do so we can do the right things in a Qt app though. And your name appears a lot in the source Kimmo :) The code is not that hard to follow, just take a look. (Btw. most of the code/API was not written by me.) Basically it just connects to D-Bus busses and allows further use of libosso functions to abstract some D- Bus messaging/signals. Digging into libosso and libossowm/osso-rpc.c I find #define HILDON_DESKTOP_SERVICE com.nokia.hildon-desktop #define HDWM_STARTUP_NOTIFICATION_IFACE com.nokia.hildon.hdwm.startupnotification #define HDWM_OBJECT_PATH/com/nokia/hildon/hdwm #define HDWM_STARTUP_NOTIFICATION_STARTING starting You don't need this. It's just for the Loading... banner in Diablo. OK - but do you have a list of things that we should do to make Qt equivalent to gtk? Gtk does not use Libosso :) I seem to recall things like dbus messages on low memory and others. Are these documented? Check osso-hw.c. Code is still in SVN (login: guest/guest): https://stage.maemo.org/svn/maemo/projects/haf/trunk/libosso/src/ The banner would be nice - but the dbus services listed above don't seem to be correct - and I can't find them using a dbus introspect (qdbusviewer) ie this bit (from original email) We don't have that in Fremantle. We have a new service for starting applications in hildon-desktop. You can learn these API things from http://www7.connecting.nokia.com/nmp/osso/ossodm.nsf/WebAllByID2/DSD07052-EN (currently in Nokia intranet only) Message:Method starting with signature on interface com.nokia.hildon.hdwm.startupnotification doesn't exist I installed qdbusmonitor and com.nokia.hildon-desktop doesn't provide hdwm.startupnotification or starting Nor do I see it on the dbus-monitor --session when my gtk app runs. Are you in a postion to help us write the Qt equivalent of osso_initialize() and help make Qt == Gtk As I said, Hildon widgets and Gtk do not use libosso at all (it would be quite ugly since libosso depends on D-Bus connections). BR; Kimmo David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gsoc Idea Barcode Reader
Hi , thanks for the comments received here . Based on that i have submitted a proposal . Please be kind and review and also please give suggestions as to how it can be improved . I would also like to know. What could be my next steps . And how I could start getting involved. On Mon, Mar 23, 2009 at 2:53 PM, Simon Pickering s.g.picker...@bath.ac.ukwrote: Hi Steffen, some month ago i tried to port http://zebra.sourceforge.net/ to the maemo platform. The Zebra Barcode Reader can decode barcodes from a live video stream (v4l) an static images (jpeg, bmp, etc.). Thanks for the pointer. For maemo-barcode we currently use the main logic provided by the Batoo project (http://people.inf.ethz.ch/adelmanr/batoo/), but it looks like zebra decodes more types of 1D barcode so I'll have a look at it. If im informed correctly, the n810's webcam has also a v4l interface that could be used for the barcode decoding. It should be quite easy to port it. Its coded in C and its sourcecode is available. I'll try to get it compiled in the week. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- A-M-I-T S|S ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: osso, muali , dbus and Qt closeEvent()s
Kimmo Hämäläinen wrote: Haloo! Hi The code is not that hard to follow, just take a look. (Btw. most of the code/API was not written by me.) Basically it just connects to D-Bus busses and allows further use of libosso functions to abstract some D- Bus messaging/signals. OK. Searching for dbus interfaces etc will probably help here. OK - but do you have a list of things that we should do to make Qt equivalent to gtk? Gtk does not use Libosso :) I meant gtk apps need to use osso-initialize() or they just don't work. Since libosso uses glib, I expect that's not really right for Qt apps. In particular I think osso-init.c calls glib setups that seem to hook into the glib context and I think the glib main loop - not used in Qt apps. eg line 503 in osso-init.c calls dbus_connection_setup_with_g_main() which: Sets the watch and timeout functions of a DBusConnection to integrate the connection with the GLib main loop. see: http://dbus.freedesktop.org/doc/api/html/group__DBusGLib.html#ga754eed235cc2b8153bd8f824b687d9e so libosso, as it stands, isn't suitable for Qt apps unless I'm confused :) I seem to recall things like dbus messages on low memory and others. Are these documented? Check osso-hw.c. Code is still in SVN (login: guest/guest): https://stage.maemo.org/svn/maemo/projects/haf/trunk/libosso/src/ Good pointer... yep, things like: com.nokia.dsme.signal shutdown_ind and save_unsaved_data_ind We don't want Qt apps ignoring these do we? The banner would be nice - but the dbus services listed above don't seem to be correct - and I can't find them using a dbus introspect (qdbusviewer) ie this bit (from original email) We don't have that in Fremantle. Currently I'm looking at Diablo... We have a new service for starting applications in hildon-desktop. You can learn these API things from http://www7.connecting.nokia.com/nmp/osso/ossodm.nsf/WebAllByID2/DSD07052-EN (currently in Nokia intranet only) Ah, I don't have that - can you post it? As I said, Hildon widgets and Gtk do not use libosso at all (it would be quite ugly since libosso depends on D-Bus connections). agreed - I am not sure how best to proceed with Qt - one of the trolls (I think) suggested extending QSession. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: detect window iconified/maximized in SDL
Hi, Note that it's not enough just to use SDL function to wait for events when it's invisible / idle. SDL does 10Hz polling even when waiting for events which will drain battery pretty soon. (I filed a bug about that for upstream SDL several years ago, it's still not fixed, but there's a broken patch available.) That is sad. I was thinking of using an SDL semaphore in the main loop that is locked/unlocked when osso notifies of display on/off. This would not do much then I guess. Because of this, in my own SDL code I use select() when the process should be idle in RAM longer times without draining battery. You can get the SDL X socket file descriptor like this: Please forgive my ignorence but I do not understand the link between select() and GetUISocket(). -- Willem-Jan de Hoog ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gsoc Idea Barcode Reader
Hello, 2009/3/25 amit sethi amit.pureene...@gmail.com: Hi , thanks for the comments received here . Based on that i have submitted a proposal . Please be kind and review and also please give suggestions as to how it can be improved . I would also like to know. What could be my next steps . And how I could start getting involved. The proposal reviews will start in the next Friday/Saturday. In the meantime you can learn more about Maemo, install the SDK[1] and read some docs[2] available in our website. [1] - http://maemo.org/development/sdks/ [2] - http://maemo.org/development/training/ Best regards, -- Valério Valério http://www.valeriovalerio.org On Mon, Mar 23, 2009 at 2:53 PM, Simon Pickering s.g.picker...@bath.ac.uk wrote: Hi Steffen, some month ago i tried to port http://zebra.sourceforge.net/ to the maemo platform. The Zebra Barcode Reader can decode barcodes from a live video stream (v4l) an static images (jpeg, bmp, etc.). Thanks for the pointer. For maemo-barcode we currently use the main logic provided by the Batoo project (http://people.inf.ethz.ch/adelmanr/batoo/), but it looks like zebra decodes more types of 1D barcode so I'll have a look at it. If im informed correctly, the n810's webcam has also a v4l interface that could be used for the barcode decoding. It should be quite easy to port it. Its coded in C and its sourcecode is available. I'll try to get it compiled in the week. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- A-M-I-T S|S ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: osso, muali , dbus and Qt closeEvent()s
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Greaves wrote: I meant gtk apps need to use osso-initialize() or they just don't work. Since libosso uses glib, I expect that's not really right for Qt apps. In particular I think osso-init.c calls glib setups that seem to hook into the glib context and I think the glib main loop - not used in Qt apps. eg line 503 in osso-init.c calls dbus_connection_setup_with_g_main() which: Sets the watch and timeout functions of a DBusConnection to integrate the connection with the GLib main loop. see: http://dbus.freedesktop.org/doc/api/html/group__DBusGLib.html#ga754eed235cc2b8153bd8f824b687d9e so libosso, as it stands, isn't suitable for Qt apps unless I'm confused :) Actually Qt has supported GLib context stuff since 4.2 (IIRC), so libosso is suitable. That doesn't say that it's practical or nice, but it should work. - -- Santtu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknKghEACgkQX9Rc0+po4p3zUQCgmZLaGy3jTDm3YuCbkuh7OZE4 2J4An3avfLa5Elu8eo94IbW1srViA8aw =ozXP -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
kernel source and maemo fremantle
Hi all, I'd like to know if I can do make n800_defconfig to set the proper kernel configs for fremantle. I'm proceeding like this, but when I try to compile the kernel, I got many errors. Is the kernel for fremantle ready/reviewed to be compiled? I need to compile fuse (http://fuse.sourceforge.net/) for fremantle to test some applications that I have developed, but when I try to compile it, I got many errors and maybe this is due to wrong kernel setup. Is there plans to release fremantle with fuse modules? Thank you, Leandro. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: osso, muali , dbus and Qt closeEvent()s
Hi, IMHO using the Qt D-Bus API to rewrite some parts of libosso is more easy that resolve the symobls, load and use libosso in Qt. Kimmo said adding D-Bus dependencies in the widget is ugly, I agree with him.. but... is this also true for the QStatusBar? In Qt we have a statusBar that manages and displays messages. Currently this status bar is hidden just because we don't have it in Hildon. I don't compiled out in order to preserve the compatibility with the Qt Desktop application. Adding D-Bus into the status bar, we can display messages using hildon passive notification dialogs just calling void QStatusBar::showMessage ( const QString message, int timeout = 0 ). Is it cool? Any comment is welcome. Cheers, Antonio On Wed, Mar 25, 2009 at 9:12 PM, Santtu Lakkala i...@inz.fi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Greaves wrote: I meant gtk apps need to use osso-initialize() or they just don't work. Since libosso uses glib, I expect that's not really right for Qt apps. In particular I think osso-init.c calls glib setups that seem to hook into the glib context and I think the glib main loop - not used in Qt apps. eg line 503 in osso-init.c calls dbus_connection_setup_with_g_main() which: Sets the watch and timeout functions of a DBusConnection to integrate the connection with the GLib main loop. see: http://dbus.freedesktop.org/doc/api/html/group__DBusGLib.html#ga754eed235cc2b8153bd8f824b687d9e so libosso, as it stands, isn't suitable for Qt apps unless I'm confused :) Actually Qt has supported GLib context stuff since 4.2 (IIRC), so libosso is suitable. That doesn't say that it's practical or nice, but it should work. - -- Santtu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknKghEACgkQX9Rc0+po4p3zUQCgmZLaGy3jTDm3YuCbkuh7OZE4 2J4An3avfLa5Elu8eo94IbW1srViA8aw =ozXP -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Isaac Asimov - I do not fear computers. I fear the lack of them. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Getting a Segmentation Fault in scratchbox when compiling gtk_helloworld
Resolved. Well, not really. It does appear to be a bug in Bash. However, I realized that I wasn't using back-ticks for pkg-config, now it works fine. I feel a little dumb. Cheers, Daniel Date: Tue, 24 Mar 2009 16:44:32 +0100 From: eero.tammi...@nokia.com Subject: RE: Getting a Segmentation Fault in scratchbox when compiling gtk_helloworld To: maemo-developers@maemo.org Message-ID: 43957a0aa6b4ce4aa7d0e2f5e1474ee03099cc3...@nok-eumsg-04.mgdnok.nokia.com Content-Type: text/plain; charset=us-ascii Hi, I am trying to get scratchbox and maemo up and running in Ubuntu. While following the Testing the Installation walk through from the Diablo documentation I ran into this: ... This occured immediately when trying to compile. No other error messages were recieved prior. Sbox exits, and then I have to close and reopen the terminal or I can't see any text that I input. Any insight into this would be appreciated. I guess you had started to edit a previously entered line? In that case it would be a bug in the Sbox Bash version command line history handling. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: detect window iconified/maximized in SDL
Hi, BTW. another, perhaps a simpler, way with SDL is to track the FocusOut and FocusIn events. I think our pre-installed games do that. So when your window has the focus, run it, otherwise keep it paused. When I listen to SDL_SYSWMEVENT I get xevent type 33 when I switch to my app or switch away from it (the app is fullscreen only). The data seems always to be 0 so I do not know if focus is in or out. Code I use: case SDL_SYSWMEVENT: printf(Xevent: %d:%d, event.syswm.msg-event.xevent.type, event.syswm.msg-event.xevent.xclient.format); printf( %d:%d, event.syswm.msg-event.xevent.xclient.data.b[0], event.syswm.msg-event.xevent.xclient.data.s[0]); printf( %d\n, event.syswm.msg-event.xevent.xclient.message_type); output is: Xevent: 33:8 0:0 327 Xevent: 33:8 0:0 327 -- Willem-Jan de Hoog ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: kernel source and maemo fremantle
ext Leandro Sales wrote: Hi all, I'd like to know if I can do make n800_defconfig to set the proper kernel configs for fremantle. Try rx51_defconfig or rx51_tiny_defconfig. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
osso display event callback not called back
Hi, In my SDL app I set my callback using: osso_hw_set_display_event_cb(osso_ctx, osso_cb_display_state, NULL); Right after being set the callback is called with state OSSO_DISPLAY_ON. When the display is dimmed, goes off or on again it is unfortunately not called anymore. Does anybody know more about this? regards, -- Willem-Jan de Hoog ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: osso, muali , dbus and Qt closeEvent()s
It seems to me that the hildon 'platform' uses dbus and if we have some widgets that are designed to interact with the platform environment (like notifiers or session) then, when built for that platform, they can depend on platform specific things. so yes, I thing showMessage should use dbus for WS_HILDON David Antonio Aloisio wrote: Hi, IMHO using the Qt D-Bus API to rewrite some parts of libosso is more easy that resolve the symobls, load and use libosso in Qt. Kimmo said adding D-Bus dependencies in the widget is ugly, I agree with him.. but... is this also true for the QStatusBar? In Qt we have a statusBar that manages and displays messages. Currently this status bar is hidden just because we don't have it in Hildon. I don't compiled out in order to preserve the compatibility with the Qt Desktop application. Adding D-Bus into the status bar, we can display messages using hildon passive notification dialogs just calling void QStatusBar::showMessage ( const QString message, int timeout = 0 ). Is it cool? Any comment is welcome. Cheers, Antonio On Wed, Mar 25, 2009 at 9:12 PM, Santtu Lakkala i...@inz.fi wrote: David Greaves wrote: I meant gtk apps need to use osso-initialize() or they just don't work. Since libosso uses glib, I expect that's not really right for Qt apps. In particular I think osso-init.c calls glib setups that seem to hook into the glib context and I think the glib main loop - not used in Qt apps. eg line 503 in osso-init.c calls dbus_connection_setup_with_g_main() which: Sets the watch and timeout functions of a DBusConnection to integrate the connection with the GLib main loop. see: http://dbus.freedesktop.org/doc/api/html/group__DBusGLib.html#ga754eed235cc2b8153bd8f824b687d9e so libosso, as it stands, isn't suitable for Qt apps unless I'm confused :) Actually Qt has supported GLib context stuff since 4.2 (IIRC), so libosso is suitable. That doesn't say that it's practical or nice, but it should work. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Isaac Asimov - I do not fear computers. I fear the lack of them. -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
