Re: Python and ZSI on maemo

[daniel wilms]

Hi,

I've installed ZSI using the installation with the setup.py.

Follow these steps:

1) Install with apt-get python2.5-runtime, python2.5-distutils and 
python2.5-setuptools

2) Run  'python2.5 setup.py install'

and that's it.

Cheers Daniel


> Hi there,
> 
> I am trying to write a python script for the N810 which polls a
> directory for files being written by another process and makes web
> service calls, one per file, before deleting the file.
> 
> I am having troubles with getting ZSI into the scratchbox.  There seems
> to be a dependency on distutils.
> 
> I have managed to install and test ZSI on just straight Ubuntu fine.
> 
> Any tips?  Anyone have experience with this?
> 
> I'm new to maemo and python so any help appreciated!
> 
> Thanks,
> Tim.
> 
> 
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Python and ZSI on maemo

[Martin Grimme]

Hi,

you should take a look at python-inotify for monitoring the directory,
instead of polling. inotify lets you get notification from the kernel
when a file is written or changed.
Constant polling is bad for battery life anyway.

As for ZSI, installing with distutils should be no problem in
Scratchbox. distutils is part of the Python distribution. You run
"python setup.py install" in the directory where the setup.py for
distutils is located.


Regards,
Martin


2009/5/6, Tim Allen :
> Hi there,
>
> I am trying to write a python script for the N810 which polls a
> directory for files being written by another process and makes web
> service calls, one per file, before deleting the file.
>
> I am having troubles with getting ZSI into the scratchbox.  There seems
> to be a dependency on distutils.
>
> I have managed to install and test ZSI on just straight Ubuntu fine.
>
> Any tips?  Anyone have experience with this?
>
> I'm new to maemo and python so any help appreciated!
>
> Thanks,
> Tim.
>
> ___
> 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

Python and ZSI on maemo

[Tim Allen]

Hi there,

I am trying to write a python script for the N810 which polls a
directory for files being written by another process and makes web
service calls, one per file, before deleting the file.

I am having troubles with getting ZSI into the scratchbox.  There seems
to be a dependency on distutils.

I have managed to install and test ZSI on just straight Ubuntu fine.

Any tips?  Anyone have experience with this?

I'm new to maemo and python so any help appreciated!

Thanks,
Tim.

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

Re: QA from extras-devel to extras-testing

[Ian]

Hi,

>> This separation of code and packaging (.diff.gz and .orig.tar.gz.) is
>> IMO extremely important for Maemo and should be actively encouraged by
>> both Nokia and the community processes.
>> Downstream projects will thank us for it, i imagine
>
> Yes, I wish that Nokia projects such as hildon stuck to that instead of
> packaging directly from svn.
I think that this should not only apply to Hildon - for example if
Nokia subcontracts an applications development out to a third party
this clean separation should be specified in the terms of work
contract (sorry if this is a bit OT for the dev list but I know
speaking to the Mer guys that they are being bitten hard by this
issue)

Regards
Ian


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

Re: no suitable windowing system found, exiting.

[Qole]

If all you want to do is run OpenOffice 3.0, install Easy Debian from Extras
and use the included installer to download the big image file. You will then
be able to run the Debian Squeeze version of OpenOffice 3.0 on your tablet.

If you wish to install OpenOffice 3.0 in Maemo, you will need to build it in
Scratchbox. This will most likely turn into a giant task, and you may not
succeed.

But if you do succeed, please package OpenOffice for Maemo. Many people
would appreciate it.

On Mon, May 4, 2009 at 6:57 PM, jiangchuang wrote:

>  Hi everyone:
>  I would like to run OpenOffice.org 3.0 on N800. I copied
> OpenOffice.org into the removable memory sd card, and run the ./soffice
> command in the terminal. I get the following error messages:
>
> *no suitable windowing system found, exiting.*
>
>
> I did my best to solve the problem,but failed.Can you give me any
> advice? TIA.
>
> Regards.
>
> JiangChuang
>
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>


-- 
enthusiast, n. "One whose mind is wholly possessed and heated by what
engages it; one who is influenced by a peculiar fervor of mind; an ardent
and imaginative person."
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA from extras-devel to extras-testing

