|
As I've mentioned in many of the other 'call for help' posts I would love to help out. I've got experience in C/C++/C#/Java/Ruby and a number of other languages. I'm a Windows user but know the linux basics so wouldn't be a problem.
Combining the ipdf patches or fbreader along with a search capability would be my top priorities with contentlister rewrite a close second.
Choice of language is also important I think. Java or Ruby are much more productive than C/C++ assuming correct OO discipline and at least in most areas just as fast but it may be a different story on the iLiad. I'd also prefer to see some automated testing going on as I believe this will help stop regressions and produce more maintainable code.
It has been stated that the source code for some of these existing apps is a mess and so I'd be happy to rework it. Though, perhaps rather than attempt an ambitious full rewrite, we start by modularizing then gradually replace. Of course if a rewrite is feasible then I'm all for it especially if a Java version can be written.
Back on the reader aspect. This is a very central part of the reader (as is the contentlister) and I'd like to see one reader to rule them all there by having a consistent interface. So another approach would be to have a basic reader API that we could then use to implement various readers. The API could specify things like zoom, page turn, columns, page counts, searching, etc., etc. and we could then have a bunch of plugins (or even just subclasses) for all the different formats PDF, FB, PRC, CHM, etc., etc.
By having this separation we then have a single user interface for all known book formats. Now I realize that some formats are very different. For example PDFs with lots of graphics would be very different to a PRC with the emphasis being text but in these cases the rendering could be taken care of by the plugin/subclass.
Just thinking out loud really and I've not looked at any code yet so this is all just theoretical (and based on previous experience)
|