Re: GSoC 2010, eBook reader. Looking for feedback and ideas.

2010-05-07 Thread Ville M. Vainio
On Fri, May 7, 2010 at 2:52 AM, Aniello Del Sorbo ani...@gmail.com wrote:

 It could be done as a separate project (the daemon), so not sure it
 should be integrated in this, actually.

It doesn't even need to be a daemon. It can be an app that fetches the
documents from instapaper and launches the ebook reader.

-- 
Ville M. Vainio
http://tinyurl.com/vainio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Marcin Juszkiewicz
Dnia czwartek, 6 maja 2010 o 18:27:34 Eero Tamminen napisał(a):

 ext Michael Cronenworth wrote:
  At most, the SDK should have been released two weeks ahead of the final
  release.
 
 Agree.

Let me write few words about my view on maemo development.

PR 1.2 introduced at least two nice things for developers to use:

- livesearch in libhildon lists (Contacts, Modest, HAM use it)
- Qt 4.6

But as those are not available for users developers do not use them or are 
writing own implementations of livesearch. I gave up on any Qt related 
programming because Qt 4.5 do not follow UI style and 4.6 is not available for 
users (just for remind: users do not use extras-devel).

I wonder what so hard is in making PR 1.1.2 release which will give Qt 4.6 as 
standard (rather none of nokia apps use it) with 1.1.3 following it with few 
other small updates. We have May now and first talks about releasing PR1.2 
were next week in February...

Currently my n900 runs that leaked image and so far I am fine with it. Apps 
which I use works, things from Extras mostly installs and works (nokia killed 
upstart-job package so good bye IM addons). I will probably update it a bit 
with few new components from local builds etc but that's me - I am not normal 
user.

   -Is PR1.2 still going to be released?
 
 Definitely.

Will it happen before users (and more important: developers) will abandon 
platform or one month after?

Regards, 
-- 
JID:  h...@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Andrea Grandi
Hi

On 7 May 2010 09:53, Marcin Juszkiewicz mar...@juszkiewicz.com.pl wrote:
 I wonder what so hard is in making PR 1.1.2 release which will give Qt 4.6 as
 standard (rather none of nokia apps use it) with 1.1.3 following it with few
 other small updates. We have May now and first talks about releasing PR1.2
 were next week in February...

I was wondering the same thing: why is it so hard to provide a 1.1.2
image with Qt 4.6.2 installed?

-- 
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Nicola Mfb
On Fri, May 7, 2010 at 10:10 AM, Andrea Grandi a.gra...@gmail.com wrote:
[...]
 I was wondering the same thing: why is it so hard to provide a 1.1.2
 image with Qt 4.6.2 installed?

+1

If PR 1.2 has too many problems to be released before *few* days,
please release a 1.1.2 with the updated qt, actually having skype
videocalls or other few things is secondary for the long term success
of your strategy.

I think you have all the interest to have a community of qt developers
around the n900/maemo that may be already mature when symbian v3/meego
will be available, delaying that process further may be very
dangerous.

Regards

  Niko
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Why should I write apps for Maemo?

2010-05-07 Thread tero.kojo
 -Original Message-
 From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-
 boun...@maemo.org] On Behalf Of ext Nicola Mfb
 Sent: 07 May, 2010 11:34
 To: Andrea Grandi
 Cc: maemo-developers@maemo.org
 Subject: Re: Why should I write apps for Maemo?
 
 On Fri, May 7, 2010 at 10:10 AM, Andrea Grandi a.gra...@gmail.com
 wrote:
 [...]
  I was wondering the same thing: why is it so hard to provide a 1.1.2
  image with Qt 4.6.2 installed?

Hindsight 20/20. Back when 1.2 was first considered Qt 4.6 was in alpha or 
beta. Beta software does not go into a pr release.
Later on when 4.6 got final it might have made sense, but as Eero said, the 
release is based on quality and not calendar. And the 1.2 tree had moved 
forward a lot in that time.

 +1
 
 If PR 1.2 has too many problems to be released before *few* days,
 please release a 1.1.2 with the updated qt, actually having skype
 videocalls or other few things is secondary for the long term success
 of your strategy.

Because it would have to be tested to the same extent as the 1.2 image. And 
that is not a few days.

Look, the N900 is a consumer electronics device. That means that normal people, 
like your mother, the guy you passed on the street and the person drinking 
coffee in a cafe use it. Those people cannot handle crashes and bad quality. It 
really is that simple.

Tero

 I think you have all the interest to have a community of qt developers
 around the n900/maemo that may be already mature when symbian v3/meego
 will be available, delaying that process further may be very
 dangerous.
 
 Regards
 
   Niko
 ___
 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: Why should I write apps for Maemo?

