Consistent naming of folders in libs/ & renaming kundo2 -> koundo

[Jaroslaw Staniek]

On 11 January 2016 at 18:03, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> Am Samstag, 9. Januar 2016, 00:11:12 schrieb Jaroslaw Staniek:
>> On 8 January 2016 at 23:29, Camilla Boemann <cbo at boemann.dk> wrote:
>> > Yeah regarding library names the renaming should rather be the other way
>> >
>> > I don't want that ko everywhere
>>
>> Same feeling here. Consistency is good but what I detest while using
>> bash or IDE (Creator) completion and most if not all folders have
>> names with the same prefix. The purpose of such a prefix is unclear then.
>> Especially that these are all local libs. So yes, I'd go the other
>> way, in particular kundo2 -> undo.
>
> Using just basenames was also my initial idea. But disadvantages:
> a) unbalanced naming of folders:
>    libs with generic basename (main, text) vs. special named (flake, pigment).
> b) results in another alias for the libname ones has to have in mind
>    (local source files also have full name of class defined in it,
>    not prefixless, so perhaps a pattern to pick up)
> c) generic basenames (main, text) can be mixed up with generic resource folder
>    names (pics, templates, styles, data), using the full lib name would be
>    more clear

Well, let's consider location of these libraries temporary.
Even if we never have them out of the calligra.git, the fact that they
exist as libraries is an implementation detail.
They are in fact shared code subdirs in our hierarchy.

The naming has to be quick to use for us, internally, and as said
isn't exposed outside.

> Like prefixes with class names never have annoyed me when using completion,
> also prefixes of folder names have not really done that, So not a real
> disadvantage on my list.
>
> But if those two chars are a big bugger for you, I have no strong opinion
> here, fine to rename instead the other to prefixless if more people prefer
> that?
>
>> > And regarding kundo2 - wasn't it supposed to be a clone of the qt5 so we
>> > could get rid of our own version ?
>> I am interested in this too since kexi.git forked kundo2 to reduce
>> deps. I'd like to know if Qt 5 has all we need or if kundo stays, if
>> we can have it in a separate repo. It's 1.5K SLOC. If so I am
>> volunteering for making it a repo.
>
> From what was said and what I saw it seems KUndo2 turned into quite some
> variant of its own, coupled with the special calligra_xgettext.
>
> While I am not too keen about splitting more repos off, also due to extra work
> on releasing, if that helps to reduce code duplication it might be a good
> thing to do afterall.
> But what namespace to use for the lib and its repo? KoUndo? KUndo?
> Needs someone to analyze what is so special about this undo system, so it
> could be reflected in the name. Possibly KoUndo would be best for now, keeping
> it a private shared lib of Calligra, not yet maintained for public
> consumption, only in own repo for reuse needs between Calligra apps in split
> repos.
>
> So not touching kundo2 subfolder for now.

A single rename is feels better than two renames. So changing to KUndo
in one go would be good if we have a separate repo at all. As we know
it's going to be pretty non-changing repo, changes are cosmetic.

Yes, let's first look at what's special there.

I see one thing that would be potentially annoying in the future.
kundo2 like the QUndo* classes depend on QtWidgets... This is a bit
unfortunate, wouldn't break anything right now until we need it for
QML solutions. And I see only QUndoView depending on QWidget.

So we have one thing that's not fixable in Qt 5 but is in kundo2.

I just checked the history (using 'gitk log --follow  -- libs/kundo2'
or 'git log --follow  -- libs/kundo2'), and there it is:

Initial commit ce619d0a98345070fdc139063e011b55335cf919
Author: Alexander Potashev <aspotashev at gmail.com>
Date:   Sun May 22 12:28:31 2011 +0400

    Add libkundo2 to Calligra

    kundo2 is a fork of Qt's Undo Framework (QUndoStack, QUndoView, ...).
    It contains two bugfixes the are going to be available only in Qt 4.8:
        https://qt.gitorious.org/qt/qt/merge_requests/1212
        https://qt.gitorious.org/qt/qt/merge_requests/2610

    To start using kundo2, one should port Calligra to it. This can be done
    by adding target_link_libraries(... kundo2) into CMakeLists.txt files
    for all modules from Calligra that use Qt Undo Framework, and by
    switching from QUndo**** classes to KUndo2**** classes.
    (switching to KUndo2 classes can easily be done by using a script)

    After Calligra starts requiring Qt 4.8+, this library can be removed,
    because it has no advantages over Qt's Undo Framework 4.8.
(END)

+ 9e12ec0fd24ba67c "Cumulative Undo/Redo"
+ a576bf0b62 "Added purgeRedoState()"
+ e98e4141e0a37 "Added extraData - user-defined object associated with
the command"

I am not sure how these additions relate to command merges.
@Boud @Dmitry @Alexander?

Also, QUndoCommand::actionText() was introduced in Qt 4.8, seems
related to what we tried to achieve by forking. Or not?

I see kexi.git could consider removing the fork and move to the plain
QUndo (QWidget deps is not an issue for now). Maybe other calligra
apps (but Krita?) could do the same.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek