Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
On 7 Nov 2013, at 11:11 PM, Mikkel Krautz wrote: > On Tue, Nov 5, 2013 at 9:57 AM, Saether Jan-Arve > wrote: >> >> Is there any big benefits in having ICNS support on other platforms than OSX? … > So my own use of the icon engine is restricted to OS X. As such, my > own use of the engine could just as well be satisfied by having an > ICNS icon engine in QtMacExtras (or wherever) that wraps NSImage - or > some native code in Mumble to load the icons via native APIs. Still, I don't see a good reason to try to avoid making it available on the other platforms. As I wrote elsewhere in the thread, maybe .icns can even turn out to be a good cross-platform icon solution. And JPEG2000 might be useful in other contexts, too; however that comes at the cost of linking with yet another library. As long as we ensure that when the library is missing, the ability to decode the larger versions of the icons is missing (or the ability to decode the icons at all is missing), and that doesn't cause any other problems at runtime, is there any other reason not to have it available? It's not like we'd have to include the JPEG2000 decoder source with Qt, just have the ability to detect the library and compile the plugin only if it's there, right? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 header diff: QtTest
On Tue, Nov 5, 2013 at 1:36 PM, Thiago Macieira wrote: > On segunda-feira, 4 de novembro de 2013 16:07:32, Thiago Macieira wrote: > > > > Module is fine. > +1 -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.2 snapshot available
Build#134 dmg packages are broken. On Fri, Nov 1, 2013 at 2:05 PM, Heikkinen Jani wrote: > Hi all, > > > > We got qt5.git integrated! It means we have now new content in latest > snapshot in http://download.qt-project.org/snapshots/qt/5.2/5.2.0-beta1/ > > > > Unfortunately MAC packages are missing, hoping we could get those during > today as well.. > > > > Build #123, Qt5 changes after Beta1 release: > > > > * qtactiveqt de09a6d...71fc126 (2): > > > fix doc build path > > > remove pointless #ifndef QT_NO_WIN_ACTIVEQT > > > > * qtandroidextras c1d9cc6...df30d67 (1): > > > Update documentation > > > > * qtbase 690cf42...fe220f3 (133): > > > Dont use NO_DEFAULT_PATH on mac when finding GL headers and libraries. > > > bring the windows configure -qconfig handling in line with the unix one > > > turn makeabs into a proper cleanPath() > > > duplicate less work while handling -qconfig > > > iOS: Add standard paths implementation for iOS > > > Windows: Do not use blend function for GL windows with alpha. > > > iOS: Fix logic for determining whether to exit the root event loop > > > Update the ICC spec on Linux to actually compile stuff > > > xcode generator: resolve QMAKE_INFO_PLIST from source dir > > > Consider multi-monitor setups in QPlatformWindow::initialGeometry(). > > > Fix QSpinBox size calculation problem with empty stylesheets > > > dbuscommon.pri: Fix source file dependency > > > Android: Dont rely on QIcon::isNull() to validate icon data. > > > Android: Fix problem with leaking local refs. > > > remove compiler warning > > > xcb: Compilefix #ifdef glx code > > > xcb: Act on the _NET_ACTIVE_WINDOW event > > > iOS: Build libs (including Qt itself) for both simulator and device > > > Fix the network proxy code for windows to detect properly services > > > Adding CI utilities to Android test script > > > Test that Qt tools can handle as a digit separator. > > > Use Q_UNLIKELY in qCDebug, qCTrace > > > Fix finding cursor position in words with accents > > > Silence the _COMPIZ_DECOR_* warnings on Ubuntu > > > Add QGuiApplication::sync() function > > > iOS: Build simulator libraries with suffix > > > Doc: Fix miscellaneous typos > > > Issue correct warnings with QObject::startTimer() > > > Doc: Remove unofficial Qt Concurrent headers > > > Different native Cocoa menu fixes. > > > Keep web fontdata alive as long as CG uses it > > > Dont support threaded GL on chromium (virtual box GL) > > > QNX: Manage foreign mmrenderer windows > > > Fix msvc project dependencies as specificed by .depends > > > remove qt_windows.h include from qwineventnotifier.h > > > Cocoa: Fix mouse event coordinates transform to window space > > > MacGui tests: Remove references to CGPostMouseEvent > > > qdbusxml2cpp: Fix warnings about writing to closed devices. > > > fix /SAFESEH linker option for VS >= 2010 > > > QLocale: Add auto tests for Poruguese(Brazil) and Greek locales > > > Make the localHostName() copy function return QByteArray > > > Fix QCommonStyle::subControlRect(SC_GroupBoxCheckBox) > > > validate qconfig-*.h against qfeatures.txt > > > dont emit comments to generated qfeatures.h > > > generate qfeatures.h at build time > > > give XMLSTREAM a Name > > > fix "markup" > > > purge references to non-features > > > purge vestiges of dead QT_NO_* defines > > > remove remaining non-concurrent branches from concurrent samples > > > remove dead code > > > Android: handle keyPress event for Key_Back > > > Fix the show/hide logic. > > > Allow the user to specify a theme list. > > > Re-enable NonFullScreenWindows on Android > > > Fail when QT_POINTER_SIZE is not set > > > eglfs: Make backingstore handle unexpected scenarios gracefully > > > Fix compilation with MinGW gcc 64 bit > > > Android: Dont crash if the screen is not yet initialized. > > > Android: Remove unneeded dependency > > > iOS: Set ARCHS in Xcode project for both simulator and device SDKs > > > Doc: Update boost::bind()/std::tr1::bind() to std::bind() > > > Remove unused static function systemtimeToMsecs() > > > QWizard: provoke enum value not handled in switch warnings in > object_name_for_button > > > QWizard: give all buttons an objectName > > > Doc: Added a new Qt Creator \externalpage > > > network: fix multi-phased NTLM authentication > > > Add QMAKE_PKGCONFIG_VERSION variable to allow version overriding > > > remove some vestiges of QFontEngineQPF > > > Fix - psql driver must format qdatetime using iso > > > eglfs: Perform initialization in initialize() instead of the constructor > > > QWindowsKeyMapper: Added some comments about functionality + cleanup > > > Rewrite qmakes exclusive-build feature > > > xcode: Set QMAKE_XCODE_LIBRARY_SUFFIX from default_post > > > CMake: Fix quoting issue with quoted paths in strings. > > > Remove sunken state for Android. > > > Android: Fix the QSlider handler position. > > > QJNI: Dont detach from the thread as long as the thread is alive. > > > Do not byteswap RGBA formats > > > support cleanly querying private modu
Re: [Development] New Qt5.2 snapshot available
Immediately tried the new snapshot. Still a problem during Qt5 deployment on Android (Deploy local Qt-libraries) > Skipping > /Qt5.2.0/5.2.0-beta1/android_armv7/plugins/imageformats/libqsvg.so. > It has unmet dependencies. I cannot display svg files in QML on Android. Unfortunately I am not experienced enough with Android/Qt to decide, whether this is my bug, or a Qt bug. But it works under Windows and Linux, so I am tempted to say: Qt bug. If there is no outcry of disagreement, I'd write a bug report. Guido ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
On Tue, Nov 5, 2013 at 9:57 AM, Saether Jan-Arve wrote: > > Is there any big benefits in having ICNS support on other platforms than OSX? > I can comment a bit about my own use of the plugin. The ICNS icon engine from the code review in my initial mail is used in Mumble (http://mumble.info/) on OS X (and only OS X) to display icons from appliactions on the system (you can add applications to a black/white list for Mumble's overlay feature). That's the extent of its use in Mumble. So my own use of the icon engine is restricted to OS X. As such, my own use of the engine could just as well be satisfied by having an ICNS icon engine in QtMacExtras (or wherever) that wraps NSImage - or some native code in Mumble to load the icons via native APIs. Let's take a step back... Having access to ICNS via QIcon on OS X would be very convenient for Qt applications that need to integrate with native apps somehow. (For example, a Web IDE providing a drop-down of available browsers on the system, or obviously the Mumble use-case mentioned earlier). So the question is, how do we implement such a thing? My proposed implementation is an icon engine that only depends on Qt functionality, and as such can work on any platform that Qt supports. The unfortunate thing about it is that access to icons in the ICNS container that have sizes greater than 128x128, we need a JP2K decoder. (This check happens at runtime. If no jp2k decoder is present, a QIcon with only the smaller sizes available is returned to the caller.) When I wrote the engine a couple of years ago, that seemed to be the best approach, and the "Qt way", if you will. All the pieces were available in Qt (JP2K was available as separate component, but still available). Another implementation strategy could be, as I mentioned previously, a wrapper around the native frameworks. It would only run on OS X, but it would not need the JasPer dependency to access the full range of icons. Back when I did my implementation, there was no QtMacExtras (Qt 4!), so perhaps that's why it didn't seem very Qt-like to wrap the native frameworks for an icon engine. I don't know what the general feeling on that subject is now. It might be the sensible thing to do. >From what I can see, though, the real blocker here is the JasPer dep. I wholeheartedly agree that including JasPer as a dependency just for an icon engine seems like a rather insane requirement. But if there are other users of the JP2K image format, then I don't see why a native wrapper would be preferred for an icon engine over a Qt-native solution that's able to run and be tested across all platforms. (Also, it's worth noting that the JP2K image format is not a hard dependency. For many use cases, including mine, displaying a small icon in a dropdown or list view might be sufficient - and the JP2K image format might not be needed at all. In fact, I'm not even building the JP2K image format myself at present - I only display the small variants of the .icns.) I am obviously also not opposed to just keeping it out of the Qt tree like I've been doing previously. It just seemed like something that would be useful for others to have . :-) (And other seem to agree. The reason I'm upstreaming the code is because Jake Petroules had wanted ICNS support In Qt, and was considering writing an icon engine for it himself. Instead, he found mine and asked me whether I was interested in submitting it upstream...) Mikkel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 header diff: QtWidgets
On 05 Nov 2013, at 19:17, Shaw Andy wrote: > IIRC it wasn’t even compiled into the QtWidgets library, although the > documentation and everything existed, those symbols were never in Qt. Morten > can say 100% at least but that is my understanding and recollection at least. That is correct, the symbols are not in Qt 5.1, confirmed with nm QtWidgets.framework/QtWidgets | grep QMacCocoaViewContainer Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Virtual GUI framework
The "Ideally, this would still capture information about what is being drawn" part is a bit more tricky but is perfectly doable. When it comes to raster painting, pretty much all existing platform plugins direct it into a QImage. That will not be suitable here since you are interested in the QPainter commands that make up the window contents, not the final output image. To do this one would subclass QPaintDevice and QPaintEngine, and make the backing store implementation return the custom paint device. The engine can then output whatever is needed for each drawTextItem, drawPolygon, drawPixmap, etc. call. This approach has been successfully used to turn (widget-based) Qt apps into outputting HTML canvas drawing code for example. Cheers, Laszlo From: development-bounces+laszlo.agocs=digia@qt-project.org [development-bounces+laszlo.agocs=digia@qt-project.org] on behalf of David Boddie [dav...@met.no] Sent: Thursday, November 07, 2013 7:40 PM To: development@qt-project.org Subject: Re: [Development] Virtual GUI framework On Thu Nov 7 15:22:31 CET 2013, Rand McRanderson wrote: > Since Qt is a cross-platform GUI library, would it be possible to > create a fake display system platform that would essentially stub out > all of the display library dependencies. Ideally, this would still > capture information about what is being draw, so that you could > calculate what would be displayed hypothetically (this could be > helpful for things such as generating pdf files based on calculated > layout). At the very least this might provide a way for Qt to run a > console application without bringing in libraries that may not be > available for all environments (the key case here is Linux servers > with display libraries disabled, Windows I'm not sure you can really > disable display libraries, but I know that the Linux use-case comes up > decently with servers). The minimal case can be done with QPA, as Friedemann mentioned in his reply. For my use case, I build minimal Qt libraries with only the features I need and use a dummy screen plugin to keep everything happy. The resulting library appears to run fine on servers without displays. I'll try to put the code up somewhere tomorrow. David ___ 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] Virtual GUI framework
On Thu Nov 7 15:22:31 CET 2013, Rand McRanderson wrote: > Since Qt is a cross-platform GUI library, would it be possible to > create a fake display system platform that would essentially stub out > all of the display library dependencies. Ideally, this would still > capture information about what is being draw, so that you could > calculate what would be displayed hypothetically (this could be > helpful for things such as generating pdf files based on calculated > layout). At the very least this might provide a way for Qt to run a > console application without bringing in libraries that may not be > available for all environments (the key case here is Linux servers > with display libraries disabled, Windows I'm not sure you can really > disable display libraries, but I know that the Linux use-case comes up > decently with servers). The minimal case can be done with QPA, as Friedemann mentioned in his reply. For my use case, I build minimal Qt libraries with only the features I need and use a dummy screen plugin to keep everything happy. The resulting library appears to run fine on servers without displays. I'll try to put the code up somewhere tomorrow. David ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Virtual GUI framework
Hi, there is a QPA platform plugin named "minimal", which roughly does that (run with -platform minimal). It is currently used by tools like qmlplugindump. It dumps out images if the environment variable QT_DEBUG_BACKINGSTORE is set. There also is a plugin named "offscreen", which is intended for testing, but is not currently being developed. Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Virtual GUI framework
I just wanted to throw out an idea. Since Qt is a cross-platform GUI library, would it be possible to create a fake display system platform that would essentially stub out all of the display library dependencies. Ideally, this would still capture information about what is being draw, so that you could calculate what would be displayed hypothetically (this could be helpful for things such as generating pdf files based on calculated layout). At the very least this might provide a way for Qt to run a console application without bringing in libraries that may not be available for all environments (the key case here is Linux servers with display libraries disabled, Windows I'm not sure you can really disable display libraries, but I know that the Linux use-case comes up decently with servers). If I had the time, I would work on this myself, of course if wishes were fishes, I would have a very smelly house seeing as I am not under water. With regards, Rand McRanderson ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats
Yes, it is. 2013/11/7 Rutledge Shawn > > On 6 Nov 2013, at 6:56 PM, Иван Комиссаров wrote: > > > Sorry for an offtop:) > > I have a DDS image format plugin, does someone interested?:) > https://gitorious.org/andromeda/imageformats/source/c637e7d8c3719e0a5cf27a32f8ea425adc09f40c:src/plugins/imageformats/dds > > DirectDraw Surface? http://en.wikipedia.org/wiki/DirectDraw_Surface ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
Detecting a colour space and converting to device colour spaces is around the same amount of developer time as for special casing sRGB. Detecting sRGB among hundrets of ICC profiles is not trivial or fast, while such a detection does not matter in a generic colour managed environment. EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That is a thiny bit of grafic processing, which is needed for handling colour space conversions. The spec is clear to not doing anything about dislpaying sRGB images on a monitor. So this OpenGL extension does not help much with colour management. Short term support for sRGB only would make Qt a pretty limiting choice for many colour managed applications. IMHO, limiting support to RGB in a first development stage is a more sound target. kind regards Kai-Uwe Behrmann Sorvig Morten schrieb: On 06 Nov 2013, at 17:18, Kai-Uwe Behrmann wrote: > What is the point of special casing sRGB? sRGB is special for a couple of reasons: - Most/Many of the images published for web are in the sRGB color space. - OpenGL has support for sRGB textures and frame buffers. Given that progress has halted on this so far it might be good idea to reduce scope to something that can be completed cross-platform in a reasonable amount time. There are arguments against as well, we don’t want to add API that would limit (future) support to sRGB only for example. Morten _ 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
