On 02/03/2012 02:26 PM, [email protected] 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
>> [email protected]
>> http://lists.qt-project.org/mailman/listinfo/development
>
--
Anselmo L. S. Melo
openBossa / INdT
http://www.indt.org
http://www.anselmolsm.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