[Murray Cumming]

On Tue, 2009-05-05 at 16:40 +0100, Ian wrote:
> Hi
> > This is ideal, at least in theory. The problem is that many package
> > maintainers don't know the programming language of the software they
> > are packaging. If you are packaging something written in erlang you
> > will not be able to quickly fix bugs in that package if you don't know
> > erlang. This problem is a big one in debian, which is why they pass
> > bugs upstream. How many package maintainers know the code of the
> > package they maintain in maemo?
> 
> This separation of code and packaging (.diff.gz and .orig.tar.gz.) is
> IMO extremely important for Maemo and should be actively encouraged by
> both Nokia and the community processes.
> Downstream projects will thank us for it, i imagine

Yes, I wish that Nokia projects such as hildon stuck to that instead of
packaging directly from svn.

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: QA from extras-devel to extras-testing

[Quim Gil]

ext Murray Cumming wrote:
> On Sun, 2009-05-03 at 20:15 +0200, Jeremiah Foster wrote:
>> Who is going to build all of this infrastructure?
> 
> For the voting stuff, I have no idea. Maemo/Nokia wants it so I guess
> they will make it happen.

Hopefully the maemo.org team and the community council also wants it, so
they will make it happen. :)

>>  Won't this type of  
>> requirement help create separate private repos?
> 
> You mean the possible bug-tracker requirement? I hope maemo.org still
> eventually aims to provide real bug tracking (bugzilla) to any package
> in extras. So a package can just use that if it doesn't have something
> already.

Agreed. I'm missing this already now, trying to install and playing with
applications available in Fremantle extras-devel. But when a package
doesn't install or has a serious problem and then I need to figure out
where to report... If I feel lazy imagine the average betatester or end
user.

-- 
Quim Gil
open source advocate
Maemo Software @ Nokia
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

... and QA of closed source applications?

[Quim Gil]

This deserves a separate thread.

In the "QA from extras-devel to extras-testing" thread we are discussing
 a community quality process that relies heavily on the fact that the
source code of an application and its dependencies is available. But
happens with the closed source applications?

The commercial developers signing contracts with Nokia go to a blessed
nokia.com repository, but what about all the rest? There have been very
popular and even community friendly apps that were not open source, like
Mauku or Canola. We can expect more in the future: free as in beer but
not as in freedom.

Currently the situation explained at
http://wiki.maemo.org/Extras#About_Extras is

"non-free applications are usually closed, binary only and their quality
and security must be taken on trust"

It's not good to have a free extras repo with good QA next to a non-free
extras repo equally offered to end users with no QA control. But what to
do? Some options come to mind.

- Don't distribute closed source, binary-only packages through
maemo.org. This will only help the proliferation of repos again, though.

- Keep the same QA process where availability of source code is not
determinant,

- Same as above but making the extras-testing hurdle higher to be more
on the safe side. For instance requiring more OK testers and/or a
dedicated OK from someone qualified e.g. the debmaster + bugmaster.

- ...

-- 
Quim Gil
open source advocate
Maemo Software @ Nokia
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA from extras-devel to extras-testing

[Ian]

Hi
> This is ideal, at least in theory. The problem is that many package
> maintainers don't know the programming language of the software they
> are packaging. If you are packaging something written in erlang you
> will not be able to quickly fix bugs in that package if you don't know
> erlang. This problem is a big one in debian, which is why they pass
> bugs upstream. How many package maintainers know the code of the
> package they maintain in maemo?

This separation of code and packaging (.diff.gz and .orig.tar.gz.) is
IMO extremely important for Maemo and should be actively encouraged by
both Nokia and the community processes.
Downstream projects will thank us for it, i imagine

Regards
Ian



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

Re: QA from extras-devel to extras-testing

[Jeremiah Foster]

On May 5, 2009, at 17:30, Quim Gil wrote:


