Re: [Development] Qt 5.1 feature set and freeze date
On 02/13/2013 08:58 PM, André Pönitz wrote: On Wed, Feb 13, 2013 at 10:08:31AM +0100, Friedemann Kleint wrote: Hi, we also plan to start Qt Windows Extras to bring at least the missing image conversion functions ( QTBUG-27103 ) back provided we can find someone to create the repository ;-) . I think the approach of per-platform add-ons for stuff that can be _somehow_ formulated as plattform-independent problem is wrong. QPlatformPixmapHandle with suitable per-platform typedefs or best-effort approximations are much easier to use in user code than platform specific #ifdef chains, or worse library additions to the build system. What use is a QPlatformPixmapHandle having per-platform typedefs (xcb_pixmap_t, HDC, etc) without #ifdefs to manipulate it using native code in the first place? Can you give a platform-independent example use case? :) -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
On 02/14/2013 05:58 PM, Ivan Vizir wrote: Hello, There're no problems with Qt Windows Extras. As I said somewhen in January, I plan to contribute to Qt my code, when it's done. Current results you can see at http://github.com/dtf/QtWindowsExtras . For now features what are ready are: --- progress bar indicator; --- overlay icons; --- thumbnails for tabs; --- thumbbar button panels; --- jump lists (not yet pushed to GitHub). Featurens that are going to be done: --- interactive wrapper around jump lists, maybe using Platform Menu. --- adapting code so it could be used with QtQuick (that means moving from using QWidgets to QWindow and/or splitting code to two versions --- for widgets and for qt quick respectively). I thought I could finish module following Qt module guidelines and then propose it for review, but if you want to see Qt Windows Extras as a part of Qt 5.1, we could move it to Qt Playground and work on it together. 14.02.2013, 09:38, André Somers an...@familiesomers.nl: Op 13-2-2013 18:24, Jake Petroules schreef: QtWindowsExtras is something I plan to contribute to heavily. What things would folks like to see in there besides the image conversion functions? I suggested Windows 7 task bar features a little while back, and I believe that there is a Windows counterpart to QMacPasteboardMime that needs replacing as well. Since the Window frame in Windows is owned by the application, how about the possibility of customising the appearance of the Window frame? Or being able to catch the window events associated with window frames like minimize, maximize clicks so I would write my own cusom window frames. Those taskbar features would be quite welcome. There currently is http://www.strixcode.com/q7goodies/ of course, but that is quite expensive for what you get if you ask me. A way to manipulate the color of the progress-bar in the windows style would also be welcome, though I am not sure that belongs in such an add-on. Windows supports states for a progress bar, like error or paused that result in a red or a yellow bar instead of the default green one. You can also see that in the task bar. Support for extending the native file dialog in windows would be awesome, but perhaps that's out of scope or something that would idealy be available on more platforms. André On Wednesday, February 13, 2013, Knoll Lars wrote: On 2/13/13 10:08 AM, Friedemann Kleint friedemann.kle...@digia.com wrote: Hi, we also plan to start Qt Windows Extras to bring at least the missing image conversion functions ( QTBUG-27103 ) back provided we can find someone to create the repository ;-) . Ok. Sergio can hopefully help with the repo. Do you think you can get it into a decent state for adding to 5.1 by 1st of March? Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org mailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development , ___ Development mailing list Development@qt-project.org mailto: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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
Samuel Rødal wrote: What use is a QPlatformPixmapHandle having per-platform typedefs (xcb_pixmap_t, HDC, etc) without #ifdefs to manipulate it using native code in the first place? Can you give a platform-independent example use case? :) It helps reducing the amount of user code within #ifdef therefore the risk of breaking branches that are not active on a developers machine. It can postpone the need to switch to native code, so helper function merely passing on such handles can be written completely #ifdef free. Structures keeping such handles can be defined more cleanly, similarly class interfaces. Ports to new platforms with new platform specific handles are easier as they touch less code. Etc etc. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
Since the Window frame in Windows is owned by the application, how about the possibility of customising the appearance of the Window frame? Or being able to catch the window events associated with window frames like minimize, maximize clicks so I would write my own cusom window frames. Just forgot to mention that I could implement that, too. :)I've already done that some time ago as an experiment. See http://gitorious.org/qutim/labs/blobs/master/sevenlist/src/toolframewindow.cpp .Screenshot http://storage2.static.itmages.ru/i/11/0403/h_1301857743_4c490c9cd3.png But, Since the Window frame in Windows is owned by the applicationactually, not. Application windows receive all window messages, both for client and non-client areas, but standart-behaviour windows just pass all of them to default window procedure, provided by Windows (user32.dll, I think). The trick, which allows us to put widgets in titlebar, is based on extending client area to title bar and then intercepting mouse clicks to tell Windows when user clicks on window frame and Windows should start dragging or resizing and when it should not.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
On 02/14/2013 10:39 AM, Poenitz Andre wrote: Samuel Rødal wrote: What use is a QPlatformPixmapHandle having per-platform typedefs (xcb_pixmap_t, HDC, etc) without #ifdefs to manipulate it using native code in the first place? Can you give a platform-independent example use case? :) It helps reducing the amount of user code within #ifdef therefore the risk of breaking branches that are not active on a developers machine. There's still the problem that it's not possible to do such typedefs as easily as in Qt 4.x since back then the windowing system was known at compile time. You would have to find a common denominator for all Unix platform plugins for instance, covering KMS, Android, XCB, Wayland, and more. It can postpone the need to switch to native code, so helper function merely passing on such handles can be written completely #ifdef free. Structures keeping such handles can be defined more cleanly, similarly class interfaces. As for passing such handles around you might just as easily be able to pass the QPixmap * or similar around. In some cases there might be multiple handles associated with a resource, such as on X11 in 4.x days, where a QPixmap had both a handle() and a x11PictureHandle(). Ports to new platforms with new platform specific handles are easier as they touch less code. Why does a port to a new platform even need to expose platform specific handles before a need arises? A problem with exposing too much of the internals is that you remove the flexibility of changing the implementation without breaking applications (like when we made QPixmap raster-based on X11). It's in any case better to try to solve in platform-independent ways problems that applications currently have to solve with platform specific code paths. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
Rodal Samuel wrote: On 02/14/2013 10:39 AM, Poenitz Andre wrote: Samuel Rødal wrote: What use is a QPlatformPixmapHandle having per-platform typedefs (xcb_pixmap_t, HDC, etc) without #ifdefs to manipulate it using native code in the first place? Can you give a platform-independent example use case? :) It helps reducing the amount of user code within #ifdef therefore the risk of breaking branches that are not active on a developers machine. There's still the problem that it's not possible to do such typedefs as easily as in Qt 4.x since back then the windowing system was known at compile time. This sounds like a contradiction. Are you saying you can use the native type at compilation time, but not a typedef with a platform-neutral name for it? You would have to find a common denominator for all Unix platform plugins for instance, covering KMS, Android, XCB, Wayland, and more. The needed common denominator for is existence, and on the technical side some would be nice if the handle (not the object) is copyable so it's possible to store and pass around. It can postpone the need to switch to native code, so helper function merely passing on such handles can be written completely #ifdef free. Structures keeping such handles can be defined more cleanly, similarly class interfaces. As for passing such handles around you might just as easily be able to pass the QPixmap * or similar around. In some cases there might be multiple handles associated with a resource, such as on X11 in 4.x days, where a QPixmap had both a handle() and a x11PictureHandle(). Perhaps. Perhaps not. What with cases that really operate on native handles only. And of course a typedef cannot be used if it does not convey the necessary information. All I am saying is that the Qt library side should try hard to make it possible for user code to stay platform-agnostic to the largest extend possible. This might not possible in all cases. Bad luck there, but no need to pro-actively make cases harder where it would be possible. Andre' PS: [...] A problem with exposing too much of theinternals is that you remove the flexibility of changing the implementation without breaking applications (like when we made QPixmap raster-based on X11). This restriction of presumably needing this or that kind of compatibility is completely self-imposed. There is no conceptual difference between saying set QT_I_DO_NOT_NEED_COMPATIBILTY than you get a few extra features. Use it if you want, but you are on your own and There is this module, add it to your build system, etc, Use it if you want, but you are on your own _except_ that the latter imposes more work for the user. Lots of real-world use cases like our very own Qt installers or the binary Qt Creator builds do e.g. not require binary compatibility on the Qt side at all (even source-incompatibility would be tolerable) but would pretty much prefer to not need a platform-independence layer on top (or alongside) Qt proper. But that's mostly a different story. We can discuss that too, but perhaps in a separate thread. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
On 02/14/2013 05:58 AM, André Pönitz wrote: On Wed, Feb 13, 2013 at 10:08:31AM +0100, Friedemann Kleint wrote: Hi, we also plan to start Qt Windows Extras to bring at least the missing image conversion functions ( QTBUG-27103 ) back provided we can find someone to create the repository ;-) . I think the approach of per-platform add-ons for stuff that can be _somehow_ formulated as plattform-independent problem is wrong. It can't be formulated as a platform-independent problem.. The image conversion functions in question for Windows are only applicable to Windows. IIRC there are other image conversion issues that are applicable to OS X but in completely different circumstances. The functions being discussed are for converting BITMAP and ICON handles internal to Windows functions only, in my case, file icon handles for the system's icon for different file types. QPlatformPixmapHandle with suitable per-platform typedefs or best-effort approximations are much easier to use in user code than platform specific #ifdef chains, or worse library additions to the build system. Andre' ___ 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 modules missing mandatory LICENSE files
There is one here, too: https://codereview.qt-project.org/#change,47371 On Thu, Feb 14, 2013 at 11:36 AM, Jason McDonald macadd...@gmail.comwrote: On Fri, Feb 8, 2013 at 5:23 PM, Timo Jyrinki timo.jyri...@gmail.com wrote: 2013/2/8 Thiago Macieira thiago.macie...@intel.com: I'd like to raise awareness that all modules and tarballs should be shipping the LICENSE files required by the (L)GPL licenses. Currently only qtbase is including the files. This is a license terms blocker for distributing the modules. ... I think it's ok. Let's just do it. Agreed. This was just an oversight of the modularization process. It shouldn't be very hard to make an autotest to check for the existence of these files ine ach module, and to verify that the text is in sync with the copies in qtbase. I'll add that my list of rainy day tasks. Thanks. I did so for the core modules except qtwebkit which doesn't need anything more besides the LGPL license text already included. qtjsbackend also has only minimal amount of code under these. https://codereview.qt-project.org/#change,47235 (qtscript) https://codereview.qt-project.org/#change,47236 (qtdeclarative) https://codereview.qt-project.org/#change,47237 (qtsvg) https://codereview.qt-project.org/#change,47238 (qtgraphicaleffects) https://codereview.qt-project.org/#change,47239 (qtmultimedia) https://codereview.qt-project.org/#change,47240 (qttools) https://codereview.qt-project.org/#change,47241 (qtquick1) https://codereview.qt-project.org/#change,47243 (qttranslations) https://codereview.qt-project.org/#change,47244 (qtdoc) https://codereview.qt-project.org/#change,47245 (qtimageformats) https://codereview.qt-project.org/#change,47246 (qtactiveqt) https://codereview.qt-project.org/#change,47247 (qtjsbackend) I've +2'd those changes, except qtactiveqt, which seems to need a copy of the LICENSE.FDL. The modules not part of official releases should also be updated at some point. Do you have time to do that? If so, feel free to add me as a reviewer. -- Jason ___ 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.1 feature set and freeze date
On 14/02/13 04:37, John Layt wrote: On 13 February 2013 15:13, Koehne Kai kai.koe...@digia.com wrote: Which parts of the ICU data are you using (from http://apps.icu-project.org/datacustom/ ) ? I'd really like us to strip down the default ICU libs on windows for 5.1 ... Good question. I think the following under Miscellaneous Data would cover it: supplementalData.res timezoneTypes.res windowsZones.res zone/*.res I'm still trying to decide if / how to even enable the ICU time zones in Windows. I think by default on Windows we'll use the host system even if QT_USE_ICU is set. If QT_NO_SYSTEMLOCALE is set and QT_USE_ICU is also set then I think it's implied to use ICU for time zones, otherwise we'll just fall-back to UTC. However, there are two special cases where we might want to use ICU on Windows anyway: 1) An app may want to always use ICU on Windows due to the poor native Time Zone support on Windows, so we may need a way to allow them to do that. see below. 2) The Windows zone names are currently only supported in the system language, and may not match the Olsen names due to the Windows ID mapping. We may prefer to use the ICU translations instead if available. Back long ago https://bugreports.qt-project.org/browse/QTBUG-71 (feel free to assign that one to yourself!) :) I was working on porting qtopia's timezone class to qt. I added full windows olsen conversion. It was able to use either system on all platforms (at least names) If you want to look at them, I can dig up those files. Yes, the windows tz stuff is limited. At that time, I believe Thiago wanted the tzdatabase to be shipped. Always using ICU on Windows if available would be an option, except ICU is missing support in it's C api for one important feature. On Linux there's a similar dilemma with the TZ file not having translations, but on Mac there is no reason to use ICU as the Mac classes already wrap ICU and are easier to use. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
On Thu, Feb 14, 2013 at 09:42:05PM +1000, Joseph Crowell wrote: On 02/14/2013 05:58 AM, André Pönitz wrote: On Wed, Feb 13, 2013 at 10:08:31AM +0100, Friedemann Kleint wrote: Hi, we also plan to start Qt Windows Extras to bring at least the missing image conversion functions ( QTBUG-27103 ) back provided we can find someone to create the repository ;-) . I think the approach of per-platform add-ons for stuff that can be _somehow_ formulated as plattform-independent problem is wrong. It can't be formulated as a platform-independent problem.. The image conversion functions in question for Windows are only applicable to Windows. I am talking about a _name_ for the handle. Having #ifdef'd code in the backend is obviously not a problem, when the goal is a clean interface and uncluttered user code. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
On 14 February 2013 19:21, Lorn Potter lorn.pot...@gmail.com wrote: Back long ago https://bugreports.qt-project.org/browse/QTBUG-71 (feel free to assign that one to yourself!) :) Will do :-) I was working on porting qtopia's timezone class to qt. I added full windows olsen conversion. It was able to use either system on all platforms (at least names) If you want to look at them, I can dig up those files. Cool, I'll attach your name to my review requests then :-) There's a patch set attached to the bug which I've just had a look at, it's a very different implementation, mine is closely modelled on the OSX and ICU api as it's really just a wrapper around them, but I'll see if there's anything useful. CLDR/ICU actually now provide a file of standard conversions to the Windows ID's that I've copied. I only directly support the Olsen names, but provide api to convert between the two on all platforms. Yes, the windows tz stuff is limited. At that time, I believe Thiago wanted the tzdatabase to be shipped. The problem with shipping and using tz by default is that we have to keep it up-to-date with the frequent changes upstream (less of an issue with our shorter release cycles now), it doesn't provide zone names or translations so we have to which again will be hard to keep up to date, and may create inconsistencies when using the Windows system locale to format times. I think it's better to use the native support by default for general locale stuff, then perhaps provide a factory method to create tz based instances for apps that have more specialised needs. Better news is that from Vista onwards the Windows support has improved, with the ability to query for historical zone data which is a big improvement. My code currently only supports the limited XP api, but I plan to add Vista support soon. Thanks! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWindowsExtras
I was under the impression we were already waiting for step 4 since there have been a decent number of messages on the mailing list regarding this proposal, and everyone seems to know what the module is for and why we need it. Anyways, is this what you want? Request for new playground module for Qt Description: a module for Windows-specific helper functions and classes that were removed from Qt 4; this is the Windows counterpart to the already existing qtmacextras and qtx11extras modules. Playground project name: qtwindowsextras (although the guidelines say the name should not include Qt, qtmacextras and qtx11extras do, and I think a similar exception should be made for the Windows library) Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 14, 2013, at 1:55 PM, Laszlo Papp lp...@kde.org wrote: Please read the rules (and follow in the future): http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt Seems, no maintainer gave a +1 yet. You need to get one first. :-) On Fri, Jan 18, 2013 at 5:47 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: As many OS/WM utility methods were removed from Qt 5, we need to reimplement their functionality in the QtWindowsExtras, QtMacExtras, and QtX11Extras libraries. For example, in QtMacExtras we have a unified toolbar implementation that replaces setUnifiedTitleAndToolbar(), and converter functions to replace QPixmap::toMacCGImageRef(), QPixmap::fromMacCGImageRef() as well as other type conversions, etc. Morten also has some clipboard functionality pending as well as a utility function to set the dock menu to a QMenu, native widgets, and some other stuff. Similarly, QtX11Extras has QX11Info ported from Qt 4 and I imagine may have more functionality in the future.. Windows is no different, and there is a lot that could fit into such a library, including but not limited to: * Replacements for native API converter functions (QPixmap::toWinHBITMAP(), QPixmap::fromWinHBITMAP(), QPixmap::toWinHICON(), QPixmap::fromWinHICON()... I think there was also a QMenu::wceMenu() that gave an HMENU and a similar function for Windows itself (not CE) would be great) * Taskbar functionality for Windows 7/8 (jump lists, overlay icons, progress indicators, thumbnail toolbars, thumbnail tab previews) * DWM interaction (enable/disable composition, extend frame into client area) This is important functionality usable by a large number of Windows apps, clearly evidenced by the former presence of some of this functionality in Qt 4. I have a decent amount of code implementing much of this functionality already, just awaiting contribution... I'm sure there is more I haven't thought of as well. Perhaps some Windows 8 APIs? Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Jan 18, 2013, at 12:16 PM, Laszlo Papp lp...@kde.org wrote: On Thu, Jan 17, 2013 at 8:58 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: As we have a QtMacExtras and QtX11Extras, could someone please create a QtWindowsExtras as well? Could you please elaborate about the use case? Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWindowsExtras
On Thu, Feb 14, 2013 at 7:59 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: I was under the impression we were already waiting for step 4 since there have been a decent number of messages on the mailing list regarding this proposal, and everyone seems to know what the module is for and why we need it. Anyways, is this what you want? I was referring to As we have a QtMacExtras and QtX11Extras, could someone please create a QtWindowsExtras as well? which did not follow the rules, and that you were asking about repository creation when you did not even get a +1 yet. Request for new playground module for Qt Description: a module for Windows-specific helper functions and classes that were removed from Qt 4; this is the Windows counterpart to the already existing qtmacextras and qtx11extras modules. Playground project name: qtwindowsextras (although the guidelines say the name should not include Qt, qtmacextras and qtx11extras do, and I think a similar exception should be made for the Windows library) This is not necessary now, and that is why I wrote: in the future. I hope a maintainer can approve this soon. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWindowsExtras
Ah, I see. I've only recently started contributing to the Qt Project so I'm not familiar with everything yet. Sorry about that! Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 14, 2013, at 3:20 PM, Laszlo Papp lp...@kde.org wrote: On Thu, Feb 14, 2013 at 7:59 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: I was under the impression we were already waiting for step 4 since there have been a decent number of messages on the mailing list regarding this proposal, and everyone seems to know what the module is for and why we need it. Anyways, is this what you want? I was referring to As we have a QtMacExtras and QtX11Extras, could someone please create a QtWindowsExtras as well? which did not follow the rules, and that you were asking about repository creation when you did not even get a +1 yet. Request for new playground module for Qt Description: a module for Windows-specific helper functions and classes that were removed from Qt 4; this is the Windows counterpart to the already existing qtmacextras and qtx11extras modules. Playground project name: qtwindowsextras (although the guidelines say the name should not include Qt, qtmacextras and qtx11extras do, and I think a similar exception should be made for the Windows library) This is not necessary now, and that is why I wrote: in the future. I hope a maintainer can approve this soon. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWindowsExtras
Well, I already gave that my approval some days ago in another thread. I've now created the repository. ssh://codereview.qt-project.org:29418/qt/qtwinextras.git. Cheers, Lars On 2/14/13 9:23 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: Ah, I see. I've only recently started contributing to the Qt Project so I'm not familiar with everything yet. Sorry about that! Jake Petroules Petroules Corporation (www.petroules.com http://www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 14, 2013, at 3:20 PM, Laszlo Papp lp...@kde.org wrote: On Thu, Feb 14, 2013 at 7:59 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: I was under the impression we were already waiting for step 4 since there have been a decent number of messages on the mailing list regarding this proposal, and everyone seems to know what the module is for and why we need it. Anyways, is this what you want? I was referring to As we have a QtMacExtras and QtX11Extras, could someone please create a QtWindowsExtras as well? which did not follow the rules, and that you were asking about repository creation when you did not even get a +1 yet. Request for new playground module for Qt Description: a module for Windows-specific helper functions and classes that were removed from Qt 4; this is the Windows counterpart to the already existing qtmacextras and qtx11extras modules. Playground project name: qtwindowsextras (although the guidelines say the name should not include Qt, qtmacextras and qtx11extras do, and I think a similar exception should be made for the Windows library) This is not necessary now, and that is why I wrote: in the future. I hope a maintainer can approve this soon. Laszlo ___ 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.1 feature set and freeze date
On Thu, Feb 14, 2013 at 7:58 AM, Ivan Vizir define-true-fa...@yandex.comwrote: I thought I could finish module following Qt module guidelines and then propose it for review, but if you want to see Qt Windows Extras as a part of Qt 5.1, we could move it to Qt Playground and work on it together. Lars has just created the repository very quickly, so I think you can push that to Gerrit now: ssh://codereview.qt-project.org:29418/qt/qtwinextras.git . Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWindowsExtras
On Thu, Feb 14, 2013 at 9:16 PM, Knoll Lars lars.kn...@digia.com wrote: Well, I already gave that my approval some days ago in another thread. I've now created the repository. ssh://codereview.qt-project.org:29418/qt/qtwinextras.git. Lars, just double checking for making sure: you meant to create qt/qtwinextras or more like playground as playground/qtmacextras? Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
