[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Volunteering to port Kooka to KDE4
From:       Klaas Freitag <freitag () kde ! org>
Date:       2009-10-16 19:35:55
Message-ID: 200910162135.55736.freitag () kde ! org
[Download RAW message or body]

Hi Eduard,

> I'm aware of the existence of the Skanlite project, but however I consider
> that Kooka is, right now, a fairly superior scanning application for KDE
> that it's really worth the effort of migrating it.
I love to hear that - I also always was convinced that Kooka is a fairly 
useful little program, many other users mentioned that as well.
>
> How should I proceed? I have some background in general Qt3 and Qt4
> developing (including porting issues), and general experience working with
> KDE API. I'm well aware of the difficulty of the process, but nevertheless
> I'd like to at least try to do it (can't promise any results, though...)
I think you should not  look at it as a real port of the existing KDE 3
application. The code quality of the old app is largely not really what 
you want (doesn't say that everybody about code she/he wrote a few
years ago?) and, what is more important, there are other projects
in KDE which do similar things way better than Kooka did it and thus
you don't need lots of the code any more.

Without knowing what for example Scanlite provides today, what I 
think is interesting with Kooka is: 
- Management of the scanner settings
- easy scan image file management, with automatic name creation
- A Scan plugin to enable other apps to "insert an image from scanner".
  That is basically libkscan. Probably it makes sense to sync with the
  libksane author, I don't know whats the status there.
- ocr support with the ability to attach various backends such as gocr and
  ocrad. Kooka supports a dictionary based post processing of the 
  ocr result which also seems nice. That could btw also done as a plugin
  to enable all  KDE apps to do ocr on arbitrary images.
  Also the situation in the commercial world of ocr engines might
  have shifted a bit. Maybe its possible nowadays to convince one of the
  large players to provide something powerful, I am not sure
- Very useful seems to be the scan region selection, which
  was called the "ant street" with an animated selection box. The animation 
  is probably outdated but there was also an auto mode which detects lets 
  say a photo which is smaller than the scan area from the preview 
  image automatically. 

What I would not recommend to do yourself any more is everything around
the image viewer and graphic processing. Probably the kipi plugins help you
with that. Maybe they come with a good image gallery as well - I don't know,
but also the image gallery can probably shared with other up to date KDE
tools and need not to be reinvented again. Finally, very important is to get
away from the trouble making dock widgets ;-)

So summarized what I would recommend is:
* Think about what makes Kooka useful and maybe unique and decide if 
  that for example could be built in in an existing other KDE4 app or if
  you really want Kooka :) Pick code peaces from the old code base 
  accordingly and port these, for example for the ocr module. 
* combine efforts with libksane. I really can not recommend to look
  into libksane unfortunately. The underlying sane lib also challenged me 
  back in the time.
* Share as much components with other KDE 4 apps as possible, eg. kipi.
* Start over with a simple brand new KDE 4 app KookaNG ;-) where you
  add functionality over time. That is more fun than digging through the old
  stuff and port.
* be audacious. Even if it looks huge at the beginning, also quite large 
  and complex apps can be done starting out with one guy and be successful.
  KDE speeds you up through technical excellence and a magical community
  so that even bold moves are possible :-)

Does that make sense?

Klaas

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]