2010-05-07 Thread Dawid Lorenz
On 7 May 2010 09:48, tero.k...@nokia.com wrote:

 Look, the N900 is a consumer electronics device. That means that normal
 people, like your mother, the guy you passed on the street and the person
 drinking coffee in a cafe use it. Those people cannot handle crashes and bad
 quality. It really is that simple.



Very good point, seriously. Yet I think Marcin had ever better:

 (Hm. Is Maemo showing its Debian roots?)

 Good attempt for joke but failed. Debian has 'testing' branch which users
 can
 use, test, report bugs against and got them fixed before release. Maemo
 does
 not give any of those.



Releasing test-and-strictly-developer-aka-geek-oriented images on regular
basis would be simply great. Think of it like extras and
extras-testing/devel - yet not for apps, but full-blown OS images. Normal
users should strictly stay away from these, but whole bunch of geek folks
who imho are the essence of Maemo/MeeGo platforms would jump high in joy and
that would definitely keep guys on both sides of the fence relatively happy.
Just my three cents.

Btw, I am also uber-eager to see PR1.2 on my device, especially after seeing
what Eero said about Browser and performance, as currently I simply need to
reboot my N900 every 5-6 days to keep my sanity while using it...

-- 
Dawid 'evad' Lorenz * http://adl.pl

null://google 'no evil' mail has taken away my random signatures
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Andrea Grandi
Hi,

On 7 May 2010 11:44, Dawid Lorenz a...@adl.pl wrote:
 Releasing test-and-strictly-developer-aka-geek-oriented images on regular
 basis would be simply great. Think of it like extras and
 extras-testing/devel - yet not for apps, but full-blown OS images. Normal
 users should strictly stay away from these, but whole bunch of geek folks
 who imho are the essence of Maemo/MeeGo platforms would jump high in joy and
 that would definitely keep guys on both sides of the fence relatively happy.
 Just my three cents.

this is another great idea. If you really belive in the Community
contribution, I think it should be normal to release development (even
daily builds) images. This is what happens usually with a Linux
distribution: final user, for example, will install Ubuntu when it's
officially out, but power-users and community contributor can install
the development version and help with testing and bug reporting.

I think that Nokia could be more open in Maemo development and this is
a solid example.

Regards,

-- 
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Nicola Mfb
On Fri, May 7, 2010 at 10:48 AM,  tero.k...@nokia.com wrote:

[forwarding to the list too]

On Fri, May 7, 2010 at 10:48 AM,  tero.k...@nokia.com wrote:
[...]
 Later on when 4.6 got final it might have made sense, but as Eero said, the 
 release is based on quality and not calendar. And the 1.2 tree had moved 
 forward a lot in that time.

Good point, but it *seems* to be not coerent with the entire
n900/maemo5 launch, that to many users *seems* was based on calendar
(why a front camera without video calls? why skype video calls on pr
1.2 and not umts video calls? are they planned? should we wait for pr
1.3? or meego? but meego will run on n900? n900 is as is, buy the
next meego device for improvements, so why pr 1.2? and so on)

*user opinions I gathered on maemo forum, do not blame me please*

[...]
 Because it would have to be tested to the same extent as the 1.2 image. And 
 that is not a few days.

You may have 3/4 blocker issues on not qt components, while qt may
have passed all the QA tests some months ago, or at least is what I
can perceive as there is no qt 4.6.2.1 or 4.6.3, but I'm an external
guy so can only guess and ask.

 Look, the N900 is a consumer electronics device. That means that normal 
 people, like your mother, the guy you passed on the street and the person 
 drinking coffee in a cafe use it. Those people cannot handle crashes and bad 
 quality. It really is that simple.

Again I have a different view, I'm not so sure that normal peoples
know the word maemo or meego as they know symbian or iphone,
and at least here, in Italy, I do not know a single guy that buyed the
n900 in a normal store, are it's rarely available, and the nokia
market was focused on free gps navigation and n97 (every single
day on main tv!) so it seems not to be targeted to the mass.

And, important, a lot of my friend (linux geeks) buyed the n900 from
poor mass market guys that wanted to give it a try and after 2 weeks
put it on e-bay becouse not complete on the phone/gps side.

In every case this does not mean that quality is not important!, I
want only to communicate as a community rappresentative, that there
is a big (it may be very big) part of n900 users that are linux geeks
and possible developers, and listing for their needs may be good for
Nokia too.

