Re: [Development] Fixing the DLL/shared/static mess
On 04/13/2012 06:41 PM, Thiago Macieira wrote: Therefore, *ALL* Qt libraries must be either static or shared. Mixed builds will not be supported Maybe this is a silly question, but what makes a library to be a Qt library ? Or asking the other way round: what is the difference between a module like QtSvg and 3rd party libraries like Qwt or Qxt - beside where they are hosted ? As far as I understand one of the ideas behind the modularization is to develop modules more independent, what makes these modules sooner or later very similar to 3rd party libraries. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Summit 2012 Registration is now open!
Op 14-4-2012 12:08, Sivan Greenberg schreef: On Fri, Apr 13, 2012 at 8:57 PM, Quim Gilquim@nokia.com wrote: Still a third party from a Qt Project point of view but I guess one that you are more used to trust. Sorry, it was the fastest and simplest way to save us from handling emails manually. Who is the third party in that case? Gitorious, I assume, as that is the hosting party of qt-project.org, right? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api changes
On Fri, Apr 13, 2012 at 12:48 PM, lars.kn...@nokia.com wrote: On 4/13/12 7:18 PM, ext Samuel Rødal samuel.ro...@nokia.com wrote: On 04/13/2012 07:08 PM, ext Girish Ramakrishnan wrote: Hi, I am going through all the new apis. I have a couple of more changes to the public apis already. I am not submitting them to api_changes branch. I think Lars and co are having enough trouble as-is with getting api_changes to merge to master :-) All the commits will have the api: prefix in the commit message (so it's easy to see on my dashboard). I will stage them only after api_changes is merged. My current understanding of the qpa plan is this, correct me if I am wrong: 1. Files with _qpa in them are supposed to be used by plugins and plugins only. If you see, _qpa.h being used in application code, they are using a binary and source incompatible Qt. _qpa.h also lacks the 'we mean it' header which I will add. Mostly, though I guess an application might use QPlatformNativeInterface to get access to a platform specific resource (such as the X display or the wayland display or window handles etc). Maybe we'll need to make a public API front-end for that down the line. I've seen other questions about how to e.g. convert a QPixmap to and from a HBITMAP or get access to other native handles. IMO we should offer APIs for these kind of things in platform dependent add-ons. Isn't this why we have QPlatformNativeInterface. Don't we just have to make the api public through the appropriate classes? ie. we have a QtX11/QtMac/QtWinSupport add-ons. That's also a natural place to add feature gaps to Qt 4.x such as QX11Embed into. I think that add-ons is a good idea. I didn't even realize that QX11Embed has disappeared :-) 2. No public Qt include files should have _qpa.h in them Correct. 3. _qpa.h files are installed only so that we can allow development of plugins outside of qt source. I would like to see them not getting installed at all but I don't know if this is an oversight or intentional. We need to install them, as we want to allow platform plugins outside of qtbase. Ideally, we move them all into a separate directory though, but that would require a bit of build system magic. I can try to move them to QtPlatform/ but no promises for 5.0 :) 4. Also, I would like to see all the handle() functions in public api die. Or make them protected and make all the classes friends (as such they are all mostly friends anyway). handle() encourages writing binary incompatible code in userland. Note that handle() in qpa land is very different from handle() in the old qt4 land (where it just implied being binary compatible but platform specific). The handle() that gets the QPlatformWindow etc? Yeah, I guess those serve no great purpose in the public API. Yes, do we still need it, or should we rename it to something that has the correct name (like platformWindow())? Explicit names would certainly be cleaner, but can break quite some thing currently, so I'd go for adding the new methods and deprecating+inlining the old ones. They should be definitely removed. If they cannot be removed because the changes are too many, I will at least rename them to platformWindow(). Thanks, Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QPlatformInputContext needs more informations
Hello,
I checked QPlatformInputContext interface and I think it needs more
informations
and also I found one of them a little bit strange.
I've learn that using the following code I can get the needed informations
about the
focused control:
QInputMethodQueryEvent query(queries);
QGuiApplication::sendEvent(qGuiApp-focusObject(), query);
Sadly query doesn't contain enough information to correctly display the
keyboard
and the edit control. I need to know where is and what is the control size on
the
screen, because an edit control can be anywhere and it can have any size on the
screen,
to be sure the user will see the entire control and its content, the screen
must be panned
or resized (depending on controls size). To fix this problem I just added and
implement a new enum element to Qt::InputMethodQuery : ImRectangle - The
rectangle of the widget in screen coordinates.. I chose screen coordinates and
not
widget coordinates because I think widget coordinates are useless as long as the
focused item is an qobject and it can be anything. This is the reason why I've
found
Qt::ImCursorRectangle value a little bit strange, IMHO Qt::ImCursorRectangle
should
represents screen coordinates, not widget coordinates.
I also attached a small patch which adds ImRectangle to Qt::InputMethodQuery and
the needed implementation in qtbase.
Before I go further (add the needed implementation to qdeclarative, and push
them to
codereview) I'd like to know what are your thoughts on this matter .
Thank you.
Cheers,
BogDan.
diff --git a/src/corelib/global/qnamespace.h b/src/corelib/global/qnamespace.h
index fa13bed..e3a588e 100644
--- a/src/corelib/global/qnamespace.h
+++ b/src/corelib/global/qnamespace.h
@@ -1269,20 +1269,20 @@ public:
enum InputMethodQuery {
ImEnabled = 0x1,
-ImCursorRectangle = 0x2,
-ImMicroFocus = 0x2, // deprecated
-ImFont = 0x4,
-ImCursorPosition = 0x8,
-ImSurroundingText = 0x10,
-ImCurrentSelection = 0x20,
-ImMaximumTextLength = 0x40,
-ImAnchorPosition = 0x80,
-ImHints = 0x100,
-ImPreferredLanguage = 0x200,
+ImRectangle = 0x2,
+ImCursorRectangle = 0x4,
+ImFont = 0x8,
+ImCursorPosition = 0x10,
+ImSurroundingText = 0x20,
+ImCurrentSelection = 0x40,
+ImMaximumTextLength = 0x80,
+ImAnchorPosition = 0x100,
+ImHints = 0x200,
+ImPreferredLanguage = 0x400,
ImPlatformData = 0x8000,
ImQueryInput = ImCursorRectangle | ImCursorPosition | ImSurroundingText |
- ImCurrentSelection | ImAnchorPosition,
+ ImCurrentSelection | ImAnchorPosition | ImRectangle,
ImQueryAll = 0x
};
Q_DECLARE_FLAGS(InputMethodQueries, InputMethodQuery)
diff --git a/src/corelib/global/qnamespace.qdoc b/src/corelib/global/qnamespace.qdoc
index 1df36f4..85306fb 100644
--- a/src/corelib/global/qnamespace.qdoc
+++ b/src/corelib/global/qnamespace.qdoc
@@ -2506,6 +2506,7 @@
\enum Qt::InputMethodQuery
\value ImEnabledThe widget accepts input method input.
+\value ImRectangle The rectangle of the widget in screen coordinates.
\value ImCursorRectangleThe rectangle covering the area of the input cursor in widget coordinates.
\value ImFont The currently used font for text input.
\value ImCursorPosition The logical position of the cursor within the text surrounding the input area
diff --git a/src/widgets/graphicsview/qgraphicsitem.cpp b/src/widgets/graphicsview/qgraphicsitem.cpp
index dab1965..1397ba8 100644
--- a/src/widgets/graphicsview/qgraphicsitem.cpp
+++ b/src/widgets/graphicsview/qgraphicsitem.cpp
@@ -10427,6 +10427,19 @@ void QGraphicsTextItem::hoverLeaveEvent(QGraphicsSceneHoverEvent *event)
QVariant QGraphicsTextItem::inputMethodQuery(Qt::InputMethodQuery query) const
{
QVariant v;
+if (query == Qt::ImRectangle)
+{
+QGraphicsView *view = 0;
+foreach (view, scene()-views())
+if (view-underMouse() || view-hasFocus())
+break;
+if (view)
+{
+QRect rc = sceneBoundingRect().toRect();
+rc.setTopLeft(view-mapToGlobal(rc.topLeft()));
+v = rc;
+}
+}
if (dd-control)
v = dd-control-inputMethodQuery(query);
if (v.type() == QVariant::RectF)
diff --git a/src/widgets/kernel/qwidget.cpp b/src/widgets/kernel/qwidget.cpp
index cccde76..a417542 100644
--- a/src/widgets/kernel/qwidget.cpp
+++ b/src/widgets/kernel/qwidget.cpp
@@ -8819,6 +8819,8 @@ void QWidget::inputMethodEvent(QInputMethodEvent *event)
QVariant QWidget::inputMethodQuery(Qt::InputMethodQuery query) const
{
switch(query) {
+case Qt::ImRectangle:
+return QRect(mapToGlobal(pos()), size());
case Qt::ImCursorRectangle:
return QRect(width()/2, 0, 1, height());
case
Re: [Development] qHash / QHash changes
So, after *too many* commits[1] -- QHash randomization was merged a few hours ago! https://qt.gitorious.org/qt/qtbase/commit/c01eaa438200edc9a3bbcd8ae1e8ded058bea268 Thanks to all of the guys involved for the ideas, feedback, reviewing the patches... and staging them :-) Cheers, -- Giuseppe D'Angelo [1] http://qtmemes.tumblr.com/post/20282984810 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QPlatformInputContext needs more informations
From: lars.kn...@nokia.com lars.kn...@nokia.com To: bog_dan...@yahoo.com; development@qt-project.org Cc: Sent: Saturday, April 14, 2012 9:40 PM Subject: Re: [Development] QPlatformInputContext needs more informations On 4/14/12 8:29 PM, ext BogDan bog_dan...@yahoo.com wrote: Hello, I checked QPlatformInputContext interface and I think it needs more informations Not sure what you're missing. QPlatformInputContext is only there to implement support for an input method, and has received quite some testing. In order to be sure the user sees the entire control and its content I need to know the control position and its size, otherwise the virtual keyboard may cover the control and its content. QInputMethod (see QGuiApplication::inputMethod()) is the remaining interface that are probably missing right now. and also I found one of them a little bit strange. I've learn that using the following code I can get the needed informations about the focused control: QInputMethodQueryEvent query(queries); QGuiApplication::sendEvent(qGuiApp-focusObject(), query); Sadly query doesn't contain enough information to correctly display the keyboard and the edit control. I need to know where is and what is the control size on the No, but QInputMethod should have the other pieces you need. Ah sorry I didn't know about QInputMethod, I checked it and it seems it doesn't have the information I'm looking for. I need the know the control coordinates (position and size). I'm afraid QInputMethod doesn't has this info. screen, because an edit control can be anywhere and it can have any size on the screen, to be sure the user will see the entire control and its content, the screen must be panned or resized (depending on controls size). To fix this problem I just added and implement a new enum element to Qt::InputMethodQuery : ImRectangle - The rectangle of the widget in screen coordinates.. I chose screen coordinates and not widget coordinates because I think widget coordinates are useless as long as the focused item is an qobject and it can be anything. This is the reason why I've found Qt::ImCursorRectangle value a little bit strange, IMHO Qt::ImCursorRectangle should represents screen coordinates, not widget coordinates. This is wrong. QInputMethod gives that info. The reason this won't work is the same as with the microFocusHint in Qt 4. Often the control doesn't know when it has been moved around on the screen, so it can't give proper feedback to the input method. So use the API in QInputMethod, as it'll also work and give correct answers when the widget or QML item has been moved around inside the window. I understand, but QInputMethod doesn't contains the control position and size :( I also attached a small patch which adds ImRectangle to Qt::InputMethodQuery and the needed implementation in qtbase. Before I go further (add the needed implementation to qdeclarative, and push them to codereview) I'd like to know what are your thoughts on this matter . See above. Cheers, Lars Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QPlatformInputContext needs more informations
I create a small video to make sure you'll understand why I need to know the control position and size. http://www.youtube.com/watch?v=qX157pS64BA BogDan. - Original Message - From: BogDan bog_dan...@yahoo.com To: lars.kn...@nokia.com lars.kn...@nokia.com; development@qt-project.org development@qt-project.org Cc: Sent: Saturday, April 14, 2012 10:26 PM Subject: Re: [Development] QPlatformInputContext needs more informations From: lars.kn...@nokia.com lars.kn...@nokia.com To: bog_dan...@yahoo.com; development@qt-project.org Cc: Sent: Saturday, April 14, 2012 9:40 PM Subject: Re: [Development] QPlatformInputContext needs more informations On 4/14/12 8:29 PM, ext BogDan bog_dan...@yahoo.com wrote: Hello, I checked QPlatformInputContext interface and I think it needs more informations Not sure what you're missing. QPlatformInputContext is only there to implement support for an input method, and has received quite some testing. In order to be sure the user sees the entire control and its content I need to know the control position and its size, otherwise the virtual keyboard may cover the control and its content. QInputMethod (see QGuiApplication::inputMethod()) is the remaining interface that are probably missing right now. and also I found one of them a little bit strange. I've learn that using the following code I can get the needed informations about the focused control: QInputMethodQueryEvent query(queries); QGuiApplication::sendEvent(qGuiApp-focusObject(), query); Sadly query doesn't contain enough information to correctly display the keyboard and the edit control. I need to know where is and what is the control size on the No, but QInputMethod should have the other pieces you need. Ah sorry I didn't know about QInputMethod, I checked it and it seems it doesn't have the information I'm looking for. I need the know the control coordinates (position and size). I'm afraid QInputMethod doesn't has this info. screen, because an edit control can be anywhere and it can have any size on the screen, to be sure the user will see the entire control and its content, the screen must be panned or resized (depending on controls size). To fix this problem I just added and implement a new enum element to Qt::InputMethodQuery : ImRectangle - The rectangle of the widget in screen coordinates.. I chose screen coordinates and not widget coordinates because I think widget coordinates are useless as long as the focused item is an qobject and it can be anything. This is the reason why I've found Qt::ImCursorRectangle value a little bit strange, IMHO Qt::ImCursorRectangle should represents screen coordinates, not widget coordinates. This is wrong. QInputMethod gives that info. The reason this won't work is the same as with the microFocusHint in Qt 4. Often the control doesn't know when it has been moved around on the screen, so it can't give proper feedback to the input method. So use the API in QInputMethod, as it'll also work and give correct answers when the widget or QML item has been moved around inside the window. I understand, but QInputMethod doesn't contains the control position and size :( I also attached a small patch which adds ImRectangle to Qt::InputMethodQuery and the needed implementation in qtbase. Before I go further (add the needed implementation to qdeclarative, and push them to codereview) I'd like to know what are your thoughts on this matter . See above. Cheers, Lars Cheers, BogDan. ___ 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
Re: [Development] Qt 5.0 alpha released
2012/4/12 marius.storm-ol...@nokia.com: ~3.4x more Windows downloads than Linux and Mac OSX combined. Not hard facts, but still interesting. I expect that quite some interested Linux developers will use packages from bleeding-edge repos. Greetings Stefan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing the DLL/shared/static mess
On sábado, 14 de abril de 2012 10.09.56, Uwe Rathmann wrote: On 04/13/2012 06:41 PM, Thiago Macieira wrote: Therefore, *ALL* Qt libraries must be either static or shared. Mixed builds will not be supported Maybe this is a silly question, but what makes a library to be a Qt library ? Or asking the other way round: what is the difference between a module like QtSvg and 3rd party libraries like Qwt or Qxt - beside where they are hosted ? I'd say: 1) where they are installed 2) whether they use qt_module_config.prf or equivalent or a future replacement 3) whether they follow Qt conding conventions -- including headers and macros to be used, like QT_STATIC 4) library and API naming 5) development workflow and other Qt Project rules As far as I understand one of the ideas behind the modularization is to develop modules more independent, what makes these modules sooner or later very similar to 3rd party libraries. All Qt libraries are first-party: they come from the Qt Project. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
