[Development] Moving QUndoStack and QUndoCommand out of QtWidgets

Anselmo L. S. Melo anselmo.melo at openbossa.org
Fri Feb 3 19:16:29 CET 2012


On 02/03/2012 02:26 PM, gunnar.sletta at nokia.com wrote:
> 
> On Feb 3, 2012, at 2:09 PM, ext Anselmo L. S. Melo wrote:
> 
>> Hi,
>>
>> On 12/15/2011 07:10 PM, Olivier Goffart wrote:
>>> On Thursday 15 December 2011 18:40:45 Jesus Sanchez-Palencia wrote:
>>>> Hi there,
>>>>
>>>> I would like to gather your opinion on whether we should move
>>>> QUndoStack and QUndoCommand out of QtWidgets so they could be used
>>>> without requiring this module as an extra dependency.
>>
>> +1
>>
> 
> Yes I agree. These classes are useful for a significant class of applications we will see people writing those types of apps in QML as well as widgets in the future, so extracting them from the QtWidgets library might be a good idea.

Exactly.

> Where to put them is another question. To me, these classes fall into the same category as QIcon, QAction, QFileSystemModel and a probably a few others. They are enablers for certain UI's, but are at the same time not useful for a different class of apps.
> For instance mobile apps. For this reason, I do not think QtGui is the right place for them. As I mentioned in the previous thread on
QFileSystemModel, I think a new module of non-widgetbased desktopui enabling would be a better location.

Yes, I agree QtGui does not seem to be the best place for such classes.
I've just read the other thread you mentioned, I like this idea of the module for enablers.


cheers,
Anselmo

> 
> cheers,
> Gunnar
> 
> 
>>>> After a brief investigation, I believe this could done by:
>>>>
>>>> 1- moving QUndoCommand entirely;
>>>>
>>>> 2- moving QUndoStack without moving the APIs that rely on or need
>>>> QAction (QAction *createUndoAction() and QAction *createRedoAction());
>>>>
>>>> 3- creating a new class (QUndoStackAction ??) inside QtWidgets and
>>>> implement the APIs mentioned above there (createUndoAction and
>>>> createRedoAction);
>>>>
>>>> 4- applying the same logic to QUndoGroup.
>>>>
>>>>
>>>> QtWebKit, for instance, would benefit from this immediately, as we aim
>>>> on removing the QtWidgets dependencies.
>>>>
>>>> Suggestions, comments and any sort of feedback here would be more than
>>>> welcome.
>>> I beleive QAction should also be moved back in QtGui
>>
>>
>> I did some experiments about it yesterday, doing a mix of the two suggestions sent to this thread, i.e., moving QUndo{Command,Stack,Group}
>> and QAction out of QtWidgets. QtGui was built successfully, however, before procced to do the adjustments needed in QtWidgets, I considered
>> important to ask for feedback regarding this task.
>>
>> A question related to the feature freeze: Should I create a new task on JIRA for it, or reopen this old one:
>> https://bugreports.qt-project.org/browse/QTBUG-3415 ?
>>
>> Back to the topic: The current status is: QUndo{Command,Stack,Group} and QAction where moved out of QtWidgets and renamed to temporary (and
>> IMHO bad) names like QGuiUndo{Command,Stack,Group} and QGuiActuion, so the QtWidgets subclasses would maintain the original names, to not
>> introduce additional SiC between Qt4/QtGui->Qt5/QtWidgets. Any suggestions regarding names here?
>>
>> Feedback is appreciated.
>>
>>
>> Cheers,
>> Anselmo
>>
>>
>> -- 
>> Anselmo L. S. Melo
>> openBossa / INdT
>> http://www.indt.org
>> http://www.anselmolsm.org
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 


-- 
Anselmo L. S. Melo
openBossa / INdT
http://www.indt.org
http://www.anselmolsm.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120203/dfa8e4a0/attachment.sig>


More information about the Development mailing list