> ext Jeremiah Foster wrote:
>> On May 5, 2009, at 15:41, Quim Gil wrote:
>> The problem is that many package
>> maintainers don't know the programming language of the software they
>> are packaging. If you are packaging something written in erlang you
>> will not be able to quickly fix bugs in that package if you don't  
>> know
>> erlang. This problem is a big one in debian, which is why they pass
>> bugs upstream. How many package maintainers know the code of the
>> package they maintain in maemo?
>
> No idea and actually not the business of the QA community process.  
> If an
> application is causing real pain to users *now* it needs to be demoted
> asap and be promoted again only when the pain is fixed.

Okay.
>
> The fact that a severe bug can't be fixed because there is only one
> maintainer interested in it not knowing much about the code and lazy
> about reporting upstream... would tell a bit about the quality of that
> piece of software, by the way.

Yes, true. I just seems a little tough, but perhaps this is what is  
required to increase quality.
>
>>> In any case it is not the business of the maemo.org extras QA
>>> process to
>>> deal with the bugfix itself. This process should make sure the  
>>> quality
>>> of the apps offered to end users is good, promoting what is good and
>>> demoting what is bad.
>>
>> Fair enough, but "quality" needs to be specifically defined. I.e.
>> installs, de-installs, has a source tarball, description, etc.
>
> Looking at the list proposed in the first email of this thread, this
> could be:
>
> Requirements for extras-testing  (should be testable automatically)
> - Install and deinstall flawlessly.
> - Don't bring conflicts in dependencies.
> - Their info in the app manager is complete (icon, summary, URL to
> project, updates info).
> - Have decent page in maemo.org/downloads.
> - Have a place to report issues to the developers.
>
> Requirements for extras (humans are needed to test)
> - Don't crash or freeze systems.
> - Don't drain batteries.
> - Are feature complete: everything inside works.
> - Have been tested by someone trusted before.

These seem reasonable to me.

>>> Goals
>>>
>>> - We need to know when an application in extras-devel is ready to be
>>> tested by power users (betatesters).
>>
>> As soon as it is uploaded?
>
> Developers upload to extras-devel, betatesters watch extras-testing.
>
> A betatester could be a regular users willing to invest time going
> trough fresh stuff and reporting about the findings. If we can save  
> them
> the major bugs automated testing can find, all the better.

This seems like an excellent solution to me.

>>
>>> - We need to know when an application in extras-testing is ready for
>>> end
>>> users.
>>
>> After going through a policy check and two weeks of power users'  
>> tests?
>
> 2 weeks minimum and 10 testers OK with no blockers?

Yes.

> We can fine tune how many days and how many testers are required.

Yes, this allows us to get started and adjust along the way.

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

Re: QA from extras-devel to extras-testing

[Quim Gil]

ext Jeremiah Foster wrote:
> On May 5, 2009, at 15:41, Quim Gil wrote:
> The problem is that many package  
> maintainers don't know the programming language of the software they  
> are packaging. If you are packaging something written in erlang you  
> will not be able to quickly fix bugs in that package if you don't know  
> erlang. This problem is a big one in debian, which is why they pass  
> bugs upstream. How many package maintainers know the code of the  
> package they maintain in maemo?

No idea and actually not the business of the QA community process. If an
application is causing real pain to users *now* it needs to be demoted
asap and be promoted again only when the pain is fixed.

The fact that a severe bug can't be fixed because there is only one
maintainer interested in it not knowing much about the code and lazy
about reporting upstream... would tell a bit about the quality of that
piece of software, by the way.


>> In any case it is not the business of the maemo.org extras QA  
>> process to
>> deal with the bugfix itself. This process should make sure the quality
>> of the apps offered to end users is good, promoting what is good and
>> demoting what is bad.
> 
> Fair enough, but "quality" needs to be specifically defined. I.e.  
> installs, de-installs, has a source tarball, description, etc.

Looking at the list proposed in the first email of this thread, this
could be:

Requirements for extras-testing  (should be testable automatically)
- Install and deinstall flawlessly.
- Don't bring conflicts in dependencies.
- Their info in the app manager is complete (icon, summary, URL to
project, updates info).
- Have decent page in maemo.org/downloads.
- Have a place to report issues to the developers.

