This chapter tries to give some advise how to develop for opie. Limited memory and dialog space require special needs. The absence of a real keyboard and a real mouse don't make it easier.
Above that, there are some rules, where to store your data / configuration and how to prepare the programs, so that they are accessible from qtopia/opie.
Debugging is another item. As a real console is missing, you may want to use syslog or similar tools. The chapter describes, how to setup debugging from my personal point of view.
This chapter describes the development for qtopia and opie. I use opie at the moment which maybe lead to other path names than given in this document when you are using qtopia. As qtopia and opie are binary compatible the other hints should match also qtopia.
This section tries to give an overview over the general rules to be used while developing for opie. It describes my personal experience and maybe added by articles of other developers. E.g. an explanation for language support is requested as well as an advise how and which pixmaps should be used.
Layout your programs always to the reduced screensize of handhelds.
Never overload your dialogs and widgets with unnecessary stuff. If you have to show a lot of items, split them into a tab-dialog with multiple pages.
I dont use menus, because they require a lot of space on the top of the application. Instead of that I try to use ToolButtons with Pixmaps. You can spread them over the dialog and also frame them e.g. vertically.
Never use fixed sizes. E.g. when opening the virtual keyboard, the application should shrink vertically. This is guaranteed using QtDesigner for layout definition.
Input fields should always be on top of the application. As this is against the desktop rules, this may be confuse some users, but allows the user to see the input field even if the keyboard is opened and the application may not shrink to the appropriate size.
Try to reduce the program size as much as possible.
Nevertheless do not create dialogs on the fly, because this causes the user to wait a long time until the dialog is created.
Create all dialogs used and just hide them. In case of usage, you just have to exec / show them, which is a very quick action.
Extract as much as possible multiple used parts out of your programs and create user libs with that parts.
still to be documented
still to be documented
Dialogs require special attention. As the user interface is restricted to a small display and no or only a virtual keyboard, the program has to support different usage than X86 programs.
This chapter describes how I myself define the user interface in my programs. This may lead (hopefully) to a discussion.