Re: Porting KWidgets to Qt5

[Frank Reininghaus]

Hi,

2012/7/9 Иван Комиссаров:
> I answered to them. They disagree with them in that case. For me is biggest
> priority is to port as much kde as code as possible.

getting code upstream into Qt is good, of course, but you can't expect
that the Qt people will accept KDE code without modifications. If they
have good suggestions how to make the API better and more general, you
should take this into account, e.g., Jeremy's idea to just have a
'tabClicked()' signal with a 'mouse button' argument. One could even
go further and add a 'keyboard modifiers' argument. Things like this
make the API more versatile and future-proof.

Some evidence to support that: QAction's triggered() signal yields no
info about how the action was triggered [1], which makes it impossible
to react to middle-clicks or Control-clicks on, e.g., toolbar buttons,
in a special way. Therefore, KAction has another triggered() signal
that has information about mouse buttons and keyboard modifiers [2].
This wouldn't be necessary if QAction had been written in a more
general way.

Best regards,
Frank

[1] http://doc-snapshot.qt-project.org/5.0/qaction.html#triggered
[2] 
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKAction.html#a47c884a5a7b9b2284553fd5552a8
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

QDocument

[Иван Комиссаров]

Hello everybody. I was looking at Cocoa framework and QtCreator's code and
i was interested in document-based application architecture. I think that
we can add something like QDocument (QAbstractDocument) class with
following features - isModified, isReadOnly, open/save from/to
QIODevice/QUrl, undo/redo, etc... This class should be the base class for
other documents in document-based apps. For example, we can inherit
QTextDocument from QDocument. Over QDocument, we can implement
QDocumentWindow - a class, inherited from MainWidnow that provides standard
slots/actions for manipulating with files in applications -
open/save/close, etc. Note, that no widgets are used here (except for
window), just only document, so you can build any UI on top of that window
- all you need is call "QDocumentWindow::setDocument" when document is
changed (for example, tab is switched).
I would like to hear pros and cons about that idea (not new one, hehe)
Unfirtunately, as long, as Qt5 is frozen and we can't add QDocument. But we
can add an empty QDocument class (QTextDocument->QDocument->QObject) and
add new functionality to it in Qt5.1/5.2 As far as i know, adding new
virtual functions to the end of vtable doesn't break BC. Am i right?
If it is not possible, maybe we can add pointer in a QTextDocument,
containing pointer to QDocument.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel