Re: Python App on Maemo
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
Re: Installing pyqt on scratchbox
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: Installing pyqt on scratchbox
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: Problem with the Diablo autobuilder
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: Python App on Maemo
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: hildon-help in fremantle?
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: hildon-help in fremantle?
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 daniel.wi...@nokia.com 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 http://www.brainyquote.com/quotes/authors/e/emo_philips.html - 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: QA from extras-devel to extras-testing
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: QA from extras-devel to extras-testing
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
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
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
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
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
... and QA of closed source applications?
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
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
Re: QA from extras-devel to extras-testing
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: no suitable windowing system found, exiting.
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 jiangchu...@redoffice.comwrote: 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
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
Python and ZSI on maemo
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
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 t...@transtech.net.au: 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
