OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: Snappy on June 25, 2006, 07:49:51 am
-
Currently: DocTab in oz/opie currently thrawls a few known locations and also external media (if selected) for certain documents and displays them in a list
Advantage: The upside is that users do not need to search for the documents as they sometimes may be saved to disparate locations depending on the apps.
Disadvantage: The downside is that the thrawling can be rather timeconsuming as it thrawls through the external media ... this is especially so, with the media cards going into the gigabyte region.
Possible solutions:
1. Adopt the Cacko approach, ie just show an folder list of the internal flash and media cards and let users browse through the different locations.
2. Modify the existing thrawling code to be directory specific. That way, users can select to show only files from certain directories.
Approach 2 can reduce the thrawling time only if the selected directories do not contain deeply nested directories and files. But if users do have that many documents or data files, then the DocTab should show them ... but showing too many items in a flat list defeats the usability of it.
I'm keen on adopting the Cacko approach as gives users the most flexibility. I'm also inclined to show the DocTab in a Tree=List view instead of a simple list view. The Tree Portion can then show the directories in the internal flash, media cards and a number of user-defined 'favorite' directories. These list of user-defined directories can come pre-defined with a list of standard directories that are commonly used to contain document files etc.
I'm hoping to use this as a learning project for myself into OE/OZ/OPIE development.
I code in C/C++ for win32, wince (PPC and HPC), Palm and other platforms.
Comments, ideas and suggestions strongly welcome and wanted!
-
Cacko == SharpROM == closed source fork of Qtopia.
Anyway feel free to write such improvments - patches are welcome.
-
Most Opie members and almost all users I've talked with would really appreciate a SharpROM-style DocTab. You're right, it would make a perfect learning project to catch up with Opie.
The Opie core developers are on opie-devel@handhelds.org and sometimes on #opie @ freenode, if you have specific questions, fire away
-
Thanks Hrw and Mike for the heads up and comments. ... let me look for that thread about the location of the source code ...
btw, incremental build/make is possible with OE right? That way I just need to compile and link the relevant files and not the whole src.
-
http://opie.handhelds.org/ (http://opie.handhelds.org/)
You might want to setup OE properly though, then you can create flashable images and ipks to test your alterations.
If you chose the latter, the opie code will be available in you tmp/work directory once it's been built.
Then you'll need to make alterations and delete the 'stamp' files so that bitbake knows to rebuild the files. You'll have to delete:
tmp/stamps/*/<packagename>.do_compile
tmp/stamps/*/<packagename>.do_package
and possibly
tmp/stamps/*/<packagename>.do_build
It may be easier, if you're new to bitbake/OpenEmbedded to use a pre-built toolchain. Mickeyl, hrw is there a recent Opie one available?
Si
-
bitbake -b recipe -f -ccompile
bitbake -b recipe -f -cinstall
bitbake -b recipe -f -cpackageare nicer then removing stamps
-
http://handhelds.org/cgi-bin/cvsweb.cgi/~c...type=text/plain (http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/opie/README.OE?rev=1.7&content-type=text/plain)
-
Thanks guys ... fiddling ... fiddling ...