To fix the QA for normal peoples, and the bleeding needs of developers
you have to provide them previews (it seems that qt-sdk, pr 1.2 sdk
and meego already follows that line so it's not so absourd).

In that way you'll assure a free (gratis) testers community while
actually testing happens only inside to Nokia (that has to pay for
that, while it wants to give more man power to meego), and you'll
never get all the use cases that an entire community have.
So, actually, when PR 1.2 will be released if an hided
one-line-commit-to-fix bug will come out, we have to wait again for
3/4 months to have it fixed and pass all the qa tests again, while it
may be discovered before by the community on the preview images.

But I may be totally wrong about that, in that case ignore all my words :)

Going positive, I understand that the community stress is at least
comparable to the one of nokia developers and administrators, so
really hoping you the best in these hot days!

Regards

  Niko
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Why should I write apps for Maemo?

2010-05-07 Thread Matan Ziv-Av

On Fri, 7 May 2010, tero.k...@nokia.com wrote:


-Original Message-
From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-
boun...@maemo.org] On Behalf Of ext Nicola Mfb
Sent: 07 May, 2010 11:34
To: Andrea Grandi
Cc: maemo-developers@maemo.org
Subject: Re: Why should I write apps for Maemo?

On Fri, May 7, 2010 at 10:10 AM, Andrea Grandi a.gra...@gmail.com
wrote:
[...]

I was wondering the same thing: why is it so hard to provide a 1.1.2
image with Qt 4.6.2 installed?


Hindsight 20/20. Back when 1.2 was first considered Qt 4.6 was in 
alpha or beta. Beta software does not go into a pr release. Later on 
when 4.6 got final it might have made sense, but as Eero said, the 
release is based on quality and not calendar. And the 1.2 tree had 
moved forward a lot in that time.


When you say 1.2 tree had moved forward, do you mean that the source 
packages in PR1.2 SDK are not the source of the actual packages that 
will be in PR1.2? Can we get updated source packages?


I am specifically interested in hildon-desktop packages 
(hildon-desktop, hildon-home, hildon-status-menu, etc.), and libhildon.





--
Matan Ziv-Av. ma...@svgalib.org


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Marcin Juszkiewicz
Dnia piątek, 7 maja 2010 o 13:21:53 Matan Ziv-Av napisał(a):
 When you say 1.2 tree had moved forward, do you mean that the source 
 packages in PR1.2 SDK are not the source of the actual packages that 
 will be in PR1.2? Can we get updated source packages?

Leaked image has newer packages then PR1.2 SDK has.

Regards, 
-- 
JID:  h...@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: N900 Linux console output for debugging

2010-05-07 Thread Kaj-Michael Lang
On Thu, 2010-05-06 at 13:00 +0200, Thomas Perl wrote:
 Hello!
 
 I'm currently playing with booting images on the N900 using a loopback
 device and bootmenu. The problem is that booting sometimes hangs, and
 I want to debug this. I've enabled the framebuffer console on the
 device, so I can see the early boot messages, but the five dots keep

Using your own custom kernel or is there some other way to enable proper
boot messages?


-- 
Kaj-Michael Lang mil...@tal.org

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Why should I write apps for Maemo?

2010-05-07 Thread Kimmo Hämäläinen
On Fri, 2010-05-07 at 13:21 +0200, ext Matan Ziv-Av wrote:
 On Fri, 7 May 2010, tero.k...@nokia.com wrote:
...
 I am specifically interested in hildon-desktop packages 
 (hildon-desktop, hildon-home, hildon-status-menu, etc.), and libhildon.

Those are all developed in completely open Gitorious.  Just compile it
from there (most of them have 1.2 branches). Everything on the way to
pr1.2 is already there:

http://maemo.gitorious.org/fremantle-hildon-desktop
http://maemo.gitorious.org/hildon

-Kimmo

 
 
 
 

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Why should I write apps for Maemo?

2010-05-07 Thread Matan Ziv-Av

On Fri, 7 May 2010, Kimmo Hämäläinen wrote:


On Fri, 2010-05-07 at 13:21 +0200, ext Matan Ziv-Av wrote:

On Fri, 7 May 2010, tero.k...@nokia.com wrote:

...

I am specifically interested in hildon-desktop packages
(hildon-desktop, hildon-home, hildon-status-menu, etc.), and libhildon.


Those are all developed in completely open Gitorious.  Just compile it
from there (most of them have 1.2 branches). Everything on the way to
pr1.2 is already there:

http://maemo.gitorious.org/fremantle-hildon-desktop
http://maemo.gitorious.org/hildon


