I thought about putting this thread in stackoverflow.com, but I think this is the best place for it.
I decided to create a new program for maemo working basically as an ebook reader.
This decision was taken after using fbreader and mobipocket for palm (on garnet vm).
My experience is almost zero with Linux programming, but I’ve done some windows coding in Delphi and C++.

The reasons I’m trying to build a new solution rather than using (or modifying) existing ones is :
• Dictionaries are not supported in Fbreader
• Highly compressed prc files fails to load in Fbreader
• Fbreader seems to handle very bad big ebooks
• Fbreader is missing some very basic features
• I just don’t like Fbreader
• Mobipocket for Palm doesn't take full advantage of my N800, Garnet VM is a beta software, the time limit is very soon, and no news from ACCESS
• I’m missing my Babylon dictionaries in my Nokia, (and in Linux too)
• Till now I cant find a good chm reader in maemo (I’m using some from easy debian, but not satisfied)
• Finally, and the most important reason, because I have 170$-worth medical ebooks (yes, they work inside in GarnetVM, again, not satisfied)

Here is what I’m thinking of :
• Writing a new ebook and dictionary program for maemo 4
• Should be lightweight, fast and responsive
• C++
• Full mobipocket support
• Maybe later CHM and Babylon support (possibly through conversion to mobipocket file)
• Should be easy to call from other programs
• Maybe Linux desktop support
• Extra: finger friendly interface (canola-like )

If you are a coder, or that you have any experience with Maemo development, your comment may be very valuable regarding :
• Am I in the good path ? Should I see the problem from another angle ?
• Does C language fit better in this project ? python ??
• What libraries should-I use ? or which I shouldn't’t ?
• HTML rendering : Libwebkit ? Qtwebkit ? a self made one ?
• Libliqbase looks like a great way to achieve this, what do you think ?
• What development environment to choose ?

Please let me know about what you think, I hope I can get version 0.1 by the end of this summer.

I do UI design, so I can help you there as far as designing it, but someone else will need to actually physically code it. I only do usability design.

<shameless pet project promotion>
I've added some ebook reading support to pyqtoreader. Originally it's a python-qt based image viewer with strong on-line integration, but it can 'view' any item we can shove into a graphicsview, which is pretty much everything (raster, vector, text, html, etc). It's explicitly written with large documents in mind, so it handles all the dynamic loading/parsing/unloading of pages and items.

The idea of extandable pyqtoreader is that people should be able to make their own library reading modules to support any format they like. Originally, this was meant for integrating webcomics or image feeds from different sources, but, as proven with the recent txt/html extension, can be used for pretty much everything.

At this point, pyqtoreader is *really* raw in terms I wouldn't recommend it for daily use and the API is still shifting, BUT, if you're interested, it's certainly a lot less effort to add a format there than write a reader from zero. And, to develop a module that works with pyqtoreader you don't even need scratchbox ! Just an install of python+qt on your linux or windows and you're good to go.

I'll try to post a video how pyqtoreader looks like these days as the version in extras-devel is pretty out of date.
</shameless pet project promotion>

Edit: Not try to dissuade the OP, just outlining some possibilities. Also, it might be possible to write an extension for an existing project and then, if not satisfied with speed/options, just replace the core. Still a lot easier than the all-from-scratch approach.

attila77 has a point. Try the extension route first, and if all else fails, go for the core too.

@atila77: I'm very interested with pyqtoreader, and I'll be happy if you give me an idea about some points :
* How fast can pytoreader render html ? Responsiveness is a Major requirement in this project.
* Should I use pure python to write a module ? Can I trust python as a language for a fast eBook engine ?
* Honestly I'm not convinced about writing a plug-in, then optimizing the core, this approach may not be as easy and straightforward as starting from zero with speed in mind.

@Lord Raiden: I will be pleased to get some UI ideas, I'll contact you once I've decided how to go ...

karatchov: I really would like a better e-book reader, and I've thought about many of the things you've mentioned. I would love to see a fast, multi-format e-book reader that does things better than fbreader or evince.

attila77: Your app sounds great. Please, please come up with a better name. Do not use "py" or "qt" anywhere in the name. Your users won't care what language and toolkit you used.

karatchov,

download and install the released liqbase , its in extras
it has a text based book reader with the mechanics required, a book reader is one of my primary desired goals of this project (i think its one the first thing I said on youtube!)

i have started work already on liqbook which is the advancement of the book reader I require but using the libliqbase framework and with a target of accepting multiple formats.

a community collaborated liqbase based book reader would be beneficial to the project as a whole, but note libliqbase is still very early in development and lacks a lot of the maturity and functionality offered in other more mature toolkits.

at the moment there are lots of things not in place yet and so as long as you don't mind helping to define the framework as a whole I would love to give as much help from my side in getting everything up and running.

I prefer my applications to sit within the playground itself, but realise that others dont, so as long as you refrain from using global variables (expect multiple instances of things..) a standalone runtime and a playground plugin can be built from the same source

its written in C because I cannot compile c++ in an efficient enough manner on the device itself

I'm using Qt to render html, so I'd say it's pretty quick if you don't have a fancy layout in the book. Also, I do cheat. I'm employing several tricks to avoid reading/parsing the WHOLE html file. This results in a major speedup in even the largest html files, but can break some of the aforementioned layouts.

As for responsiveness as in UI, I'd say liqbase will be invariably be faster on *today's* devices. Especially the startup time The graphicsview double buffering is no match for lcuk's black magic on a N8x0. However, the moment Maemo devices receive 3D acceleration (which is announced for the next generation), I believe this advantage will be more than matched as graphicsview talks OpenGL natively so I can bring on the heavy artillery

It's your call ! Python is excellent as a glue language - you can write your code in C/C++ and then interface it to Python with minimal effort. I'd say use the language you're more proficient with - language speed rarely makes up for programmer experience except for the simplest constructs. If you're equally good in both and don't mind setting up scratchbox or a native dev environment, go for C/C++.

I can tell you straight away that the devil is in the details. It's not hard to write a reader, it's hard to write a QUICK reader as you have to cut a lot of corners. This in turn requires detailed analysis and experimenting with the underlying formats you want to support. That work/knowledge can be put to good use in both a plugin and a standalone project.

Well, I do it quite differently, that's certain. Whether that means *better* or not is yet to be seen/judged by users

Bummer. And I actually thought that's a cool name. You now, as in picture-reader. Pictoreader. Pyqtoreader. Oh well

I didn't see that; I was reading it Pie-Cute-O-Reader. Now that you've pointed it out, I think you're on the right track; PictoReader is fine.