Requirements for extras (humans are needed to test)
- Don't crash or freeze systems.
- Don't drain batteries.
- Are feature complete: everything inside works.
- Have been tested by someone trusted before.



>> Goals
>>
>> - We need to know when an application in extras-devel is ready to be
>> tested by power users (betatesters).
> 
> As soon as it is uploaded?

Developers upload to extras-devel, betatesters watch extras-testing.

A betatester could be a regular users willing to invest time going
trough fresh stuff and reporting about the findings. If we can save them
the major bugs automated testing can find, all the better.

> 
>> - We need to know when an application in extras-testing is ready for  
>> end
>> users.
> 
> After going through a policy check and two weeks of power users' tests?

2 weeks minimum and 10 testers OK with no blockers?

We can fine tune how many days and how many testers are required.

-- 
Quim Gil
open source advocate
Maemo Software @ Nokia
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA from extras-devel to extras-testing

[Jeremiah Foster]

On May 5, 2009, at 15:41, Quim Gil wrote:

> Hi,
>
> Let me start again because I don't think this downstream-upstream
> relationship is relevant to define hhis extras QA process.
>
> Proof: if an application in extras has been demoted because of a  
> severe
> bug in a library it's the maintainer of that app the main  
> responsible of
> finding a solution.

Another problem with this is the fact that a lot of the packages in  
Maemo have debian developers as their maintainer address. I strongly  
suspect whoever packaged these packages for maemo did not put their  
email address in the maintainer field, despite the fact that the  
packaging policy explicit says they have to. For example, the package  
"chrpath" has Tollef Fog Heen's debian email address - did he in fact  
package this for maemo? Or was this just ported without change?

So if we email the maintainer of this package, he'll probably say;  
"What? I never uploaded anything to the maemo repositories?" Now we  
have a package without a maintainer. A lot of users might be  
inconvenienced if all of a sudden important libraries like libcairomm  
get removed because the maemo packager cannot be found.

Jeremiah

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

Re: QA from extras-devel to extras-testing

[Jeremiah Foster]

On May 5, 2009, at 15:41, Quim Gil wrote:

> Hi,
>
> Let me start again because I don't think this downstream-upstream
> relationship is relevant to define hhis extras QA process.
>
> Proof: if an application in extras has been demoted because of a  
> severe
> bug in a library it's the maintainer of that app the main  
> responsible of
> finding a solution. Going upstream might be the safest bet but  
> probably
> not the fastest. He will decide in any case. If a package is used by
> many apps then the problem is common to many maintainers and, again,
> they will decide whether to fix the bug themselves and file the fix
> upstream or report upstream and fix the problem altogether.

This is ideal, at least in theory. The problem is that many package  
maintainers don't know the programming language of the software they  
are packaging. If you are packaging something written in erlang you  
will not be able to quickly fix bugs in that package if you don't know  
erlang. This problem is a big one in debian, which is why they pass  
bugs upstream. How many package maintainers know the code of the  
package they maintain in maemo?
>
> In any case it is not the business of the maemo.org extras QA  
> process to
> deal with the bugfix itself. This process should make sure the quality
> of the apps offered to end users is good, promoting what is good and
> demoting what is bad.

Fair enough, but "quality" needs to be specifically defined. I.e.  
installs, de-installs, has a source tarball, description, etc.
>
> Goals
>
> - We need to know when an application in extras-devel is ready to be
> tested by power users (betatesters).

As soon as it is uploaded?

> - We need to know when an application in extras-testing is ready for  
> end
> users.

After going through a policy check and two weeks of power users' tests?
>
> - We need to have a community process to report severe bugs and demote
> an application if a confirmed severe bug is not being addressed.

I think this is a good idea.
>
> Assumptions:
>
> - We have extras-devel, extras-testing and extras.
>
> - The jump from extras-devel to extras-testing is initiated manually  
> by
> the maintainer of an application once he thinks it's free of major
> issues and would be stopped by some kind of objective criteria applied
> to automated testing with no human testing: installs/de-installs,
> package info complete...

Excellent.
>
> - The jump from extras-testing to extras is made automatically after n
> days when human-based criteria are met: no crashes or severe bugs
> detected, n votes for promotion. Betatesters have specific tools
> installed in their devices helping them to detect and report crashes  
> and
> power management issues.

