Re: [Interest] qtquickcontrols question
On 7 Nov 2013, at 7:53 AM, Damian Ivanov wrote: Thanks Shawn for the clarification. That's rather old, about an earlier iteration of the component set that we are shipping with Qt 5.x (x = 1). Menu is now multi-purpose and therefore has replaced ContextMenu. ok. how can I show the menu then :) ? popup() instead of show() seems to work. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qtquickcontrols question
Great! Super Thanks Shawn. Two last questions for today I promise :) Is it possible that I have them persistent i the main window like ___ |Menu1 |Menu2| | Item1|Item1 | |2 | 2 | |3 | 3 | |4 | 4 | | | | | | | | | | | | | | | | And is Menu and MenuItem stylable? I can see a style property but I can not find any documentation on it. I want also to define the background of the menu. 2013/11/7 Rutledge Shawn shawn.rutle...@digia.com: On 7 Nov 2013, at 7:53 AM, Damian Ivanov wrote: Thanks Shawn for the clarification. That's rather old, about an earlier iteration of the component set that we are shipping with Qt 5.x (x = 1). Menu is now multi-purpose and therefore has replaced ContextMenu. ok. how can I show the menu then :) ? popup() instead of show() seems to work. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qtquickcontrols question
On Nov 7, 2013, at 10:31 AM, Damian Ivanov damianator...@gmail.com wrote: Great! Super Thanks Shawn. Two last questions for today I promise :) Is it possible that I have them persistent i the main window like No, we don’t currently support sticky menus in any way. What’s your use case? I don’t quite understand your diagram. […] And is Menu and MenuItem stylable? I can see a style property but I can not find any documentation on it. I want also to define the background of the menu. This is work in progress, although styling will probably be very minimal for 5.2. Best regards, Dr. Gabriel de Dietrich Senior Software Developer qt.digia.com ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qtquickcontrols question
On 7 Nov 2013, at 10:31 AM, Damian Ivanov wrote: Great! Super Thanks Shawn. Two last questions for today I promise :) Is it possible that I have them persistent i the main window like ___ |Menu1 |Menu2| You can read the docs about menu bars. And is Menu and MenuItem stylable? I can see a style property but I can not find any documentation on it. I want also to define the background of the menu. No, because we try to use native platform menus when possible. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qtquickcontrols question
My idea was that have them expanded on the main window. e.g like on a windows starmenu: left side right side3 Favorites LIST Control Panel - Menu with subitems Recently used LIST Recent documents menu All Program - Menu etc 2013/11/7 Rutledge Shawn shawn.rutle...@digia.com: On 7 Nov 2013, at 10:31 AM, Damian Ivanov wrote: Great! Super Thanks Shawn. Two last questions for today I promise :) Is it possible that I have them persistent i the main window like ___ |Menu1 |Menu2| You can read the docs about menu bars. And is Menu and MenuItem stylable? I can see a style property but I can not find any documentation on it. I want also to define the background of the menu. No, because we try to use native platform menus when possible. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Did QUrlQuery::queryItemValue change its decoding behaviour in 5.2-beta1?
My code just broke when I wanted to use the return value of requestQuery.queryItemValue(redirect_uri); and expected it to be schema://authorized (as in 5.2) but instead got it back as undecoded value. So has the default behaviour changed? I couldn't find anything in the commit history about it. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Quick2 ShaderEffect: source or provider missing when binding textures
Hi all, if I use a ShaderEffect on an image that is loaded asynchronously, I get the error/debug message on the console: ShaderEffect: source or provider missing when binding textures for every frame rendered until the image is completely loaded and the texture is complete. This means our system logs on the target system (embedded linux device) gets flooded whenever we load new images (a photo viewer). Would it be possible to at least limit the number of times this is written (once instead of every frame)? Or could the message be removed completely? It's not useful at all when ShaderEffect is used this way. Best regards, Ola ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Quick2 ShaderEffect: source or provider missing when binding textures
The error message has been quite helpful with tracking down errors in the past,
but I guess we can at least remove it from release builds and limit it a bit :)
Added https://bugreports.qt-project.org/browse/QTBUG-34676 to track this.
But why are you showing ShaderEffects which lack their image data? That is just
wasting GPU resources
ShaderEffect {
property variant source;
visible: typeof source != 'undefined' source.status == Ready
...
}
Should keep it hidden and also remove the warning...
cheers,
Gunnar
Fra: interest-bounces+gunnar.sletta=digia@qt-project.org
[interest-bounces+gunnar.sletta=digia@qt-project.org] på vegne av Ola Røer
Thorsen [o...@silentwings.no]
Sendt: 7. november 2013 16:43
To: interest@qt-project.org
Emne: [Interest] Quick2 ShaderEffect: source or provider missing when binding
textures
Hi all,
if I use a ShaderEffect on an image that is loaded asynchronously, I get the
error/debug message on the console:
ShaderEffect: source or provider missing when binding textures
for every frame rendered until the image is completely loaded and the texture
is complete.
This means our system logs on the target system (embedded linux device) gets
flooded whenever we load new images (a photo viewer). Would it be possible to
at least limit the number of times this is written (once instead of every
frame)? Or could the message be removed completely? It's not useful at all when
ShaderEffect is used this way.
Best regards,
Ola
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
On quinta-feira, 7 de novembro de 2013 08:40:03, William Hallatt wrote: On 7 November 2013 00:38, Thiago Macieira thiago.macie...@intel.com wrote: On quarta-feira, 6 de novembro de 2013 20:12:33, phil.kursawe@gmail.comwrote: I see. I thought Qt renders using the system natively. It could load opengl like it loads SSL support, dynamically. That's a solution we really dislike. Would you mind explaining why? My knowledge of this level of design is virtually non-existent so your input would be hugely appreciated (even if you can just provide me with a few related key words so that I may research the concepts that influenced the design decision myself). Dynamic loading a library requires that we write the code to find the library to be loaded. That's extra code that we need to write, duplicating what the dynamic loader already has. Unlike plugins, libraries can be anywhere in the system. Also, libraries on Unix systems have version numbers attached to the file names and we have to know *which* number to find. For example, for libudev, we need to scan for both libudev.so.0 and libudev.so.1. That means we, the developers, need to guess what the system has. We can't indiscriminately load any number, since we don't know whether libudev.so.2 will retain compatibility. Dynamic loading also requires that we provide fallback code, if the library we request is missing. That's because dynamic loading does not write a requirement into the library's header, which packaging tools know to look for. For the libudev case, we had to ensure that QtSerialPort has fallback in case it can't use udev to find the serial ports. For SSL support, we transferred the to the users: you *have* to check if QSslSocket::supportsSsl() returns true before you start using SSL. Another drawback is that it generates worse code. Unless we start writing assembly by hand, per platform, our finding and calling of functions in loaded libraries is not going to be as efficient as the one generated by the compiler and linker. We've done both solutions that search for all functions at startup (SSL), which in turn means we have a load-time impact searching for functions that may or may not ever be used; and we have solutions that do lazy lookups (D-Bus), but then the application has no graceful way to fail if a function is missing at runtime: it can only crash. There's also an issue of thread-safety: libraries properly linked to get loaded and initialised before the application reaches main(), which means no threads are running. Libraries dynamically loaded may be loaded into the application while multiple threads are running. Some libraries may not like being accessed from multiple threads. And then there's the question of when to unload them. We have to figure out when to unload those libraries by ourselves. I did a lot of work to rewrite the QLibrary static unloader in Qt 5.2 and, trust me, it was not easy. Moreover, we may end up unloading a library from QtCore's global destructors before another global destructor gets run, one that still requires the library. Our best bet would be to actually leak the loaded libraries. Finally, on platforms that make use of prelinking, libraries only loaded through dynamic loading will, at best, not be prelinked. At worst, it will actually have been prelinked to the wrong address and cause a pessimisation. So, in all, I will oppose any use of dynamic loading of libraries. I will accept only when we're forced to, like udev and OpenSSL. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
On quinta-feira, 7 de novembro de 2013 08:34:53, Philipp Kursawe wrote: OpenGL should not be a dependency on a base windowing framework imho. We disagree. We concluded a couple of years ago that OpenGL is the future. Therefore, that's not an argument. What would be an argument would be to be able to support in the same build multiple GL libraries: ANGLE, desktop GL, GL ES, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Did QUrlQuery::queryItemValue change its decoding behaviour in 5.2-beta1?
On quinta-feira, 7 de novembro de 2013 14:02:06, Philipp Kursawe wrote: My code just broke when I wanted to use the return value of requestQuery.queryItemValue(redirect_uri); and expected it to be schema://authorized (as in 5.2) but instead got it back as undecoded value. So has the default behaviour changed? I couldn't find anything in the commit history about it. There was a behaviour change, indeed. I fixed some problems with our understanding of the URI specification. In specific, this paragraph from RFC 3986: URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Qt 5.0 and 5.1 got it wrong. Qt 4 was mostly right. Qt 3 was completely broken. For a full explanation, see https://qt.gitorious.org/qt/qtbase/commit/993bbb4d4be524321575668740ea46c6665d6064 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QtDBus interface design question
Hey there,
I'm struggling with a design issue and cannot find a easy and clean
solution. So I hope you experts could help me out maybe.
I have a daemon application built with C++/Qt. It is a client for a
network and should run in the background. The plan was to connect the UI
via DBus to this daemon in order to make the objects inside the daemon
also available to other external tools/addons. So far nothing special,
this is done in many places in KDE.
The thing is , the object hierarchy is quite deep and complicated. The
best example is the object managing the applications settings, lets call
it CSettingsManager : public QObject. It holds several client QObjects,
representing each a different setting group:
CSettingsManager
|--- CServerSettings
|--- CUserSettings
|--- CLoggingSettings
|--- CGuiSettings
Now we want to expose these hierarchy via DBus. After reading thousands
of DBus applications and their interfaces, we decided to try the
following interface:
/CSettingsManager
/CSettingsManager/CServerSettings
/CSettingsManager/CUserSettings
/CSettingsManager/CLoggingSettings
/CSettingsManager/CGuiSettings
I think up to now its convenient. Instead of passing custom classes via
DBus, I thought its better to register the child objects too and just
point to the object via a QDbusObjectPath argument. So anyone can act
and react on the real object via DBus.
For example I can call CSettingsManager::getServerSettings() {return
QDBusObjectPath /CSettingsManager/CServerSettings } and create a
QDbusAbstractInterface with the returned objectpath and call methods on
the child object. So far so good. I have to mention here, the number of
CServerSettings is dynamic and decided during runtime (based on what is
specificed in the configuration file).
The DBus interface for example could look like:
/CSettingsManager/CServerSettings/Server1
/CSettingsManager/CServerSettings/Server2
...
/CSettingsManager/CServerSettings/ServerN
The issue is now, I want to have a table view displaying the properties
for each Server and let the user edit it.
--
|Server 1 | IP address | port | name |
|Server 2 | IP address | port | name |
|Server 3 | IP address | port | name |
--
I could get a list of all objects and start retrieving their properties,
but lets suppose I have 1000 rows with 4 properties each = 4000 Dbus
calls to build the table. The performance would be horrible.
The only solution I can imagine is to pass the entire table in one DBus
message, but how. I cannot pass the objects itself, because I cannot
transfer an QObject via DBus. Creating plain structs and pass them is an
option but is rather dirty to me.
How are DBus experts handling this? I know our DBus interface is quite
complex and most others are far easier, but there must be a solution.
I'm still a DBus noob, so any hint how to change the design would be
very very welcome.
Thanks very much
Roland
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
On Thu, Nov 07, 2013 at 07:51:16AM +0100, Tomasz Olszak wrote: 2013/11/7 Uwe Rathmann uwe.rathm...@tigertal.de On Wed, 06 Nov 2013 08:03:47 -0800, Thiago Macieira wrote: Shouldn't they be in Qt5OpenGL.dll? No, they are where they were supposed to be. That's by design. With some nasty consequences for us users: Our applications run on several pieces of embedded hardware, where one of them had been designed 7 years ago with a graphic chip, where only OpenGL ES 1.1 is supported. This board needs to be supported and updated for many, many years - no way to exchange it by something more recent. Even if we don't need OpenGL ( using widgets only ) we are stuck with Qt 4 forever, because Qt5 has this unnecessary OpenGL dependency. So far this had been no big problem - Qt4 is pretty fine - and there are some backports of new Qt5 features ( by the way: it would be nice to add the json classes to Qt 4.9 ), but sooner or later this will become an issue. AFAIK you can build Qt5 with no-opengl switch and you should be able to run QtWidgets applications without having libQt5OpenGl dependency in libQt5Gui. The problem is that this won't scale. One cannot provide custom builds of Qt for each realistic user configuration, let alone proactively package such stuff in large quantities. Requiring the users to run one, or one out of a few blessed configurations is likewise infeasible. Runtime detection of capabilities and selecting features _then_ is the only viable appraoch. Andre' ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt 4.8.5 and VS2012
Can somebody point me to a list of the corrections that need to be made to the 4.8.5 source so it compiles with VS2012? The WebKit HashSet.h header has issues, and I recall running into this in the past when I built 4.8.4 with VS2012, but I don't recall everything I had to modify to get it to compile. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Did QUrlQuery::queryItemValue change its decoding behaviour in 5.2-beta1?
Thanks, I found the commit before, but missed that it also changed decoding of :// On Thu, Nov 7, 2013 at 6:50 PM, Thiago Macieira thiago.macie...@intel.comwrote: On quinta-feira, 7 de novembro de 2013 14:02:06, Philipp Kursawe wrote: My code just broke when I wanted to use the return value of requestQuery.queryItemValue(redirect_uri); and expected it to be schema://authorized (as in 5.2) but instead got it back as undecoded value. So has the default behaviour changed? I couldn't find anything in the commit history about it. There was a behaviour change, indeed. I fixed some problems with our understanding of the URI specification. In specific, this paragraph from RFC 3986: URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Qt 5.0 and 5.1 got it wrong. Qt 4 was mostly right. Qt 3 was completely broken. For a full explanation, see https://qt.gitorious.org/qt/qtbase/commit/993bbb4d4be524321575668740ea46c6665d6064 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] ID based .ui translations
So we hacked out version of lupdate to compile id based .ts files from ui files but thats only the first step. Now the ui compiler also has to be changed to generate code for retranslateUI that uses qtTrid instead of QApplication::translate That is a huge amount of work. Why oh why was id based UI translation never considered to be important? And since we cannot mix id based and message based translations we are stuck now. Any ideas? How are other pro-projects handling this issue? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 4.8.5 and VS2012
Nevermind. I think this is what I used last time, and it appears to be working for 4.8.5 as well: http://stackoverflow.com/questions/12113400/compiling-qt-4-8-x-for-visual-studio-2012 On 11/7/2013 12:59 PM, Bob Hood wrote: Can somebody point me to a list of the corrections that need to be made to the 4.8.5 source so it compiles with VS2012? The WebKit HashSet.h header has issues, and I recall running into this in the past when I built 4.8.4 with VS2012, but I don't recall everything I had to modify to get it to compile. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
On 7 November 2013 19:42, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 7 de novembro de 2013 08:40:03, William Hallatt wrote: On 7 November 2013 00:38, Thiago Macieira thiago.macie...@intel.com wrote: On quarta-feira, 6 de novembro de 2013 20:12:33, phil.kursawe@gmail.comwrote: I see. I thought Qt renders using the system natively. It could load opengl like it loads SSL support, dynamically. That's a solution we really dislike. Would you mind explaining why? My knowledge of this level of design is virtually non-existent so your input would be hugely appreciated (even if you can just provide me with a few related key words so that I may research the concepts that influenced the design decision myself). Dynamic loading a library requires that we write the code to find the library to be loaded. That's extra code that we need to write, duplicating what the dynamic loader already has. Unlike plugins, libraries can be anywhere in the system. Also, libraries on Unix systems have version numbers attached to the file names and we have to know *which* number to find. For example, for libudev, we need to scan for both libudev.so.0 and libudev.so.1. That means we, the developers, need to guess what the system has. We can't indiscriminately load any number, since we don't know whether libudev.so.2 will retain compatibility. Dynamic loading also requires that we provide fallback code, if the library we request is missing. That's because dynamic loading does not write a requirement into the library's header, which packaging tools know to look for. For the libudev case, we had to ensure that QtSerialPort has fallback in case it can't use udev to find the serial ports. For SSL support, we transferred the to the users: you *have* to check if QSslSocket::supportsSsl() returns true before you start using SSL. Another drawback is that it generates worse code. Unless we start writing assembly by hand, per platform, our finding and calling of functions in loaded libraries is not going to be as efficient as the one generated by the compiler and linker. We've done both solutions that search for all functions at startup (SSL), which in turn means we have a load-time impact searching for functions that may or may not ever be used; and we have solutions that do lazy lookups (D-Bus), but then the application has no graceful way to fail if a function is missing at runtime: it can only crash. There's also an issue of thread-safety: libraries properly linked to get loaded and initialised before the application reaches main(), which means no threads are running. Libraries dynamically loaded may be loaded into the application while multiple threads are running. Some libraries may not like being accessed from multiple threads. And then there's the question of when to unload them. We have to figure out when to unload those libraries by ourselves. I did a lot of work to rewrite the QLibrary static unloader in Qt 5.2 and, trust me, it was not easy. Moreover, we may end up unloading a library from QtCore's global destructors before another global destructor gets run, one that still requires the library. Our best bet would be to actually leak the loaded libraries. Finally, on platforms that make use of prelinking, libraries only loaded through dynamic loading will, at best, not be prelinked. At worst, it will actually have been prelinked to the wrong address and cause a pessimisation. So, in all, I will oppose any use of dynamic loading of libraries. I will accept only when we're forced to, like udev and OpenSSL. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest Hi Thiago, Thank you very much for taking the time out to write that up. I appreciate it immensely! Have a great weekend, William. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] How can I make a QSplitterHandler wider then the others?
I tried to subclass it and setMinimumWidth(12). That make it wieder but now it seems to reach inthe the next widget of the splitter. Same when I set the min-width using CSS. So how can I force Qt to correctly honor different sized QSplitterHandles? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtDBus interface design question
The only solution I can imagine is to pass the entire table in one DBus message, but how. I cannot pass the objects itself, because I cannot How about returning an array of strings in the method call? Both are valid DBus types and you could probably concatenate the various properties using a delimiter and tokenize them at the receiver end. I'm no dbus expert and have mostly used QtDbus to communicate with existing services, like NetworkManager etc, so CMIIW! :) HTH, -mandeep transfer an QObject via DBus. Creating plain structs and pass them is an option but is rather dirty to me. How are DBus experts handling this? I know our DBus interface is quite complex and most others are far easier, but there must be a solution. I'm still a DBus noob, so any hint how to change the design would be very very welcome. Thanks very much Roland ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
