Reply
Thread Tools
krk969's Avatar
Posts: 754 | Thanked: 630 times | Joined on Sep 2009 @ London
#1
Hello people,

Ive just begun my journey with QT on the maemo5 SDK.
Thought Id first try a battery percentage app and then later convert it to a desktop widget.

Im attaching the app here.

Need your help and suggestions here with it.

the app when I try running in the N900 emulator,

1. the progress bar displays 80 first, then 70,60,30,10.
Couldnt figure out why it doesnt go in steps of 10 as ive programmed it, is there some delay while using signals ?

2. as stated in my comments int he code, ive used a simple while loop to simulate the battery percentage value, anyone can suggest an mechanism where i can get an interrupt or signal when the battery percentage value changes ?
I dont want to resort to periodically polling the value returned by lshal | grep percentage, im sure there are better ways.

thanks for any help...
Attached Files
File Type: txt qprogress.cpp.txt (1.2 KB, 254 views)
File Type: txt qprogress.hpp.txt (557 Bytes, 159 views)
 

The Following 5 Users Say Thank You to krk969 For This Useful Post:
krk969's Avatar
Posts: 754 | Thanked: 630 times | Joined on Sep 2009 @ London
#2
Originally Posted by krk969 View Post
Hello people,

Ive just begun my journey with QT on the maemo5 SDK.
Thought Id first try a battery percentage app and then later convert it to a desktop widget.

Im attaching the app here.

Need your help and suggestions here with it.

the app when I try running in the N900 emulator,

1. the progress bar displays 80 first, then 70,60,30,10.
Couldnt figure out why it doesnt go in steps of 10 as ive programmed it, is there some delay while using signals ?

2. as stated in my comments int he code, ive used a simple while loop to simulate the battery percentage value, anyone can suggest an mechanism where i can get an interrupt or signal when the battery percentage value changes ?
I dont want to resort to periodically polling the value returned by lshal | grep percentage, im sure there are better ways.

thanks for any help...
reattached the code files with some formatting, had copied it directly from unix to windows
Attached Files
File Type: txt qprogress.cpp.txt (1.4 KB, 215 views)
File Type: txt qprogress.hpp.txt (643 Bytes, 148 views)
 
krk969's Avatar
Posts: 754 | Thanked: 630 times | Joined on Sep 2009 @ London
#3
just tried adding the following line in the while loop

window->update() // to refresh the objects

now the values go 80,70,60,50,40,30,and 10 :-)
wonder where the 100,90 and 20 dissappear !
 
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#4
IIRC the event loop is started with the QApplication::exec - until that point your signals and slots might not work 'as expected', which brings us to another conclusion -> sending signals from main() is usually wrong
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 

The Following 2 Users Say Thank You to attila77 For This Useful Post:
krk969's Avatar
Posts: 754 | Thanked: 630 times | Joined on Sep 2009 @ London
#5
Originally Posted by attila77 View Post
IIRC the event loop is started with the QApplication::exec - until that point your signals and slots might not work 'as expected', which brings us to another conclusion -> sending signals from main() is usually wrong
thanks for that piece of info attila77, I guess it explains as I "seemed to have solved" the above issue just 30 minutes ago using

app.processEvents()

where app is my QApplication, and the processEvents is processing my pending events which probably didnt execute due to what you mentioned, or maybe ive not understood this well

Anyways, once I did that , it seems to refresh my progressbar for each iteration of the while loop.

But I take your point, thanks.

Last edited by krk969; 2009-12-21 at 00:33.
 
krk969's Avatar
Posts: 754 | Thanked: 630 times | Joined on Sep 2009 @ London
#6
Update on the problems so far.

Problem 1 : is solved now, thanks to Attila77 for clarifying that, but for the moment ive worked around the problem of generating signals in main by calling processEvents on my QApplication to update my widgets.

Problem 2: remains

Problem 3: Im not able to get the output of "lshal | grep percentage" system command using QProcess.
As per my newly attached code , im trying to display the output of the above command in a QTextEdit widget but nothing gets displayed.
As a test I tried to execute even an ls command in unix using QProcess and it still showed no output.

Any help appreciated.

Many thanks.
Attached Files
File Type: tar qprogress.tar (10.0 KB, 128 views)

Last edited by krk969; 2009-12-21 at 01:08.
 
Posts: 236 | Thanked: 223 times | Joined on Oct 2009 @ NE UK
#7
This won't be a massive help with either 2) or 3), but I did notice just now that using

lshal -m

you get continuously updated data on changes detected by the hal daemon.

~# lshal -m