The n votes for promotion sounds like a good plan, where n is  
reasonably low.

> - Betatesters can also flag an application that is buggy enough to be
> demoted. Only the relevant packages should be demoted, as one library
> might be shared by many apps. They would be all demoted if the library
> is demoted so we want to do this only when it is proven that the  
> severe
> bug is in the library. This means that the demotion needs to be done
> manually by people really knowing what they are doing.
>
> - We are looking for end user perceived quality and therefore we  
> need to
> handle end user bug reports. We can't expect a user to know what exact
> package or library is causing the problem, the bugs will be filed
> against applications found buggy.

Interesting.

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

Re: QA from extras-devel to extras-testing

[Quim Gil]

ext Murray Cumming wrote:
> On Mon, 2009-05-04 at 12:06 +0200, Jeremiah Foster wrote:
> [snip]
>> And if  
>> someone does not want to create a bug tracker, for whatever reason,  
>> how can we convince them not to open their own repo if Maemo rejects  
>> their package?

maemo.org extras would reject their package, but perhaps not
extras-testing and definitely not extras-devel (unless there is some
kind of criminal intend or something).

> 
> We can't. But then it probably won't be as easy for people to install
> that application. At the least, it will be much less visible on the
> device and on maemo.org.

ditto

-- 
Quim Gil
open source advocate
Maemo Software @ Nokia
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: QA from extras-devel to extras-testing

[Quim Gil]

Hi,

Let me start again because I don't think this downstream-upstream
relationship is relevant to define hhis extras QA process.

Proof: if an application in extras has been demoted because of a severe
bug in a library it's the maintainer of that app the main responsible of
finding a solution. Going upstream might be the safest bet but probably
not the fastest. He will decide in any case. If a package is used by
many apps then the problem is common to many maintainers and, again,
they will decide whether to fix the bug themselves and file the fix
upstream or report upstream and fix the problem altogether.

In any case it is not the business of the maemo.org extras QA process to
deal with the bugfix itself. This process should make sure the quality
of the apps offered to end users is good, promoting what is good and
demoting what is bad.

Goals

- We need to know when an application in extras-devel is ready to be
tested by power users (betatesters).

- We need to know when an application in extras-testing is ready for end
users.

- We need to have a community process to report severe bugs and demote
an application if a confirmed severe bug is not being addressed.


Assumptions:

- We have extras-devel, extras-testing and extras.

- The jump from extras-devel to extras-testing is initiated manually by
the maintainer of an application once he thinks it's free of major
issues and would be stopped by some kind of objective criteria applied
to automated testing with no human testing: installs/de-installs,
package info complete...

- The jump from extras-testing to extras is made automatically after n
days when human-based criteria are met: no crashes or severe bugs
detected, n votes for promotion. Betatesters have specific tools
installed in their devices helping them to detect and report crashes and
 power management issues.

- Betatesters can also flag an application that is buggy enough to be
demoted. Only the relevant packages should be demoted, as one library
might be shared by many apps. They would be all demoted if the library
is demoted so we want to do this only when it is proven that the severe
bug is in the library. This means that the demotion needs to be done
manually by people really knowing what they are doing.

- We are looking for end user perceived quality and therefore we need to
handle end user bug reports. We can't expect a user to know what exact
package or library is causing the problem, the bugs will be filed
against applications found buggy.

-- 
Quim Gil
open source advocate
Maemo Software @ Nokia
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: hildon-help in fremantle?

[Antonio Aloisio]

Hi,
A good and updated documentation about using Qt Assistant in  Qt application
is in the section "Using Qt Assistant remotely" at
http://doc.trolltech.com/4.5/assistant-custom-help-viewer.html

Cheers,
Antonio

On Tue, May 5, 2009 at 2:27 PM, daniel wilms  wrote:

