[KPhotoAlbum] New features for testing and discussion

[Jesper K. Pedersen]

On Wednesday 01 August 2012 20:10:05 Johannes Zarl wrote:
> On Wednesday 01 August 2012 15:04:18 Jesper K. Pedersen wrote:
> > > > > course the default behavior is a matter of taste and changing the
> > > > > icon from {} to ^ would also be sufficient for me.
> > > 
> > > I chose the "{}" icon because MatchFromBeginning effectively matches the
> > > whole tag name, whereas MatchFromWordStart splits the tag name. If you
> > > find a better icon in the standard KDE icon set, I'll be happy to use
> > > that instead.
> 
> Let me rephrase that: this was the best fitting icon in KDE I could find for
> the job. If somebody knows of better one, please point me to it. I can
> rework it as a text-button, though.

I wonder if this is something that a user will ever change after having 
changed it initially. In other words, is this something you go forth and back 
with? If not maybe it should just move to the settings pages.

> > 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. 

> > Seriously, please find something better than the {} icon, even with your
> > description I don't understand your icon (or at least would not be able to
> > memorize it)
> 
> As said above. If it's that bad, I'll just change it to a text-button.
> (Which might have been the better choice from the start on)

I wrote KRegExpEditor, so I'm mister regexp, still looking at that icon did 
not give me that association, so I fear the average KPA user would not get it.

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

> > > 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.

Cheers
-- 
Having trouble finding a given image in your collection containing
thousands of images?

http://www.kphotoalbum.org might be the answer.