[KPhotoAlbum] New features for testing and discussion

[Johannes Zarl]

On Thursday 02 August 2012 08:27:16 Jesper K. Pedersen wrote:
> On Wednesday 01 August 2012 20:10:05 Johannes Zarl wrote:
> > On Wednesday 01 August 2012 15:04:18 Jesper K. Pedersen wrote:
> > > Dude, I have two director titles on my business card, you do not want
> > > to challenge me in the delegation game :-)
> > 
> > Sorry to break the news to you: being the primary author of KPA gives you
> > some leverage with me. Your titles give you the same importance as your
> > middle name or hair color, unless the person signing my paycheck says
> > otherwise...
> 
> Gee, I had thought the word "Dude", the smilie and the word "Seriously"
> would have given it away that this was for fun. I'm sorry you missed that
> joke.
> 
> What I was asking was that you did not just dump the work of finishing this
> on me, but instead took input on improvement suggestions.

I guess I was too much taken aback by that sentence to even see the smiley. It 
was not my intention to dump my work on others -- I just wanted to see if 
someone had a viable suggestion.

> Yes, please change to text or put it in the settings dialog.

Now this is what I was looking for: some suggestion I can work from ;-)

I'll try to fix it before the weekend, as I won't have any time to spare next 
week.

> > > > And now for something completely different: One refactoring on my
> > > > backlog
> > > > still is to pull out the DB part of KPA into its own library. On the
> > > > other hand the dependencies from the DB to the GUI-part seem to grow
> > > > rather than shrink. This begs my question: are other developers also
> > > > interested in seperating the database part, or should I just fork the
> > > > database code if I need a standalone library?
> > > 
> > > No comment really. When you say separate library, you do not mean
> > > something
> > > shipped separate from KPA, do you?
> > 
> > Potentially, yes. I would like a clean interface between GUI and
> > database. This makes it way easier to set up unit-tests for the database
> > part, to write a commandline-client (my use-case) or to write a KIO
> > slave. Also I would hope that less interdependencies would make writing
> > other backends (SQL) feasible.
> 
> I'm not against cleaner code, nor am I against separation of logic.
> However, before you venture out on this be warned that it is not that
> Tuomas, me and others haven't tried already, so it is not just a few hours
> of work. Further, before I accept any extra layer of complexity into KPA
> for this to be possible, I want to see true value.
> 
> Don't get me wrong, I welcome the work, I just ask that you conduct it in a
> way where you don't let a half split up KPA lay around when you are half
> way through and lost interest in it.
> 
> SO I suggest that you get git access, and make a branch that you
> continuously rebase from master, and then on that branch do this work and
> e.g. implement a command line interface. (Which indeed would be cool to
> have).
> 
> As always I'm on the #kphotoalbum IRC channel if you want input on it.

Since I started looking into the KPA source code I know its codebase well 
enough to know this project needs more than a few hours, so I do understand 
your concerns. You telling me that there were already several tries to achieve 
that (and also the failed sqldb backend) confirms my fears that doing this 
work "inside" KPA probably won't work out too well.

I'll do my own branch and push it to my github-fork once I'm confident that 
it's somewhat usable. Don't get too eager though -- my timeframe is more like 
"this year", not "next month".

Thanks for the reminder abou IRC, I'll keep that in mind...

Cheers,
  Johannes