Re: [Development] New Qt 5.2 snapshot build #172
On 27 Nov 2013, at 12:06, Adam Strzelecki o...@java.pl wrote: I am hereby submitting my candidature. I am registered MaciOS developer. I am personally interested to improve Qt experience on Mac, since I am using it for several projects. I may either submit patches or fork Git master. Of course if Qt maintainers are open for dropping idea of Qt installer framework based installer for OSX platform if they are convinced that these ideas work better for Mac users. I may then also fix other issues, such as @rpath support and OSX Retina issues in Qt Creator. Welcome to the club, we hang out on #qt-cocoa and #qt-ios on freenode in addition to #qt-labs. @rpath (or the OS X equivalent) support is something that is on the TODO list. Retina fixes are also welcome. As for installers I think “dropping the Qt installer framework” is a bit to extreme, let’s start by experimenting with a new self-contained installer. Is Qt on the Mac App store within reach? Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
On 27 Nov 2013, at 16:24, Ziller Eike eike.zil...@digia.com wrote: Adding plugins into the respective frameworks would simplify deployment significantly. macdeployqt's task would be reduced to inspecting the frameworks the app links against, and copying the framework folders into the bundle. Don't need to think about plugins, don't need to mess with install names. It just works.™ Yeah. I’m all for self-contained, relocatable Qt (@rpath, plugins in bundles, etc), and afair the corresponding Qt Project maintainers too. It’s a bit independent from the question of how to distribute Qt packages for developers though. macdeployqt has been chasing after which plugins to deploy ever since it started to support deploying plugins. What we need is a per-platform default plugin list for each module. This list should be maintained by the module maintainer. MODULE_PLUGIN_TYPES is a start, perhaps we can use something similar for specific plugins. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
Hi all. I find this one: https://bugreports.qt-project.org/browse/QTBUG-35002 I cannot remember any other related to 5.2 RC1 installer fonts. Do you see this is blocking RC1? I agree this don't give good first impression but still I am wondering if this is bad enough to delay to RC1... Br, Jani -Original Message- From: development-bounces+jani.heikkinen=digia@qt-project.org [mailto:development-bounces+jani.heikkinen=digia@qt-project.org] On Behalf Of Knoll Lars Sent: 26. marraskuuta 2013 17:57 To: Thiago Macieira; development@qt-project.org Subject: Re: [Development] New Qt 5.2 snapshot build #172 I have to agree with Thiago. I tried the install on a retina mac book/10.9 two weeks ago, and the installer looked extremely ugly. It simply doesn¹t make for a good first impression. Cheers, Lars On 26.11.13 16:22, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 26 de novembro de 2013 14:55:52, Koehne Kai wrote: FYI, installer font is still messed up on OSX 10.9. I have tried to find the original bug report but only found QT 4.8.x reports marked fixed: https://bugreports.qt-project.org/browse/QTBUG-33049 https://bugreports.qt-project.org/browse/QTBUG-32789 https://bugreports.qt-project.org/browse/QTBUG-31803 Well, they're fixed for Qt 4.8.6, which isn't released yet. Not sure we should start cherry-picking because of it... The bug reports sound like it's just a minor ugliness (though I haven't seen it live yet). This is the first thing users see. It will detract from the perception of Qt's quality. And it's not like we didn't know about this -- we just failed to put two and two together. How difficult is it to cherry-pick the fixes into the installer framework build? -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
Subject: Re: [Development] New Qt 5.2 snapshot build #172 Hi all. I find this one: https://bugreports.qt-project.org/browse/QTBUG-35002 I cannot remember any other related to 5.2 RC1 installer fonts. Do you see this is blocking RC1? I agree this don't give good first impression but still I am wondering if this is bad enough to delay to RC1... I don't think so. Let's try to upgrade the Qt used in the IFW, but it shouldn't block the RC1. My 2 cents Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
On 27 November 2013 10:09, Koehne Kai kai.koe...@digia.com wrote: Subject: Re: [Development] New Qt 5.2 snapshot build #172 Hi all. I find this one: https://bugreports.qt-project.org/browse/QTBUG-35002 I cannot remember any other related to 5.2 RC1 installer fonts. Do you see this is blocking RC1? I agree this don't give good first impression but still I am wondering if this is bad enough to delay to RC1... I don't think so. Let's try to upgrade the Qt used in the IFW, but it shouldn't block the RC1. This is a known Qt bug. Affects me with Qt 4.8.5 on OS X Mavericks. See here for a possible solution http://successfulsoftware.net/2013/10/23/fixing-qt-4-for-mac-os-x-10-9-mavericks/ Or go directly to the bug report https://bugreports.qt-project.org/browse/QTBUG-32789 Cheers, Tom ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
On 27/11/13 10:09, Koehne Kai kai.koe...@digia.com wrote: Subject: Re: [Development] New Qt 5.2 snapshot build #172 Hi all. I find this one: https://bugreports.qt-project.org/browse/QTBUG-35002 I cannot remember any other related to 5.2 RC1 installer fonts. Do you see this is blocking RC1? I agree this don't give good first impression but still I am wondering if this is bad enough to delay to RC1... I don't think so. Let's try to upgrade the Qt used in the IFW, but it shouldn't block the RC1. No it shouldn't delay the RC. But let's try to get it fixed for the final. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
Jake Petroules wrote:
But what exactly do you include in the offline installer?
Thanks for detailed insight. I think I am all way with /Applications/Qt
Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ because of simple reason
that on OSX you don’t need elevated permissions to put anything into
/Applications (comparing to /Library).
1st of all I wouldn’t call it installer, but it would be DMG bundle with nice
background layout:
1. Drag to Application to install
[Qt Creator.app] == [/Applications]
2. Then double click to install SDK:
{mkspec}-{version}.qtsdk
Where online bundle would have just (1) Qt Creator bare app + Qt Creator Mac
plugin that downloads offline .dmg-s for iOS, Android or whatever, mounts dmg
and copies .qtsdk.
We can easily have helper (i.e. written in Apple Script) embedded in Qt
Creator.app that is bound to .qtsdk extension, that simply launches Finder copy
into /Applications/Qt Creator.app/Contents/SDKs or wherever it is placed, then
ejects the .dmg.
What’s more cool, we can figure out the case user have not dragged yet .app
into /Application but clicks on the .qtsdk and show „please drag Qt Creator
into your Applications first”.
As for Xcode compatibility sake, we can make in Qt Creator a button [Install
Command Line Tools] which will:
(1) install symlink to qmake into /usr or /usr/local
(2) install symlinks to all .frameworks into /Library/Frameworks
Again we can make it as Qt Creator plugin, rather putting it into base code.
Since these are symlinks, even if we trash Qt Creator.app (and all SDKs within)
these will be dangling, but not occupying any space on the disk.
Finally regarding maintenance burden: actually there would be less, because we
will get the .qtsdk helper and Qt Creator plugin just once. Then making OSX Qt
bundles will be less work, since it would be what it done right now minus
creating Qt installer framework based installer app.
Adding plugins into the respective frameworks would simplify deployment
significantly. macdeployqt's task would be reduced to inspecting the
frameworks the app links against, and copying the framework folders into the
bundle. Don't need to think about plugins, don't need to mess with install
names. It just works.™
Yeah.
Thiago Macieira wrote:
So, as much as this would look desirable, it will not leave the paper unless
someone volunteers to start experimenting with it. Let's see some volunteers
trying it during the 5.2.x timeframe. If it works fine, we can release it
officially for 5.3.0.
I am hereby submitting my candidature. I am registered MaciOS developer. I am
personally interested to improve Qt experience on Mac, since I am using it for
several projects. I may either submit patches or fork Git master.
Of course if Qt maintainers are open for dropping idea of Qt installer
framework based installer for OSX platform if they are convinced that these
ideas work better for Mac users.
I may then also fix other issues, such as @rpath support and OSX Retina issues
in Qt Creator.
WDYT?
Cheers,
--
Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
On Nov 27, 2013, at 12:06 PM, Adam Strzelecki o...@java.pl wrote:
Jake Petroules wrote:
But what exactly do you include in the offline installer?
Thanks for detailed insight. I think I am all way with /Applications/Qt
Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ because of simple reason
that on OSX you don’t need elevated permissions to put anything into
/Applications (comparing to /Library).
1st of all I wouldn’t call it installer, but it would be DMG bundle with nice
background layout:
1. Drag to Application to install
[Qt Creator.app] == [/Applications]
2. Then double click to install SDK:
{mkspec}-{version}.qtsdk
So that would always contain the Qt sources, documentation and examples too?
I just want to mention here that there *is* the plan to get rid of the
requirement to install Qt Creator from the installers. There are several
possible ways to solve that and I think the discussion of what is the preferred
way to do it is not over yet, but I think there is overall consensus that it
should be done.
Where online bundle would have just (1) Qt Creator bare app + Qt Creator Mac
plugin that downloads offline .dmg-s for iOS, Android or whatever, mounts dmg
and copies .qtsdk.
We can easily have helper (i.e. written in Apple Script) embedded in Qt
Creator.app that is bound to .qtsdk extension, that simply launches Finder
copy into /Applications/Qt Creator.app/Contents/SDKs or wherever it is
placed, then ejects the .dmg.
“double-click .qtsdk to register only works if you have exactly one Qt Creator
install on your machine. Of course there still would be “drag qtsdk thing into
Qt Creator” etc, but I don’t really see the advantages.
What’s more cool, we can figure out the case user have not dragged yet .app
into /Application but clicks on the .qtsdk and show „please drag Qt Creator
into your Applications first”.
I’d guess that the more common case would be that people double-click Qt
Creator without double-clicking the .qtsdk (which they have no idea what it’s
supposed to be).
As for Xcode compatibility sake,
I’m convinced that the AppStore is the only reason why Xcode is having
“everything in the bundle” nowadays. Not because it would make sense
usability-wise. I don’t think the normal user of Xcode cares if the SDK was
installed within the Xcode.app or not. It’s not that Xcode didn’t come as a
installer for years, and it’s not that installers are completely alien on OS X.
And actually Apple now needs to provide and maintain two “installers”:
Xcode.app with its package management, and the separate CommandLineTools
package, which is still available (for a reason).
we can make in Qt Creator a button [Install Command Line Tools] which will:
The “Install Command Line Tools” thing in Xcode is one of the things that are
really *bad* usability-wise now. Apple doesn’t care, because for Apple this is
the “if you are not using Xcode we don’t care much” path, but I don’t think we
want to follow that.
(1) install symlink to qmake into /usr or /usr/local
(2) install symlinks to all .frameworks into /Library/Frameworks
I’m actually glad that we got rid of system wide installs (that we did for
Qt4), so I don’t think system wide installs would be a good direction to go.
It’s also not very common to do that on OS X.
Again we can make it as Qt Creator plugin, rather putting it into base code.
Since these are symlinks, even if we trash Qt Creator.app (and all SDKs
within) these will be dangling, but not occupying any space on the disk.
That would be highly unintuitive (after all it is supposed to be *installed*),
and counter productive to the “I don’t want Qt Creator” case (you can’t
“install the tools” and trash Qt Creator). Again, Apple doesn’t care with
Xcode, I think we should.
Finally regarding maintenance burden: actually there would be less, because
we will get the .qtsdk helper and Qt Creator plugin just once. Then making
OSX Qt bundles will be less work, since it would be what it done right now
minus creating Qt installer framework based installer app.
I can’t follow that calculation.
We’d still need the online installer functionality *somewhere*. Which would
functionality-wise be mostly what the current installer framework does, so we’d
still need to maintain installer framework for Mac, or the exact same
functionality in a Qt Creator plugin: Component management (what is available
on the remote repository, what is installed, what should be installed +
deinstalled), downloading and installing components (even if the last is just
unpackaging some package somewhere), uninstalling components.
Adding plugins into the respective frameworks would simplify deployment
significantly. macdeployqt's task would be reduced to inspecting the
frameworks the app links against, and copying the framework folders into the
bundle. Don't need to think about plugins, don't need to mess with install
names. It just
[Development] New Qt 5.2 snapshot build #172 available..
Hi,
We have new Qt 5.2 snapshot packages now available
http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-26_172/
Unfortunately Linux installers are not available.
These packages are considered to be really close to RC1 release packages.
Please report your testing effort via
http://testresults.qt-project.org/forms/release-testing form and in case of
new bugs report those in JIRA https://bugreports.qt-project.org .
Br,
Akseli
Latest Qt5 changes in new packages:
* qtbase eafa224...40290b0 (10):
actually complain about invalid -[no-]{sql|imageformat}-* options
iOS: update keyboard layout upon focus transfer
iOS: add [QUIView updateTextInputTraits]
iOS: dont loose precision when converting CG types
iOS: dont scroll after inputItem has moved
iOS: scroll screen when keyboard opens
iOS: Do not skip building QtGraphicalEffects module
iOS: Do not skip building QtQuickControls module
iOS: Do not skip building QtMultimedia
Allow for QtDeclarative and QtQml to co-exist at run-time
* qtdeclarative 1b8795e...ce38c71 (10):
Fix out of bounds array access when index is integer and negative
Use QFontDatabase to check if a font is scalable.
Stop render thread regardless when the window is being destroyed
Fix rendering of Flipable content.
No assert when the focus changes and a window has no active focus item.
Fix memory corruption in QML expression compilation
Allow for QtQml and QtDeclarative to co-exist at run-time
Do not crash when resizing invisible (non-tracked) windows.
Android: Add qmltooling plugins to apk
Be even more tolerant towards broken platform behavior.
* qtmultimedia f0f6205...041e75d (1):
Add mmrenderer configure check
* qtserialport dc4e899...e0be9ed (1):
Fix the detection of PCI serial ports with sysfs and without udev
* qtbase a474b1d...eafa224 (19):
iOS: decouple QIOSWindow and QIOSInputContext
fix handling of \\ in replacement string in s/// cmd of built-in sed
Fixed assert in Windows key handling
fix handling of | in s/// commands of built-in sed
adequately shell-escape generated sed commands
Prepare for printing support.
Add PPS configure check
QNX: Only link libclipboard when building with clipboard support
BlackBerry: Fixed root window size, continued
Avoid incorrect warning when painting onto a QImage
iOS: Re-enable kEAGLDrawablePropertyRetainedBacking
iOS: Deliver resize events synchronously after setGeometry for QtWidgets
iOS: Allow QBackingStore::flush() without beginPaint()
iOS: Fix build against iOS 5 SDK and auto-rotation on iOS 5
iOS: Use separate release pool for qt_ios_version()
iOS: Change show() to imply maximize, and showFullScreen() to hide status bar
iOS: Take position of root viewcontroller into account for geometry changes
iOS: Fix when and how we send geometry and expose events
Add convenience macros for checking OS X and iOS platform SDK and target
* qtdeclarative 475879b...51da186 (5):
Android: Add qmltooling plugins to apk
Be even more tolerant towards broken platform behavior.
QtQuick.Dialogs MessageDialog docs
Safeguard the threaded renderloop against incorrectly exposed windows.
Avoid symbol clashes when linking QtDeclarative and QtScript statically
* qtquickcontrols bc477d4...34523bb (1):
Set more window flags to keep Windows from omitting titlebar buttons
* qttools 082efca...9ca1e89 (1):
rewrite support for listing translation files as sources
* qttranslations 604441b...46718cc (1):
Ukrainian translation update
* qtwebkit 8d3a152...fb02f6e (1):
Doc: Fix issues in Qt WebKit documentation config file
* qtwinextras 7317f44...4431a4d (1):
Fix disableBlurBehindWindow(QWidget*)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
FYI, installer font is still messed up on OSX 10.9. I have tried to find the original bug report but only found QT 4.8.x reports marked fixed: https://bugreports.qt-project.org/browse/QTBUG-33049 https://bugreports.qt-project.org/browse/QTBUG-32789 https://bugreports.qt-project.org/browse/QTBUG-31803 Still now way to *not* install Qt Creator: (bug reported last year) https://bugreports.qt-project.org/browse/QTBUG-28101 Also now way to not install documentation and examples: https://bugreports.qt-project.org/browse/QTBUG-34870 Regards, -- Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
The installers are built with 4.8.5, right? My fix for the font issue (https://bugreports.qt-project.org/browse/QTBUG-32789, https://codereview.qt-project.org/#change,70097) won't be in until 4.8.6. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Nov 26, 2013, at 9:43 AM, Adam Strzelecki o...@java.pl wrote: FYI, installer font is still messed up on OSX 10.9. I have tried to find the original bug report but only found QT 4.8.x reports marked fixed: https://bugreports.qt-project.org/browse/QTBUG-33049 https://bugreports.qt-project.org/browse/QTBUG-32789 https://bugreports.qt-project.org/browse/QTBUG-31803 Still now way to *not* install Qt Creator: (bug reported last year) https://bugreports.qt-project.org/browse/QTBUG-28101 Also now way to not install documentation and examples: https://bugreports.qt-project.org/browse/QTBUG-34870 Regards, -- Adam ___ 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] New Qt 5.2 snapshot build #172
-Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Adam Strzelecki Sent: Tuesday, November 26, 2013 3:43 PM To: development@qt-project.org Subject: Re: [Development] New Qt 5.2 snapshot build #172 FYI, installer font is still messed up on OSX 10.9. I have tried to find the original bug report but only found QT 4.8.x reports marked fixed: https://bugreports.qt-project.org/browse/QTBUG-33049 https://bugreports.qt-project.org/browse/QTBUG-32789 https://bugreports.qt-project.org/browse/QTBUG-31803 Well, they're fixed for Qt 4.8.6, which isn't released yet. Not sure we should start cherry-picking because of it... The bug reports sound like it's just a minor ugliness (though I haven't seen it live yet). Still now way to *not* install Qt Creator: (bug reported last year) https://bugreports.qt-project.org/browse/QTBUG-28101 Yeah. Unfortunately it's not that easy to fix, since the Qt versions / toolchains packages register themselves into Qt Creator. Also now way to not install documentation and examples: https://bugreports.qt-project.org/browse/QTBUG-34870 I personally don't see the point in such fine grain splits. It's a nightmare to test, and there are few people who care (otherwise https://bugreports.qt-project.org/browse/QTBUG-33121 would have been spotted by more people, I guess). Regards Kai Regards, -- Adam ___ 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] New Qt 5.2 snapshot build #172
On terça-feira, 26 de novembro de 2013 14:55:52, Koehne Kai wrote: FYI, installer font is still messed up on OSX 10.9. I have tried to find the original bug report but only found QT 4.8.x reports marked fixed: https://bugreports.qt-project.org/browse/QTBUG-33049 https://bugreports.qt-project.org/browse/QTBUG-32789 https://bugreports.qt-project.org/browse/QTBUG-31803 Well, they're fixed for Qt 4.8.6, which isn't released yet. Not sure we should start cherry-picking because of it... The bug reports sound like it's just a minor ugliness (though I haven't seen it live yet). This is the first thing users see. It will detract from the perception of Qt's quality. And it's not like we didn't know about this -- we just failed to put two and two together. How difficult is it to cherry-pick the fixes into the installer framework build? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
On Nov 26, 2013, at 10:22 AM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 26 de novembro de 2013 14:55:52, Koehne Kai wrote: FYI, installer font is still messed up on OSX 10.9. I have tried to find the original bug report but only found QT 4.8.x reports marked fixed: https://bugreports.qt-project.org/browse/QTBUG-33049 https://bugreports.qt-project.org/browse/QTBUG-32789 https://bugreports.qt-project.org/browse/QTBUG-31803 Well, they're fixed for Qt 4.8.6, which isn't released yet. Not sure we should start cherry-picking because of it... The bug reports sound like it's just a minor ugliness (though I haven't seen it live yet). This is the first thing users see. It will detract from the perception of Qt's quality. And it's not like we didn't know about this -- we just failed to put two and two together. I completely agree; this should be fixed for the 5.2 final. How difficult is it to cherry-pick the fixes into the installer framework build? It's just one patch. Alternatively, use QFont::insertSubstitution(.Lucida Grande UI, Lucida Grande) for these builds of QIF when running on OS X = 10.9 if that's simpler. -- 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 -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
Yeah. Unfortunately it's not that easy to fix, since the Qt versions / toolchains packages register themselves into Qt Creator. Does it have to be so complicated? Why QtCreator just not figures out installed Qt versions upon next run if they are installed on well known location, otherwise just asks user. Also Qt installer does really many unnecessary (obsolete) things considering supported OSX versions: https://bugreports.qt-project.org/browse/QTBUG-31814 Also now way to not install documentation and examples: https://bugreports.qt-project.org/browse/QTBUG-34870 I personally don't see the point in such fine grain splits. It's a nightmare to test, and there are few people who care (otherwise https://bugreports.qt-project.org/browse/QTBUG-33121 would have been spotted by more people, I guess). Right now the choice is really limited to: (1) Installing QtCreator only (2) Installing QtCreator+Qt frameworks (3) Installing all above+Sources The question is why then we need installer at all, if it has so minimal added value? Look at Xcode, everything embedded into Xcode.app. On Mac it is really ugly way to ship anything with own custom installer. Even Microsoft Nvidia use native packages. I have really Mac-centric point of view, but unfortunately Qt5 packaging is really Windows-centric, and that’s not the way Mac users like it. On Mac Qt4 was really close to what Xcode packaging was, not anymore for Qt5. It is isn’t also Linux friendly, coz if it was it would be shipped as pair of RPM/DEB custom repos installing into /opt, not .run like custom installers. Again NVIDIA does it well. Also sooner or later someone has to create these packages to bundle with specific distro. Finally if Qt installer framework has online installer capability, why not embed it into QtCreator itself and let user download Qt SDK components from the app. Need complete offline version? Ship both bare QtCreator and one with all components preinstalled. Cheers, -- Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
I have to agree with Thiago. I tried the install on a retina mac book/10.9 two weeks ago, and the installer looked extremely ugly. It simply doesn¹t make for a good first impression. Cheers, Lars On 26.11.13 16:22, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 26 de novembro de 2013 14:55:52, Koehne Kai wrote: FYI, installer font is still messed up on OSX 10.9. I have tried to find the original bug report but only found QT 4.8.x reports marked fixed: https://bugreports.qt-project.org/browse/QTBUG-33049 https://bugreports.qt-project.org/browse/QTBUG-32789 https://bugreports.qt-project.org/browse/QTBUG-31803 Well, they're fixed for Qt 4.8.6, which isn't released yet. Not sure we should start cherry-picking because of it... The bug reports sound like it's just a minor ugliness (though I haven't seen it live yet). This is the first thing users see. It will detract from the perception of Qt's quality. And it's not like we didn't know about this -- we just failed to put two and two together. How difficult is it to cherry-pick the fixes into the installer framework build? -- 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
Re: [Development] New Qt 5.2 snapshot build #172
On Nov 26, 2013, at 10:52 AM, Adam Strzelecki o...@java.pl wrote:
Yeah. Unfortunately it's not that easy to fix, since the Qt versions /
toolchains packages register themselves into Qt Creator.
Does it have to be so complicated? Why QtCreator just not figures out
installed Qt versions upon next run if they are installed on well known
location, otherwise just asks user.
Also Qt installer does really many unnecessary (obsolete) things considering
supported OSX versions:
https://bugreports.qt-project.org/browse/QTBUG-31814
Also now way to not install documentation and examples:
https://bugreports.qt-project.org/browse/QTBUG-34870
I personally don't see the point in such fine grain splits. It's a nightmare
to test, and there are few people who care (otherwise
https://bugreports.qt-project.org/browse/QTBUG-33121 would have been spotted
by more people, I guess).
Right now the choice is really limited to:
(1) Installing QtCreator only
(2) Installing QtCreator+Qt frameworks
(3) Installing all above+Sources
The question is why then we need installer at all, if it has so minimal added
value? Look at Xcode, everything embedded into Xcode.app. On Mac it is really
ugly way to ship anything with own custom installer. Even Microsoft Nvidia
use native packages.
I have really Mac-centric point of view, but unfortunately Qt5 packaging is
really Windows-centric, and that’s not the way Mac users like it. On Mac Qt4
was really close to what Xcode packaging was, not anymore for Qt5.
It is isn’t also Linux friendly, coz if it was it would be shipped as pair of
RPM/DEB custom repos installing into /opt, not .run like custom installers.
Again NVIDIA does it well. Also sooner or later someone has to create these
packages to bundle with specific distro.
Finally if Qt installer framework has online installer capability, why not
embed it into QtCreator itself and let user download Qt SDK components from
the app. Need complete offline version? Ship both bare QtCreator and one with
all components preinstalled.
Cheers,
--
Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
I agree with everything you say and as an OS X user I feel your pain. Qt SDK
absolutely should be a drag and drop installer just like Xcode. Unfortunately
there are some major blockers in the way before we could begin to think about
doing that - see https://bugreports.qt-project.org/browse/QTBUG-14150 (and
https://bugreports.qt-project.org/browse/QTBUG-31814 as you said).
I would argue there is value in an installer since there are multiple versions
of the SDK available. But then again... an online installer is an easy way
around this - put package management into Qt Creator preferences and store SDKs
in /Applications/Qt Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ But
what exactly do you include in the offline installer? OS X, iOS and two or
three Android versions (and eventually BlackBerry?)? That would be massive. One
solution is that SDKs bundles in a DMG could be provided as separate downloads
(and the builtin package manager in QtC could automate downloading and
installing them). The .qtsdk extension could be registered with Creator -
double clicking it registers it with the Qt Creator version it's opened with,
and QtC pops up a dialog even offering to move the SDK folder within its app
bundle.
To use the .qtsdk by itself (without QtC) just drop the folder somewhere and go.
These are nice eventual goals but it will take a lot of work in different areas
to get there.
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
On terça-feira, 26 de novembro de 2013 11:56:20, Jake Petroules wrote:
I agree with everything you say and as an OS X user I feel your pain. Qt SDK
absolutely should be a drag and drop installer just like Xcode.
Unfortunately there are some major blockers in the way before we could
begin to think about doing that - see
https://bugreports.qt-project.org/browse/QTBUG-14150 (and
https://bugreports.qt-project.org/browse/QTBUG-31814 as you said).
One big advantage is that we maintain one single codebase for all platforms.
Doing it the Mac way requires us to start doing Qt SDKs installations per
platform.
I would argue there is value in an installer since there are multiple
versions of the SDK available. But then again... an online installer is an
easy way around this - put package management into Qt Creator preferences
and store SDKs in /Applications/Qt
Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ But what exactly do
you include in the offline installer? OS X, iOS and two or three Android
versions (and eventually BlackBerry?)? That would be massive. One solution
is that SDKs bundles in a DMG could be provided as separate downloads (and
the builtin package manager in QtC could automate downloading and
installing them). The .qtsdk extension could be registered with Creator -
double clicking it registers it with the Qt Creator version it's opened
with, and QtC pops up a dialog even offering to move the SDK folder within
its app bundle.
I'd expect you to download one .dmg that contains Creator and the online
installer / update tool. Then you *need* to run the update tool to download
any Qt version. Before you do that, Qt Creator is useful for writing C++ code,
but there will be no Qt versions to link against.
Also, the online update tool should be separate from Creator: don't install
the toolchains inside the Qt Creator bundle. That way, if someone wants to use
XCode and not Creator, they can simply remove the bundle by dragging to the
Trash.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.2 snapshot build #172
On Nov 26, 2013, at 1:19 PM, Thiago Macieira thiago.macie...@intel.com wrote:
On terça-feira, 26 de novembro de 2013 11:56:20, Jake Petroules wrote:
I agree with everything you say and as an OS X user I feel your pain. Qt SDK
absolutely should be a drag and drop installer just like Xcode.
Unfortunately there are some major blockers in the way before we could
begin to think about doing that - see
https://bugreports.qt-project.org/browse/QTBUG-14150 (and
https://bugreports.qt-project.org/browse/QTBUG-31814 as you said).
One big advantage is that we maintain one single codebase for all platforms.
Doing it the Mac way requires us to start doing Qt SDKs installations per
platform.
Single codebase but a degraded user experience that makes Qt less appealing out
of the box than, say, Xcode. If anything I would guess the Mac way would even
be simpler than the other platforms.
There's a good reason VLC, for example, uses a native Cocoa UI on OS X and Qt
only for the rest. Overall, Qt for OS X just isn't that great in a lot of
areas, specifically UI and system integration. Unfortunately these areas happen
to be the most noticeable ones, and taking only OS X into account, leads to the
native development tools being the best ones for the job in the majority of
cases... and even sometimes for cross-platform apps like VLC.
On Windows, Qt is quite often better than the native tools (Win32, MFC) - it
would be nice to see that eventually become the case for OS X as well.
I would argue there is value in an installer since there are multiple
versions of the SDK available. But then again... an online installer is an
easy way around this - put package management into Qt Creator preferences
and store SDKs in /Applications/Qt
Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ But what exactly do
you include in the offline installer? OS X, iOS and two or three Android
versions (and eventually BlackBerry?)? That would be massive. One solution
is that SDKs bundles in a DMG could be provided as separate downloads (and
the builtin package manager in QtC could automate downloading and
installing them). The .qtsdk extension could be registered with Creator -
double clicking it registers it with the Qt Creator version it's opened
with, and QtC pops up a dialog even offering to move the SDK folder within
its app bundle.
I'd expect you to download one .dmg that contains Creator and the online
installer / update tool. Then you *need* to run the update tool to download
any Qt version. Before you do that, Qt Creator is useful for writing C++
code,
but there will be no Qt versions to link against.
Also, the online update tool should be separate from Creator: don't install
the toolchains inside the Qt Creator bundle. That way, if someone wants to
use
XCode and not Creator, they can simply remove the bundle by dragging to the
Trash.
Yes, that makes sense. Qt Creator could install the SDK manager tool to
/Library/Qt/Qt SDK Manager.app - or /Applications to make it more accessible if
the user opts to trash Creator. (it would also have a nice icon - the Qt icon
with a opened box overlaid on the corner? :) ) The SDK manager app could
install Qt SDKs to /Library/Qt/SDKs, so for example the base path of a Qt 5 SDK
for OS X would be /Library/Qt/SDKs/Qt5.2.0-macx-clang.qtsdk. Or ~/Library/Qt if
we don't want to bother with elevated permissions. As I said before, *.qtsdk
could be registered as a bundle, so it could contain an Info.plist at the root
which would describe the properties of the SDK as necessary (mkspec, version
number, display name). The layout might look something like:
- Qt5.2.0-macx-clang.qtsdk/
-- Applications/
--- Assistant.app, Designer.app, Linguist.app, QMLViewer.app, pixeltool.app
(what is the point of this thing?)
-- bin/ (non-bundle binaries only!)
--- qmake, moc, rcc, uic, etc...
-- imports/
-- include/ (this could be omitted for framework builds, there's no point
duplicating the header locations... if we need this for backwards compat, at
least symlink them to the framework bundles, it wastes space otherwise)
-- lib/ (non-framework libraries only!)
-- libexec/
-- Library/Frameworks/
--- QtGui.framework/PlugIns
libqgif.dylib, libqico.dylib, ... (perhaps bundles)
-- mkspecs/
-- phrasebooks/
-- plugins/{category}/ (non-framework builds only)
-- qml
-- translations
The SDK manager tool could also add symlinks such as Qt5.2.qtsdk, Qt5.qtsdk,
pointing to the latest versions for convenience.
Adding plugins into the respective frameworks would simplify deployment
significantly. macdeployqt's task would be reduced to inspecting the frameworks
the app links against, and copying the framework folders into the bundle. Don't
need to think about plugins, don't need to mess with install names. It just
works.™
A rather fascinating aspect of having a fixed install path such as /Library/Qt
is that macdeployqt could have an option to copy Qt to the lesser
Re: [Development] New Qt 5.2 snapshot build #172
On terça-feira, 26 de novembro de 2013 14:46:06, Jake Petroules wrote: One big advantage is that we maintain one single codebase for all platforms. Doing it the Mac way requires us to start doing Qt SDKs installations per platform. Single codebase but a degraded user experience that makes Qt less appealing out of the box than, say, Xcode. If anything I would guess the Mac way would even be simpler than the other platforms. Understood. However, the one big advantage of one codebase is that of lesser maintenance burden. If we start maintaining a Mac-specific installer layout and installer tools, it increases our burden. And most likely we'd need to create Linux binary packages using build.opensuse.org too, which again adds burden. So, as much as this would look desirable, it will not leave the paper unless someone volunteers to start experimenting with it. Let's see some volunteers trying it during the 5.2.x timeframe. If it works fine, we can release it officially for 5.3.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
