[Development] Moving Qt's undo framework out of Qt Widgets

[Ch'Gans]

On 6 April 2017 at 00:02, Morten Sørvig <Morten.Sorvig at qt.io> wrote:
>
>
>> On 5 Apr 2017, at 12:37, Oswald Buddenhagen <oswald.buddenhagen at qt.io> wrote:
>>
>> On Wed, Apr 05, 2017 at 09:24:15AM +0000, 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”;
>
> QtCoreCore    QtGuiCore
> QtCoreSink    QtGuiSink

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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development