For hildon-desktop I see a list of 27 branches. Among them is one called 
PR1_1, but none called PR1_2. Similarly for the rest of the packages. 
What branch contains the exact code that is expected to be in PR1.2?




--
Matan Ziv-Av. ma...@svgalib.org
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Why should I write apps for Maemo?

2010-05-07 Thread Kimmo Hämäläinen
On Fri, 2010-05-07 at 14:13 +0200, ext Matan Ziv-Av wrote:
 On Fri, 7 May 2010, Kimmo Hämäläinen wrote:
 
  On Fri, 2010-05-07 at 13:21 +0200, ext Matan Ziv-Av wrote:
  On Fri, 7 May 2010, tero.k...@nokia.com wrote:
  ...
  I am specifically interested in hildon-desktop packages
  (hildon-desktop, hildon-home, hildon-status-menu, etc.), and libhildon.
 
  Those are all developed in completely open Gitorious.  Just compile it
  from there (most of them have 1.2 branches). Everything on the way to
  pr1.2 is already there:
 
  http://maemo.gitorious.org/fremantle-hildon-desktop
  http://maemo.gitorious.org/hildon
 
 For hildon-desktop I see a list of 27 branches. Among them is one called 
 PR1_1, but none called PR1_2. Similarly for the rest of the packages. 
 What branch contains the exact code that is expected to be in PR1.2?

The master is PR1.2. Take the latest tag.  I believe this applies for
libhildondesktop, libmatchbox2, libclutter, hildon-status-menu also.  At
some point the master may or may not be branched and the guys will start
working on the next maintenance release.

It would be best to have some Maemo/Meego-wide convention for this,
yes...

-Kimmo


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Sascha Mäkelä
I would be already happy if the Qt Simulator in Qt SDK would run like
PR1.2. Currently as it is I'm stuck on my development, because I
cannot test the Qt 4.6.2 Maemo features like
WA_Maemo5PortraitOrientation.

Sascha
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Noob question re Qt Application structure

2010-05-07 Thread Scifi Guy

Hi All,

I am developing a Qt4.6 based application that monitors outgoing international 
calls (by connecting to relevant DBUS signals) and routes
them via a calling card number. I have developed a configuration UI widget 
(QWidget subclass) to enable/disable such routing. 
The problem is that the UI widget code and DBUS slots code are all in the same 
class. If I launch the application, the UI widget is shown.

This is the code in my main.cpp.


#include QtGui/QApplication
#include eventmonitor.h
#include QDebug

int main(int argc, char *argv[])
{

QApplication a(argc, argv);
EventMonitor w;
w.show();
return a.exec();
}


EventMonitor is a QWidget subclass which also has functions to connect to DBUS 
signals. My aim is to separate the functionality into two different classes. 
The class with DBus slots should be running as a daemon which is invoked on 
startup.
The class with QWidget (config screen) should be invoked when user launches the 
app from the applications menu. Think on the lines of AutoDisconnect. 

What is the best way to achieve this? Let me know if you want me to post more 
code.


Thanks  Regards,
Sudheer   
_
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Noob question re Qt Application structure

2010-05-07 Thread Ram Kurvakat
just my 2 pence worth.

you should perhaps try to make 2 different apps for it.
1 which runs as a daemon and invoked on startup using an upstart  
http://upstart.ubuntu.com/getting-started.html script.
and the other a GUI based app , that can interact with your daemon, via files, 
sockets, any which way.

cheers
Ram


- Original Message -
From: Scifi Guy
Sent: 05/07/10 03:26 PM
To: maemo-developers@maemo.org
Subject: Noob question re Qt Application structure

 Hi All,

I am developing a Qt4.6 based application that monitors outgoing international 
calls (by connecting to relevant DBUS signals) and routes
them via a calling card number. I have developed a configuration UI widget 
(QWidget subclass) to enable/disable such routing. 
The problem is that the UI widget code and DBUS slots code are all in the same 
class. If I launch the application, the UI widget is shown.

This is the code in my main.cpp.


#include QtGui/QApplication
#include eventmonitor.h
#include QDebug

int main(int argc, char *argv[])
{

 QApplication a(argc, argv); 
 EventMonitor w;
 w.show();
 return a.exec();
}


EventMonitor is a QWidget subclass which also has functions to connect to DBUS 
signals. My aim is to separate the functionality into two different classes. 
The class with DBus slots should be running as a daemon which is invoked on 
startup.
The class with QWidget (config screen) should be invoked when user launches the 
app from the applications menu. Think on the lines of AutoDisconnect. 

What is the best way to achieve this? Let me know if you want me to post more 
code.


