Re: Replacement for Qt's Undo Framework
On Monday, May 9, 2011 13:53:55 Alexander Potashev wrote: > 2011/4/26 Aaron J. Seigo : > > it's bad practice if it can be fixed in Qt; it's not bad practice if it > > is something that doesn't belong in Qt. kdelibs should be a value-add > > extension of Qt for areas that make sense primarily/exclusively to the > > kinds of apps we create and/or target. it should not be a collection of > > bug fixes or minor improvements to Qt. > > Both problems fixed in Qt 4.8 with these patches: > https://qt.gitorious.org/qt/qt/merge_requests/1212 > https://qt.gitorious.org/qt/qt/merge_requests/2610 that is terrific news :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Replacement for Qt's Undo Framework
2011/4/26 Aaron J. Seigo : > it's bad practice if it can be fixed in Qt; it's not bad practice if it is > something that doesn't belong in Qt. kdelibs should be a value-add extension > of Qt for areas that make sense primarily/exclusively to the kinds of apps we > create and/or target. it should not be a collection of bug fixes or minor > improvements to Qt. Both problems fixed in Qt 4.8 with these patches: https://qt.gitorious.org/qt/qt/merge_requests/1212 https://qt.gitorious.org/qt/qt/merge_requests/2610 About "magic split" (i.e. different strings for "Undo %1" and QUndoView): 1. "\n" will be used as separator instead of "|-|". 2. Before using this new feature, translators will need to wait until KDE SC (or other software you translate) depends on Qt 4.8 (which hasn't been released yet, by the way). -- Alexander Potashev
Re: Replacement for Qt's Undo Framework
On Monday 25 April 2011 Apr, Alexander Potashev wrote: <...> Just want to say I think it's really nice to see Matus' Google Code In work noticed :-) -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: Replacement for Qt's Undo Framework
Le Tuesday 26 April 2011, Albert Astals Cid a écrit : > A Dimarts, 26 d'abril de 2011, Olivier Goffart va escriure: > > > What do you think about inclusion of KUndo*2 into kdelibs? > > > > I have not seen the details about KUndo2 yet, but what are the reasons > > that keep you from improving QUndo in Qt? Is there technical reasons? or > > just political issues? > > In http://bugreports.qt.nokia.com/browse/QTBUG-14442 ossi implies it's an > API problem and thus as the API can not be changed in QUndo it implies it > needs new classes. Of course one could introduce QUndo2 classes but you > seldom do that No. Ossi suggest to add overloads. > and of course there is the issue of the extreme overhead > needed to get something into Qt vs getting it in kdelibs. Yes, this is something that hopefully will get better soon.
Re: Replacement for Qt's Undo Framework
2011/4/26 Aaron J. Seigo :
> On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote:
>> What do you think about inclusion of KUndo*2 into kdelibs?
>
> we really don't want more duplication of code and effort between Qt and
> kdelibs, and we certainly don't want forks of Qt code in kdelibs.
>
> please work on having this fixed in Qt itself, which is the correct/best place
> for this effort. it would be good to have this improved, and it's great that
> you're willing to work on it :)
Attempts to fix the bug in Qt are going to look very hacky (and those
hack will most likely not be accepted for inclusion in Qt), or even
break the Qt API (as Albert has also written).
Example: The prefix "Undo"/"Redo" is stored in an instance variable
(m_prefix) of QUndoAction. If we still allow custom prefixes
(otherwise it will be an API breakage), we need to keep m_prefix. This
will lead to unnecessary memory usage for it.
> in the code you've written, i see in the #includes KLocale as well as some
> "kis_" files. i didn't see any actual use of KLocale, however? is there any
> actual use of kdelibs in your work (hopefully not, as that would make a Qt
> target easier), are there any binary incompatible changes (again, hopefully
> not... :)
KLocale is here for i18n() (i18n("Undo %1"), i18n("Undo action"), etc).
The "kis_" includes were left over after copying KUndoView2 from
Krita's KisUndoView, they can be removed.
--
Alexander Potashev
Re: Replacement for Qt's Undo Framework
2011/4/26 Albert Astals Cid : >> I kept the arguments of UndoCommand() the same, but now if you put >> something like "Create a document|-|creation of a document" as the >> "text" into the constructor (or translate it with a similar string >> with "|-|"), you'll get "Create a document" as the name of an item in >> Undo History panel, and the "Undo ..." menu item will be called "Undo >> creation of a document". > > This approach seems a bit too fragile to "wrong/careless" translations, though > i guess we can always add it to the pology checks I didn't mention it, but traditional undo command names (w/o "|-|") work in KUndo2 exactly like in plain QUndoCommands (see the "else" block in https://github.com/aspotashev/libkundo2/blob/master/src/kundostack2.cpp#L267). Nothing is going to be broken unless you accidentally but "|-|" in your translation not knowing what that means (i.e. translators and developers can just ignore this functionality). -- Alexander Potashev
Re: Replacement for Qt's Undo Framework
A Dimarts, 26 d'abril de 2011, Olivier Goffart va escriure: > > What do you think about inclusion of KUndo*2 into kdelibs? > > I have not seen the details about KUndo2 yet, but what are the reasons > that keep you from improving QUndo in Qt? Is there technical reasons? or > just political issues? In http://bugreports.qt.nokia.com/browse/QTBUG-14442 ossi implies it's an API problem and thus as the API can not be changed in QUndo it implies it needs new classes. Of course one could introduce QUndo2 classes but you seldom do that and of course there is the issue of the extreme overhead needed to get something into Qt vs getting it in kdelibs. Albert
Re: Replacement for Qt's Undo Framework
On Tuesday 26 April 2011, Aaron J. Seigo wrote: > we really don't want more duplication of code and effort between Qt and > kdelibs, and we certainly don't want forks of Qt code in kdelibs. Especially after I moved the KUndoCommand/KUndoHistory classes to kde3support, after polishing them for kdelibs-4.0 and then noticing Qt got undo classes... It would be extremely ironic (not to say frustrating) to now see another set of undo classes in kdelibs in their place! -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: Replacement for Qt's Undo Framework
On Tuesday, April 26, 2011 07:12:32 Tom Albers wrote: > It does sound like to me as we take the base class from Qt and > improve it for usage within KDE. not if it can be improved directly in the classes in Qt itself, limiting the number of classes we have, lowering the cost of learning the combined Qt+KDE API and ensuring we don't end up with yet more stories of Qt implementing something today that was done in kdelibs a year ago as a subclass of a Qt class. > We've done that for years and years. yes, because Qt was generally closed to external development and we didn't consider it a valid development target. this has changed, and the "put it into kdelibs" practice also had its costs, however. we now have the opportunity to improve on this historical practice, so perhaps we should try to do so. > Does > this now imply that that's bad practice and kdelibs is closed for such > classes? it's bad practice if it can be fixed in Qt; it's not bad practice if it is something that doesn't belong in Qt. kdelibs should be a value-add extension of Qt for areas that make sense primarily/exclusively to the kinds of apps we create and/or target. it should not be a collection of bug fixes or minor improvements to Qt. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Replacement for Qt's Undo Framework
On Tuesday, 26 de April de 2011 07:12:32 Tom Albers wrote: > - Original Message - > > > On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote: > > > What do you think about inclusion of KUndo*2 into kdelibs? > > > > we really don't want more duplication of code and effort between Qt > > and > > kdelibs, and we certainly don't want forks of Qt code in kdelibs. > > Forks? It does sound like to me as we take the base class from Qt and > improve it for usage within KDE. We've done that for years and years. Does > this now imply that that's bad practice and kdelibs is closed for such > classes? No, it implies that if it can be done there, it should be done there. Kdelibs should be for new functionality that doesn't belong in Qt. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Replacement for Qt's Undo Framework
Tom, with all the due respect, "improve" should mean the Qt version does the job, but you have a more specific target to meet, which is alien to Qt. I'm not aware of Qt localization having defined Russian "off target", so I'd say an upstream bug is an upstream bug. That's unless Qt says they have no interest for localization... Bèrto On 26 April 2011 10:12, Tom Albers wrote: > - Original Message - > > On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote: > > > What do you think about inclusion of KUndo*2 into kdelibs? > > > > we really don't want more duplication of code and effort between Qt > > and > > kdelibs, and we certainly don't want forks of Qt code in kdelibs. > > Forks? It does sound like to me as we take the base class from Qt and > improve it for usage within KDE. We've done that for years and years. Does > this now imply that that's bad practice and kdelibs is closed for such > classes? > > Best, > -- > Tom Albers > KDE Sysadmin > -- == If Pac-Man had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music.
Re: Replacement for Qt's Undo Framework
- Original Message - > On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote: > > What do you think about inclusion of KUndo*2 into kdelibs? > > we really don't want more duplication of code and effort between Qt > and > kdelibs, and we certainly don't want forks of Qt code in kdelibs. Forks? It does sound like to me as we take the base class from Qt and improve it for usage within KDE. We've done that for years and years. Does this now imply that that's bad practice and kdelibs is closed for such classes? Best, -- Tom Albers KDE Sysadmin
Re: Replacement for Qt's Undo Framework
On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote: > What do you think about inclusion of KUndo*2 into kdelibs? we really don't want more duplication of code and effort between Qt and kdelibs, and we certainly don't want forks of Qt code in kdelibs. please work on having this fixed in Qt itself, which is the correct/best place for this effort. it would be good to have this improved, and it's great that you're willing to work on it :) in the code you've written, i see in the #includes KLocale as well as some "kis_" files. i didn't see any actual use of KLocale, however? is there any actual use of kdelibs in your work (hopefully not, as that would make a Qt target easier), are there any binary incompatible changes (again, hopefully not... :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Replacement for Qt's Undo Framework
Le Monday 25 April 2011, Alexander Potashev a écrit : > Hi, > > The Qt's Undo Framework (QUndoCommand, QUndoStack, QUndoGroup, > QUndoView) has a few oddities: > 1. The names of undo actions can only have a predefined prefix > (https://bugs.kde.org/show_bug.cgi?id=253459), > 2. You can't use different strings for the name of undo action (Edit > -> Undo/Redo [some action]) and for the items in the undo history > (there is such panel, for example, in Step and Krita). The reason for > having different strings is to make grammatical cases of the names of > actions consistent with the context (in Russian and a few other > languages you should put %1 in accusative case in "Undo %1"). > > > If I'm not mistaken, those problems can't be solved by just deriving > your own classes from QUndo*, because you need to override methods > like createUndoAction which are not "virtual" (sure, you can name > those methods differently, but then other problems may arise). > > The solution is to fork QUndo* classes and fix the problems in the new > classes, so did I: > https://github.com/aspotashev/libkundo2 > (the code looks like garbage, I only made it working, but didn't try > to clean it up) > > > At the first glance, the only way to use two strings for every > UndoCommand is to add yet another argument to the constructor of > UndoCommand. But then a huge amount of code would need changes, that's > not very good. Also, most languages don't really need different names > for undo actions and items in undo history. > I kept the arguments of UndoCommand() the same, but now if you put > something like "Create a document|-|creation of a document" as the > "text" into the constructor (or translate it with a similar string > with "|-|"), you'll get "Create a document" as the name of an item in > Undo History panel, and the "Undo ..." menu item will be called "Undo > creation of a document". > > Screenshots: > http://ompldr.org/vOGYxaQ -- translation in Lokalize (into Russian) > http://ompldr.org/vOGYxag -- Step using different translations for > "Undo ..." command and undo history. > > The patch I used for Step is attached. > > > What do you think about inclusion of KUndo*2 into kdelibs? I have not seen the details about KUndo2 yet, but what are the reasons that keep you from improving QUndo in Qt? Is there technical reasons? or just political issues? Because this KUndo2 things are just against the others goal: http://community.kde.org/KDE_Core/QtMerge
Re: Replacement for Qt's Undo Framework
A Dilluns, 25 d'abril de 2011, Alexander Potashev va escriure: > Hi, > > The Qt's Undo Framework (QUndoCommand, QUndoStack, QUndoGroup, > QUndoView) has a few oddities: > > The solution is to fork QUndo* classes and fix the problems in the new > classes, so did I: > https://github.com/aspotashev/libkundo2 > (the code looks like garbage, I only made it working, but didn't try > to clean it up) > > > I kept the arguments of UndoCommand() the same, but now if you put > something like "Create a document|-|creation of a document" as the > "text" into the constructor (or translate it with a similar string > with "|-|"), you'll get "Create a document" as the name of an item in > Undo History panel, and the "Undo ..." menu item will be called "Undo > creation of a document". This approach seems a bit too fragile to "wrong/careless" translations, though i guess we can always add it to the pology checks > What do you think about inclusion of KUndo*2 into kdelibs? Maybe it would make sense you to improve your code to a point to are happy with it before asking for inclusion? Albert
