Re: Consistent naming of folders in libs/ & renaming kundo2 -> koundo
Am Samstag, 9. Januar 2016, 00:11:12 schrieb Jaroslaw Staniek: > On 8 January 2016 at 23:29, Camilla Boemannwrote: > > 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
On 11 January 2016 at 18:03, Friedrich W. H. Kossebauwrote: > 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
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
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
On 8 January 2016 at 23:29, Camilla Boemannwrote: > 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