Thanks  Regards,
Sudheer 
-
The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get 
started. 
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Noob question re Qt Application structure

2010-05-07 Thread ianaré sévi
I second that opinion. Subclassing by functionality is definitely good
for a single app, but if you need to have the two parts running at
different times a daemon app and a GUI app is the way to go.

Another option you could use to interact with your two apps is through
dbus itself, ince you will already be using that kind of code.

- ianaré sévi



2010/5/7 Ram Kurvakat rkma...@gmx.com:
 just my 2 pence worth.

 you should perhaps try to make 2 different apps for it.

 1 which runs as a daemon and invoked on startup using an upstart script.

 and the other a GUI based app , that can interact with your daemon, via
 files, sockets, any which way.

 cheers

 Ram

 - Original Message -

 From: Scifi Guy

 Sent: 05/07/10 03:26 PM

 To: maemo-developers@maemo.org

 Subject: Noob question re Qt Application structure

 Hi All,

 I am developing a Qt4.6 based application that monitors outgoing
 international calls (by connecting to relevant DBUS signals) and routes
 them via a calling card number. I have developed a configuration UI widget
 (QWidget subclass) to enable/disable such routing.
 The problem is that the UI widget code and DBUS slots code are all in the
 same class. If I launch the application, the UI widget is shown.

 This is the code in my main.cpp.


 #include QtGui/QApplication
 #include eventmonitor.h
 #include QDebug

 int main(int argc, char *argv[])
 {

     QApplication a(argc, argv);
     EventMonitor w;
     w.show();
     return a.exec();
 }


 EventMonitor is a QWidget subclass which also has functions to connect to
 DBUS signals. My aim is to separate the functionality into two different
 classes. The class with DBus slots should be running as a daemon which is
 invoked on startup.
 The class with QWidget (config screen) should be invoked when user launches
 the app from the applications menu. Think on the lines of AutoDisconnect.

 What is the best way to achieve this? Let me know if you want me to post
 more code.


 Thanks  Regards,
 Sudheer
 
 The New Busy is not the old busy. Search, chat and e-mail from your inbox.
 Get started.





 ___
 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: Noob question re Qt Application structure

2010-05-07 Thread Scifi Guy

Hi Ram  ianaré,

Thank you for the response. Creating two apps makes sense. I was trying to 
avoid user having to install two apps for one feature. But it is not a big deal 
i guess (If i set the dependencies properly).

Here is another question though. How I do launch/kill the daemon app from the 
GUI app? This is required when user chooses enable/disable application from GUI 
app. I can exit the daemon by receiving a custom DBUS signal but how do I 
launch it?

Thanks  Regards,
Sudheer

P.S: Sometimes 2 cents is worth more than a million :)

 Date: Fri, 7 May 2010 10:54:15 -0400
 Subject: Re: Noob question re Qt Application structure
 From: ian...@gmail.com
 To: rkma...@gmx.com
 CC: scifi@hotmail.com; maemo-developers@maemo.org
 
 I second that opinion. Subclassing by functionality is definitely good
 for a single app, but if you need to have the two parts running at
 different times a daemon app and a GUI app is the way to go.
 
 Another option you could use to interact with your two apps is through
 dbus itself, ince you will already be using that kind of code.
 
 - ianaré sévi
 
 
 
 2010/5/7 Ram Kurvakat rkma...@gmx.com:
  just my 2 pence worth.
 
  you should perhaps try to make 2 different apps for it.
 
  1 which runs as a daemon and invoked on startup using an upstart script.
 
  and the other a GUI based app , that can interact with your daemon, via
  files, sockets, any which way.
 
  cheers
 
  Ram
 
  - Original Message -
 
  From: Scifi Guy
 
  Sent: 05/07/10 03:26 PM
 
  To: maemo-developers@maemo.org
 
  Subject: Noob question re Qt Application structure
 
  Hi All,
 
  I am developing a Qt4.6 based application that monitors outgoing
  international calls (by connecting to relevant DBUS signals) and routes
  them via a calling card number. I have developed a configuration UI widget
  (QWidget subclass) to enable/disable such routing.
  The problem is that the UI widget code and DBUS slots code are all in the
  same class. If I launch the application, the UI widget is shown.
 
  This is the code in my main.cpp.
 
 
  #include QtGui/QApplication
  #include eventmonitor.h
  #include QDebug
 
  int main(int argc, char *argv[])
  {
 
  QApplication a(argc, argv);
  EventMonitor w;
  w.show();
  return a.exec();
  }
 
 
  EventMonitor is a QWidget subclass which also has functions to connect to
  DBUS signals. My aim is to separate the functionality into two different
  classes. The class with DBus slots should be running as a daemon which is
  invoked on startup.
  The class with QWidget (config screen) should be invoked when user launches
  the app from the applications menu. Think on the lines of AutoDisconnect.
 
  What is the best way to achieve this? Let me know if you want me to post
  more code.
 
 
  Thanks  Regards,
  Sudheer
  
  The New Busy is not the old busy. Search, chat and e-mail from your inbox.
  Get started.
 
 
 
 
 
  ___
  maemo-developers mailing list
  maemo-developers@maemo.org
  https://lists.maemo.org/mailman/listinfo/maemo-developers
 
 
  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Noob question re Qt Application structure