> Hi,
>
> an additional comment regarding the help-system to avoid misunderstandings.
> As I said before there won't be any help-system in Fremantle. This means
> that any help, has to be implemented within the application itself.
>
> There are a lot of ways how to do that, and a really easy way would be to
> implement it based on html. The old help system was based on gtkhtml, which
> could be used here as well or opening simply a locally stored html page in
> the browser, even though the overhead in this case might be an issue.
>
> If you are developing in Qt it can be done quite easily by using the Qt
> Assistant [1]. It is definitely worth to have a look, as it provides an easy
> standard way for this purpose.
>
> My suggestion would be to realise the help based on html if it is needed in
> some application. In Qt applications a standardised help is available.
>
> [1] http://doc.trolltech.com/3.3/assistant.html
>
> Cheers Daniel
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



-- 

Emo Philips 
- "I got some new underwear the other day. Well, new to me."
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: hildon-help in fremantle?

[daniel wilms]

Hi,

an additional comment regarding the help-system to avoid misunderstandings. As 
I said before there won't be any help-system in Fremantle. This means that any 
help, has to be implemented within the application itself.

There are a lot of ways how to do that, and a really easy way would be to 
implement it based on html. The old help system was based on gtkhtml, which 
could be used here as well or opening simply a locally stored html page in the 
browser, even though the overhead in this case might be an issue.

If you are developing in Qt it can be done quite easily by using the Qt 
Assistant [1]. It is definitely worth to have a look, as it provides an easy 
standard way for this purpose.

My suggestion would be to realise the help based on html if it is needed in 
some application. In Qt applications a standardised help is available.

[1] http://doc.trolltech.com/3.3/assistant.html

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

Re: Python App on Maemo

[Attila Csipa]

On Tuesday 05 May 2009 10:41:11 Jeremiah C. Foster wrote:
> project.) But there is no need to prototype first in python - it gives
> you no special advantages aside from the fact that most prefer to code
> in python versus C++ and that some consider prototyping to be much
> faster in python.

Another, very important advantage for some, is that you don't need scratchbox, 
or any maemo specific setup (god forbid cross compile) to develop in PyQt and 
you can run literally the same code on both your desktop and your NIT. Just 
install python-qt on your desktop and when done, copy over .py files and you're 
good to go.

Having worked with Qt in c++ and python as well, I would be one of those who 
say development in python is significantly faster (especially prototyping). 
Even if you don't keep a single line of python code in the end. I usually 
found myself better off developing my c++ (re)implementation based on a python 
prototype than developing in c++ from scratch. YMMV, of course. If both 
development time and execution speed are required I usually go for a mix - 
python prototype and then optimize speed by replacing profiled 
functions/classes with C(++) code to achieve the required speed. YMMV, again, 
neither qt nor python are a silver bullet, but both are very very useful if 
you use them right :)



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

Re: Problem with the Diablo autobuilder

[Niels Breet]

Hi,

Sorry for the delay. The queue-manager for diablo extras-devel didn't run
because there was a residual PID file.

The incoming queue has now been processed and everything should be back to
normal.

--
Niels Breet
maemo.org webmaster

On Sun, May 3, 2009 18:52, Faheem Pervez wrote:
> Hi,
>
>
> The autobuilder doesn't seem to be moving packages to extras-devel. I
> uploaded python-vte to the diablo autobuilder and it still has not shown
> up yet. I checked with some other packages, by other people, osm2go and
> dialcentral and they haven't been uploaded to extras-devel - despite it
> having been many hours since they had been uploaded.
>
> Please don't tell me to reupload as I do not have the original source
> packages available to me and the autobuilder, being the clever thing it
> is, deletes the source packages it has while it's "moving" them to
> extras-devel.
>
> I realise my tone isn't a nice one and the annoyance isn't directed at
> you, or the maemo.org team responisble for the autobuilder, but rather at
> the autobuilder for chewing my packages.
>
> Best Regards,
> Faheem
>
>
> On Thu, Apr 30, 2009 at 10:05 AM, Jeremiah Foster <
> jerem...@jeremiahfoster.com> wrote:
>
>>
>> On Apr 30, 2009, at 8:57, Cornelius Hald wrote:
>>
>>
>>> Hi,
>>>
>>>
>>> it looks like there is something wrong with the Diablo autobuilder. I
>>>  was submitting conboy 0.3.2 two times already and it doesn't show up
>>>  in extras-devel. For Chinook and Fremantle it worked fine.
>>>
>>> The mails I received are attached.
>>>
>>>
>>> It would be nice if someone please could check.
>>>
>>
>> As far as the autobuilder is concerned, the indexing tool that updates
>> the list of Packages stopped running yesterday. I am trying to fix that
>> now so that new packages start appearing in diablo.
>>
>> Jeremiah


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

