Mobile and Embedded

Hi anselmolsm Yes, I have also tried with INCLUDEPATH+=, with the same result. In both cases the location of the .h files (/home/kif/NokiaQtSDK/QtService/src) is part of the g++ line of the compiler output. Kim

Oh yeah, that was the problem. I got it set when I moved it a bit further. Thx.

bq. If Qt libraries are installed to memory card, startup of Qt applications is very slow due to Symbian doing additional checking of libraries found from removable media. Therefore, Qt libraries can only be installed to the phone memory (C:).

yea. I'm also interested in this.

[quote author="Tobias Hunger" date="1284566463"]I took the liberty to file "bug QTMOBILITY-510":http://bugreports.qt.nokia.com/browse/QTMOBILITY-510 about this issue.[/quote] Excellent! Thanks.

[quote author="Mimik" date="1284463249"] i think need compile application with library, and program will have needed libs =) [/quote] Statically linked Qt for Symbian is really not supported. Try the Smart Installer before you go there :)

[quote author="frgo" date="1284427094"]Thanks for your answer, I´m looking for using QtWebKit over MeeGo...I believe it will behave like Maemo, right?[/quote] Yes :) At the moment Maemo has no real security model - and I really think us the developers should be happy for that and enjoy it while it lasts :) Did you guys know the N900 users count for a significant % of the overall downloads of apps by Nokia users - even though the percentage of N900 users is very small? There are several reasons for that, but this is one of them - developing, deploying and installing apps is a lot easier as there is no complicated signing method to stop it all.

Even the non nuron 5230 is perfect! Tested!

You also need to be prepared that you will hit WinCE's resource limits very quickly if you are just using a stock Qt for Windows CE. You need to slim down Qt considerably by removing the parts you don't want/need in your application. Doing without QtWebkit goes a long way, for starters.

[quote author="cheng" date="1284352976"]I couldn't find any solution in the Bug. Could you please tell me in detail? Thanks,[/quote] Seems the issue is certainly the same as chetan has pointed out. You can now try to either reduce your resources size or try on a machine with more than 4 MB RAM.

Yes, you are right. ToolBar uses layout to internally set the size of QAction derived buttons to "minimal".

Hi kschultz, thanks for that feedback. You're right, solution (2) allows the specific manager to build the id manually. We have prototyped up a (mostly complete, but untested; prototype) version of this API, available at: http://qt.gitorious.org/qt-mobility/contacts/trees/multical-custom/src/organizer Especially, see the qorganizeritem.h/cpp, qorganizeritemenginelocalid.h/cpp, and for an example implementation, the engines/qorganizeritemmemorybackend.cpp/_p.h. Solution (4) with quint64 was investigated more thoroughly, and it doesn't seem to provide any advantages over the quint32 version if the nativeId could possibly be a string (that is, on those platforms, a full database read is required to build up the mapping on instantiation or on first read), so this solution is not optimal. Solution (5) is nice, but apart from the memory-usage, there is the added problem that whenever the engine receives on of these, it must parse the string to break out the bits that it needs, serially, for every id in the list (eg for a fetch request taking a list of ids). This cost seems prohibitive, since it affects (pretty much) every operation. So, we think you're right -- solution (2) seems the nicest. If you (or anyone else) do (does) get a chance to review the proposed API, that'd be greatly appreciated. Cheers, Chris. edit: there's currently one major missing piece of functionality from that branch: converting to/from a QVariant isn't implemented (needs to serialize/deserialize the private implementation in that conversion process). Just to be clear, it IS implementable (although may have to instantiate the engine factory and request the deserialization during the process..) but just not implemented yet.

[quote author="snowpong" date="1284066809"] Anyways - Qt Everywhere is true for the desktop, but it is NOT yet true for the mobile. I think if the community, partners and companies contribute - and Nokia help and push not just their own platforms, it can absolutely happen. Apple has tried locking developers in, which doesn't work long term. Nokia could be completely opposite, and make it easy for developers to target not just Symbian and MeeGo, but all the major mobile platforms. [/quote] Yes, very true. On mobile it is far from being everywhere. The smart installer is said to work reliably only on a couple of Symbian devices, N97 mini being one. Correct me if I'am wrong. In fact I like to be wrong here. I don't know if it will work well on other devices in near future. So how do we deploy apps made with Qt on Symbian phones ? True that most of the Symbian devices support Qt. But without a reliable means of deployment, it is of not much use. Bundling Qt is not an option in most cases. So as of now, we can use Qt if we are targeting N8 and probably N97 mini. About Nokia's openness, it is a good thing. But it will hurt Qt adoption. With J2me present, and with much more installed base, most of the applications for Symbian will be done in J2me rather than Qt. So Qt may be a platform for the future. We may still have to wait for 1 - 2 years, wait for Meego to get popular. Thats a troubling thought for a Qt lover like me. Also, now I'am more hopful about the iPhone port.

Thanks. I assumed they'd be "auto" generated - I know better now :)

snowpong, as for simulator rebuilding helped me (I'm able to generate pdfs). About other way for pdfs generating. I'm not sure I'm ready to rewrite eXaro library, but if it will not work at some devices then maybe I will need to do it :)

And the "source code":http://developer.symbian.org/oss/FCL/sf/mw/appinstall/ is actually available too

It seems that the focus policy (http://doc.qt.nokia.com/4.6/qwidget.html#focusPolicy-prop) of both QToolBox and QTabWidget has been explicitly set to Qt::NoFocus so they won't handle keypad navigation at all at the moment. I suggest you subclass them, set the focus policy to TabFocus, and then check out other classes like QSlider and QComboBox (search for #ifdef QT_KEYPAD_NAVIGATION) and check out how things are handled there, then do similar handling in your subclassed versions. Or just install an event filter and hack a less elegant solution :) (Alessandro, feel free to pitch in here :)

add -no-kbd-<> and -no-feature-keyboard

All 5th ed phones have the same processor(434 Mhz ARM11) and RAM (128 MB). "http://www.forum.nokia.com/Devices/Device_specifications/5250/":http://www.forum.nokia.com/Devices/Device_specifications/5250/ So all 5th editon/Symbian^1 phones should run QT apps with the same performance. As far as 3rd edition phones go i think it certainly depends on the Ram available and also the processor.I think Qt is compiled and runs on all ARM11s but doesn't on ARM9s,hence the reason why the N96 and a couple of other phones don't run QT.

Hi, yes can reproduce the problem. also I noticed that when the program is launched on the simulator, there is a white border on the first list item, which goes away when you change the selection. If you set the selectionmode to multiselection, the same behavior is observed on the simulator. Looks like a bug, you should log this.