On 2/7/12 10:02 AM, "ext Bart Cerneels" <bart.cerne...@kde.org> wrote:
>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.
Stripping QAction of it's widgets dependencies is going to break way too
much code out there IMO.
Also what do you need QAction for in QtGui? While I agree that we might
over time need something there I do wonder whether QAction is the right
API and abstraction for it.
>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.
It might be easier (and better in the long term) to create a new class for
this that fits better with the needs of QML and also integrates into
QAction.
Cheers,
Lars
>
>[1]
>http://quickgit.kde.org/index.php?p=amarok.git&a=blob&h=e5075479000e8b20aa
>39a2ea7c51012128e82348&hb=88f7be636917cdf060b0b6de62a5701161727185&f=src%2
>Fbrowsers%2Fplaylistbrowser%2FPlaylistBrowserModel.cpp
>_______________________________________________
>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
