2012/2/3 Anselmo L. S. Melo <anselmo.m...@openbossa.org>:
> 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
>
>>> 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.
The best case result for me would be to have QAction, stripped of GUI
specifics, in core and the GUI classes using QAction changed to work
without the GUI specific functions. If really required a QGuiAction
offering the old API can be added to QtGui.
I see the point of keeping the same name for migration but with the
above I'm wondering how much QtGui using code will really be broken.
We could also name the stripped class QAbstractAction, but I prefer
short class names.
I have a use case whereby passing QAction-pointer via
QAbstractItemModel::data() (actions specific to items and not
hardcoded in the GUI) the models could potentially be 100% reusable in
a QML only app [1]. If QAction is not moved then at least I need
something that can be easily shared between QtGui and QML codebases.
[1]
http://quickgit.kde.org/index.php?p=amarok.git&a=blob&h=e5075479000e8b20aa39a2ea7c51012128e82348&hb=88f7be636917cdf060b0b6de62a5701161727185&f=src%2Fbrowsers%2Fplaylistbrowser%2FPlaylistBrowserModel.cpp
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