2010-05-07 Thread Ram Kurvakat
assuming you have the communication between the GUI and daemon in place.

you could always launch a daemon ( this is not running ) using QProcess 
http://doc.trolltech.com/4.6/qprocess.html  and shutdown by listening to a 
custom DBUS message or similar 
communication.

-Ram


- Original Message -
From: Scifi Guy
Sent: 05/07/10 04:24 PM
To: ian...@gmail.com, rkma...@gmx.com
Subject: RE: Noob question re Qt Application structure

 Hi Ram  ianaré,

Thank you for the response. Creating two apps makes sense. I was trying to 
avoid user having to install two apps for one feature. But it is not a big deal 
i guess (If i set the dependencies properly).

Here is another question though. How I do launch/kill the daemon app from the 
GUI app? This is required when user chooses enable/disable application from GUI 
app. I can exit the daemon by receiving a custom DBUS signal but how do I 
launch it?

Thanks  Regards,
Sudheer

P.S: Sometimes 2 cents is worth more than a million :)

 Date: Fri, 7 May 2010 10:54:15 -0400
 Subject: Re: Noob question re Qt Application structure
 From: ian...@gmail.com
 To: rkma...@gmx.com
 CC: scifi@hotmail.com; maemo-developers@maemo.org
 
 I second that opinion. Subclassing by functionality is definitely good
 for a single app, but if you need to have the two parts running at
 different times a daemon app and a GUI app is the way to go.
 
 Another option you could use to interact with your two apps is through
 dbus itself, ince you will already be using that kind of code.
 
 - ianaré sévi
 
 
 
 2010/5/7 Ram Kurvakat rkma...@gmx.com:
  just my 2 pence worth.
 
  you should perhaps try to make 2 different apps for it.
 
  1 which runs as a daemon and invoked on startup using an upstart script.
 
  and the other a GUI based app , that can interact with your daemon, via
  files, sockets, any which way.
 
  cheers
 
  Ram
 
  - Original Message -
 
  From: Scifi Guy
 
  Sent: 05/07/10 03:26 PM
 
  To: maemo-developers@maemo.org
 
  Subject: Noob question re Qt Application structure
 
  Hi All,
 
  I am developing a Qt4.6 based application that monitors outgoing
  international calls (by connecting to relevant DBUS signals) and routes
  them via a calling card number. I have developed a configuration UI widget
  (QWidget subclass) to enable/disable such routing.
  The problem is that the UI widget code and DBUS slots code are all in the
  same class. If I launch the application, the UI widget is shown.
 
  This is the code in my main.cpp.
 
 
  #include QtGui/QApplication
  #include eventmonitor.h
  #include QDebug
 
  int main(int argc, char *argv[])
  {
 
  QApplication a(argc, argv);
  EventMonitor w;
  w.show();
  return a.exec();
  }
 
 
  EventMonitor is a QWidget subclass which also has functions to connect to
  DBUS signals. My aim is to separate the functionality into two different
  classes. The class with DBus slots should be running as a daemon which is
  invoked on startup.
  The class with QWidget (config screen) should be invoked when user launches
  the app from the applications menu. Think on the lines of AutoDisconnect.
 
  What is the best way to achieve this? Let me know if you want me to post
  more code.
 
 
  Thanks  Regards,
  Sudheer
  
  The New Busy is not the old busy. Search, chat and e-mail from your inbox.
  Get started.
 
 
 
 
 
  ___
  maemo-developers mailing list
  maemo-developers@maemo.org
  https://lists.maemo.org/mailman/listinfo/maemo-developers 
  https://lists.maemo.org/mailman/listinfo/maemo-developers 
 
 

-
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox. See how. 
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Noob question re Qt Application structure

2010-05-07 Thread ianare
Right, one way is to have two separate deb packages, making the GUI depend on 
the daemon. This is expecially useful if you envision the daemon to be accessed 
by other apps or does not need the GUI in all cases.
Another way is to package both apps (executables) in the same deb package.

