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

2016-01-11 Thread Friedrich W. H. Kossebau
Am Samstag, 9. Januar 2016, 00:11:12 schrieb Jaroslaw Staniek:
> On 8 January 2016 at 23:29, Camilla Boemann  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

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.

Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


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

2016-01-11 Thread Jaroslaw Staniek
On 11 January 2016 at 18:03, Friedrich W. H. Kossebau  wrote:
> Am Samstag, 9. Januar 2016, 00:11:12 schrieb Jaroslaw Staniek:
>> On 8 January 2016 at 23:29, Camilla Boemann  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 
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 

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

2016-01-09 Thread Boudewijn Rempt

On Sat, 9 Jan 2016, Jaroslaw Staniek wrote:


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.



kundo2 started out as a fork of qt5's qundo stuff, but over the years extra 
functionality was added, but it might be that that was only used in Krita's 
history docker.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


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

2016-01-08 Thread Camilla Boemann
Yeah regarding library names the renaming should rather be the other way

I don't want that ko everywhere

And regarding kundo2 - wasn't it supposed to be a clone of the qt5 so we could 
get rid of our own version ?

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of 
Friedrich W. H. Kossebau
Sent: 8. januar 2016 23:20
To: calligra-devel@kde.org
Subject: Consistent naming of folders in libs/ & renaming kundo2 -> koundo

Hi,

to remove some complexity and add more patterns to the code structure, both for 
us current developers and even more for future developers trying to grasp the 
landscapes of Calligra code, I will be going to do two things next week (around 
Wednesday 13th) in master:

a) rename the kundo2 lib and all its classes to koundo/KoUndo

b) rename folders in libs/ consistently to match the lib name

   version -> koversion
   widgetutils -> widgetutils
   widgets -> kowidgets
   store -> kostore
   odf -> koodf
   textlayout -> kotextlayout
   kundo2 -> koundo
main -> komain
rdf -> kordf
vectorimage -> kovectorimage


Any issues with that?

Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


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

2016-01-08 Thread Jaroslaw Staniek
On 8 January 2016 at 23:29, Camilla Boemann  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.

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

> -Original Message-
> From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of 
> Friedrich W. H. Kossebau
> Sent: 8. januar 2016 23:20
> To: calligra-devel@kde.org
> Subject: Consistent naming of folders in libs/ & renaming kundo2 -> koundo
>
> Hi,
>
> to remove some complexity and add more patterns to the code structure, both 
> for us current developers and even more for future developers trying to grasp 
> the landscapes of Calligra code, I will be going to do two things next week 
> (around Wednesday 13th) in master:
>
> a) rename the kundo2 lib and all its classes to koundo/KoUndo
>
> b) rename folders in libs/ consistently to match the lib name
>
>version -> koversion
>widgetutils -> widgetutils
>widgets -> kowidgets
>store -> kostore
>odf -> koodf
>textlayout -> kotextlayout
>kundo2 -> koundo
> main -> komain
> rdf -> kordf
> vectorimage -> kovectorimage
>
>
> Any issues with that?
>
> Cheers
> Friedrich
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel



-- 
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
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel