Re: QtCreator, libraries, and multiple platforms
On Sat, Aug 6, 2011 at 1:02 AM, David Talmage wrote: > I agree that static linking would make this simple. However, I'm targeting > devices with limited memory (e.g. N900, N8, N9). Dynamic linking is better in > this context. Applications probably want to (need to!) ship their own copy of the library anyway, which eliminates memory savings. Your library would need to be huge, or very popular, for this to matter. I'd encourage you to just link statically and call it a day. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QtCreator, libraries, and multiple platforms
So I guessed correctly; your rationale for using a library is wrong ;-). You are introducing a bunch of deployment headaches for the sake of having a "reusable unit", which is not in fact reused by other applications. In general, libraries should only be introduced when your module is part of the operating system, there are licensing issues, or you are releasing something linked against by other applications as well. You should just link all the code statically with your main application to keep things simple. On Fri, Aug 5, 2011 at 11:39 PM, David Talmage wrote: > Thanks to Danil, Ville, and Christian for taking the time to answer my call > for help. > > On Thursday, August 04, 2011 06:16:16 AM Daniil Ivanov wrote: > >> I agree that three project files are the way to go: >> ... >> This is how you declare your library for your application >> http://doc.qt.nokia.com/latest/qmake-project-files.html#declaring-other-li >> braries > > I got about that far. More below. > > To answer Ville's question about the need for a separate library: I refactored > my application into a library that other applications can use and an > application that uses the library. I have at least one more application in > mind that will use this library. For the curious, it's a home-grown dialog > for choosing contacts. I wrote it last year because the native Maemo contacts > dialog didn't support pre-selecting some contacts. (The documentation said it > did but I couldn't make it work at all.) > > To answer Christian's question about linking: By "can't link" I mean that the > linker can't find my library, so it complains about undefined symbols. > > > I have a directory structure like this: > > N900/app > N900/app-uberproject > N900/lib > > The contain, respectively, the app, the subdirs project, and the library. > > I'm building for Maemo, Harmattan, Simulator, and Remote Compiler. In short, > everything but Desktop. > > When I build for Simulator, I get directories > > N900/app-build-simulator > N900/app-uberproject-build-simulator > N900/lib-build-simulator > > The next challenge is to teach app.pro how to find the library for the build > platform, simulator in the example above. It looks like some hackery-pokery > with replace() will do the job. I was hoping that QMake would Do The Right > Thing for me. > > After that, my challenge is to install liblib.so in the simulator so that app > can load it. That's just the usual packaging task, right? > > > Dave > >> On Thu, Aug 4, 2011 at 12:48 PM, Ville M. Vainio wrote: >> > Do you have a particular reason for the requirement (like license) to >> > have a separate library, instead of just having one monolithic >> > application? >> > >> > On Wed, Aug 3, 2011 at 10:03 PM, David Talmage wrote: >> >> I need help making QtCreator build an application and a library for >> >> Maemo, Symbian (using the remote compiler), and the simulator. I've >> >> been all over the documentation, the forum on Qt Developer Network, and >> >> Google. I can't find an example that does what I need. >> >> >> >> I have a library (lib) and an application (app). Each one is a QtCreator >> >> project. I can build them individually but I can't link app with >> >> liblib.so. Whatever I use has to work with maemo.org's autobuilder and >> >> Nokia's remote compiler for Symbian. >> >> >> >> As a first pass, it would help if there is an environment variable I can >> >> reference in app.pro like $$OUT_PWD that contains the name of the build >> >> directory for lib. Then linking might work. I can hack something >> >> together with qmake's replace(), like replace($$OUT_PWD, app, lib) and >> >> that might work as long as app/ and lib/ were in the same directory. I >> >> don't know how well it would port or whether it would continue to work >> >> when I install app and liblib.so on the phones. >> >> >> >> Dave >> >> ... >> > ... >> ... > ___ > 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: QtCreator, libraries, and multiple platforms
Do you have a particular reason for the requirement (like license) to have a separate library, instead of just having one monolithic application? On Wed, Aug 3, 2011 at 10:03 PM, David Talmage wrote: > I need help making QtCreator build an application and a library for Maemo, > Symbian (using the remote compiler), and the simulator. I've been all over > the documentation, the forum on Qt Developer Network, and Google. I can't > find > an example that does what I need. > > I have a library (lib) and an application (app). Each one is a QtCreator > project. I can build them individually but I can't link app with liblib.so. > Whatever I use has to work with maemo.org's autobuilder and Nokia's remote > compiler for Symbian. > > As a first pass, it would help if there is an environment variable I can > reference in app.pro like $$OUT_PWD that contains the name of the build > directory for lib. Then linking might work. I can hack something together > with qmake's replace(), like replace($$OUT_PWD, app, lib) and that might work > as long as app/ and lib/ were in the same directory. I don't know how well it > would port or whether it would continue to work when I install app and > liblib.so on the phones. > > Dave > ___ > 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: package promotion blocked
There probably is no reason to block it anymore. Any objections to removing the block, anyone? On Wed, Jun 8, 2011 at 1:05 AM, b0unc3 wrote: > Hello, > > I would like to promote my package to the extras-testing, but I see a > warning that says: > "Warning: Promotion of experimental Qtm based applications (libqtm11 or > libqtm-extras) is blocked due to conflicts with stable versions." > My package is a QML app, that, as far as I can tell, depends (needs) on > libqtm-11-sensors and libqtm-11-declarative. > Could someone please give some advice on which library I've to use to > promote my package? > Thank you. > ___ > 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: Stopping QML update when not visible
On Mon, May 30, 2011 at 6:15 PM, Andrew Flegg wrote: > BTW, list handling in QML is a pain. I suspect this list > recreation/parsing/manipulation is accounting for a large portion of > the CPU usage. Other thoughts from Qt Quick experts appreciated; but Have you considered using plain javascript Arrays, instead of QML lists? I find them better, mainly because I dislike the undocumented and quirky behavior of most QML specific data types (immutable QVariantMap's etc). They would probably be faster than what you are currently doing as well. There is no way to store javascript objects in QML components yet (yes, I frequently complain about this in various places), but you can accomplish the same by using this "priv" hack: http://projects.forum.nokia.com/catbowling/browser/qml/catbowling/priv.js http://projects.forum.nokia.com/catbowling/browser/qml/catbowling/GameScene.qml Check out how the list "enemies" is handled in GameScene.qml ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stopping QML update when not visible
On Mon, May 30, 2011 at 6:07 PM, Ville M. Vainio wrote: > Right - so I confirmed Andrew's fear that QML would be "stupid" about Erk, reverse logic, I confirmed Andrew's fear was *unnecessary*, of course. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stopping QML update when not visible
On Mon, May 30, 2011 at 5:49 PM, Robin Burchell wrote: >> I confirmed that e.g. QmlReddit does nothing when it's hidden. > > Note that of course, nothing will be happening if there's nothing to > actually happen. If your objects aren't moving, etc, then Qt won't > constantly have to redraw items, at most, it'll just be blitting from the > widget backing store to the screen, but even that shouldn't happen here > since we only have one topmost window, and no cursor moving around, etc. Right - so I confirmed Andrew's fear that QML would be "stupid" about this, and waking up the process when it should be steady (e.g. by doing a dummy op at 60fps). If you have animations that proceed when the application should be steady, you have a broken design in the first place; this is a problem that application developer can easily solve. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Stopping QML update when not visible
On Mon, May 30, 2011 at 4:55 PM, Andrew Flegg wrote: > Thoughts welcome. To be honest, it's amazing (and disappointing) that > there isn't a way of doing this in Qt Quick 1.0. Can anyone confirm > whether or not it's at least not updating the screen when hidden (it > does in the task manager), and it's only the accelerometer signalling > I need to switch off? I confirmed that e.g. QmlReddit does nothing when it's hidden. I checked this with: ltrace -C -p 1677 strace shows some random mainloop wakeups, but nothing that would register in "top". So, the problem luckily appears to be application specific (and accelerometer is a good start). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: scratchbox question
On Fri, May 6, 2011 at 5:25 PM, Rainer Dorsch wrote: >> Did you try creating the symlink yourself, i.e: >> >> [sbox-FREMANTLE_ARMEL: ~] > mv /opt /opt_old >> [sbox-FREMANTLE_ARMEL: ~] > ln -s /targets/links/opt /opt >> >> >> ? > > Thanks for your quick reply. After adding it manually (and reinstalling the > packages installing to /opt), I have a working scratchbox again. > > Is that worthwhile a bugreport? Yeah, please file one and add the link here, for reference. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: scratchbox question
On Fri, May 6, 2011 at 8:14 PM, Rainer Dorsch wrote: > Seems that my fundamental problem is that /opt is not a symlink to /targets. > > Is that a known problem? If yes, what is the workaround/solution for that? I see that problem (missing symlink) on my scratchbox as well. Can't say what broke that. Did you try creating the symlink yourself, i.e: [sbox-FREMANTLE_ARMEL: ~] > mv /opt /opt_old [sbox-FREMANTLE_ARMEL: ~] > ln -s /targets/links/opt /opt ? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Qt version & CSSU
Am I correct in assuming that CSSU plans to add new Qt stable Qt versions as they are released, currently 4.7.3? Was there some manual work in getting 4.7.2 going, apart from just merging the maemo5 branch stuff over mainline Qt? Or was even that required? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt SDK 1.1 RC released
On Fri, Apr 8, 2011 at 7:53 PM, Till Harbaum / Lists wrote: > i am mainly using the remote compiler (my broken n900 and the absence of any > meego device has > made symbian my primary target). This still returns a 4.7.2/1.1.1 binary. > Will this also change? Remote Compiler will always be upgraded to latest Qt versions in routinely fashion, though there may be slight delays. That said, it doesn't matter much what Qt version is used for compilation, what matters is the library version installed on the device. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
CSSU: optification of /var/lib/dpkg and /var/lib/apt
Possibly this has been discussed before, but - Would it make sense to optify the mentioned directories in CSSU? Altogether both dirs take 64megs of space for me. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libdeclarative-multimedia on Maemo 5: Video component not working?
On Sun, Feb 6, 2011 at 2:55 PM, Thomas Perl wrote: >> Hmm, I wonder whether pyside builds in extras-devel should be switched >> over to using the unofficial 1.1 / 1.2 qtm packages on maemo5 >> eventually... > > I don't think PySide has anything to do with this, as all this happens > inside the QML Declarative Engine. This is easily reproducable using > qmlviewer :) Qt Mobility provides the multimedia functionality for QML, it's not built in to Qt 4.7. > I've now installed Qt Mobility 1.2 from Extras-Devel, and still > experience the same issue. Let's see if we can make some sense of it next week... -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libdeclarative-multimedia on Maemo 5: Video component not working?
On Sun, Feb 6, 2011 at 2:01 PM, Thomas Perl wrote: > ~ $ dpkg -l | grep -i mobility > ii libdeclarative-multimedia > 1.0.2-maemo1+0m5 Qt Mobility Multimedia QML plugin Hmm, I wonder whether pyside builds in extras-devel should be switched over to using the unofficial 1.1 / 1.2 qtm packages on maemo5 eventually... http://wiki.forum.nokia.com/index.php/Latest_Qt_and_Qt_mobility_evaluation_on_Maemo -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libdeclarative-multimedia on Maemo 5: Video component not working?
On Sun, Feb 6, 2011 at 1:17 PM, Thomas Perl wrote: > I plan to use the QML "Video" element from libdeclarative-multimedia > (Qt Mobility QML Multimedia Components), and it already works great on > Linux on my laptop, but it does not work right now on Maemo 5. The > element exists, and I can create instances of it, but videos don't > load. I can provide an example if necessary. It does not work for both > local files and remote files (source set to a URL). What mobility vecsion are you using? -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Important information for QML & N900 users
On Sat, Jan 29, 2011 at 5:02 PM, Sivan Greenberg wrote: > What is the fix that enables remote images to load through QML? is > this related to the security sand box? There is no security sandbox in N900, the fix is: http://maemo.org/packages/view/libqt4-bearer-hotfix/ It's about bearer management race conditions in in Qt. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Important information for QML & N900 users
See: http://blogs.forum.nokia.com/blog/ville-vainios-forum-nokia-blog/2011/01/29/mcsp TL;DR: apt-get install mcsp -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
On Thu, Jan 27, 2011 at 6:00 PM, Felipe Crochik wrote: > I have to say that I like how the 3 of them work. If we are going to take on > making a better tool we should aim high. It needs to be more than an > "application manager" it needs to be a tool for the user to find and decide > among all the applications available what he needs and, just by accident, > install them. We need to have all the information about the application > available (screenshots, score, repository, user reviews, # of downloads, > ); a very good search; and above all we need to have some service > tracking what the user has installed not just to notify him about updates > but also to remind him to vote/comment on applications that he has > installed; A Donate button would also be great once we are there! There has been some activity in the cross-distro app manager front recently: http://ostatic.com/blog/one-package-manager-for-them-all The fact that rpm/deb repositories are quite badly suited for modern desktop/mobile linux use is undeniable. What we should have is a fast web-service that sits on top of the "real" repository and provides only the information that is needed at the time. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Mon, Jan 10, 2011 at 4:06 PM, Cornelius Hald wrote: > I just tried to compile my app agains libqtm-11, but it fails to find > the included and the libraries. Of course I can add them manually, but > usually this works using Qt features. > > To me it looks like the dev package doesn't install the necessary files > to /opt/qt4-maemo5/mkspecs/features. What's in /opt/qt4-maemo5 these days? I thought it was dead after pr1.2. These packages use the default system Qt, not /opt/qt-maemo5 stuff. Remember to do CONFIG += mobility11 instead of just mobility. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Localization of application fails - GLIB WARNING
On Sun, Jan 9, 2011 at 2:46 AM, wrote: > I just dived into Maemo development. As a "warm-up" I thought to translate a You should re-dive form a different spot, as you are currently looking at "legacy" way of doing Maemo development (Gtk+, Hildon). Read up on Qt Quick. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Tue, Jan 4, 2011 at 3:47 PM, Felipe Crochik wrote: > I think the most important thing is to decide on a place that the people > involved will check/comment so the information doesn't get lost. This list > will be fine to start with. Any major issues will probably have to be > reported upstream anyway. We have trac at: https://projects.forum.nokia.com/qtmexperimental > Just so you know in the past when I tried to package an "alternative" > version of the backend I had problems getting my applications to use it - it > was not enough to compile (with a different prefix) and install qtm to a > different folder. I couldn't figure out and just decided to define a new > backend "name" so they could live in parallel on the official plugins > folder. Plan is to use this in your app (yeah, that's a custom change #2): http://doc.qt.nokia.com/stable/qcoreapplication.html#addLibraryPath stay tuned, though. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Wed, Dec 29, 2010 at 4:47 PM, Felipe Crochik wrote: > This is really great news! I assume applications using it can not promoted > to extras-testing until we have the SSU with libqtm-11-*, right? Not really (see my reply to Niels). > Please let me know if I can help in any way. You and everyone else can help by switching your apps to use 1.1 packages and see whether they still work. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt Mobility 1.1 for Fremantle
On Wed, Dec 29, 2010 at 5:19 PM, Niels Breet wrote: >> This is really great news! I assume applications using it can not promoted >> to extras-testing until we have the SSU with libqtm-11-*, right? >> > > I've put a block in place to prevent a mess, but once we have a SSU > with newer qtm we can remove the block. I believe we can remove the block early next year anyway, after we see some apps using these successfully in extras-devel. The SSU delivery of qtm 1.1 (if/when it happens, but let's not count on it) is a replacement for 1.0.2, and can exist parallel to these packages. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to forward a message to QCoreApplication::arguments() ?
On Fri, Nov 19, 2010 at 8:22 PM, Timo Pelkonen wrote: > I am trying to give a message with random length and formation to simple Qt > cli application. What is the best way to do it? I have tried with quotation > marks but åäö don't appear at all and the message could contain quotation > marks so that probably messes everything up. Would it be the most failsafe > method to put the whole message into a single file which is read then by the > application? That, or use stdin & stdout to relay the data to the child process. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Community SSU
On Tue, Nov 2, 2010 at 12:44 AM, Andrew Flegg wrote: > Well, we won't know unless we test them, will we? Having said that, it > seems that the Nokia maintainers have been tidying up loose ends - > and, indeed, I hope we'll even see them contributing further now that > they have more free rein to do "what they've always wanted". In general terms, this is the first chance for the community to really get involved with the software and get their code deployed to tons of devices around the world - not just as an insulated application, but something that forms the essence of the very phone. If this gathers steam well, It could be a sort of new start for Maemo5. > >>> This is not a proper announcement for the SSU, but more of a prerelease >>> before it's posted on talk.maemo.org, so please, >>> do not post about this on talk. >> >> That does not sound right. It sounds like you are trying to split this small >> community into a few communities. > > No, it sounds like getting proper experienced developer feedback when > launching something which has real possibility to lead to a reflash. > In particular, the process with the X Terminal is already a little > clunky (and didn't work for me directly; but did work when I ran the > postinst as root from another X Terminal, something I've already > reported to Mohammad). > >> What is your goal in setting up this SSU repository? > > AIUI (and Mohammad has the full backing of this council member), the > aim is to ensure that the community SSU is up and running to deliver > bug fixes and improvements to Maemo 5 now that Nokia have (most > likely) completely moved on. The long delay in getting similar set up > for Diablo meant that a lot of the impetus was lost. Now, however, the > N900 development community has yet to move on to Harmattan (and, > indeed, with some of the changes may not entirely) and has many more > eager users. It's the perfect time to start building on the starting > point delivered by Nokia. (For example, I already appreciated the > packaging that hrw did in the past, and Mohammad is now doing, of > Modest with the "proper quoting" and attribution patches the community > provided; but Nokia never shipped). > > I can imagine a number of ways of getting involved if you want to > help, including carving out a space on wiki.maemo.org to deal > with/document the issues of and around: > > * Release management - how does testing/QA/release work? > * Source code management - community SSU has branches in > gitorious, with "upstream" being the original projects with > their Nokia maintainers? > * Collaboration - new mailing list in addition to the IRC > channel? > * SSU utility development - improving the enabler, for example. > * Build process - are these packages being built from tarballs > by the autobuilder, or manually? > > I'd like to thank Mohammad again for his efforts over the last few > months in starting this effort, and continuing with it now that > PR1.3's been released. > > Cheers, > > Andrew > > > -- > Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ > Maemo Community Council member > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: window focus and screen lock events
apt-get source suspendprocess is a good start (be sure to have source repos enabled) -- Sent from my Nokia N900 - Original message - > Hi all, > > there was a discussion some time ago about suspending (pausing) an > application when it loses focus or the screen is locked. I am now > trying to do just that. I gathered that I need to handle a GTK signal > for window focus and a DBus message for the screen lock. But searching > further I haven't found much information... > > I must be looking in the wrong place for the GTK signal documentation. > The DBus message I could probably figure out, but I thought I'd ask > first for pointers to any existing examples or a good documentation > someone might have? (I have zero knowledge of both GTK and DBus...) > > Thanks in advance > lukash > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reviewing beginner packaging docs
On Thu, Oct 14, 2010 at 3:28 PM, Dave Neary wrote: > If you're building your software with autotools, you get a bunch of > helper scripts for your packaging coming along for the ride. You also > get "make install" and "make dist" for free. If you're building your > software with a Qt project, you also have a standard way of installing > software. You can get "make install" quite easily with qmake as well. It's a basic boilerplate you attach to your project: http://pastebin.com/QfsRYtqF (it's not perfect, but gets the job done). > And usually software writers don't particularly want to install their > software on only one distribution, you'll often get .tar.gz, .rpm and > .deb versions of the same package. Yeah, what you have to do with qmake is to tweak the .pro file (with the above snippet) so that "make install" works. After that, packaging just captures the resulting files in the usual fashion. It's not perfect, but gets the job done. You may blame it for mindless copy-pasting, but that irritation passes and you move on ;-). Note that "shadow build" (build outside source tree) works just fine with qmake. > Also, one of the typical beginner strategies I see is someone who takes > existing desktop software & tries to adapt it for the N900. So there's > an existing build infrastructure in place already. Right. Do you think that's the average developer though? In this case, we would be dealing with someone that has pre-existing Linux skills, and possibly also a larger tolerance for pain and lack of documentation (or overabundance of misleading documentation and folklore, as is often the case). > I disagree. MADDE and Nokia Qt SDK may be the future for MeeGo, but when > we're talking about Maemo 5 documentation, Hildon is still the > reccommended UI toolkit and we should ensure that people coming to > Fremantle have good docs. >From PR1.2 onwards, Qt is the recommended toolkit, at least if you are doing anything commercial (but you know this already). N900 has an excellent Qt implementation, and with Qt you stand a recent chance of someone being able (and willing) to help you out if you have problems. All of this is somewhat besides the point of your thread, which is to fix the documentation, and I don't wish to act as stop energy on that. It's just that the page http://wiki.maemo.org/Packaging is not really what we'd like to tell random beginners about packaging right now. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reviewing beginner packaging docs
On Thu, Oct 14, 2010 at 11:07 AM, Dave Neary wrote: > So - your advice to someone looking to package a Hildon application for > Fremantle would be to rewrite it as a Qt app? Or will qdebwiz also work > with Hildon apps? Nope, qdebwiz is only for simple Qt + qmake apps (I made it for personal use, really). I wasn't even thinking Hildon application authors would have trouble packaging; new developers (the ones that need guidance the most) are expected to use Qt, or have a good reason not to use Qt. Also, all the existing Hildon applications are probably packaged already. > Or perhaps I'm misunderstanding you, and you're suggesting that > developers should use whatever method is appropriate for the upstream > build tools, and then handle the packaging afterwards? (which seems like > sensible advice). Actually, I wasn't even considering the option that "upstream" could be someone apart from the packager. That's not the beginner usecase - it's something for a separate porting guide (outlining what you need to change when porting stuff from debian/ubuntu). We don't really want to create the illusion that it's ok for a beginner to create a project using autotools/cmake and expect everything to work - we would be doing them a disservice. It was ok in the early days of maemo5, but nowadays things we push should work with MADDE and Nokia Qt SDK as well. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reviewing beginner packaging docs
it trivially easy for someone to create a package, given working source > code, which will pass muster for extras-devel, and understand what each > step is useful for along the way. > > Does anyone have some time over the next couple of days to help make > this stuff rock? I'd be very happy to see us split pages off (say: a > .desktop format reference separate from the "here's the 3 required > fields in a .desktop file, here's where you create it, here's how you > make sure it gets installed in the right place" basic docs. > > Thanks! > Dave. > > -- > maemo.org docsmaster > Email: dne...@maemo.org > Jabber: bo...@jabber.org > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Good email framework library
On Sat, Oct 2, 2010 at 3:46 PM, Sivan Greenberg wrote: >> A (probably) good decision has already been made for you - QMF is used >> in MeeGo handset UX: >> >> http://labs.qt.nokia.com/2009/09/21/introducing-qmf-an-advanced-mobile-messaging-framework/ > > So I can go ahead and test drive it in a latest meego-arm image? Possibly (I don't know how broken it is atm), but a much better way to test drive it is to use qtmail on desktop. Or, it seems it's packaged for maemo5 as well: http://www.my-maemo.com/software/applications.php?name=QMF_Mail_Client&fldAuto=1854&faq=37 -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Good email framework library
On Sat, Oct 2, 2010 at 1:50 PM, Sivan Greenberg wrote: > Can anybody recommend good email framework lib that would be a good > backend for a Qt baed email client? Any feedback about what you think > could have been done better or should not be repeated mistake in a > piece of software like this is highly appreciated. A (probably) good decision has already been made for you - QMF is used in MeeGo handset UX: http://labs.qt.nokia.com/2009/09/21/introducing-qmf-an-advanced-mobile-messaging-framework/ I have developed a plugin for both QMF and Tinymail, and have to say QMF has a "safer", simpler design - it stores the emails in sqlite database and relies on multiprocess, rather than multithreaded architecture. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MADDE 'developer' account - good or bad?
On Mon, Sep 27, 2010 at 8:58 AM, wrote: > Earlier in the summer I tried with "root" using the password authentication > scheme - it worked. If you use "user" then you do not need to use the key > mechanism, the password does not change frequently like the "developer" > password. Storing the password at qtcreator is problematic for those of us who tend to use "high value" password for user. In fact it might be handy to treat the user password just like developer password - just have it be temporary until user leaves Mad Developer. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MADDE 'developer' account - good or bad?
On Wed, Sep 22, 2010 at 6:25 PM, Thomas Perl wrote: > The current version of Qt SDK automatically creates and deploys a .deb > on the device, so once the package has been deployed, if I want to > test the app with the "user" account, I just run it from X Terminal > (/usr/local/bin/ with a standard project). Don't know if that > is a solution for IDE-loving developers, but it's not that hard, and > you can always have a xterm (or PuTTY for Windows users) running on > your development machine and start the app from there. Being able to set a breakpoint and actually hitting that breakpoint on device without batting an eyelid is what IMO rocks most about the whole Nokia Qt SDK scheme. If I was launching the program over ssh, I could as well go back to scratchbox and a bunch of scripts to build & copy the program over to device. BTW, in new versions you can disable that packaging step (from build settings, by expanding the "Create Package" build step). This makes the deployment ~1 sec experience, which is pretty nice. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MADDE 'developer' account - good or bad?
On Wed, Sep 22, 2010 at 5:53 PM, Christian Kandeler wrote: >> That means that it doesn't use the information (databases etc.) stored >> in the users home directory. I'm gradually starting to feel this is a >> bad idea, that leads to subtle problems when developers are trying to >> pretend that they are running their application as default user (and >> hence have direct access to all the data user has). > > From Qt Creator's side, nothing prevents you from just giving the user name > "user" instead of "developer" in the Maemo device configuration. The only > problem is then accessing that account; if I'm not much mistaken, login is > disabled for it. I just tried - Giving password to "user" - ssh in as user from terminal (success, answer "yes" to host id query though). - Test connection as "user" (success, qt versions listed) - Deploy key as "user", test the "key" authentication scheme (success, qt versions listed) - Run a program with ctrl + r using this setup (fail): Cleaning up remote leftovers first ... Error running initial cleanup: Could not connect to host.. Have you guys (Christian & Tomi mostly ;-) verified this scheme (using 'user') to work recently? -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MADDE 'developer' account - good or bad?
On Wed, Sep 22, 2010 at 3:01 PM, Attila Csipa wrote: > If there are no components that work with hardcoded usernames od uid/gids, > that would roughly be it (for files, which are the most common problem > IIUC). Services/daemons might get tricky but I suppose that is not a nearly > as common scenario. One-time copy can also be problematic if you are mutating the data in real time as 'user' while running a program (that is interested in the same data) as 'developer'. This is not an entirely unrealistic use case. Also, developer would be on separate dbus session bus from 'user' (UUIC). Considering all of this, I'm inclined to wish we had a "I know what I'm using, please run this app as 'user'|" checkbox in Nokia Qt SDK. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
MADDE 'developer' account - good or bad?
As many of you go, Nokia Qt SDK uses, through MADDE, a special 'developer' account (with it's own home directory) to do stuff on the device That means that it doesn't use the information (databases etc.) stored in the users home directory. I'm gradually starting to feel this is a bad idea, that leads to subtle problems when developers are trying to pretend that they are running their application as default user (and hence have direct access to all the data user has). Discuss :). -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package promoting
On Wed, Sep 22, 2010 at 1:38 PM, Attila Csipa wrote: > A secret weapon is in the making - KISStester, which would allow easier > feedback for users, and it also acts as a REMINDER for people who are using > software that is in dire need of testing (the problem is that people > *download* things from testing but forget/can't be bothered to come BACK to > vote on it). I'd also like a mailing list where people can complain about this kind of stuff (maemo-apps?). TMO has incredibly low SNR, and pleas for testing drop away from front page in less than an hour. Interstingly, it seemed that e.g. my "qreddit" app had got >1 downloads before it passed the vote threshold (w/ 3 supertesters); it seems people are downloading, but sure as heck they are not voting. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: suspendprocess - poor man's power save
On Mon, Sep 20, 2010 at 3:35 PM, Eero Tamminen wrote: > For example D-BUS will infinitely buffer messages that are sent > to a connected client but not read by it. If these messages can > be very frequent (say device orientation & network condition messages), > this will soon bloat D-BUS memory usage quite a bit. After D-BUS > starts to swap, it won't perform very well. Ok, so much for the easy hack. What you say above has other sinister overtones as well - an application that is listening to frequent dbus signals has no way of getting swapped out, or staying swapped out (it can stay mapped in for days without doing any useful work at all). I don't think real applications out there have a habit of unsubscribing from dbus signals when they don't need them either. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autocomplete Library
On Sun, Sep 19, 2010 at 8:25 PM, Sivan Greenberg wrote: > I would go to the trouble to provide a more "complete" autocomplete > lib, in the form of completing not just by autocomplete lists provided > by some readline client apps, but to employ "heuristics" to > autocomplete words related to a usage domain of certain tools and > apps. Sort of like that tool that's available from Debian that reads You are thinking of bash competions: http://www.debian-administration.org/article/An_introduction_to_bash_completion_part_1 -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: suspendprocess - poor man's power save
On Sun, Sep 19, 2010 at 9:27 AM, Ville M. Vainio wrote: > 2) Perhaps this would be even more useful to keep multitasking memory > usage at bay - by suspending the processes not in foreground (by their > own volition of course)? ... one more thought: It would be more useful if it wasn't a launch wrapper, but rather a lone daemon that sits in the background and suspends a set of processes according to given heuristics (e.g. suspend gpodder when a call is initiated, matched by /proc/NNN/cmdline). This would allow suspend rules to be created for apps outside the packaging/implementation for the app itself. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: suspendprocess - poor man's power save
On Sun, Sep 12, 2010 at 9:47 AM, Attila Csipa wrote: > It has been difficult for many developers to comply with many of the > recommended > power-saving practices for Maemo, especially those porting apps from desktop > environments. I'm not sure how many of you noticed already, but in the best > hack-tradition of the N900 mikkov made a suspendprocess package, not unlike > what was talked about on this list - which could allow many of these power- > guzzling apps to become a little more suspend-power-friendly with little to no > effort. > > http://maemo.org/packages/package_instance/view/fremantle_extras- > devel_free_armel/suspendprocess/0.1/ > > Basically it is a launch-wrapper that SIGSTOPs and resumes the app it started > based on the DBUS signals. > > I would recommend all interested parties to take a look and if it > improves/helps in their apps/packages, apply it to them (or report any > problems/improvement suggestions, naturally). It's not the prettiest solution > and native level DBUS solution is of course still preferred by far, but if you > don't have that time or luxury (or are blessed with SDL code or similar), this > might come handy. Quoting everything because this is an old email (and not everyone still has it around). It's an intriguing hack, and I'm somewhat curious about people's thoughts about the following: 1) Will native dbus solution *really* be better in all cases? Or would suspending the process actually help move a sleeping process to swap more aggressively than just blocking? 2) Perhaps this would be even more useful to keep multitasking memory usage at bay - by suspending the processes not in foreground (by their own volition of course)? 3) It seems to be implemented in python + somewhat heavy libs (gobject, osso). C + libdbus implementation would be more convenient, esp. if this turns out to be a popular approach. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application icons
On Tue, Aug 31, 2010 at 1:42 PM, Naresh Mehta wrote: >> Ok, thanks. What about Harmattan? I've tried some possible locations, but >> haven't had any luck so far with the icon showing up. >> > > Same problem for me. I am not able to get the icon to display in the > grid menu or on the shortcut on the desktop. But it shows up pretty > good in the application manager. Don't know what is wrong with it. If you are also talking about Harmattan, it's not (yet) kosher for this public mailing list. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application icons
On Tue, Aug 31, 2010 at 10:17 AM, Christian Kandeler
wrote:
> when writing Qt applications for Maemo,
> http://wiki.maemo.org/Packaging_a_Qt_application advises to add the
> following to one's .pro file:
> iconxpm.path = $$DATADIR/pixmap
> iconxpm.files += ../data/maemo/$${TARGET}.xpm
My theory is that this is folklore from pre-maemo5 days ;-).
I tried "calling the bullshit" and just doing this in my app (64x64 icon):
icon.files += data/scalable/qtdone.png
icon.path = $$DATADIR/icons/hicolor/scalable/hildon
and I don't really miss anything in terms of icons.
BTW, would it be possible to have the packaging stuff created by qt
creator done in a .pri file that is merely included by the .pro file?
It would seem much cleaner to me.
--
Ville M. Vainio @@ Forum Nokia
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo / MeeGo application gallery?
2010/8/29 Benoît HERVIER : > http://maemo.org/downloads/Maemo5/ isn't restricted to extras. You can > put any install file to any repository. This is just not recommended > to send user to extras devel. When a package reach extras some infos > are updated on Maemo5 download page. But this isn't the case when the > package didn't reach extras, but the dev can do it manually. Are there instructions somewhere on how to create an entry in the "Downloads" page, without getting the app to extras? -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo / MeeGo application gallery?
The concept is so obvious, it has probably been discussed to death many times over - Should we have some central place to "showcase" maemo / meego applications, wherever they are? I mean all of extras / extras-devel / Ovi store. Sort of like http://maemo.org/downloads/Maemo5/ , but with the difference that you don't need to be in extras to have a space there. It could also have a nicer wiki (that would not revert your changes randomly ;-). -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to use osso RPC calls properly
On Wed, Aug 25, 2010 at 5:25 PM, Dave Neary wrote: >> You should avoid osso_ calls, my understanding is that they are >> deprecated (and they deliver very little value in the first place - >> just make your program maemo specific). > > > > How would you feel about converting this to a use-case for the Maemo > wiki, something along the lines of "Searching for bluetooth devices"? I believe this will be better done by mr. Possunuha, since he will soon have a full, functional example anyway. I have no complete, tried example at my disposal. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to use osso RPC calls properly
On Wed, Aug 25, 2010 at 4:10 PM, wrote:
> I've been trying to show bluetooth device search dialog using osso_rpc_run
> and osso_rpc_run_system but this code returns OSSO_RPC_ERROR every time.
You should avoid osso_ calls, my understanding is that they are
deprecated (and they deliver very little value in the first place -
just make your program maemo specific).
Your string vector argument seems like illegal to me (
DBUS_TYPE_ARRAY, DBUS_TYPE_STRING) - where is the value?
Have you checked out this already:
https://garage.maemo.org/pipermail/maemo-pan-devel/2008-May/06.html
function show_pairing_dialog :
+ if (!dbus_g_proxy_call(proxy, CONBTDIALOGS_SEARCH_REQ,
+ &error,
+ G_TYPE_STRING, "",
+ G_TYPE_STRING, "",
+ G_TYPE_STRV, &filter,
+ G_TYPE_STRING, "require",
+ G_TYPE_INVALID, G_TYPE_INVALID)) {
+ g_print("ERROR: %s\n", error->message);
+ g_clear_error(&error);
+ g_strfreev(filter);
+ g_object_unref(G_OBJECT(proxy));
+ return;
--
Ville M. Vainio @@ Forum Nokia
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Let's break this silence
On Sat, Aug 21, 2010 at 10:56 AM, koos vriezen wrote: > Cross posting because I'm curious about meego efforts to create a Qt > application booster. Does this help: http://apidocs.meego.com/mtf/faststart.html -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to upload screenshot for my application on extras?
On Mon, Aug 16, 2010 at 4:31 AM, Felipe Crochik wrote: > I just promoted some of my applications to extras and would like to have > them show a “screenshot” on the downloads page but can’t find how. You have to click "edit" on your apps download page, then you can upload an image. Interestingly, while you can edit the package description, those edits don't stick. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to create an icon on desktop on N900 and link my binary to that
Nah, single instance works without x-osso-service as well. I don't know whether that line has any sensible purpose, actually - dbus activation will be done with separate dbus service file anyway. -- Sent from my Nokia N900 - Original message - > > I thought the DBus initialization was used to allow only one intsnace of > your program to be run, which is good on a handheld device ... > > I think you should let the user decide if he wants to put a shortcut on > his desktop or not ? > > Fred > > Le 10/08/2010 17:29, Naresh Mehta a écrit : > > Hi All, > > > > > wrote: > > > > > > > You simply have to create a .desktop file associated with your > > > > program (don't forget to initialize dbus session with osso_init) > > > osso_initialize is not needed if you don't specify X-Osso-Service in > > > the .desktop file. > > > > > > Here's a .desktop file that works properly: > > > > > > [ville~/qtdone]|4> cat qtdone.desktop > > > [Desktop Entry] > > > Encoding=UTF-8 > > > Version=1.0 > > > Type=Application > > > Name=qtdone > > > Exec=/usr/bin/qtdone > > > Icon=qtdone > > > StartupWMClass=qtdone > > > X-Window-Icon=qtdone > > > X-HildonDesk-ShowInToolbar=true > > > X-Osso-Type=application/x-executable > > > Terminal=false > > > > > I have a similar desktop file in my application and it shows up in the > > menu. But I can't place a shortcut/link on the active screen. I would > > like to do it during installation. Also my icon does not show up > > properly. The code is available on http://confmgr.garage.maemo.org/. > > Would be great if someone can point me in the right direction. > > > > > -- > > > Ville M. Vainio @@ Forum Nokia > > > ___ > > > 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: How to create an icon on desktop on N900 and link my binary to that
On Tue, Aug 10, 2010 at 4:02 PM, Fred Lefévère-Laoide wrote: > You simply have to create a .desktop file associated with your program > (don't forget to initialize dbus session with osso_init) osso_initialize is not needed if you don't specify X-Osso-Service in the .desktop file. Here's a .desktop file that works properly: [ville~/qtdone]|4> cat qtdone.desktop [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=qtdone Exec=/usr/bin/qtdone Icon=qtdone StartupWMClass=qtdone X-Window-Icon=qtdone X-HildonDesk-ShowInToolbar=true X-Osso-Type=application/x-executable Terminal=false -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Begininer-PLZ HELP.
On Tue, Aug 3, 2010 at 10:43 PM, akhilesh ashwin wrote: > My ambition is to do a Gsoc project in Maemo .Could you please give me > information on how to go about the whole thing.Should I start with > freemantle or diablo?Its pretty confusing.Please help me to develop > myself for Gsoc. In a nutshell - learn Qt. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: I cannot build a QtMobility application with Scratchbox
On Wed, Jul 28, 2010 at 12:38 AM, Andrea Grandi wrote: > But... if I try to compile it under Scratchbox, I get the following > errors: http://pastebin.com/LGAxjxLv This raises the alarm bells: I/targets/FREMANTLE_ARMEL/opt/qt4-maemo5 apparently you are using the old unofficial qt4-maemo5 stuff. Ensure that you have removed all the old -maemo5 qt packages. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo QA process
On Thu, Jul 22, 2010 at 2:02 PM, Thomas Perl wrote: > Wouldn't this slow down the whole process even more? Instead of > getting one vote right away, you have to wait for the "return vote" to > be completed, and only then the vote gets counted. A "download People could still give unconditinal votes (they would be passed around by people that don't need votes, i.e. have no apps). It would only slow down the process for those that are not willing to test other applications. I'm certainly in favor of improving the testing experience on all fronts (and in fact suggested an app for this purpose months ago, so I'm not expecting anyone to jump in and do one now). However, what I'm proposing here is a direct incentive for developers to start helping each other. > enough votes during one week. Visibility and promotion of the apps are > the problems, I think (searching for apps is tedious, so nobody does > it) - the conditional vote idea sounds like a technical solution > (enforced policy, added restrictions) to a social problem (non-popular > apps don't get enough exposure and consequently testers). Technical solution is the best solution for a social problem ;-). It cuts through the bullshit, to parahprase an 80's movie. Other solutions would appear to require continuing effort from several parties (all of whom are probably overloaded). However, here are some "softer" solutions: - Put a sticky post at "applications" forum on TMO, linking to the vote page - Don't fret too much about QA checklist ( http://wiki.maemo.org/Extras-testing/QA_Checklist ): - Not everybody should check for optification, it should be automatic - Doesn't missing bugtracker link prevent promotion to e-t anyway? -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo QA process
On Thu, Jul 22, 2010 at 1:11 PM, Thomas Perl wrote: > If there are enough users / testers, releasing every month is no > problem. I have the same situation with my app (a new release nearly > every month), and with enough testers, I usually get enough votes in Well, using, say, gPodder (a "bestseller" of sorts that everybody uses) does not really paint the whole picture. How about a system where developers could convince other developers to test drive their application by voting on theirs? I.e. being able to give a conditional vote that is "realized" only after the receiver votes up/down on your application? This would also encourage voting on less popular applications, as popular apps don't need to care about conditional votes. Incidentally: Someone please vote for qtdone -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resolve network connectivity without using Qt Mobility in Qt?
On Thu, Jul 22, 2010 at 10:33 AM, Marius Vollmer wrote: > Ville, if you escalate this, the right thing IMO would be to fix the > Application Manager, make a new Maemo 5 release with it, and somehow > 'force' people to update to it when they install a package from Ovi > Store that needs dependencies resolved. > > I am here this week only, so let's find some time to get this going. I was thinking of small scale escalation (i.e. fix test suite the Ovi QA guys are using). Getting an updated version of app manager out there is a whole different matter, unfortunately, and probably in the realm of confidential Nokia matters like the PR release schedules. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resolve network connectivity without using Qt Mobility in Qt?
On Thu, Jul 22, 2010 at 10:47 AM, Sascha Mäkelä wrote: > So according your opinion, should I wait for this issue to be resolved at > Nokia's end or should I try to make changes to my app? The one suggestion > I've been given several times is to statically include Qt Mobility, but I'm > not so sure if that is a great idea and even if it was, I don't know how to > do that. As it appears, rabbit hole goes deeper than initially expected, so don't hold your breath on getting the issue fixed in reasonable timeframe :-/. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resolve network connectivity without using Qt Mobility in Qt?
Yes, my understanding is indeed that repository is used for paid applications (weird as it sounds). - Original message - > Hi Ville, > > I did that and this is the response I got: > > In fact, the issue is not we cannot install the missing libraries on our > own; it is that we cannot assume that end-users/consumers have this > knowledge to install the dependencies by themselves. > > Thus, the current workaround for this is to package the dependencies into > the app build so that end-users/consumers do not have to handle this > hassle. > > > Are you saying that Ovi Store is, after all, using a proper repository > even for paid apps? Could it be that all the people who know anything > about Maemo are currently on holidays and therefore I got this? > > Cheers, > > Sascha > > > On Thu, Jul 22, 2010 at 16:54, Ville M. Vainio > wrote: > > > I believed this is a misunderstanding or bad test case on ovi QA side. > > They are trying dpkg -i to ensure dependencies on "clean" environment, > > without awareness that dependencies to nokia repositories are ok. > > > > Advice them of this. > > > > > > > > - Original message - > > > Hi Ville, > > > > > > Let me just copy and paste here a few emails I got from Publish To > > > Ovi Support: > > > > > > As a matter of fact, this app is failed in QA because of "feature of > > > application manager direct installing from deb file cause that > > > installing > > > > > will complain two dependence library: 'libqtm-bearer and > > > libqtm-systeminfo are missing.'", quoted from internal communication > > > with our back-end. > > > > > > The reason is that Nokia hasn't yet embedded Qt Mobility on N900. > > > Although it will happen soon, currently developers have to manually > > > package the Qt Mobility package with their apps. > > > > > > You may find the Qt Mobility package and its individual packages > > > here: http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/. > > > > > > Files ending with _armel.deb are those ones that should be > > > pre-installed on N900 devices, whereas _i386.deb ones are for PC > > > environment. > > > > > > To be specific, for your case, you should at least package the > > > > > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/libqtm-bearer_1.0.0-maemo1+0m5_armel.deb > > > and > > > the > > > > > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/libqtm-systeminfo_1.0.0-maemo1+0m5_armel.debinto > > > your final build. > > > > > > > > > > > > And here is a other one: > > > > > > In fact, the issue is not we cannot install the missing libraries on > > > our own; it is that we cannot assume that end-users/consumers have > > > this knowledge to install the dependencies by themselves. > > > > > > Thus, the current workaround for this is to package the dependencies > > > into > > > > > the app build so that end-users/consumers do not have to handle this > > > hassle. > > > > > > > > > > > > And here is the final one: > > > > > > You can always try to build the Qt Mobility source with your app. The > > > source package can be downloaded at > > > > > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/qt-mobility_1.0.2-maemo1.tar.gz; > > > > > or you can use apt-get source libqtm-bearer to acquire. > > > > > > I'm also working on possible other solutions. Packaging a deb file > > > into another looks like having some trouble currently. I'll let you > > > know if I've made any progress. Sorry for the inconvenience. > > > > > > > > > > > > As you can see what I'm told by them, it seems that they are not > > > using a repository for paid apps. Do you have other information? > > > > > > Cheers, > > > > > > Sascha > > > > > > > > > > > > On Thu, Jul 22, 2010 at 16:16, Ville M. Vainio > > > wrote: > > > > > > > Well, that's certainly not the general understanding (inside > > > > Nokia) of how it should work. Do you care to elaborate so that we > > > > can escalate the issue (with the understanding that it's holiday > > > > period...)? > > > > >
Re: How to resolve network connectivity without using Qt Mobility in Qt?
That comment doesn't apply since applications are downloaded from repository, triggered by .install file (unless there is a terrible misunderstanding somewhere). Daniil, if you are not on holiday please priorize clarifying this issue with ovi guys. - Original message - > Hi Ville! > > Unfortunately what Sascha is saying is true. You cannot use Qt > Mobility in paid > applications. See this thread for a details: > > http://lists.maemo.org/pipermail/maemo-developers/2010-July/027109.html > > Thanks, Daniil. > > On Thu, Jul 22, 2010 at 4:54 PM, Ville M. Vainio > wrote: > > I believed this is a misunderstanding or bad test case on ovi QA side. > > They are trying dpkg -i to ensure dependencies on "clean" environment, > > without awareness that dependencies to nokia repositories are ok. > > > > Advice them of this. > > > > > > > > - Original message - > > > Hi Ville, > > > > > > Let me just copy and paste here a few emails I got from Publish To > > > Ovi Support: > > > > > > As a matter of fact, this app is failed in QA because of "feature of > > > application manager direct installing from deb file cause that > > > installing will complain two dependence library: 'libqtm-bearer and > > > libqtm-systeminfo are missing.'", quoted from internal communication > > > with our back-end. > > > > > > The reason is that Nokia hasn't yet embedded Qt Mobility on N900. > > > Although it will happen soon, currently developers have to manually > > > package the Qt Mobility package with their apps. > > > > > > You may find the Qt Mobility package and its individual packages > > > here: http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/. > > > > > > Files ending with _armel.deb are those ones that should be > > > pre-installed on N900 devices, whereas _i386.deb ones are for PC > > > environment. > > > > > > To be specific, for your case, you should at least package the > > > > > > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/libqtm-bearer_1.0.0-maemo1+0m5_armel.deb > > > and > > > the > > > > > > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/libqtm-systeminfo_1.0.0-maemo1+0m5_armel.debinto > > > your final build. > > > > > > > > > > > > And here is a other one: > > > > > > In fact, the issue is not we cannot install the missing libraries on > > > our own; it is that we cannot assume that end-users/consumers have > > > this knowledge to install the dependencies by themselves. > > > > > > Thus, the current workaround for this is to package the dependencies > > > into the app build so that end-users/consumers do not have to handle > > > this hassle. > > > > > > > > > > > > And here is the final one: > > > > > > You can always try to build the Qt Mobility source with your app. The > > > source package can be downloaded at > > > > > > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/qt-mobility_1.0.2-maemo1.tar.gz; > > > or you can use apt-get source libqtm-bearer to acquire. > > > > > > I'm also working on possible other solutions. Packaging a deb file > > > into another looks like having some trouble currently. I'll let you > > > know if I've made any progress. Sorry for the inconvenience. > > > > > > > > > > > > As you can see what I'm told by them, it seems that they are not > > > using a repository for paid apps. Do you have other information? > > > > > > Cheers, > > > > > > Sascha > > > > > > > > > > > > On Thu, Jul 22, 2010 at 16:16, Ville M. Vainio > > > wrote: > > > > > > > Well, that's certainly not the general understanding (inside > > > > Nokia) of how it should work. Do you care to elaborate so that we > > > > can escalate the issue (with the understanding that it's holiday > > > > period...)? > > > > > > > > Definitely qtmobility is to be usable for Ovi store applications, > > > > and same applies for all the other packages that can be downloaded > > > > from nokia repos. If this is not currently the case, the process > > > > is broken at the moment. You should not change your apps design >
Re: How to resolve network connectivity without using Qt Mobility in Qt?
I believed this is a misunderstanding or bad test case on ovi QA side. They are trying dpkg -i to ensure dependencies on "clean" environment, without awareness that dependencies to nokia repositories are ok. Advice them of this. - Original message - > Hi Ville, > > Let me just copy and paste here a few emails I got from Publish To Ovi > Support: > > As a matter of fact, this app is failed in QA because of "feature of > application manager direct installing from deb file cause that installing > will complain two dependence library: 'libqtm-bearer and > libqtm-systeminfo are missing.'", quoted from internal communication > with our back-end. > > The reason is that Nokia hasn't yet embedded Qt Mobility on N900. > Although it will happen soon, currently developers have to manually > package the Qt Mobility package with their apps. > > You may find the Qt Mobility package and its individual packages here: > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/. > > Files ending with _armel.deb are those ones that should be pre-installed > on N900 devices, whereas _i386.deb ones are for PC environment. > > To be specific, for your case, you should at least package the > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/libqtm-bearer_1.0.0-maemo1+0m5_armel.deb > and > the > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/libqtm-systeminfo_1.0.0-maemo1+0m5_armel.debinto > your final build. > > > > And here is a other one: > > In fact, the issue is not we cannot install the missing libraries on our > own; it is that we cannot assume that end-users/consumers have this > knowledge to install the dependencies by themselves. > > Thus, the current workaround for this is to package the dependencies into > the app build so that end-users/consumers do not have to handle this > hassle. > > > > And here is the final one: > > You can always try to build the Qt Mobility source with your app. The > source package can be downloaded at > http://repository.maemo.org/pool/fremantle/free/q/qt-mobility/qt-mobility_1.0.2-maemo1.tar.gz; > or you can use apt-get source libqtm-bearer to acquire. > > I'm also working on possible other solutions. Packaging a deb file into > another looks like having some trouble currently. I'll let you know if > I've made any progress. Sorry for the inconvenience. > > > > As you can see what I'm told by them, it seems that they are not using a > repository for paid apps. Do you have other information? > > Cheers, > > Sascha > > > > On Thu, Jul 22, 2010 at 16:16, Ville M. Vainio > wrote: > > > Well, that's certainly not the general understanding (inside Nokia) of > > how it should work. Do you care to elaborate so that we can escalate > > the issue (with the understanding that it's holiday period...)? > > > > Definitely qtmobility is to be usable for Ovi store applications, and > > same applies for all the other packages that can be downloaded from > > nokia repos. If this is not currently the case, the process is broken > > at the moment. You should not change your apps design because of this > > glitch. > > > > - Original message - > > > Hi Ville, > > > > > > Yes, this is what I thought too, but apparently Ovi Store is NOT > > > using a repository for paid apps. So it simply using "dpgk" to > > > install the deb files and therefore it's not able to install > > > dependencies. It's frankly quite shocking, but this is the situation. > > > > > > Cheers, > > > > > > Sascha > > > > > > On Thu, Jul 22, 2010 at 15:54, Ville M. Vainio > > > wrote: > > > > > > > Qt mobility is in official nokia repo (not extras). It's ok to > > > > depend on those packages when publishing at ovi store. > > > > > > > > - Original message - > > > > > Hi, > > > > > > > > > > After struggling for about a month with my app and the Ovi Store > > > > > QA, this is what I found out: apparently Ovi Store is not using a > > > > > repository, at least for paid apps, and therefore cannot install > > > > > dependencies. However, at the same time their QA team requires > > > > > quite a few things when dealing with network connectivity. > > > > > Obviously these requirements are not published anywhere, > > > > > otherwise this would be much > > > > > > > to
Re: How to resolve network connectivity without using Qt Mobility in Qt?
Well, that's certainly not the general understanding (inside Nokia) of how it should work. Do you care to elaborate so that we can escalate the issue (with the understanding that it's holiday period...)? Definitely qtmobility is to be usable for Ovi store applications, and same applies for all the other packages that can be downloaded from nokia repos. If this is not currently the case, the process is broken at the moment. You should not change your apps design because of this glitch. - Original message - > Hi Ville, > > Yes, this is what I thought too, but apparently Ovi Store is NOT using a > repository for paid apps. So it simply using "dpgk" to install the deb > files and therefore it's not able to install dependencies. It's frankly > quite shocking, but this is the situation. > > Cheers, > > Sascha > > On Thu, Jul 22, 2010 at 15:54, Ville M. Vainio > wrote: > > > Qt mobility is in official nokia repo (not extras). It's ok to depend > > on those packages when publishing at ovi store. > > > > - Original message - > > > Hi, > > > > > > After struggling for about a month with my app and the Ovi Store QA, > > > this is what I found out: apparently Ovi Store is not using a > > > repository, at least for paid apps, and therefore cannot install > > > dependencies. However, at the same time their QA team requires quite > > > a few things when dealing with network connectivity. Obviously these > > > requirements are not published anywhere, otherwise this would be much > > > too easy! > > > > > > Anyway, this is what I think they want: > > > > > > 1. Detectect if the device is Offline and give appropriate warning. > > > 2. Detect if the device is connected and if not establish the > > > connection. > > > > > 3. If the connection is set to manual, the app needs to give the > > > necessary prompt. > > > 4. If the connection is set to automatic, it should connect without > > > any prompt. > > > > > > So these, I believe, are the requirements of the Ovi Store > > > QA regarding network connectivity. Now the question is how can this > > > be done without using Qt Mobility (or any other library that is not > > > included with PR1.2)? Is it even possible? > > > > > > It would be nice if there would be a Wiki page or something where a > > > sample code that would pass Ovi Store's QA would be available. I > > > understands that most of the competing platforms have these sample > > > codes freely available, so to prevent the need for devs to reinvent > > > the wheel. It's about time Nokia would have something similar. > > > Currently it seems that while Nokia is recommending Qt for everyone > > > with great enthusiasm, their QA team seems to be out of touch what > > > is currently possible to do with it and what not. > > > > > > Cheers, > > > > > > Sascha > > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resolve network connectivity without using Qt Mobility in Qt?
Qt mobility is in official nokia repo (not extras). It's ok to depend on those packages when publishing at ovi store. - Original message - > Hi, > > After struggling for about a month with my app and the Ovi Store QA, > this is what I found out: apparently Ovi Store is not using a > repository, at least for paid apps, and therefore cannot install > dependencies. However, at the same time their QA team requires quite a > few things when dealing with network connectivity. Obviously these > requirements are not published anywhere, otherwise this would be much > too easy! > > Anyway, this is what I think they want: > > 1. Detectect if the device is Offline and give appropriate warning. > 2. Detect if the device is connected and if not establish the connection. > 3. If the connection is set to manual, the app needs to give the > necessary prompt. > 4. If the connection is set to automatic, it should connect without any > prompt. > > So these, I believe, are the requirements of the Ovi Store > QA regarding network connectivity. Now the question is how can this be > done without using Qt Mobility (or any other library that is not > included with PR1.2)? Is it even possible? > > It would be nice if there would be a Wiki page or something where a > sample code that would pass Ovi Store's QA would be available. I > understands that most of the competing platforms have these sample codes > freely available, so to prevent the need for devs to reinvent the wheel. > It's about time Nokia would have something similar. Currently it seems > that while Nokia is recommending Qt for everyone with great enthusiasm, > their QA team seems to be out of touch what is currently possible to do > with it and what not. > > Cheers, > > Sascha ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: qdbus needed on my N900
On Fri, Jul 16, 2010 at 6:38 AM, praveen koduru wrote: > showing the dashboard , I need command to get focus on application again. I > am not query what are the method_calls available with hildon_desktop > service. http://unmaintainable.wordpress.com/2006/12/19/using-dbus-introspection/ -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: qdbus needed on my N900
Argh, that was broken with pr 1.2. I will fix this, stay tuned. -- Sent from my Nokia N900 - Original message - > Hi, > > I want qdbus on my N900 Maemo device. I have tried extras-devel, but > there is no qqdbus package listed. > Please provide some way to get qdbus on my N900. > > Thanks, > Praveen ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OCR for Fremantle
On Wed, Jul 14, 2010 at 12:47 PM, wrote: > We would be very interested in trying to improve the OCR that now is used on > harmattan. Note that Harmattan sdk has not been released (despite the MeeGo handset stuff you see all around the place), so talking about the possible contents of it is not entirely kosher at this point. -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo-launcher does not load in scratchbox
On Mon, Jul 5, 2010 at 8:08 AM, Sudheer K. wrote: > Today I was trying to manually update Glib for compiling an app. I know I > messed up something but I don't know what exactly. I don't want to reinstall > Maemo SDK unless it is absolutely necessary. Reinstall the packages you broke (glib, gtk, hlldon?) -- Ville M. Vainio @@ Forum Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification in MADDE, again
Please review these: https://bugs.maemo.org/show_bug.cgi?id=10826 (use the attached template) http://wiki.forum.nokia.com/index.php/How_to_make_optification_with_MADDE On Fri, Jul 2, 2010 at 12:31 PM, Martin Storsjö wrote: > Hi, > > It seems I'm late to the discussion on optification in MADDE... In the > earlier discussion, I saw this quote: > >> You cannot use that with MADDE, because maemo-optify* commands use >> internally some dpkg* command options that are not implemented by MADDE. > > When grepping through the source of maemo-optify 0.2.1, I see no such > calls at all, anyone care to clarify this? > > > I tried adding the maemo-optify scripts outside of MADDE, in my path (on > OS X), and it seems to work just fine, but the rest of the environment > adds some complications. > > dh_fixperms, which write the list of files for tarlisted, doesn't > recognize symlinks at all, but this can be fixed with the attached patch. > This would be an issue also if doing manual optification and using > symlinks, I think? > > The final problem, though, is that of the order of commands in > debian/rules, which, for me, initially looked like this: > > dh_strip > dh_compress > dh_fixperms > # dh_perl > # dh_makeshlibs > dh_installdeb > dh_shlibdeps > dh_gencontrol > dh_md5sums > maemo-optify > dh_builddeb > > dh_fixperms is called a few steps before maemo-optify, so it creates a > .tarlist that references files as they are at that point, but maemo-optify > changes them later on. maemo-optify cannot be called before dh_installdeb, > though. Moving dh_fixperms down to below maemo-optify does seem to work, > although I'm not sure if that's an acceptable change in general. > > // Martin > ___________ > 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: How to compile in Scratchbox a project created with Nokia SDK?
Last time I checked, the command is "debuild" if we are talking about extras-assistant: https://garage.maemo.org/extras-assistant/ However, it seems it's still using old data from NQS. Clean up all the Makefiles. On Wed, Jun 30, 2010 at 4:29 PM, Andrea Grandi wrote: > Hi all, > > I'm working to a project created with Nokia SDK (Qt4/C++) and at the > moment we're able to compile for Maemo target and let the IDE to > generate the .deb package (please note that generating the .deb means > that we already have a working debian/ directory with all contro, > changelog ecc... files). > > I'd like to upload this package to extras-devel, and following the > instructions of Autobuilder Wizard, I've to rebuild the source package > using Scratchbox in this way: dpkg-buildpackage -rfakeroot -sa -S > > Trying to execute this command under Scratchbox I get the following errors: > > [sbox-FREMANTLE_ARMEL: ~/MyDocs/msoma-build-maemo] > dpkg-buildpackage > -rfakeroot -sa -S > dpkg-buildpackage: source package is msoma > dpkg-buildpackage: source version is 0.1.1 > dpkg-buildpackage: source changed by Andrea Grandi > dpkg-buildpackage: source version without epoch 0.1.1 > fakeroot debian/rules clean > dh_testdir > dh_testroot > rm -f build-stamp configure-stamp > # Add here commands to clean up after the build process. > /scratchbox/tools/bin/make clean > make[1]: Entering directory `/home/andrea/MyDocs/msoma-build-maemo' > make[1]: *** No rule to make target > `../../../../NokiaQtSDK/Maemo/4.6.2/sysroots/fremantle-arm-sysroot-10.2010.19-1-slim/usr/share/qt4/mkspecs/linux-g++-maemo5/qmake.conf', > needed by `Makefile'. Stop. > make[1]: Leaving directory `/home/andrea/MyDocs/msoma-build-maemo' > make: *** [clean] Error 2 > [sbox-FREMANTLE_ARMEL: ~/MyDocs/msoma-build-maemo] > > > How can I fix this problem? Thanks for your help! > > -- > 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 > -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
GoogleCL
Anybody gave this a spin on phone already? http://google-opensource.blogspot.com/2010/06/introducing-google-command-line-tool.html It seems it will provide a trivial, supported way to integrate with google services. Who will be the first to package it? :) -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
On Wed, Jun 16, 2010 at 3:57 PM, Benno Senoner wrote: > I just represent a multimedia developer wanting to use the platform > and point out the flaws in order to contribute to improve it. ... and that is appreciated. OTOH it's waste of typing to engage in long diatribes about business models and whatnot here (such discussion is more appropriate for talk.maemo.org). -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
On Wed, Jun 16, 2010 at 12:56 PM, Benno Senoner wrote: > If Nokia can show us that pulse audio is able to achieve > stable,dropout-free 10-20 msec audio latencies in any audio app > requiring it and working perfectly > when using QAudioInput/QAudioOutput classes then I'll shut up and take > my words back, but at the moment the situation does not seem so, and I > fear that > those "features" will be inherited by Meego. I think you are barking at the wrong tree - pulseaudio should get way better latency than 5000ms, otherwise it would be useless for pretty much everything. You should take this up at bugreports.qt.nokia.com => Qt => Multimedia. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-devel cleanup?
On Wed, Jun 16, 2010 at 12:36 AM, Sivan Greenberg wrote: > Why is the current app manager not as fast ? Maybe we could just add > some changes to it to have a daemon process or a cron that would check > in some intervals when there is data/network connection and update the > cache in the background? Instead of just doing so on-demand while the > user awaits at the UI? There are many things that could be improved with app manager, it's just a matter of somebody actually doing it. E.g. there is no real reason why you couldn't browse the catalog while a package is being downloaded/installed (as is done by Ubuntu Software Center). -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-devel cleanup?
On Tue, Jun 15, 2010 at 10:13 AM, Attila Csipa wrote: > . The apt dir also got moved to /opt, which probably slowed it down a bit in > exchange for a lot more space or the rootfs. And last, but not least, the > extras-devel Packages file is a solid 14MB nowadays (curse them icons !), > which takes time to get parsed/processed/updated no mater how you slice it. Ok then. I guess what we need is an alternative app manager - something that is as fast as apt-cache search / apt-get, but still allows "relaxed" usage, with a modern ui. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Extras-devel cleanup?
Some time ago there was talk about removing the old junk from extras-devel, in order to make app manager faster. What happened to that idea? Do we still have hope of this happening? -- Sent from my Nokia N900 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to optify in MADDE?
On Thu, Jun 10, 2010 at 12:49 PM, daniel wilms wrote: >> Moreover, if you put binary to /opt on MADDE dpkg-buildpackage will >> fail to set >> execution bit to your binary (I hope it will be fixed soon). >> >> > > This is what I said. It is fixed already (this morning ;) ) and should be in > the next release. What's the schedule for next release? We have several commercial developers complaining about this issue already, and it would be nice to point them to fixed madde instead of patch/workaround... > > Daniel > >> Thanks, Daniil. >> >> On Thu, Jun 10, 2010 at 11:45 AM, daniel wilms >> wrote: >> >>> >>> Hi, >>> >>> ext Daniil Ivanov wrote: >>> >>>> >>>> Hi Daniel! >>>> >>>> Of course manual optification is the way to go when there is no other >>>> way. >>>> But is it so that installing scratchbox and performing optification >>>> there is considered as too difficult? >>>> >>>> >>> >>> I think the manual way is reasonably easy. Or which drawback do you see >>> here? If you have set up your environment already with MADDE, the >>> optification should not be a reason to install the Platform SDK with >>> Scratchbox etc. There is just one bug in MADDE, if you package your >>> application that way, you have to set the rights of your binary to >>> executable in the postinst file. >>> >>> >>> >>>> >>>> BTW, are there any chances maemo-optify will be included into MADDE? >>>> >>>> >>> >>> I doubt that, but I'm not sure. Will find that out. >>> >>> Daniel >>> >>>> >>>> Thanks, Daniil. >>>> >>>> On Thu, Jun 10, 2010 at 11:12 AM, daniel wilms >>>> wrote: >>>> >>>> >>>>> >>>>> Hi, >>>>> >>>>> ext Sascha Mäkelä wrote: >>>>> >>>>> >>>>>> >>>>>> OK and how would I do that? Should I edit the src.pro <http://src.pro> >>>>>> file and how should it look? Is something else needed? >>>>>> >>>>>> >>>>> >>>>> one thing you could do is putting the files of the application (like >>>>> binary, >>>>> images etc.) in a folder like /opt/myapp/. This you can specify in your >>>>> src.pro. There is a packaging guide for Qt applications available in >>>>> the >>>>> wiki [1]. After doing that you can then have the right path to your >>>>> executable in the *.desktop file. >>>>> >>>>> 1. http://wiki.maemo.org/Packaging_a_Qt_application >>>>> >>>>> Daniel >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sascha >>>>>> >>>>>> On Thu, Jun 10, 2010 at 10:53, Pasi Savanainen >>>>>> >>>>> <mailto:pasi.savanai...@nixu.com>> wrote: >>>>>> >>>>>> On 6/9/10 5:58 PM, Sascha Mäkelä wrote: >>>>>> > How can I optify a package in Windows using MADDE? Does this work: >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> http://maemo.org/packages/package_instance/view/fremantle_extras_free_armel/maemo-optify/0.2.1/ >>>>>> > >>>>>> > If it does, how can I install it to MADDE? >>>>>> > >>>>>> > Cheers, >>>>>> > Sascha >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > ___ >>>>>> > maemo-developers mailing list >>>>>> > maemo-developers@maemo.org <mailto:maemo-developers@maemo.org> >>>>>> > https://lists.maemo.org/mailman/listinfo/maemo-developers >>>>>> >>>>>> You cannot use that with MADDE, because maemo-optify* commands use >>>>>> internally some dpkg* command options that are not implemented by >>>>>> MADDE. >>>>>> You have to do optify our packages by hand. >>>>>> >>>>>> -- Pasi >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> ___ >>>>> 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 > -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Quality assurance of "stable" software: my battery drained in few hours
On Sat, May 29, 2010 at 1:01 PM, Andrea Grandi wrote: > I went to sleep at 3:00, I wake up few minutes ago with the N900 > powered off. There was not any active connection when I went to sleep, > so could anyone please explain me WHO drained my whole battery?! Can you ensure that your phone doesn't create connections automatically? -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Disable wlan scan with qt-mobility bearer and gconf
On Wed, May 26, 2010 at 3:18 AM, Nicola Mfb wrote: > in that case is it safe/supported/helpful using libgq-gconf-dev? is it > planned that library will reach extras? It's in Nokia repo (because bits of mobility use it): Nokia-N900:~# apt-cache policy libgq-gconf0 libgq-gconf0: Installed: 0.2-3+0m5 Candidate: 0.2-3+0m5 Version table: *** 0.2-3+0m5 0 500 https://downloads.maemo.nokia.com ./ Packages 100 /var/lib/dpkg/status the -dev package is in SDK repository. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
1.2
http://conversations.nokia.com/2010/05/25/nokia-n900-software-update-release-1-2/ -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to distribute a console program with local files
On Sun, May 23, 2010 at 7:33 PM, wrote: > Is MeeGo 1 still working with .deb packages? To conveniently sidestep the question: - Harmattan still uses .deb - The Moblin-derived netbook stuff uses .rpm -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT Packages, Repositories and PR1.2
On Fri, May 21, 2010 at 10:14 AM, Marcin Juszkiewicz wrote: >> The developer should wait for pr 1.2. At this point in time all the >> work spent on dealing with PR1.1 is wasted effort. > > Which means that whole work spent on dealing with Maemo is also wasted. Nokia > wants to be good at scarying developers out of platform? No, it means PR1.2 will probably happen sooner than you think. If someone wants to start implementing workaround schemes today it's ok, but I'd personally suggest using the time between now and PR1.2 on something that's actually going to see real use. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT Packages, Repositories and PR1.2
On Fri, May 21, 2010 at 2:42 AM, Felipe Crochik wrote: > As today what a developer needs to do to get an application that uses qt to > the end user? Is there a way to tell the autobuilder to compile against the > 4.5 qt and make the package only depend on it? The developer should wait for pr 1.2. At this point in time all the work spent on dealing with PR1.1 is wasted effort. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OBS and Fremantle .... 193 Extras apps built...
On Sun, May 16, 2010 at 4:59 PM, David Greaves wrote: > A couple of posts on Planet Maemo[0] that may be interesting Not sure I understood correctly, but does this mean that we'll have a PPA-like thingie for Fremantle soon? -- 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?
On Fri, May 7, 2010 at 8:58 PM, Ville M. Vainio 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
Re: Why should I write apps for Maemo?
On Fri, May 7, 2010 at 5:10 PM, Sascha Mäkelä 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: GSoC 2010, eBook reader. Looking for feedback and ideas.
On Fri, May 7, 2010 at 2:52 AM, Aniello Del Sorbo 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: GSoC 2010, eBook reader. Looking for feedback and ideas.
On Fri, Apr 30, 2010 at 10:51 PM, Mikhail Gusarov wrote: > etc) in various languages. Browser engines might be also a good learning > excersise, given lot of formats being just a subset of XHTML in > containers nowadays. Especially this applies to .epub, as it is not only > subset of XHTML, but also a subset of CSS. I think the recommended approach here is to just use a browser engine ;-). It should be enough for 95% of the users. Perhaps even QTextBrowser could be up to the job... -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC 2010, eBook reader. Looking for feedback and ideas.
>> I don't think format support is hugely important in the end, as you >> can convert between formats with a program like calibre. > Strongly disagree. Maybe your or I can, but it's rather terribly inconvenient > and requires using another device to facilitate ebook reading on your N900. > Without good format support, there's hardly any point. You have a point. However, support for several formats is something that can be accumulated later on, when the rest of the program is in shape. GSoC is a very finite time period. As long as we can add backends that output epub-like data (table of contents, sections as html), we should be in the clear. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC 2010, eBook reader. Looking for feedback and ideas.
On Fri, Apr 30, 2010 at 1:09 AM, Ryan Abel wrote: > Implementing format handling from-scratch is going to be a herculean > undertaking, so I wonder if you could've borrow FBReader's handling Okular (that happens to be a Qt program) also has format handling code, including support for epub. I don't think format support is hugely important in the end, as you can convert between formats with a program like calibre. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC 2010, eBook reader. Looking for feedback and ideas.
On Thu, Apr 29, 2010 at 10:00 PM, Aniello Del Sorbo wrote: > Second, I don't know (I'll read the proposal later today) if you've > already had a thought about this, but will you be using "regular" text > (i.e. normal font rendering by Pango) or will you be looking at > handling the fonts yourself? To make the schedule realistic (and future maintainability reasons), I think letting Qt handle all of this is the way to go. It doesn't hurt that the app can be easily ported to other platforms either. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Nokia Qt SDK beta released
People that don't unconditionally love scratchbox may be delighted to hear that madde + qt creator combination is taking steps to a more official & endorsed status: http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/IDEs/Nokia_Qt_SDK/ It has a simulator as well (i.e. a custom version of Qt libraries that mocks various things, including hw events from Qt mobility). CAUTION: You can't use the (excellent) hw debugging feature on your N900 yet, PR 1.2 is needed. In the mean time, you can kick the tires with the simulator (or a Symbian device if you have a spare windows machine around ;-) ). -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Routing SMS to another app.
On Sat, Apr 3, 2010 at 5:06 PM, Sukhbir Singh wrote: >> Mobility apis haven't been wrapped yet afaik. I don't doubt for a second >> that someone will step up to do it sooner or later, though >> > > Would it be ok if I mention this in my GSoC application? Most importantly, > would it be done tentatively by 24th May, i.e. when the development begins? > Cause if yes, then it would be awesome. You should ask on pyside mailing list; though I don't think anyone can promise such a thing as far the schedule goes. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC10 - hints needed about google apps
On Sun, Apr 4, 2010 at 9:19 AM, 姚杰 wrote: > Now , I have a primitve approach to have success in this idea. > Firstly,I need to know google apis for gmail,buzz,,, > Secondly,if I could get the java source code of google apps for mobile(), I > can use them > as a reference.However, We need to implement them using C++/Qt This might help: http://johnvey.com/features/gmailapi/ http://libgmail.sourceforge.net/ -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC 2010 - Client Centric Energy Efficient Communication
> Will you be interested in mentoring this project? I think you'd benefit from someone better versed in kernel details mentoring for it. Make sure the project is listed in the maemo gsoc page and someone will take note. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Routing SMS to another app.
> > Easiest way is to do this with QtMobility messaging API. There > > QMEssagestore, > > you can get signal of arriving SMS and then delete it. QTmobility Messagign > > with Messge Store support will be there in next couple of weeks. > > In the pymaemo or the pyside stack? Mobility apis haven't been wrapped yet afaik. I don't doubt for a second that someone will step up to do it sooner or later, though ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: madde and Qt State Machine
On Fri, Apr 2, 2010 at 10:52 PM, wrote: > Thank you very much for your aswer, > > Could I for the moment compile it through the scratch box the actual Maemo > SDK? Yes, the scratchbox sdk already has 4.6 (no need to hit extras-devel anymore, even). -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: madde and Qt State Machine
On Fri, Apr 2, 2010 at 10:31 PM, wrote: > Hi, > > I am trying to develop and application on Qt using the state machine > frameword. > > All is fine for linux and windows, buy when I use madde for compiling it. It > does not fount the #include library. State machine is Qt 4.6 stuff, Madde still has the old 4.5.3. Madde will have 4.6 when PR1.2 for N900 is out. -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC 2010 - Client Centric Energy Efficient Communication
On Fri, Apr 2, 2010 at 7:39 PM, Ahmad Nazir wrote:
>> Are you aware of what Maemo already does with iphb ("heartbeat"), and
>> delaying tcp keepalives?
>>
>> --
>> Ville M. Vainio
>> http://tinyurl.com/vainio
>
> I am afraid that I am not totally aware of what iphb does. If it just
Heartbeat is basically a global (per-system) range timer that helps
apps synchronize their periodic network traffic. Since the component
is not open sourced currently, I can't point you to documentation (and
I also think it's nda-encumbered still).
It appears it's not relevant to your proposal anyway.
> by reconfiguring the value according to our requirements. According to
> to proposal, the wireless interface sleep times can be maximized by
> modifying the values of the congestion window in the ACK.
It may be that this is something that's not currently done on Maemo,
so it may be a worthwhile gsoc project. Perhaps it could even be a
project for something with a wider scope, like Linux kernel.
--
Ville M. Vainio
http://tinyurl.com/vainio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC 2010 - Client Centric Energy Efficient Communication
On Fri, Apr 2, 2010 at 6:28 PM, Ahmad Nazir wrote:
> management (PSM), there are a lot of problems attributed to the mechanism. I
> plan to implement a client centric technique for TCP sessions that focuses
> on efficiently using the wireless network interface. This can be possible
> with a linux based operating system such as Maemo. I can share the details
Are you aware of what Maemo already does with iphb ("heartbeat"), and
delaying tcp keepalives?
--
Ville M. Vainio
http://tinyurl.com/vainio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OT: Cannot select targets - where's the session PID file?
On Tue, Mar 30, 2010 at 1:19 PM, Ram Kurvakat wrote: > log out of all your scratchbox env except one. > > type sb-menu. > > select kill all processes in scratch box. You often need to specify signal 9 as well. You can save some time by executing "sb-conf ka -s 9". -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
