Active Topics

 


Reply
Thread Tools
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#1
I have a question for the Qt gurus. I want to provide a GUI for a daemon that reads the accelerometer device file many times per second. Realistically, the frontend will probably be running any time that the back end is, so is there a good reason to separate the two processes and have them communicate with dbus or other IPC, or should i just combine them?
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful
 
Posts: 3,428 | Thanked: 2,856 times | Joined on Jul 2008
#2
You could use threads.. and just emit some signals to update the GUI.

That's how I handle the time remaining/total with my app. It updates every second and then throws up a signal.

Not sure how Threads would work in C++ though... dbus might be easier

ETA: Actually.. QT itself brings thread support. It can be done in C++ as well.
__________________
If I've helped you or you use any of my packages feel free to help me out.
-----------------------------------------------------------------------------------
Maintaining:
pyRadio - Pandora Radio on your N900, N810 or N800!

Last edited by fatalsaint; 2010-02-24 at 02:43.
 

The Following User Says Thank You to fatalsaint For This Useful Post:
Posts: 307 | Thanked: 157 times | Joined on Jul 2009 @ Illinois, USA
#3
pid_t processID = fork();
 
pycage's Avatar
Posts: 3,404 | Thanked: 4,474 times | Joined on Oct 2005 @ Germany
#4
Originally Posted by Flandry View Post
I have a question for the Qt gurus. I want to provide a GUI for a daemon that reads the accelerometer device file many times per second. Realistically, the frontend will probably be running any time that the back end is, so is there a good reason to separate the two processes and have them communicate with dbus or other IPC, or should i just combine them?
If only your app uses the data, I wouldn't separate the process into GUI and daemon. There are already a lot of daemons running on the device. Using threads would be the easiest. You could pass the communication over a synchronized queue. This should be doable in any language.
__________________
Tidings - RSS and Podcast aggregator for Jolla - https://github.com/pycage/tidings
Cargo Dock - file/cloud manager for Jolla - https://github.com/pycage/cargodock
 

The Following 2 Users Say Thank You to pycage For This Useful Post:
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#5
I could use threads, i suppose. I guess that's what i'm wondering, not knowing much about how Qt works: should i? Is it possible to have an app control its own timing if it is a Qt app? Does it even need a separate thread?
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful
 
Posts: 2,014 | Thanked: 1,581 times | Joined on Sep 2009
#6
A nice example of Qt threading updating a GUI

http://qt.nokia.com/doc/4.0/network-...uneclient.html

Essentially you have a thread that emits a signal and that signal is caught and updates the GUI. So in your case you would have two files, one for the gui (or as many as you need) which then fires up the monitoring thread code which emits updateData and updates your gui.

As far as querying the accelerometer I plead ignorant about that but on other phones I have coded for its possible to set the rate at which you query.
__________________
Class .. : Power Poster, Potential Coder
Humor .. : [*********] Alignment: Chaotic Evil
Patience : [***-------] Weapon(s): +2 Logic Mace
Agro ... : |*****-----] Relic(s) : G1, N900

 

The Following User Says Thank You to Bratag For This Useful Post:
Posts: 415 | Thanked: 732 times | Joined on Jan 2009 @ Finland
#7
I would do the listening in it's own thread and send signals from that thread to the UI when something changes. Threads are pretty easy to use with Qt. You can also use timers and poll for the changes but I think threading is a better solution.

http://doc.trolltech.com/4.6/qthread.html#details
 

The Following User Says Thank You to timoph For This Useful Post:
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#8
Ok, will consider doing threads then. Thanks for the suggestions.

It might be time to put into practice all the garbledygook about semaphores and mutexes and stuff from the OS class years back.
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful
 
bbns's Avatar
Posts: 101 | Thanked: 129 times | Joined on Oct 2009 @ Los Angeles, CA
#9
You may want to look at this as well:
http://labs.trolltech.com/blogs/2010...nt-in-threads/
__________________
Hi, I am from Nokia Research Center, Hollywood.
 
Reply


 
Forum Jump


All times are GMT. The time now is 11:31.