Re: [Development] Moving Qt's undo framework out of Qt Widgets
05.04.2017, 17:46, "Oswald Buddenhagen" : > On Wed, Apr 05, 2017 at 12:02:32PM +, Morten Sørvig wrote: >> On 5 Apr 2017, at 12:37, Oswald Buddenhagen >> wrote: >> > also, a plan for splitting up qtbase wouldn't be entirely off the >> > mark. untangling tests and examples would be the major effort here. >> >> No, we should follow Google and Facebook’s lead: large monolithic >> repos (as large as the infrastructure can handle), which can be >> updated atomically. > > that's kinda the point: the infrastructure (and tooling) can't handle > it, at multiple levels. > for the atomicity, see https://bugreports.qt.io/browse/QTQAINFRA-868 . Right now it requires a lot of time and patience to get any patch integrated into qt5.git. If everything is in the same repo, the same will apply to patches for other modules :/ > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving Qt's undo framework out of Qt Widgets
On Wed, Apr 05, 2017 at 12:02:32PM +, Morten Sørvig wrote: > On 5 Apr 2017, at 12:37, Oswald Buddenhagen wrote: > > also, a plan for splitting up qtbase wouldn't be entirely off the > > mark. untangling tests and examples would be the major effort here. > > No, we should follow Google and Facebook’s lead: large monolithic > repos (as large as the infrastructure can handle), which can be > updated atomically. > that's kinda the point: the infrastructure (and tooling) can't handle it, at multiple levels. for the atomicity, see https://bugreports.qt.io/browse/QTQAINFRA-868 . ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving Qt's undo framework out of Qt Widgets
On 6 April 2017 at 00:02, Morten Sørvig wrote: > > >> On 5 Apr 2017, at 12:37, Oswald Buddenhagen wrote: >> >> On Wed, Apr 05, 2017 at 09:24:15AM +, Mitch Curtis wrote: >>> So, should this get its own module, and if so, can widgets depend on >>> it? >>> >> an own module just for that seems over the top - i don't think we want >> to end up with 100 micro-libraries. >> >> however, splitting up qtcore has been raised multiple times, and >> putting this into one of the resulting libs would seem reasonable. for >> example, this seems conceptually quite related to item models. possibly >> also state machine. and animation. these are all things which initially >> elicit a "huh, this is core?" response, until you think a bit about it. >> GuiSupport may be a better name for it (i'm sure some will disagree). > > So both QtCore and QtGui could be split up into “Core” and “Kitchen Sink”; > > QtCoreCoreQtGuiCore > QtCoreSinkQtGuiSink You forgot QtCoreKitchen, QtGuiKitchen, QtCoreKitchenSinkSupport, QtGuiKitchenCoreSinkSupport and of course QtCoreKitchenGuiSinkCoreSupport! ;) I would even consider a new QtCoreGuiBridge module to help with decoupling GUI from Core and Sink from kitchen. Of course all class names would start with QAbstract, eg QAbstractCoreGuiKitchenSinkBridge. This goes without saying that to help with creating object of arbitrary concrete types a QCoreGuiKitchenSinkBridgeFactory is a must have! Along with a proper QCoreGuiKitchenSinkBridgeFactoryPluginInterface and for user's convenience (and the fun of it) a QCoreGuiKitchenSinkBridgeFactoryPluginLoader. -> [] Chris > > QtWidgets and QtDeclarative would depend on all of these; are we gaining > anything? Well: > > 1) The “Core” versions will be satisfyingly uncluttered. > 2) Those who do not use QtWidgets or QtDeclarative can possibly depend >on smaller libraries. > >> >> also, a plan for splitting up qtbase wouldn't be entirely off the mark. >> untangling tests and examples would be the major effort here. > > (At the risk of derailing the discussion (sorry Mitch)) No, we should > follow Google and Facebook’s lead: large monolithic repos (as large as > the infrastructure can handle), which can be updated atomically. > > Morten > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving Qt's undo framework out of Qt Widgets
> On 5 Apr 2017, at 12:37, Oswald Buddenhagen wrote: > > On Wed, Apr 05, 2017 at 09:24:15AM +, Mitch Curtis wrote: >> So, should this get its own module, and if so, can widgets depend on >> it? >> > an own module just for that seems over the top - i don't think we want > to end up with 100 micro-libraries. > > however, splitting up qtcore has been raised multiple times, and > putting this into one of the resulting libs would seem reasonable. for > example, this seems conceptually quite related to item models. possibly > also state machine. and animation. these are all things which initially > elicit a "huh, this is core?" response, until you think a bit about it. > GuiSupport may be a better name for it (i'm sure some will disagree). So both QtCore and QtGui could be split up into “Core” and “Kitchen Sink”; QtCoreCoreQtGuiCore QtCoreSinkQtGuiSink QtWidgets and QtDeclarative would depend on all of these; are we gaining anything? Well: 1) The “Core” versions will be satisfyingly uncluttered. 2) Those who do not use QtWidgets or QtDeclarative can possibly depend on smaller libraries. > > also, a plan for splitting up qtbase wouldn't be entirely off the mark. > untangling tests and examples would be the major effort here. (At the risk of derailing the discussion (sorry Mitch)) No, we should follow Google and Facebook’s lead: large monolithic repos (as large as the infrastructure can handle), which can be updated atomically. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving Qt's undo framework out of Qt Widgets
On Wed, Apr 05, 2017 at 09:24:15AM +, Mitch Curtis wrote: > So, should this get its own module, and if so, can widgets depend on > it? > an own module just for that seems over the top - i don't think we want to end up with 100 micro-libraries. however, splitting up qtcore has been raised multiple times, and putting this into one of the resulting libs would seem reasonable. for example, this seems conceptually quite related to item models. possibly also state machine. and animation. these are all things which initially elicit a "huh, this is core?" response, until you think a bit about it. GuiSupport may be a better name for it (i'm sure some will disagree). generally, an effort to map all the qt classes to smaller libraries would be welcome. also, a plan for splitting up qtbase wouldn't be entirely off the mark. untangling tests and examples would be the major effort here. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving Qt's undo framework out of Qt Widgets
> On 5 Apr 2017, at 11:24, Mitch Curtis wrote: > > I'd like to remove the undo framework's dependency on widgets. There's a bug > report for this here: > > https://bugreports.qt.io/browse/QTBUG-40040 > > My plan is mentioned in the commit message of the following change: > > https://codereview.qt-project.org/#/c/190704/ > > To summarise: > > - Introduce QGuiUndo* classes that don't have any QAction-related API (which > is the only thing tying the framework to widgets) I keep wishing that QAction wasn’t tied to widgets either, though. Could we fix that in Qt 6? I think it would remove obstacles in quite a few places... > - Make the existing QUndo* classes derive from the respective Qt Gui classes > > This would allow existing code that relies on the QAction API (or otherwise > uses widgets anyway and hence doesn't care) to remain unchanged, and for e.g. > Qt Quick applications to use the undo framework without relying on widgets. > > This is a change for Qt 6, seeing as we cannot "[for existing classes] change > the class hierachy in any way (add, remove, or reorder base classes)." > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts > > > If people are OK with having duplicated code until Qt 6 (it's code that's > rarely touched anyway), we could also introduce the QGuiUndo* classes in the > next applicable minor version. > > Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do > with graphics". While he phrased it in a pretty ridiculous (the majority of > applications using undo/redo are graphical user interfaces) and familiarly > arrogant way, I do agree that non-GUI applications could benefit from this. > > So, should this get its own module, and if so, can widgets depend on it? > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving Qt's undo framework out of Qt Widgets
> -Original Message- > From: Konstantin Tokarev [mailto:annu...@yandex.ru] > Sent: Wednesday, 5 April 2017 11:29 AM > To: Mitch Curtis ; development@qt-project.org > Subject: Re: [Development] Moving Qt's undo framework out of Qt Widgets > > > > 05.04.2017, 12:24, "Mitch Curtis" : > > I'd like to remove the undo framework's dependency on widgets. There's a > bug report for this here: > > > > https://bugreports.qt.io/browse/QTBUG-40040 > > > > My plan is mentioned in the commit message of the following change: > > > > https://codereview.qt-project.org/#/c/190704/ > > > > To summarise: > > > > - Introduce QGuiUndo* classes that don't have any QAction-related API > (which is the only thing tying the framework to widgets) > > - Make the existing QUndo* classes derive from the respective Qt Gui > classes > > Out of curiosity, why does this code have to be in QtGui? Looks pretty-much > GUI-independent. It doesn't, it just seemed like a reasonable option to me; it's in the same repo and it's mostly used by GUI applications. The same could be said about QValidator and friends. > > > > This would allow existing code that relies on the QAction API (or otherwise > uses widgets anyway and hence doesn't care) to remain unchanged, and for > e.g. Qt Quick applications to use the undo framework without relying on > widgets. > > > > This is a change for Qt 6, seeing as we cannot "[for existing classes] > > change > the class hierachy in any way (add, remove, or reorder base classes)." > > > > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2 > B%2B#The_Do.27s_and_Don.27ts > > > > If people are OK with having duplicated code until Qt 6 (it's code that's > rarely touched anyway), we could also introduce the QGuiUndo* classes in > the next applicable minor version. > > > > Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do > with graphics". While he phrased it in a pretty ridiculous (the majority of > applications using undo/redo are graphical user interfaces) and familiarly > arrogant way, I do agree that non-GUI applications could benefit from this. > > > > So, should this get its own module, and if so, can widgets depend on it? > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving Qt's undo framework out of Qt Widgets
05.04.2017, 12:24, "Mitch Curtis" : > I'd like to remove the undo framework's dependency on widgets. There's a bug > report for this here: > > https://bugreports.qt.io/browse/QTBUG-40040 > > My plan is mentioned in the commit message of the following change: > > https://codereview.qt-project.org/#/c/190704/ > > To summarise: > > - Introduce QGuiUndo* classes that don't have any QAction-related API (which > is the only thing tying the framework to widgets) > - Make the existing QUndo* classes derive from the respective Qt Gui classes Out of curiosity, why does this code have to be in QtGui? Looks pretty-much GUI-independent. > > This would allow existing code that relies on the QAction API (or otherwise > uses widgets anyway and hence doesn't care) to remain unchanged, and for e.g. > Qt Quick applications to use the undo framework without relying on widgets. > > This is a change for Qt 6, seeing as we cannot "[for existing classes] change > the class hierachy in any way (add, remove, or reorder base classes)." > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts > > If people are OK with having duplicated code until Qt 6 (it's code that's > rarely touched anyway), we could also introduce the QGuiUndo* classes in the > next applicable minor version. > > Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do > with graphics". While he phrased it in a pretty ridiculous (the majority of > applications using undo/redo are graphical user interfaces) and familiarly > arrogant way, I do agree that non-GUI applications could benefit from this. > > So, should this get its own module, and if so, can widgets depend on it? > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Moving Qt's undo framework out of Qt Widgets
I'd like to remove the undo framework's dependency on widgets. There's a bug report for this here: https://bugreports.qt.io/browse/QTBUG-40040 My plan is mentioned in the commit message of the following change: https://codereview.qt-project.org/#/c/190704/ To summarise: - Introduce QGuiUndo* classes that don't have any QAction-related API (which is the only thing tying the framework to widgets) - Make the existing QUndo* classes derive from the respective Qt Gui classes This would allow existing code that relies on the QAction API (or otherwise uses widgets anyway and hence doesn't care) to remain unchanged, and for e.g. Qt Quick applications to use the undo framework without relying on widgets. This is a change for Qt 6, seeing as we cannot "[for existing classes] change the class hierachy in any way (add, remove, or reorder base classes)." https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts If people are OK with having duplicated code until Qt 6 (it's code that's rarely touched anyway), we could also introduce the QGuiUndo* classes in the next applicable minor version. Jake ever-so-politely chimed in with "an undo/redo stack has nothing to do with graphics". While he phrased it in a pretty ridiculous (the majority of applications using undo/redo are graphical user interfaces) and familiarly arrogant way, I do agree that non-GUI applications could benefit from this. So, should this get its own module, and if so, can widgets depend on it? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