- ianaré

- Original message -

 Hi Ram  ianaré,

 Thank you for the response. Creating two apps makes sense. I was trying to 
 avoid
 user having to install two apps for one feature. But it is not a big deal i
 guess (If i set the dependencies properly).

 Here is another question though. How I do launch/kill the daemon app from the
 GUI app? This is required when user chooses enable/disable application from 
 GUI
 app. I can exit the daemon by receiving a custom DBUS signal but how do I 
 launch
 it?

 Thanks  Regards,
 Sudheer

 P.S: Sometimes 2 cents is worth more than a million :)

  Date: Fri, 7 May 2010 10:54:15 -0400
  Subject: Re: Noob question re Qt Application structure
  From: ian...@gmail.com
  To: rkma...@gmx.com
  CC: scifi@hotmail.com; maemo-developers@maemo.org
 
  I second that opinion. Subclassing by functionality is definitely good
  for a single app, but if you need to have the two parts running at
  different times a daemon app and a GUI app is the way to go.
 
  Another option you could use to interact with your two apps is through
  dbus itself, ince you will already be using that kind of code.
 
  - ianaré sévi
 
 
 
  2010/5/7 Ram Kurvakat rkma...@gmx.com:
   just my 2 pence worth.
  
   you should perhaps try to make 2 different apps for it.
  
   1 which runs as a daemon and invoked on startup using an upstart script.
  
   and the other a GUI based app , that can interact with your daemon, via
   files, sockets, any which way.
  
   cheers
  
   Ram
  
   - Original Message -
  
   From: Scifi Guy
  
   Sent: 05/07/10 03:26 PM
  
   To: maemo-developers@maemo.org
  
   Subject: Noob question re Qt Application structure
  
   Hi All,
  
   I am developing a Qt4.6 based application that monitors outgoing
   international calls (by connecting to relevant DBUS signals) and routes
   them via a calling card number. I have developed a configuration UI widget
   (QWidget subclass) to enable/disable such routing.
   The problem is that the UI widget code and DBUS slots code are all in the
   same class. If I launch the application, the UI widget is shown.
  
   This is the code in my main.cpp.
  
  
   #include QtGui/QApplication
   #include eventmonitor.h
   #include QDebug
  
   int main(int argc, char *argv[])
   {
  
          QApplication a(argc, argv);
          EventMonitor w;
          w.show();
          return a.exec();
   }
  
  
   EventMonitor is a QWidget subclass which also has functions to connect to
   DBUS signals. My aim is to separate the functionality into two different
   classes. The class with DBus slots should be running as a daemon which is
   invoked on startup.
   The class with QWidget (config screen) should be invoked when user 
   launches
   the app from the applications menu. Think on the lines of AutoDisconnect.
  
   What is the best way to achieve this? Let me know if you want me to post
   more code.
  
  
   Thanks  Regards,
   Sudheer
   
   The New Busy is not the old busy. Search, chat and e-mail from your inbox.
   Get started.
  
  
  
  
  
   ___
   maemo-developers mailing list
   maemo-developers@maemo.org
   https://lists.maemo.org/mailman/listinfo/maemo-developers
  
  
                           
 _
 Hotmail is redefining busy with tools for the New Busy. Get more from your 
 inbox.
 http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Noob question re Qt Application structure

2010-05-07 Thread Mikhail Gusarov

Twas brillig at 08:24:06 07.05.2010 UTC-07 when scifi@hotmail.com
did gyre and gimble:

 SG I can exit the daemon by receiving a custom DBUS signal but how do
 SG I launch it?

Register it as a D-Bus service and daemon will be started by D-Bus upon
first access.

-- 
  http://fossarchy.blogspot.com/


pgpRfnhVJcCP4.pgp
Description: PGP signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Noob question re Qt Application structure

2010-05-07 Thread Scifi Guy


 From: dotted...@dottedmag.net
 To: scifi@hotmail.com
 CC: ian...@gmail.com; rkma...@gmx.com; maemo-developers@maemo.org
 Subject: Re: Noob question re Qt Application structure
 Date: Fri, 7 May 2010 23:26:50 +0700
 
 
 Twas brillig at 08:24:06 07.05.2010 UTC-07 when scifi@hotmail.com
 did gyre and gimble:
 
  SG I can exit the daemon by receiving a custom DBUS signal but how do
  SG I launch it?
 
 Register it as a D-Bus service and daemon will be started by D-Bus upon
 first access.
 
 -- 
   http://fossarchy.blogspot.com/



Hi Mikhail,