Re: Installing pyqt on scratchbox

[Attila Csipa]

On Tuesday 05 May 2009 06:57:35 Jey Han Lau wrote:
> I've been trying to install pyqt4 on scratchbox and I kept getting
> broken packages error =/ There are instructions on installing pyqt on
> the nokia device itself but not on the scratchbox. I have added
> extras-devel to /etc/apt/sources.list, and have installed python 2.5 and
> qt.

PyQt is borked in extras-devel, I've got multiple reports on inability to 
install pyqtoreader for this very same reason. Not sure if it's a pyqt 
packaging or autobuilder related issue, but in either case it's not you doing 
things wrong. Half of the pyqt packages is 4.4.3-maemo7 (gui, network) and the 
other half is 4.4.3-maemo9 (core, xml, etc).

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

Re: Installing pyqt on scratchbox

[Attila Csipa]

On Tuesday 05 May 2009 04:20:32 you wrote:
> I suppose it is not really "translating". I'll elaborate a little more.
> Say you create a signal/slot for a button. So the button fires a
> "clicked" signal and say there's a UI list that clears the item (slot)
> on the list. You can do this using the Qt Designer and all the code
> would be translated to Python using pyuic. But say the slot isn't
> clearing the list, but to add an item to the list. You'd then need to
> create a custom "slot" (say it is called addEntry), and you'd write some
> C++ code for the addEntry slot function to add items to the list. But
> pyuic wouldn't convert that and you'd have to write some python method
> for addEntry.

I'm not sure I completely follow, but you can write slots in pure python, in 
fact, PyQt treats all class methods of QObject subclasses as slots (just don't 
forget to call the QObject constructor from your own !). There are some 
caveats which stem from C++ polymorphism and Qt metaobjects, but those are 
solvable with a few decorators.

You might want to take a look at 
http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/pyqt4ref.html#signal-
and-slot-support

(actually, the whole page is a good read to familiarize yourself with the 
python aspect of Qt)

> I hope I am getting the right idea here (after reading and trying out a
> few tutorials), and what's pyrrc? I don't think I've heard it before...

pyrrc compiles qrc (resource) files, usually containing bundled icons, images, 
etc.

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

Re: Python App on Maemo

[Jeremiah C. Foster]

On May 5, 2009, at 1:48 AM, Jey Han Lau wrote:

> We are currently trying to build a GUI application on Maemo, and after
> listening to suggestions from a few Maemo developers we started
> prototyping it with Python and Qt.
>
> Python and Qt seems easy since the UI code designed from Qt designer  
> can
> be converted into python automatically. But soon we came to realize  
> that
> only the UI code (in xml) is converted, any functions, methods or code
> written in C++ for the original Qt application has to be manually
> translated into Python. Seems reasonable but now we aren't so sure if
> this is the best approach anymore...
>
> The application we are building isn't too complicated (but will have
> quite some number of screens/forms), and will contain SOAP web service
> calls, and some file writing/reading. We've got the web service call
> working using ZSI, so all that is left to decide is the UI framework  
> to
> be used. Qt seems to be a better choice initially since it comes  
> with a
> designer IDE that allows us to design the GUI more easily.
>
> Before we move on to spend more time using Python and Qt to develop  
> our
> program, we'd like to hear some comments from you developers : )

If the strength of your development team is in C++, then prototype  
your application in C++. Qt is built on C++. The python bindings are  
very useful to prototype quickly if you are strong in python (Qt has  
other bindings as well, including perl bindings which are a SoC  
project.) But there is no need to prototype first in python - it gives  
you no special advantages aside from the fact that most prefer to code  
in python versus C++ and that some consider prototyping to be much  
faster in python.

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