Start monitoring devicelist:
-------------------------------------------------
01:17:36.433: platform_slide property button.state.value = false
01:17:36.629: platform_slide condition ButtonPressed = cover
01:17:37.119: bme property battery.reporting.current = 419 (0x1a3)
01:17:37.164: bme property battery.charge_level.percentage = 33 (0x21)
01:17:54.022: platform_slide property button.state.value = true
01:17:54.049: platform_slide condition ButtonPressed = cover
...
If I run

lshal -m -u /org/freedesktop/Hal/devices/bme

I tell lshal to only show messages about the bme device (this is the bit that monitors the battery, it seems).

Actually, when you run this, for reasons I don't understand, you get a full list from lshal before the monitoring starts. But when it does start, you get to see only messages about the bme.

I'm not suggesting you run this as a shell command inside your program!

Maybe you could think about doing what lshal does in order to accomplish this. The source code is available (a quick google found http://www.koders.com/c/fid5039F7523...99C106B3D.aspx but there's probably a more canonical source)

lshal is hooking into libhal, which is available for you to use on the N900. Maybe you could get libhal to talk to your program when the battery status changes using the function documented here: http://maemo.org/api_refs/4.1/hal-0....perty-modified

I don't know for sure this is the way to do it (you have more experience programming for the N900 than I do! ) but I'd be looking at doing something like that if I tried it. Just some ideas to get you thinking
 

The Following 2 Users Say Thank You to kwotski For This Useful Post:
Posts: 66 | Thanked: 44 times | Joined on Nov 2009
#8
Yeah, kwotski has found just the function you need to use. Go with this method and then you won't need to use a QProcess, so that solves your other problem too.
 

The Following User Says Thank You to kyle For This Useful Post:
krk969's Avatar
Posts: 754 | Thanked: 630 times | Joined on Sep 2009 @ London
#9
thanks Kwotski and Kyle, Ive picked up the lead you gave me, let me see where it takes me
will be posting back my updates as and when I have them.

cheers
 
Posts: 39 | Thanked: 4 times | Joined on Nov 2009
#10
hi,

check the links below "After setting up a connection, listener callbacks can be registered:"

http://www.share-linux.com/hal1.php

http://wiki.maemo.org/Documentation/...ents/Using_HAL


In order to make developers' life easier, the communication to the HAL daemon has been wrapped into a C library. Thus, applications can easily use the services provided by the library to monitor and query different devices. For a complete description of the API, see libhal.h (in package libhal-dev). Here, the basic steps to set up a connection to HAL and some basic functions are described. Error checking etc. are omitted from the examples, for the sake of clarity.

Setting up a connection to HAL is performed as follows:

include <libhal.h>
void set_up(void)
{
LibHalContext *ctx;
DBusConnection *dbus_connection;
DBusError error;
ctx = libhal_ctx_new();
dbus_error_init(&error);
dbus_connection = dbus_bus_get(DBUS_BUS_SYSTEM, &error);
libhal_ctx_set_dbus_connection(ctx, dbus);
/* ... */

After setting up a connection, listener callbacks can be registered:

libhal_ctx_set_device_added (ctx, _device_added);
libhal_ctx_set_device_removed (ctx, _device_removed);
libhal_ctx_set_device_property_modified(ctx, _property_modified);

Finally, initialize the connection and start listening to HAL:

libhal_ctx_init(ctx, &error);
libhal_device_property_watch_all(ctx, &error);

The listener functions and the application in general can obtain information about devices using functions in libhal. For instance, as a device gets connected, the following functions can be used to obtain information about it:

/* If UDI is known (the callbacks provide a UDI for added/removed devices),
existence of specific capabilities can be queried with the following function: */
if(libhal_device_query_capability(ctx, udi, "volume", NULL)) {
/* Capability "volume" exists */
...
}
/* The library also provides plenty of get/set functions for querying specific
information about a device by its UDI. For instance, querying the storage.
drive_type property of the device, which is created by HAL when a memory card
is inserted into the Internet Tablet device, returns 'sd_mmc', indicating an
active memory card reader for SecureDigital/MultiMediaCard memory cards. */
libhal_device_get_property_string (ctx, udi, "storage.drive_type", NULL);

All the query functions follow the same pattern. The HAL specification describes the type of each property. The types can optionally be queried with the 'lshal' tool, which adds type information into its output. For each type, libhal provides a get/set function, such as libhal_device_get_property_string(), libhal_device_get_property_int(), etc. The library also provides functions for listing all devices and their properties: libhal_get_all_devices(), _device_get_all_properties(), if more user-controlled filtering is needed.

Last edited by n900_ag; 2009-12-21 at 11:29.
 

The Following User Says Thank You to n900_ag For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 17:59.