Could you please elaborate what you mean by upon first access? This is the 
typical scenario I am assuming.

A custom D-Bus service for the daemon will be registered when user enables the 
application from the GUI app. This ideally happens only once. After enabling 
the application, user can reboot the device any number of times. Will D-Bus 
automatically start the daemon after each reboot?  Or do I need to register the 
service each time using an upstart script?

Regards,
Sudheer
  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Noob question re Qt Application structure

2010-05-07 Thread Scifi Guy

ianaré 
wrote:
 

Right, one way is to have two separate deb packages, making the GUI depend on 
the daemon. This is expecially useful if you envision the daemon to be 
accessed by other apps or does not need the GUI in all cases.

Another way is to package both apps (executables) in the same deb package.



- ianaré 


ianaré - I'll go with two executables in same deb package then. The daemon is 
too specific for this app that there is no use creating a new deb for that 
alone. 



Thanks  Regards,
Sudheer

  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Noob question re Qt Application structure

2010-05-07 Thread Mikhail Gusarov

Twas brillig at 10:05:38 07.05.2010 UTC-07 when scifi@hotmail.com
did gyre and gimble:

 SG Could you please elaborate what you mean by upon first access?

There is elaborate documentation.

http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services

-- 
  http://fossarchy.blogspot.com/


pgpVJb22sKPlX.pgp
Description: PGP signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


RE: Noob question re Qt Application structure

2010-05-07 Thread Scifi Guy


 From: dotted...@dottedmag.net
 To: scifi@hotmail.com
 CC: ian...@gmail.com; rkma...@gmx.com; maemo-developers@maemo.org
 Subject: Re: Noob question re Qt Application structure
 Date: Sat, 8 May 2010 00:19:03 +0700
 
 
 Twas brillig at 10:05:38 07.05.2010 UTC-07 when scifi@hotmail.com
 did gyre and gimble:
 
  SG Could you please elaborate what you mean by upon first access?
 
 There is elaborate documentation.
 
 http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services
 
 -- 
   http://fossarchy.blogspot.com/

Thank you :) 

I will create the service for the daemon and post back the results. Probably 
tonight (at work now). 

Thank you all for taking time to read and respond to my post.

~Sudheer
  
_
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Ville M. Vainio
On Fri, May 7, 2010 at 5:10 PM, Sascha Mäkelä sascha.mak...@gmail.com wrote:

 I would be already happy if the Qt Simulator in Qt SDK would run like
 PR1.2. Currently as it is I'm stuck on my development, because I

Qt simulator doesn't get the maemo specific goodies; it's not PR 1.1
level either, it's just it'

 cannot test the Qt 4.6.2 Maemo features like
 WA_Maemo5PortraitOrientation.





 Sascha
 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers




-- 
Ville M. Vainio
http://tinyurl.com/vainio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Ville M. Vainio
On Fri, May 7, 2010 at 8:58 PM, Ville M. Vainio vivai...@gmail.com wrote:

 Qt simulator doesn't get the maemo specific goodies; it's not PR 1.1
 level either, it's just it'

It's just a modified version of desktop Qt. If you ever feel like
buing a cheap logitech flat keyboard, don't.

 cannot test the Qt 4.6.2 Maemo features like
 WA_Maemo5PortraitOrientation.

Luckily you can test that stuff in scratchbox...

-- 
Ville M. Vainio
http://tinyurl.com/vainio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


maemo-qemu gles-libs

2010-05-07 Thread Nicolai Hess
Hi,

is anyone using maemo-qemu with gles-libs wrappers?
I tried to boot a n900 image (Kernel and Rootfs) with qemu.
As I understand the Readme.maemo in gles-libs, it should be
possible to use maemo-qemu and gles-libs to boot n900 image
with simulated gles support.

My image boots up in qemu and  I can login. But the xserver (xomap)
does not start up.

Anyone who get this running or any suggestions.

regards nicolai
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Why should I write apps for Maemo?

2010-05-07 Thread Benoît HERVIER
 Luckily you can test that stuff in scratchbox...
But scratchbox isn't installable on n900...
-- 
Benoît HERVIER, Khertan Software - http://khertan.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


qt 4.6 without pt1.2

2010-05-07 Thread acano

Hi everyone,

I suceeded to compile a program that uses the  state machine framework  
for fremantle but using the madde program provided by Nokia SDK.


Nevertheless, when I pass this program to my N900 it sais that some Qt  
libraries are missing. Should I wait till pr1.2 or can I install Qt  
4.6 without it.


Thanks


This message was sent using IMP, the Internet Messaging Program.


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers