Re: [Development] What kind of airplane we want to build?
On Wed, Jan 20, 2016 at 3:25 PM, Bo Thorsen wrote: > > Why do you think people hate C++? I love C++ but I hate the string > classes. I like some part of the std containers, I don't like their API. > > Spot on. People run scared from Boost-like C++. That kind of code is very performant but it's neither easy to write, understand or, in many cases, figure out. On the other hand, Qt is usually love at first sight. Makes C++ look doable. Even easy. Sure, some people who have spent a lot of time writing C++ move on from Qt and like Boost-like code the better but that kind of code, those APIs, are to blame for the very bad opinion many people have on C++. They hurt C++ jobs. Replacing QThread with std::thread? Please don't. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FOSDEM Desktops DevRoom 2016: Call for Participation
Hello, Just a quick mail to remind everybody we will accept talk proposals for the Desktops DevRoom at FOSDEM 2016 only until this Saturday. Hurry up! On Mon, Nov 2, 2015 at 8:44 PM, Pau Garcia i Quiles wrote: > > FOSDEM Desktops DevRoom 2016 Call for Participation > > FOSDEM is one of the largest gatherings of Free Software contributors in > the world and happens each February in Brussels (Belgium, Europe). One of > the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop > DevRoom”), which will host Desktop-related talks. > > We are now inviting proposals for talks about Free/Libre/Open-source > Software on the topics of Desktop development, Desktop applications and > interoperability amongst Desktop Environments. This is a unique opportunity > to show novel ideas and developments to a wide technical audience. > > Topics accepted include, but are not limited to: > >- Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor, MATE, >Cinnamon, ReactOS, etc > >- Closed desktops: Windows, Mac OS X, CDE, MorphOS, etc (when talking >about a FLOSS topic) > >- Software development for the desktop > >- Development tools > >- Applications that enhance desktops > >- General desktop matters > >- Cross-platform software development > >- Web > > > Talks can be very specific, such as the advantages/disadvantages of > development with Qt on Wayland over X11/Mir; or as general as predictions > for the fusion of Desktop and web in 5 years time. Topics that are of > interest to the users and developers of all desktop environments are > especially welcome. The FOSDEM 2015 schedule[1] might give you some > inspiration. > > > Submissions > > Please include the following information when submitting a proposal: > >- Your name > >- The title of your talk (please be descriptive, as titles will be >listed with around 400 from other projects) > >- Short abstract of one or two paragraphs > >- Short bio (with photo) > >- Requested time: from 15 to 45 minutes. Normal duration is 30 >minutes. Longer duration requests must be properly justified. You may be >assigned LESS time than you request. > > > How to submit > > All submissions are made in the Pentabarf event planning tool: > > https://penta.fosdem.org/submission/FOSDEM16 > > When submitting your talk, make sure to select the "Desktops" devroom as > the "Track". Otherwise your talk will not be even considered for any > devroom. > > If you already have a Pentabarf account from a previous year, even if your > talk was not accepted, please reuse it. Create an account if, and only if, > you don’t have one from a previous year. If you have any issues with > Pentabarf, please contact pgquiles at elpauer dot org. > > > Deadline > > The deadline for submissions is December 6th 2015. > > FOSDEM will be held on the weekend of January 30th and 31st 2015 and the > Desktops DevRoom will take place on Sunday, January 31st 2015. > > We will contact every submitter with a "yes" or "no" before December 18th > 2015. > > > Recording permission > > The talks in the Desktops devroom will be audio and video recorded, and > possibly streamed live too. > > By submitting a proposal you consent to be recorded and agree to license > the content of your talk under a Creative Commons (CC-BY) license. > > If you want us to stop the recording in the Q & A part (should you have > one), please tell us. We can do that but only for the Q & A part. > > > More information > > The official communication channel for the Desktops DevRoom is its mailing > list desktops-devr...@lists.fosdem.org. > > Use this page to manage your subscription: > > https://lists.fosdem.org/listinfo/desktops-devroom > > > Organization > > The Desktops DevRoom 2016 is managed by a team representing the most > notable open desktops: > > >- Pau Garcia i Quiles, KDE > >- Christophe Fergeau, Gnome > >- Michael Zanetti, Unity > >- Philippe Caseiro, Enlightenment > >- Jérome Leclanche, Razor > > > If you want to join the team, please contact pgquiles at elpauer dot org > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FOSDEM Desktops DevRoom 2016: Call for Participation
FOSDEM Desktops DevRoom 2016 Call for Participation FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium, Europe). One of the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop DevRoom”), which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: - Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor, MATE, Cinnamon, ReactOS, etc - Closed desktops: Windows, Mac OS X, CDE, MorphOS, etc (when talking about a FLOSS topic) - Software development for the desktop - Development tools - Applications that enhance desktops - General desktop matters - Cross-platform software development - Web Talks can be very specific, such as the advantages/disadvantages of development with Qt on Wayland over X11/Mir; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2015 schedule[1] might give you some inspiration. Submissions Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 400 from other projects) - Short abstract of one or two paragraphs - Short bio (with photo) - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request. How to submit All submissions are made in the Pentabarf event planning tool: https://penta.fosdem.org/submission/FOSDEM16 When submitting your talk, make sure to select the "Desktops" devroom as the "Track". Otherwise your talk will not be even considered for any devroom. If you already have a Pentabarf account from a previous year, even if your talk was not accepted, please reuse it. Create an account if, and only if, you don’t have one from a previous year. If you have any issues with Pentabarf, please contact pgquiles at elpauer dot org. Deadline The deadline for submissions is December 6th 2015. FOSDEM will be held on the weekend of January 30th and 31st 2015 and the Desktops DevRoom will take place on Sunday, January 31st 2015. We will contact every submitter with a "yes" or "no" before December 18th 2015. Recording permission The talks in the Desktops devroom will be audio and video recorded, and possibly streamed live too. By submitting a proposal you consent to be recorded and agree to license the content of your talk under a Creative Commons (CC-BY) license. If you want us to stop the recording in the Q & A part (should you have one), please tell us. We can do that but only for the Q & A part. More information The official communication channel for the Desktops DevRoom is its mailing list desktops-devr...@lists.fosdem.org. Use this page to manage your subscription: https://lists.fosdem.org/listinfo/desktops-devroom Organization The Desktops DevRoom 2016 is managed by a team representing the most notable open desktops: - Pau Garcia i Quiles, KDE - Christophe Fergeau, Gnome - Michael Zanetti, Unity - Philippe Caseiro, Enlightenment - Jérome Leclanche, Razor If you want to join the team, please contact pgquiles at elpauer dot org -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Tue, Jul 21, 2015 at 10:26 PM, Ansel Sermersheim wrote: As to your question about relicensing, can you please elaborate on what > this is referring to? As long as Qt is covered by the current license, > we can not relicense CopperSpice since we are bound by the terms of the > licenses under which we forked the code. > > I think the actual question(s) were: - Are you and Barbara developing CopperSpice full-time, part-time or just on your spare time? - How do you sustain development of CopperSpice? Support & services to Qt4 delopers? You use it only for your own (paid-for) projects? Venture Capital? No funding at all, just hobby? And I would repeat the question Milian asked: why did you fork Qt4 instead of Qt5? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of Qt Quick 1 in Qt 5
On Sat, May 9, 2015 at 3:47 PM, Thiago Macieira wrote:Why do people read "remove" as in "you need to stop using it now"? > > When we're saying "remove", we meant only that it's no longer included in > the > convenience big tarball and in the binary releases. If you still need it, > there's still the source version of the last release, which works > perfectly. > > There is no broken backwards compatibility promise and there are no reasons > yet to go for Qt 6. > How do you know Qt WebKit from Qt 5.5 is going to work with QtCore from e. g. Qt 5.7? IIUC, not being part of the release means it will not be tested or even compiled/autotested by CI -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of Qt Quick 1 in Qt 5
On Sat, May 9, 2015 at 6:34 AM, Turunen Tuukka < tuukka.turu...@theqtcompany.com> wrote: The thing is that since the beginning of Qt 5 we have been constantly > adding things and not removing the parts that are less used (and > deprecated). Even though one might think it takes very little effort to > keep things around, the aggregate effort is significant. > > There are many great new things and improvements we could bring into Qt, > but now a lot of time goes into keeping old parts afloat. If someone needs > to use an old module, why not do it with a Qt version that supports it? > Same goes to platforms and compilers - it is not feasible to properly > support all upcoming and old versions. > > Break backwards compatibility promise, remove hard-to-maintain modules which have an alternative, introduce some fundamental code changes... It seems to me Qt 6 is perfectly justified :-? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android Serial Port USB device
On Sun, Jan 18, 2015 at 9:42 PM, Thiago Macieira wrote: > I'd like to hear someone from Enterprise Qt here too. My opinion is that we > should accept the feature but make it an optional build-time dependency or > an > optional run-time dependency. That way, Enterprise Qt does not need a > licence > change and customers who will not install usb-serial-for-android will need > to > root their devices. > > I have been looking for alternatives and it seems this one would be acceptable even for Enterprise customers: https://github.com/ksksue/FTDriver Apache 2.0 license, supports FTDI (most common chip, proprietary protocol) and CDC-ACM (most common alternative to FTDI, standard). No external dependency. Lighweight (1 file, ~1,000 lines of code). Problem: it's unmaintained, since author moved to another library: https://github.com/ksksue/PhysicaloidLibrary Physicaloid does a lot more stuff, which we probably don't need. My proposal: adopt FTDriver, include it as part of Qt and implement Qt Serial Port on Android. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Android Serial Port USB device
Hello, Mike Gonza worked on a wrapper of usb-serial-for-android and provided patches a while ago but they were not accepted because usb-serial-for-android is LGPLv2.1 only: https://codereview.qt-project.org/#/c/83480/ https://codereview.qt-project.org/#/c/84338/ https://github.com/mik3y/usb-serial-for-android As a consequence, Qt has no support for non-rooted serial port on Android. AFAIK there is no alternative to usb-serial-for-android (other than reinventing it from scratch with a more acceptable license). Or is there? Is there any chance Mike's patches are at least merged as an optional feature which is not compiled by default? Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FOSDEM 2015
Guys, Less than 10 days for the deadline for the Desktops DevRoom at FOSDEM 2015 and not a single Qt-related talk submited. I cannot really believe nobody has anything to say! Call for Talks: http://www.elpauer.org/2014/10/fosdem-2015-desktops-devroom-call-for-talks/ -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Explicit linking vs dlopen/dlsym
On Wed, Nov 19, 2014 at 5:59 PM, Thiago Macieira wrote: > On Wednesday 19 November 2014 11:38:41 Pau Garcia i Quiles wrote: > > Today I installed an snapshot of Qt 5.4.0 for Linux x86 on my Kubuntu > 14.04 > > and found a problem: it links to libudev.so.0, while Ubuntu 14.04 > provides > > libudev.so.1. > > What library is that? I thought we did dlopen libudev... > libQt5SerialPort pgquiles@macbookpro30:~/Qt5.4.0/5.4/gcc/lib$ objdump -x libQt5SerialPort.so libQt5SerialPort.so: file format elf32-i386 libQt5SerialPort.so architecture: i386, flags 0x0150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x4780 [...] Dynamic Section: NEEDED libQt5Core.so.5 NEEDED libpthread.so.0 *NEEDED libudev.so.0* NEEDED libstdc++.so.6 NEEDED libc.so.6 SONAME libQt5SerialPort.so.5 RPATH$ORIGIN INIT 0x3efc FINI 0x00013958 [...] In other libraries, ICU, GStreamer, PulseAudio,NSPR, FreeType, zlib and other are also explicitly linked to. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Explicit linking vs dlopen/dlsym
Hello, Today I installed an snapshot of Qt 5.4.0 for Linux x86 on my Kubuntu 14.04 and found a problem: it links to libudev.so.0, while Ubuntu 14.04 provides libudev.so.1. I was wondering if it would be a good idea for Qt to move from explicit linking to dlopen/dlsym. That would help supporting different versions of a certain library, and support different codepaths at runtime depending on which one was found. Eg. libudev.so.0 or libudev.so.1, libstreamer-0.10.so or libgstreamer-1.0.so, etc Incidentally, MESA is doing that for udev already: http://lists.freedesktop.org/archives/mesa-dev/2014-January/052548.html And the proprietary database Intersystems Caché has been doing that for decades to ease the burden of support for many different platforms (these guys supported VMS until not too long!). They do this for EVERY third party dependency: libssh2, Xalan, Xerces-C, libodbc, Cenera (Samba), ICU, etc Yes, code is a bit more complex, but support for newer and older platforms is also easier because there is no need to recompile. Also, some customers do not want "custom" versions of third-party libraries but only the "official" one. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The dark side of QtMultimedia
On Mon, Nov 17, 2014 at 9:43 AM, André Somers wrote: IMHO, it is not up for framework developers to decide that user won't > need this kind of capability. It does need to be there, so application > developers can be creative in how they use video playback. > > Indeed. In fact, I am about to start development of a cross-platform application (Windows, Linux, iOS, Android, Windows Phone). Showing a preview video in a quarter-of-a-screen window is one of the fundamental requirements of the app due to its nature. I had considered Qt and Xamarin and bugs like this make me think if I should change the team I selected and go for Xamarin instead :-/ -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Encoding video via QtMultimedia?
Hello, I would use ffmpeg instead of libav (ffmpeg merges every commit from libav + their own) But QtGStreamer is probably a better solution and has fewer problems with licenses. ffmpeg and libav are GPLv2 if you enable some compilation flags, GStreamer is always LGPL. If even LGPL is a problem, then MediaStreamer2 from LinPhone would be my preferred choice. It is available under GPLv2 and a commercial license: http://www.linphone.org/technical-corner/mediastreamer2/downloads http://www.belledonne-communications.com/mediastremer2.html On Mon, Nov 17, 2014 at 1:57 PM, Lopes Yoann wrote: > There is no API in Qt Multimedia to do this. As mentioned, QMediaRecorder > can only be used with a QCamera. > > In a similar fashion to QAudioDecoder, we could have APIs like > QAudioEncoder, QVideoDecoder and QVideoEncoder. Though, considering the > amount of work there is to improve existing APIs, I don’t think new APIs > like these ones will be added any time soon. > > I’d recommend to use libav (https://libav.org) to do this. > > — > Yoann > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FOSDEM 2015 Desktops DevRoom Call for Talks
Hello, --8<--- FOSDEM <http://www.fosdem.org> is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop DevRoom”), which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, LXQt, Windows, Mac OS X, software development for the desktop, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as the advantages/disadvantages of development with Qt on Wayland over X11/Mir; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2014 schedule <https://archive.fosdem.org/2014/schedule/track/desktops/> might give you some inspiration. Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) - Short abstract of one or two paragraphs - Short bio (with photo) - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request. The deadline for submissions is December 7th 2014. FOSDEM will be held on the weekend of January 31st-February 1st 2015 and the Desktops DevRoom will take place on Sunday, February 1st 2015. Please use the following website to submit your proposals: https://penta.fosdem.org/submission/FOSDEM15 (you do not need to create a new Pentabarf account if you already have one from past years). You can also join the devroom’s mailing list, which is the official communication channel for the DevRoom: desktops-devr...@lists.fosdem.org <https://lists.fosdem.org/private/desktops-devroom/> (subscription page <https://lists.fosdem.org/listinfo/desktops-devroom> for the mailing list) – The Desktops DevRoom 2015 Organization Team --8<--- -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.4 snapshot available
On Mon, Oct 27, 2014 at 1:07 PM, Oswald Buddenhagen < oswald.buddenha...@theqtcompany.com> wrote: > it is conceivable to make the init-repo script more capable (also, fex., > checking out branches in all subrepos). i have some ideas, but no code. > Mmm I tried $ git checkout --brainch ideas -- I3f0739b279123e0a049d52da455f40ad1a20b4ab but for some reason it failed :-P -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt5.4 snapshot available
with perl >= 5.18 > > * qtquick1 af503cb...61df130 (1): > > Merge remote-tracking branch origin/5.3 into 5.4 > > * qtquickcontrols 045c1c9...e76f811 (17): > > BasicButton: handle mnemonics > > Android style: hide mnemonics > > AbstractCheckable: handle mnemonic > > Base style: stylize mnemonics > > Menu: fix key navigation on Windows > > dialogs: let QtQuick.Dialogs depend on QtQuick.Dialogs.Private > > Dialogs: all QML dialogs must have the Qt::Dialog window type > > Merge "Merge remote-tracking branch origin/5.3 into 5.4" into > refs/staging/5.4 > > Fix popup menu position for QQuickWidget > > iOS style: import private to get ToolButtonStyle > > MenuStyle: fix a typo that prevented mnemonics showing up > > Revert "QQuickPopupWindow: dont create 1x1 windows" > > qquickrangemodel: dont emit signals before component is completed > > Custom filled dialog example: handle back button to close > > Dialogs: added private maximumDimension property for initial size > > Dialogs: if implicitHeight becomes smaller, ensure the minimum does too > > Android: check the minimum required SDK version (11) > > * qtrepotools 2c2b3aa...acde1d3 (1): > > Fix submodule merge script > > * qtscript db84d17...9871b41 (1): > > Merge remote-tracking branch origin/5.3 into 5.4 > > * qtserialport 14fe584...3bb682e (1): > > Merge remote-tracking branch origin/5.3 into 5.4 > > * qtsvg 2f0fabd...9f1c31c (1): > > Merge remote-tracking branch origin/5.3 into 5.4 > > * qttools 8f03d0b...dff9a4c (5): > > Assistant: Make "Bookmarks Menu" the default bookmarks folder > > Merge "Merge remote-tracking branch origin/5.3 into 5.4" into > refs/staging/5.4 > > uic: dont use QStringLiteral in comparisons > > generate_ui: adapt to upstream change in qtbase > > Assistant: Fix index updating on startup in the remote control mode > > * qtwayland 5558b42...c3d2a7b (2): > > Fix -no-opengl builds > > Be compatible with older compositors > > * qtwebchannel e8c280a...d9845c2 (1): > > Added some more examples > > * qtwebengine d44b90f...14fcf0d (12): > > Disable geolocation > > Look for the NINJA_PATH env var and prefer that over the bootstrapped > ninja > > Allow building on boot2qt. > > Add plugins.qmltypes for WebEngine API > > Include QMAKE_CC when extracting C compiler flags > > Fix ARM NEON detection for -mfpu=neon-vfpv4 > > Fix up coding style in GetNavigationErrorStrings > > Add setting ErrorPageEnabled > > Disable Desktop Notifications. > > Use the shared waitForSignal method in QQuickWebEngineViewGraphics test > > Import QQuickWebEngineView API test > > Fix localization on OS X > > * qtwebkit 2b23baa...7778f88 (16): > > Remove QtScript includes > > Fix Qt 5.3 backward compatible build > > Blacklist libkpartsplugin > > StylePendingImage needs to correctly manage the CSSValue pointer lifetime > > Fix android compile. > > Fix LLInt vector offsets on Windows 64 > > Crash in WebCore::BidiResolver WebCore::BidiRun>::createBidiRunsForLine > > Merge "Merge remote-tracking branch origin/5.3 into 5.4" into > refs/staging/5.4 > > Crash in HTMLMediaElement::contextDestroyed > > Get rid of old harmattan workaround hurting Qt on ARM > > Check for ICU at configure time the same way we add it later > > Do not use JIT on big endian architectures > > Fix CLoop on big-endian machines > > Fix crash when a network-request is aborted while forwarding data > > Load flags used by Qt modules when compile testing for a module > > Do not let TexureMapper create backing stores that are too large > > * qtwebsockets f617556...0854eda (2): > > Also forward the bytesWritten(qint64) signal > > Update the plugins.qmltypes meta data. > > Best regards, > Jani Heikkinen > Release Manager | The Qt Company > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, > Finland > Email: jani.heikki...@theqtcompany.com | Mobile: + 358 50 48 73 735 > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, > @Qtproject Facebook: www.facebook.com/qt > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Bluetooth iOS
Hello, Actually I am mostly interested in Serial Port Profile over Bluetooth. Maybe this should be implemented as part of Qt Serial Port insted of Qt Bluetooth? On Fri, Mar 14, 2014 at 10:50 AM, Blasche Alexander < alexander.blas...@digia.com> wrote: > Hi, > > One more update on this topic. After some investigations yesterday it > turns out that iOS doesn't actually have a classic Bluetooth API. There is > a Bluetooth Low Energy API since iOS 6 but this would require the Bluetooth > Low Energy (BtLE) feature first. While BtLE is currently in the works, > there is no firm target release yet (ready when it's ready). > > The only other Bluetooth related API I could find was related to the > External Accessory Framework. An accessory may happen to be a Bluetooth > device but that's not really the same. > > Of course MacOSX and the windows flavours have some Bluetooth > opportunities. > > -- > > Alex > -- > *From:* > development-bounces+alexander.blasche=digia@qt-project.org[development-bounces+alexander.blasche= > digia@qt-project.org] on behalf of Blasche Alexander [ > alexander.blas...@digia.com] > *Sent:* Monday, March 10, 2014 10:01 > *To:* development@qt-project.org > *Subject:* Re: [Development] Qt Bluetooth iOS > > Hi, > > Sorry to disappoint, but to the best of my knowledge there is no ongoing > port for iOS at this point in time. > > -- > > Alex > -- > *From:* > development-bounces+alexander.blasche=digia@qt-project.org[development-bounces+alexander.blasche= > digia@qt-project.org] on behalf of Pau Garcia i Quiles [ > pgqui...@elpauer.org] > *Sent:* Sunday, March 09, 2014 01:10 > *To:* development@qt-project.org > *Subject:* [Development] Qt Bluetooth iOS > > Hello, > > Is anyone working on an iOS backend of Qt Bluetooth? I could use it but > I cannot find any information at all. > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Bluetooth iOS
Hello, Is anyone working on an iOS backend of Qt Bluetooth? I could use it but I cannot find any information at all. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Embedded (Linux) specific features
On Sat, Feb 15, 2014 at 9:05 PM, Laszlo Papp wrote: I wrote some C++ classes 1.5-2 years ago for some of the following features: > > * GPIO > * Eeprom > * Power management > * LED > * Hardware Monitoring > * DMA > * Real Time Clock > * I2C > * SPI > * etc. > > Out of curiosity: is there anyone working on such classes in Qt? Would > such features be welcome in Qt in general? If not, why not, if yes, > where would they fit into the overall architecture? > > It is not necessarily embedded Linux specific, but at least embedded. > They might be useful on QNX, etc, but I cannot be sure. I would have a > hard time suggesting place like QtEmbeddedExtras or so. I have no > clear idea at this point. > > These are generic features, and I only thought about bringing this > topic up because I see customers and hobbyists reimplementing the > same, e.g. for the raspberry pi. > > Apologies if there are no interest at all for this. > > I'm interested in almost all of the above, (and CAN bus communication) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] i.MX6 zero copy video playback
Hello, Great! On Wed, Feb 12, 2014 at 10:43 AM, Thomas Senyk wrote: > Hi, > > I finally got around to polish and upstream zero copy video playback for > the > i.MX6. > > The change: > https://codereview.qt-project.org/#change,76764 > > A video showcasing the functionality: > http://www.youtube.com/watch?v=pmxsWGhrrBQ > > > Greets > Thomas > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Consoles
On Fri, Jan 17, 2014 at 9:07 PM, Joshua Kolden wrote: I’d like to add my vote and reiterate this as a valid target for Qt. > Consoles are becoming media centers, and a new discreet type of ‘device’ > just like a tablet or phone. Although the scope of functionality of these > devices is still being worked out I think we can expect a pretty clear set > of non game uses. In addition to non game functions like media playing we > already see, I’m sure we can expect features like Home & Office control, > info displays for system monitoring, interactive advertising, and other > applications that require fewer interaction points and a more ‘lean back’ > experience in the near future. > I'd like to add to that list: home automation, baby monitoring (yes, really: while you are playing, if your baby starts crying, you would see a window open and see video/audio), video subscription services (like Netflix), videoconferencing (XBox + Kinect), remote medical diagnose (again, XBox + Kinect + maybe some other more specialized device), etc -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Consoles
On Fri, Jan 17, 2014 at 12:12 PM, Laszlo Papp wrote: > > For many developers, the proper 3D module is already in place and its > name > > is Unity :-) > > But if Unity works, why do you need Qt? > Because not an application usually requires more than Unity. Try to do text entry, lists, combos, etc, any data manipulation, with Unity alone. It's a pain. Or network. Or XML. Or many of the other great features Qt brings. I mean, Mono does support PS3. Why shouldn't Qt? Supporting XBox shouldn't be that difficult and can probably be done by the community, as any XBox One can be used as a development unit. Main problem I've found so far is the developer program page fails when I try to register (IIS error). PS4 will be more difficult and quite difficult for the community because it's expensive: you need to purchase a special development unit. For PS3, a development unit was in the range of US $20,000. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Consoles
On Fri, Jan 17, 2014 at 11:52 AM, Laszlo Papp wrote: > Wouldn't it be useful to get a proper 3D module in place first? > For many developers, the proper 3D module is already in place and its name is Unity :-) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.3 Feature freeze is coming quite soon...
dy for feature freeze at that date. > > Just a reminder: > In the feature freeze all new functionality must > > - Compile on all reference platforms (If a module/feature is only for one > platform, make sure qmake/make does nothing on the other platforms) > - Have tests. Automated tests should cover as much as possible of the new > functionality. If certain areas are not covered by automated tests, there > must be clarification how testing will be done for those > - Have documentation. No undocumented public API. Basic docs have to be > there, only polishing should still be required after the freeze > - Have examples. Have some examples showing how to use the API. Examples > need to be linked to from documentation. > > In addition, new modules need to > > - Follow the branching scheme. dev/stable/release should be there. A new > module can be ok to only have dev, with stable being created at branching > time. > - Have a CI system. New modules that are going to be part of Qt releases > need to have a CI system set up > > Br, > Jani > ___ > 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 >___ 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 > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Consoles
Hello, Qt is already well supported on desktops and mobile is mostly there (WP8 being the only remaining itch), what about consoles? Are there any plans for support XBox One and PlayStation 4? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Building add-in installer
Hello, This wiki page describes how to build the Qt Visual Studio Add-in: http://qt-project.org/wiki/QtVSAddin But it says nothing about building the installer for the Qt VS Add-in. If I have understood tools\buildAddin\buildAddin.cmd correctly, I need one clone of the VS Tools repository for each version of Visual Studio I want to support. Is that so? Are there instructions somewhere? Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt/Android Ministro Question
On Thu, Jan 2, 2014 at 12:10 PM, Paul Olav Tvete wrote: > The Qt Project does indeed supports two different deployment method (and a > third one for debugging purposes). Ministro was developed by and is > maintained > by BogDan. The bundling option was done by Eskil for Digia, so we feel more > responsible for that one. (Another factor is the support that Digia offers > to > its customers...) What's the third one? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling SSE2 by default on x86 builds (32-bit)
On Wed, Dec 11, 2013 at 10:21 AM, Simon Hausmann wrote: > > The other option for 5.2 would be to do runtime detection of SSE2 and > > enable/disable the JIT according to that. > > I think the main issue with run-time detection is that we need -msse2 > -mfpmath=sse in order to get reliable math results (no 80-bit temps) that > match with our test expectations, when using the interpreter or non-inline > math functions. > I have not looked into the actual code, I know everybody hates dlopen and I haven't even though about the performance implications but, what about this? - Move "maybe-SSE2" code to a separate library - Compile that library twice, one with SSE2 (-msse2 -mfmath=sse), the other without SSE2 - Ship both versions of the library: libwhatever_sse2.so, libwhatever_i486.so - On runtime, check for SSE2 and load the appropriate version The same approach could be used in other parts of Qt, or even for having SSE2, SSE2, etc versions of that library/plugin -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FOSDEM 2014 Desktops DevRoom Call for Talks
Hello, As usual, it's time to submit your talk proposal for FOSDEM --8<--- FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the Desktops DevRoom (formerly known as "CrossDesktop DevRoom"), which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE/Razor, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2013 schedule might give you some inspiration: https://archive.fosdem.org/2013/schedule/track/cross_desktop/ Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) - Short abstract of one or two paragraphs - Short bio (with photo) - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request. The deadline for submissions is December 14th 2013. FOSDEM will be held on the weekend of 1-2 February 2014. Please use the following website to submit your proposals: https://penta.fosdem.org/submission/FOSDEM14 You can also join the devroom's mailing list, which is the official communication channel for the DevRoom: desktops-devr...@lists.fosdem.org(subscription page for the mailing list: https://lists.fosdem.org/listinfo/desktops-devroom ) – The Desktops DevRoom 2014 Organization Team --8<--- -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Win32 API] Windows 8.1 deprectaed GetVersion(Ex) -> QSysInfo should be fixed!
Hello, As a quickfix, this also works: #if defined(_MSC_VER) && (_MSC_VER >= 1800) #pragma warning (disable:4996) #endif On Sun, Oct 20, 2013 at 3:56 PM, MuldeR wrote: > Hello. > > As you might have read, with Windows 8.1, the GetVersion(Ex) API has been > deprecated by Microsoft and will now pretend to be Windows 8.0 (NT v6.2), > even when running under Windows 8.1 (NT v6.3). And yes, officiallay and in > other API's, Windows 8.1 *is* NT v6.3. > > See here for details: > http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx > > Microsoft says that they did this in order to prevent compatibility > problems. I think it is a horrible idea to break the API in that way. It > is also the reason why Qt happily detects Windows 8.1 as Windows 8. > Actually Qt should detect an “unknown” operating system, since there is no > 8.1 (NT v6.3 )detection code yet - I have checked latest version in Git. > But Qt detects NT v6.2, thanks to Microsoft's GetVersion(Ex) hack. In other > words: QSysInfo::windowsVersion() reports *wrong* info, starting with > (and probably not limited to) Windows 8.1. > > So let's fix QSysInfo! > > I have pulled together a solution that is based on the VerifyVersionInfo() > API, which has not been broken, fortunately. Basically, we first call > GetVersionEx() to get the "fake" version as a starting point. Then we try > to increase the version numbers from there, calling VerifyVersionInfo() > each time in order to make sure we did not exceed the *real* version. End > result will be the maximum supported version, i.e. the *real* version > number. > > > Code is here: > http://pastie.org/private/kkva8pkk7nzcmm8jjwstfa > > Tested on: Windows XP (RTM), Windows 7 SP-1, Windows 8.0, Windows 8.1 > > (should work on Windows 2000 too, but I don't really care) > > > Output on Windows 7: > > (Fake) Windows Version: 6.1 > Trying to verify: 7.0 -->NO > Trying to verify: 6.2 -->NO > *Real* Windows Version: 6.1 > > > Output on Windows 8.0: > > > (Fake) Windows Version: 6.2 > > Trying to verify: 7.0 -->NO > > Trying to verify: 6.3 -->NO > > *Real* Windows Version: 6.2 > > > Output on Windows 8.1: > > (Fake) Windows Version: 6.2 > Trying to verify: 7.0 -->NO > Trying to verify: 6.3 -->YES > Trying to verify: 6.4 -->NO > *Real* Windows Version: *6.3* > > > > Regards, > MuldeR > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing libudev dependency from binary packages?
Hello, What about dlopen/dlsym? Due to problems like this, InterSystems ( http://www.intersystems ) resorted to: a) Distribute third-party dependencies, and b) dlopen/dlsym *every* third-party dependency in their software (and they have quite a lot: zlib, OpenSSL, Xerces, Samba, libXSLT, libXML2, ANTLR, LDAP, libssh2, Xalan, etc) The dlopen/dlsym method usually works* even if someone is setting LD_LIBRARY_PATH because he wants/needs to use newer versions of some library. * Unless there have been severe changes in API/ABI but if someone is setting LD_LIBRARY_PATH, he knows what he's risking Would it be possible to dlopen/dlsym libudev and have a fallback code path? On Tue, Oct 22, 2013 at 8:05 AM, Hausmann Simon wrote: > I think the problem is shipping binaries that accommodate the fact that > every distro ships libudev in a different major version. That means you > can't reliably use dynamic linking :( > > > Simon > > *Fra: *Donald Carr > *Sendt: *07:46 tirsdag 22. oktober 2013 > *Til: *Thiago Macieira > *Kopi: *development@qt-project.org > *Emne: *Re: [Development] Removing libudev dependency from binary > packages? > > God dag, > > I still don't follow the need for remove udev support: > > http://packages.ubuntu.com/lucid/libudev-dev > > There udev is as far back as Lucid. Where is it not present, exactly? > > When you remove it from webkit, you remove joypad hotplug detection. > When you remove it from Qt, you remove the only generalized mechanism > for hot plugging USB devices on Linux systems. Are we doing this in > order to facilitate the same package being used from Ubuntu 13.10 > through to Slackware 1.0? > > Cheerio, > moi > > On Mon, Oct 21, 2013 at 3:18 PM, Thiago Macieira > wrote: > > On segunda-feira, 21 de outubro de 2013 23:07:25, Thiago Macieira wrote: > >> - libqgtk2: fix, it doesn't need libudev > >> > >> The fix for libqgtk2 can probably be: > >> linux: QMAKE_LFLAGS += -Wl,--as-needed > > > > Can anyone check if the other plugins linking to QtPlatformSupport also > have > > the udev dependency? > > > > The fix for platforms other than Linux is to split QtPlatformSupport into > > multiple libraries, one per purpose. At the very least, one library per > > *external* dependency. > > > > Or simply remove the library and let the few files that each plugin > needs be > > compiled multiple times (this would also require moving the wayland > plugin > > back into qtbase). Not a solution for 5.2, I guess. > > > > We may want to investigate turning on --as-needed everywhere. I've been > > building Qt with that flag for years. However, it might introduce > problems > > related to building a new version of Qt when an older version is already > > present and installed, even though we are apparently already doing what > we > > need to do (pass --rpath-link). > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > -- > --- > °v° Donald Carr > /(_)\ Vaguely Professional Penguin lover > ^ ^ > > Cave canem, te necet lingendo > ___ > 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 > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Disable ActiveQt from MinGW
On Thu, Oct 10, 2013 at 3:15 PM, Koehne Kai wrote: > Fair enough. We're even shipping it in the mingw-builds toochain, although > it's named 'i686-w64-mingw32-widl' :) > > Let's see, maybe I can get the combo even working... > > Depending on where that executable is located, it may not be the right one. Check this thread and the FAQ: http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/8574/focus=8599 http://sourceforge.net/apps/trac/mingw-w64/wiki/Usable%20compiler%20executable -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Disable ActiveQt from MinGW
Hello, Wine provides an IDL compiler, which has been adopted my mingw-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-tools/widl/ Mozilla is using it: https://developer.mozilla.org/en/docs/Cross_Compile_Mozilla_for_Mingw32#Install_widl_(optional) On Thu, Oct 10, 2013 at 11:24 AM, Koehne Kai wrote: > Hi, > > I'm wondering whether we should remove ActiveQt from the MinGW binary > packages, and skip it by default if we build for MinGW. > > I'm not an expert on ActiveQt, but my understanding is that it's of minor > use without an IDL compiler. MinGW doesn't offer one, which is why all > examples except the 'webbrowser' one are skipped for MinGW ... and that one > crashes: > > https://bugreports.qt-project.org/browse/QTBUG-32140 > > So, any thoughts on this? Surely the bug above mentioned can be fixed, but > is there any use of shipping ActiveQt for MinGW if there is no idl > compiler? I understood you can't just use the Microsoft midl one ... > > Regards > > Kai > -- >Kai Köhne, Senior Software Engineer - Digia, Qt >Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin >Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius >Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868 >Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Minified javascript libraries in Qt source code
On 27-Sep-2013 11:55 AM, "Jonathan Riddell" wrote: > This also means we can't ship it in Ubuntu, preferred modifiable form is a requirement for free software > > > d) Ship the libraries unmodified from upstream and include a link to where > > they were obtained and where to obtain the non-minified sources. > > Pointing to somewhere else is not a valid way of providing a preferred > modifiable form because the link might get new versions or disappear. A good compromise is shipping both minified (for users) and unminified (for distributions). That's what I'm doing with Wt in Debian. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out)
On Wed, Jul 3, 2013 at 12:28 PM, Tor Arne Vestbø wrote: What percentage of Qt developers develop on Windows? > Significant. Even when developing only for Windows, using Qt over Visual C++ makes worlds of difference. And it's not only Windows, it's also the cross-build features CMake provides (still not up to autotools but getting closer) Out of those, what percentage use cmake over qmake? > Any project which depends on pre-built third-party libraries is better off with CMake over QMake thanks to features such as find_package. If the project is cross-platform, more so. In fact, even if the third-party libraries are not pre-built but will be built as part of the project you are working on, CMake provides ExternalProject which makes it easy to automatically download (optional) and build those third-parties. I don't know whether qbs is making any progress in regards to find_package or ExternalProject but for us those features have become ESSENTIAL in a build system for any non-toy application. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] magic number 0xf291
On Fri, Mar 1, 2013 at 4:59 PM, Joerg Bornemann wrote: > On 01/03/2013 16:47, Pau Garcia i Quiles wrote: > > http://stackoverflow.com/**questions/9187021/c-** >> application-exit-error-code-**62097-what-does-that-mean<http://stackoverflow.com/questions/9187021/c-application-exit-error-code-62097-what-does-that-mean> >> >> It means memory allocation failed. >> > > Yeah I also found this comment but I cannot make my memory allocator fail > in a way that I get this exit code. > > When an MSVC program crashes, a first class exception is thrown. Every > exception has a numerical code. This numerical code is used as exit code. > And those codes have proper defines like EXCEPTION_ACCESS_VIOLATION. That error code is there at least since Qt 3. Is the history for that code available? The obvious solution seems to be to ask to whoever wrote that 10 years ago -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] magic number 0xf291
Hello, According to: http://stackoverflow.com/questions/9187021/c-application-exit-error-code-62097-what-does-that-mean It means memory allocation failed. On Fri, Mar 1, 2013 at 4:43 PM, Joerg Bornemann wrote: > In qprocess_win.cpp there's this code for determining if the child > process crashed or not. > > //### for now we assume a crash if exit code is less than -1 or the > magic number > crashed = (exitCode == 0xf291 || (int)exitCode < 0); > > Does anybody have an idea where this magic number 0xf291 comes from? > I cannot find it anywhere in the Windows headers. Neither can I produce > a crashing application that returns this code. > > Hint: it is not the exit code for unsatisfied DLL dependencies. > That's STATUS_DLL_NOT_FOUND. > > > Cheers, > > Joerg > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
On Mon, Jan 14, 2013 at 1:31 PM, Konstantin Tokarev wrote: > >> On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote: > >>> Which is not always that easy... if a library function returns, say, an > >>> simple std::string *by value*, then who will destroy the allocated > memory? > >>> It's really too easy to break something, somwhere, causing a random > crash > >>> almost impossible to reproduce reliably. > >> > >> The ICU C API does not use std::string: it was meant to be used from C > code. > >> It's quite easy to avoid std::string in that case. > > > > But as John said a few mails ago, it seems the C is not enough to > implement all the required features. > > ICU provides C++ API but it does not use std::string. It operates on char > * or UnicodeString objects. > > std::string is just one case, the C++ API does allocate other objects and I'm sure that was what Yves (and me) wanted to highlight -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ICU and Windows
On Mon, Jan 14, 2013 at 9:35 AM, Thiago Macieira wrote: On segunda-feira, 14 de janeiro de 2013 08.31.19, Yves Bailly wrote: > > Which is not always that easy... if a library function returns, say, an > > simple std::string *by value*, then who will destroy the allocated > memory? > > It's really too easy to break something, somwhere, causing a random crash > > almost impossible to reproduce reliably. > > The ICU C API does not use std::string: it was meant to be used from C > code. > It's quite easy to avoid std::string in that case. > > But as John said a few mails ago, it seems the C is not enough to implement all the required features. In addition to that, having ICU in 3rd parties makes Qt easier to build on Windows. Developers who build their own Qt need not go and look at how to build ICU, debug vs release flags, etc. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
On Fri, Jan 11, 2013 at 4:31 PM, Eskil Abrahamsen Blomfeldt < eskil.abrahamsen-blomfe...@digia.com> wrote: > This suggestion is definitely something we'll investigate. I haven't > looked into the Ministro code yet, so I don't know if it's technically > possible, but as far as I've understood from previous discussions, there > are limits to where apps can write on the device and there are limits to > where they can load libraries, which makes the app serving as a central > repository of libraries necessary. But it's something we need to > investigate further, and for the moment we don't have the resources to take > this on for Qt 5.1, where our main priority will be to get the Qt 5 port on > par with the Qt 4 version of Necessitas. When get that far, we can start > looking into alternative solutions for deploying Qt apps which does not > require the extra "install ministro" step when a user launches a Qt app for > the first time on a device. > Many Symbian applications you can download from the Ovi Store include something like "This application may require a one-time download of around 20 MB" in the description. What happens behind the scenes in that case? Is Qt downloaded from Ovi when the user asks to install the application? Or is Qt downloaded the first time the application is launched? I'd say Qt on Android, iOS, etc is not too different of a case from Qt on Symbian. Or maybe it is, if there is specific support in the Ovi Store for that. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5
On Tue, Dec 4, 2012 at 6:26 PM, Konstantin Tokarev wrote: > > 04.12.2012, 21:02, "Pau Garcia i Quiles" : > > On Tue, Dec 4, 2012 at 5:21 PM, Konstantin Tokarev > wrote: > > > >> There's no point in keeping separate branch purely for tags. It is just > an unnecessary overcomplication. > > Actually, there is: it allows you to continue working in stabilization > branches, then discard those changes (i. e. never release them into master > or the -releases branch) > > This is something you are supposed to do in topic branches, forked from > stabilization branch. Also, you have git revert for extreme cases. > > Our workflow is a bit different, we have QA, marketing and other stakeholders who may decide, after 3 weeks of QA validation, that the version to release is not the tip of the -stabilization branch but an older version (we then update -release with some older version from -stabilization). You could say release-3.1-stabilization and release-3.1-releases are topic branches; we don't. >and it helps overcome the lack of git tags support in some continuous > integration systems. > > Sounds weird, like it was continuous integration system without support > for branches. > > Welcome to the wonderful world of CruiseControl.NET. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Bumping Qt 4 version to 4.8.5
On Tue, Dec 4, 2012 at 5:21 PM, Konstantin Tokarev wrote: > There's no point in keeping separate branch purely for tags. It is just an > unnecessary overcomplication. > Actually, there is: it allows you to continue working in stabilization branches, then discard those changes (i. e. never release them into master or the -releases branch) and it helps overcome the lack of git tags support in some continuous integration systems. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Reminder: FOSDEM CrossDesktop DevRoom 2013 - Call for Talks
Hello, The Call for Talks for the CrossDesktop DevRoom at FOSDEM 2013 is officially open and will close in two weeks (Dec 14th). Where are all the talks about the split repositories, Qt Creator, add-ons, insight on how to develop cross-platform applications, etc? Please submit your talk proposals ASAP! --8<--- * FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the CrossDesktop DevRoom, which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2012 schedule might give you some inspiration: https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html <https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html> Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) - Short abstract of one or two paragraphs - Short bio - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. The deadline for submissions is December 14th 2012. FOSDEM will be held on the weekend of 2-3 February 2013. Please submit your proposals to crossdesktop-devr...@lists.fosdem.org (subscribtion page for the mailing list: https://lists.fosdem.org/listinfo/crossdesktop-devroom ) -- The CrossDesktop DevRoom 2013 Organization Team* --8<--- -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of WP8 port
On Fri, Nov 2, 2012 at 12:58 AM, Turunen Tuukka wrote: > What comes to WP8 we believe it is more important to tackle Android and > iOS first, as discussed earlier. It does not mean we do not care about WP8. > There is just so much more user base in Android and iOS that we think it > would be outright stupid not to address those. > > While I agree iOS and Android are currently bigger than WP8, it's the similarity between Windows 8 and Windows Phone 8 what made send the question in the first place. Properly supporting Metro applications with Qt for Windows 8 in C++ almost implies implementing the same features that would enable Qt for WP8. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of WP8 port
I rrecently wrote abou mobile development frameworks http://www.elpauer.org/?p=1205 On 11/2/12, Nicola De Filippo wrote: > Hi, > i'm qt ambasassor and monday i'll begin a new job how mobile expert, i > should > to choose cross-platform tool, for android, windows, iphone and if possible > > other platforms. > Thus, for me i fundamental know the platforms supported of Qt, time of > releasing, licence. > Also, what's the relationship with necessitas? > I use qt from 1997 and i hope of use it for other 30 years. > BR >Nicola > > It's good news that Digia is targetting iOS and Android platforms, which > have > huge user base, I wonder how are these ports going, though ? > You guys planning to have an alpha this year for any of the platforms ? > > I am asking as our team is preparing a tablet app which should be running on > > Android and iPad earlny next year and we don't see other option than using > Qt. > > Kacper Gazda > Founder/CEO > > Milo Solutions > (+48) 604131027 > > > http://milosolutions.com > > > > > On Fri, Nov 2, 2012 at 12:58 AM, Turunen Tuukka > wrote: > > > >> From: Baldo Davide >> Reply-To: "baldos...@gmail.com" >> Date: perjantaina 2. marraskuuta 2012 1.31 >> To: "development@qt-project.org" >> Subject: Re: [Development] Status of WP8 port > >> >> It would be nice to have 2 weeks update for each major internal project, >> qt > blog is almost dead since it's passed to digia. >> Without any update digia is loosing credibility, but we all know that >> digia > is worthy of trust and credibility, don't we? > > > > I am sorry to hear you find the Qt Blog having too little articles for you. > > We are continuously blogging on interesting topics, for example the last > 4 blogs have been about: Styles in Qt 5, Using Angle for HW accelerated > graphics on Windows, Release of Qt Creator 2.6 beta and Widgets on > header – published in less than 2 weeks. I think those are all interesting > articles and luckily so do many others. > > > What comes to WP8 we believe it is more important to tackle Android > and iOS first, as discussed earlier. It does not mean we do not care > about WP8. There is just so much more user base in Android and iOS > that we think it would be outright stupid not to address those. > > > Yours, > > > Tuukka > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FOSDEM CrossDesktop DevRoom 2013 - Call for Talks
Hello, The Call for Talks for the CrossDesktop DevRoom at FOSDEM 2013 is now officially open. Please do not wait till the last minute! --8<--- * FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the CrossDesktop DevRoom, which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2012 schedule might give you some inspiration: https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html <https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html> Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) - Short abstract of one or two paragraphs - Short bio - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. The deadline for submissions is December 14th 2012. FOSDEM will be held on the weekend of 2-3 February 2013. Please submit your proposals to crossdesktop-devr...@lists.fosdem.org (subscribtion page for the mailing list: https://lists.fosdem.org/listinfo/crossdesktop-devroom ) -- The CrossDesktop DevRoom 2013 Organization Team* --8<--- -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Status of WP8 port
Hello, Microsoft has released the Windows Phone 8.0 SDK with native support. http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/10/30/announcing-the-new-windows-phone-8-developer-platform.aspx https://dev.windowsphone.com/en-us/downloadsdk What's the status of Qt 5 on WP8? Last I remember, a feasibility study was being carried on. What was the outcome? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Sun, Oct 21, 2012 at 2:45 PM, Lisandro Damián Nicanor Pérez Meyer < perezme...@gmail.com> wrote: > Well, my impression is exactly the contrary: most people developing > against Qt > just install the development packages. > > In fact, I have never met someone who installed the SDK when [s]he can get > the > packages from the distro repo. > Commercial users usually get the SDK, especially if they are redistributing Qt along with the application ($ORIGIN rpath / LD_LIBRARY_PATH, etc) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Sat, Oct 20, 2012 at 1:16 AM, Thiago Macieira wrote: > b) additionally, it accepts an extra argument (-select), which causes it > to > select a different Qt version. For example: > qmake -qt=5 -project > qmake -qt=4.8.4 CONFIG+=debug > etc. > As a shorthand, the option "-qtX" means "-qt=X". > This argument will be stripped from the command-line before calling the > real > qmake. > Without this option, it will fall back to a well-known environment > variable > (say, QT_SELECT=5). And if that is also missing, it selects some > system-defined > or user-defined default. > > [..] > In turn, the official Qt 5 documentation should always talk about qmake > like > so: > qmake -qt5 "LIBS+=-L/usr/local/lib -lmysqlclient_r" mysql.pro > What's "-qt5" ? Latest Qt 5.x.y available? A shorthand for "qmake -qt=5.0.0"? Something else? Also, why not use pkg-config --list-all and simply look for everything called "libqt-x.y.z" or alike? (I know, I know, no external dependencies is an advantage and this new qmake is very easy to implement but still...) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Static release vs debug size
Hello, I have compiled Qt 4.8.3 statically in release and debug on Windows using Visual Studio 2010 SP1. Something odd happened: the *release* libraries are way bigger (5x to 10x) than the *debug* version. Is there a logical explanation for that? (I was expecting the opposite) Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
> SEH & 32 : patented by MSFT It's actually Borland's patent and Borland said they only patented that to defend themselves from third-party attacks, they have no interest in attacking gcc: http://web.archive.org/web/20070818053531/blogs.codegear.com/dcc/archive/2005/05/12/4294.aspx I wonder if anybody "rang the doorbell and asked" as Danny Thorpe proposed. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On Fri, Aug 31, 2012 at 3:00 PM, wrote: > > Alright, since there are people both in favor of mingw-builds and mingw-64 I > guess we have to do a proper comparison :) > Question to the mingw-64 supporters: Which exact package should we evaluate? > http://mingw-w64.sourceforge.net/ talks about > "Version 2.0 [...] been released and is considered stable." But I couldn't > find any pre-build toolchain with -2.0 in the file name > under > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/ > ... > > PS: I started already adding my personal experiences on > http://qt-project.org/wiki/MinGW-64-bit . I forwarded your mail to the mingw-w64-public mailing list and got a couple of answers: --8<--- MinGW-builds gcc-4.7.1-release will be rebuilt this weekend for use GDB-7.5.0 and binutils-2.22.90. --8<--- --8<--- Ray Donnelly mingw.andr...@gmail.com via lists.sourceforge.net 4:36 PM (30 minutes ago) to mingw-w64-publ. Hi Pau, The Android Necessitas Qt project moved from MinGW to MinGW-w64 for our A4 release. As we also build our own version of the Android NDK for Necessitas, we used (improved and merged back into) their mingw-w64 build script also build our cross MinGW compilers: https://android.googlesource.com/platform/ndk/+/5d6dd385bd9814e8da832c70a598a729b9172585/build/tools/build-mingw64-toolchain.sh For the released Windows version I used ruben's 4.7.0 GCC (the cross compile did work fine for Qt and Qt Creator actually, but we never got the packaging side of things finished) We've run into just one bug so far in the Qt Creator we released with it (and it's unlikely the compiler's fault). --8<--- Using the same compiler in Necessitas and in Qt Project looks like a good idea to me. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
Hi, On Fri, Aug 31, 2012 at 3:34 AM, Yang Fan wrote: > Currently, official MinGW project provides GCC 4.7, but it uses SJLJ > exception mode when TDM/MinGW-w64/MinGW-build projects use Dwarf2 exception > mode which is known as zero-overhead exception. I forgot to say we now have SEH exception support, which is the best solution. See this thread in mingw-w64 http://sourceforge.net/mailarchive/message.php?msg_id=29641656 > All those MinGW and forks contain mingw32-make.exe util which does have -j > option, but in fact this option doesn't make the real parallel build. Maybe > sh.exe is needed, but this shell util will pass the incompatible path string > so that the build process will be interrupted. Are you sure of that? I remember reading a thread in the mingw.org mailing list in which Earnie Boyd explained MSYS did the path string translation and in most cases it worked fine. Or are you talking about the cases where it fails? (recursive spawns, overinterpretation of the path string, etc) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
Hi, On Thu, Aug 30, 2012 at 4:56 PM, wrote: > Hi, > > I'd like to get this on the table again: What is the MinGW package that we > want to support officially? The matrix for Qt 5.0 right now says MinGW gcc > 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org > it's already installing gcc 4.7, and I guess you'd need to dig into the > archive to get gcc 4.5 ... But anyway, it's still 32 bit only. > > In the last days I gave the following packages that also support both 32 bit > and 64 bit a try: > > TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not > much (visible) activity > Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are > popular, 'semi-official' personal builds with 4.7.1 though ... > Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in > the prerelease directory ... [...] There are more differences than that. There are differences in features, such as threading support, large-file support, etc. Mingw-w64 is usually ahead of any other in terms of features. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
>>>>> stakeholders in the Qt Project on which MinGW to ship. >>>>> >>>>> From my POV, the following things are important when choosing a >>>>> “proper” MinGW-based compiler: >>>>> >>>>> - Prefer existing MinGW distros* over compiling& maintaining >>>>> MinGW ourselves (although others may disagree here) >>>>> - Make sure they are minimal and centered around C/C++ >>>>> development (i.e. no elaborate gjc cruft like we still have in our >>>>> current MinGW 4.4 packages) >>>>> - Make sure we pick a distro that provides regular updates and >>>>> provides new GCC versions in a timely manner >>>>> - Let’s ship both a 64 and a 32 bit version, and ideally ones >>>>> that provide a cross-compiler respectively >>>>> - Let’s make sure we start providing them at the same time, and >>>>> we start building our products with them >>>>> >>>>> Marius found http://sourceforge.net/projects/mingwbuilds/files/, which >>>>> seems to satisfy all of the above. Other suggestions/preferences are >>>>> welcome. >>>>> >>>>> If deemed necessary, we can also build our own MinGW distro via Qt >>>>> Project’s public build infrastructure (http://builds.qt-project.org). We >>>>> need good build recipes for that, though, and someone who is willing to >>>>> maintain them. >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> *) by “Distro” I mean different entities compiling& providing MinGW >>>>> releases such as MinGW.org, TDM, etc >>>>> >>>>> >>>>> >>>>> >>>>> Why not wait till there is a MingW with GCC 4.7.0 release? I'm asking >>>>> that since GCC 4.7 adds support for AVX and AMD bulldozer (bdver1) >>>>> specific compiler optimization which seem to be greatly beneficial for >>>>> AMD cpu's. So it might be worth the consideration to postpone the next Qt >>>>> Creator release till there is a MingW with GCC 4.7.0. >>>>> >>>>> >>>>> Just my opinion. >>>>> >>>>> >>>>> Cheers, >>>>> Mark >>>>> ___ >>>>> 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 >> ___ >> 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 -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Fri, Apr 20, 2012 at 11:12 AM, andy fillebrown wrote: > On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz > wrote: >> On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote: >>> I would add to the "proper compiler" list the ability to set debug >>> breakpoints quickly and proper display of call stacks across .dll >>> boundaries. IMO those are the two things that bug me the most about >>> the "distros" already mentioned. Waiting 2+ minutes for the debugger >>> to start, and then not being able to see a complete callstack, is >>> frustrating. So much so that I find myself going back to Qt's GCC 4.4 >>> release. >> >> Does that mean you have experience with both the 4.4 version >> that's currently distributed, and the version from >> http://sourceforge.net/projects/mingwbuilds/files/ >> and you found the latter lacking? >> >> Startup time should be mostly related to gdb, less so to the >> debug information gcc creates... > > Yes, I have experience with many versions and I have always reverted > back to qt's gcc 4.4 release due to the issues with gdb. I'm trying > out the gcc 4.7.0 version from > http://sourceforge.net/projects/mingwbuilds/files right now. I'll let > you know if I find it lacking, too. > > I realize there is a distinction between gcc and gdb, but since gdb is > included in the distro I thought I'd bring up the issues I've had, > seeing that the gdb from the distro might be the gdb included in the > Qt SDK. Have you tried this? http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/3699 (last message in the thread) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt on WP Tango
Hi, Apparently Windows Phone 7.6 "Tango" will be released in Q2 2012 and will support C++ development. Is anyone at Nokia already working on porting Qt 5 to Tango? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The future of QtAlgorithms
On Fri, Jan 27, 2012 at 5:27 PM, Olivier Goffart wrote: > /me wonder why we still even care about QT_NO_STL > > Embedded? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Let's discuss QPluginManager
On Fri, Jan 20, 2012 at 7:38 PM, Artur Souza (MoRpHeUz) wrote: > Another feature related to plugins that KDE implemented and I find it > very useful and "elegant" is KPluginFactory: > https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kdecore/util/kpluginfactory.h In addition to plugins which provide non-visual features, what about something like KParts that could be embedded in applications? Some guidelines to avoid ABI problems might be needed, but I think this is a good opportunity to create a marked for 3rd-party companies developing components. It's huge in Delphi and .NET and I have always wondered why it does not really exist in the Qt world. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FOSDEM 2012 - CrossDesktop DevRoom Call for Talks
Hi, FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the CrossDesktop DevRoom, which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2011 schedule might give you some inspiration: http://archive.fosdem.org/2011/schedule/track/crossdesktop_devroom Please include the following information when submitting a proposal: your name, the title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) and a short abstract of one or two paragraphs. The deadline for submissions is December 20th 2011. FOSDEM will be held on the weekend of 4-5 February 2012. Please submit your proposals to: crossdesktop-devr...@lists.fosdem.org ( https://lists.fosdem.org/listinfo/crossdesktop-devroom ) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] proposing Richard Moore as approver
2011/11/2 Thiago Macieira : >> But am I alone to think that 3 weeks of waiting time is a lot? >> 15 work day is a lot, how about reducing it to something between 7 and 10 >> work days? > > I think the number was chosen so that people who might be on vacations have > the time to react. But I agree it's a bit high. May I suggest taking a look at what Debian does? http://wiki.debian.org/DebianMaintainer Instead of waiting 3 weeks, once you get our advocates, you submit a bug linking to the thread in the mailing list. Then there are 4 days for objections. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] mingw x64
Hi, Great. Another benefit of mingw-w64 is large file support via _FILE_OFFSET_BITS=64, which makes very easy to support cross-platform applications that deal with > 2 GB files. No other MinGW flavor supports that, AFAIK. On Sat, Oct 29, 2011 at 1:52 PM, andy fillebrown wrote: > Thanks for the heads up. I'm building Qt with ruben's personal 4.6.3 > now. If it works, it would be very nice to see a supported version of > w64 in the Qt SDK. > > Cheers, > ~ andy.f > > > > On Fri, Oct 28, 2011 at 8:43 PM, Pau Garcia i Quiles > wrote: >> Hi, >> >> It works fine with the latest stable mingw-w64 release (gcc 4.6.1). >> See this recent thread in the mingw-w64 mailing list: >> >> http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/3622 >> >> >> On Sat, Oct 29, 2011 at 12:06 AM, andy fillebrown >> wrote: >>> AFAIK, python enabled gdb does not compile with any version of 64 bit mingw. >>> >>> Cheers, >>> ~ andy.f >>> >>> >>> >>> On Fri, Oct 28, 2011 at 10:28 AM, Pau Garcia i Quiles >>> wrote: >>>> Hi, >>>> >>>> According to the wiki, MinGW will only be supported for 32-bit >>>> compilations. >>>> >>>> http://developer.qt.nokia.com/wiki/Qt_5.0 >>>> >>>> I was wondering if there are any plans to add 64-bit to those >>>> platforms, via mingw-w64 ( http://mingw-w64.sf.net ). KDE on Windows >>>> moved from MinGW32 (mingw.org) to mingw-w64 for both 32-bit and 64-bit >>>> recently, which should pave the way. >>>> >>>> Same for Qt Creator, in fact: any plans to ship a 64-bit compiler? >>>> >>>> -- >>>> Pau Garcia i Quiles >>>> http://www.elpauer.org >>>> (Due to my workload, I may need 10 days to answer) >>>> ___ >>>> Development mailing list >>>> Development@qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >> >> >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] mingw x64
Hi, It works fine with the latest stable mingw-w64 release (gcc 4.6.1). See this recent thread in the mingw-w64 mailing list: http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/3622 On Sat, Oct 29, 2011 at 12:06 AM, andy fillebrown wrote: > AFAIK, python enabled gdb does not compile with any version of 64 bit mingw. > > Cheers, > ~ andy.f > > > > On Fri, Oct 28, 2011 at 10:28 AM, Pau Garcia i Quiles > wrote: >> Hi, >> >> According to the wiki, MinGW will only be supported for 32-bit compilations. >> >> http://developer.qt.nokia.com/wiki/Qt_5.0 >> >> I was wondering if there are any plans to add 64-bit to those >> platforms, via mingw-w64 ( http://mingw-w64.sf.net ). KDE on Windows >> moved from MinGW32 (mingw.org) to mingw-w64 for both 32-bit and 64-bit >> recently, which should pave the way. >> >> Same for Qt Creator, in fact: any plans to ship a 64-bit compiler? >> >> -- >> Pau Garcia i Quiles >> http://www.elpauer.org >> (Due to my workload, I may need 10 days to answer) >> _______ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] mingw x64
Hi, According to the wiki, MinGW will only be supported for 32-bit compilations. http://developer.qt.nokia.com/wiki/Qt_5.0 I was wondering if there are any plans to add 64-bit to those platforms, via mingw-w64 ( http://mingw-w64.sf.net ). KDE on Windows moved from MinGW32 (mingw.org) to mingw-w64 for both 32-bit and 64-bit recently, which should pave the way. Same for Qt Creator, in fact: any plans to ship a 64-bit compiler? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
