Re: [Development] Frameworks on Mac?

2012-11-22 Thread Sorvig Morten

On Nov 22, 2012, at 6:52 AM, Thiago Macieira thiago.macie...@intel.com
 wrote:
 
 That's the point: the conclusion was that the default on Mac is to *not* have 
 frameworks anymore. It might have been the case in the past, but recently the 
 trend has been to have regular libraries. Apple themselves are now preferring 
 that way, by having a full system sysroot shipped with XCode, for each 
 supported version of Mac OS X.

The sysroots have frameworks, so the notion that Apple is moving away from 
frameworks is inaccurate. There are .dylibs as well, mostly for the Darwin 
layer.

 
 Though I confess I don't understand why the frameworks in 
 /System/Library/Frameworks have headers inside.
 
 Besides, I'm told that deploying frameworks inside app bundles is harder than 
 deploying simple shared libraries.

Not that much harder. I don't think this is a very good argument for dropping 
framework support.

I also missed this part of the discussion. Can the case for making 
non-framework builds the default be presented again?

Morten

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


[Development] Examples packaging

2012-11-22 Thread Kalinowski Maurice
Hi,

We are currently going through the examples for the final Qt 5 packages and as 
mentioned before, there are some differences compared to Qt 4 packaging.

Most prominently, examples are packaged via make install and then taken from 
the prefix directory. This has two problems:
a) We need to adapt some install rules to also include dependencies, otherwise 
they would not build on user's target installation
b) We are packaging a whole bunch of generated binaries (the example binaries 
themselves) while one would expect users to use qmake/make in any case.

Also install rules are a bit misused as they need to install the sources, which 
is what you usually do not want to do and taking example code as a guideline 
for beginners might lead them into the wrong direction.

My question is, what are the benefits compared to picking the example source 
code from the source package directly. Does anybody really want to have 
prebuilt binaries in the examples directory? Current assumption is that you go 
through the list via Qt Creator and build the examples are required for testing 
purposes.

 As we are so close to the final release, most likely nothing will happen 
within the 5.0 timeframe, but we should aim for a decision at least for 5.1.

BR,
Maurice

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Rutledge Shawn
On 22 Nov 2012, at 9:08 AM, Sorvig Morten wrote:

 
 On Nov 22, 2012, at 6:52 AM, Thiago Macieira thiago.macie...@intel.com
 wrote:
 
 That's the point: the conclusion was that the default on Mac is to *not* 
 have 
 frameworks anymore. It might have been the case in the past, but recently 
 the 
 trend has been to have regular libraries. Apple themselves are now 
 preferring 
 that way, by having a full system sysroot shipped with XCode, for each 
 supported version of Mac OS X.
 
 The sysroots have frameworks, so the notion that Apple is moving away from 
 frameworks is inaccurate. There are .dylibs as well, mostly for the Darwin 
 layer.
 
 
 Though I confess I don't understand why the frameworks in 
 /System/Library/Frameworks have headers inside.
 
 Besides, I'm told that deploying frameworks inside app bundles is harder 
 than 
 deploying simple shared libraries.
 
 Not that much harder. I don't think this is a very good argument for dropping 
 framework support.
 
 I also missed this part of the discussion. Can the case for making 
 non-framework builds the default be presented again?

I don't understand either; I thought that frameworks have the advantage of 
being shared between applications.  If one application includes Qt 5.0.0 in the 
.app bundle and another includes 5.0.1, and you run both of them, does it mean 
that you will have duplicates of all the libraries that those apps need, in 
memory?  It's bad enough that they will be duplicated on disk, but I know it's 
becoming the norm not to worry about that, in exchange for not having the 
problems that Windows often does with incompatible DLL versions.  But we 
guarantee binary compatibility, so shouldn't it be OK for an application 
installer to upgrade the system Qt framework at the same time, the way an 
application's Windows installer would typically do?  (I'm referring to ordinary 
users rather than developers)

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Volker Götz
Hi,

Am 22.11.2012 um 11:42 schrieb Rutledge Shawn:

 I don't understand either; I thought that frameworks have the advantage of 
 being shared between applications.  If one application includes Qt 5.0.0 in 
 the .app bundle and another includes 5.0.1, and you run both of them, does it 
 mean that you will have duplicates of all the libraries that those apps need, 
 in memory?  It's bad enough that they will be duplicated on disk, but I know 
 it's becoming the norm not to worry about that, in exchange for not having 
 the problems that Windows often does with incompatible DLL versions.  But we 
 guarantee binary compatibility, so shouldn't it be OK for an application 
 installer to upgrade the system Qt framework at the same time, the way an 
 application's Windows installer would typically do?  (I'm referring to 
 ordinary users rather than developers)

Usually, there are NO application installers on the Mac.

The regular way is to have application bundles (directories with a certain 
structure; the name ends on .app and is treated like a single file in the 
Finder) that contain everything that is needed to run the program, including 
all libraries and/or frameworks that are not pre-installed on the system. You 
just put that application binary into a ZIP or (preferrably) a disk image (DMG) 
and the user just drags and drops the application to a place on the filesystem.

Using frameworks inside an application bundle is possible, but a bit overkill, 
as one does not need to ship the header files in a release version (it bloats 
the size of the application bundle too).


Cheers
Volker___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Raul Metsma
I think we should keep the frameworks and we can add plugins into the framework 
bundle.
(eg. qjpeg, qtiff, qaccessibility into the QtGui.framework and character and 
general plugins into QtCore.framework)
It will simplify probably the deploy process.

Raul

On Nov 22, 2012, at 1:06 PM, Volker Götz berlinbik...@googlemail.com wrote:

 Hi,
 
 Am 22.11.2012 um 11:42 schrieb Rutledge Shawn:
 
 I don't understand either; I thought that frameworks have the advantage of 
 being shared between applications.  If one application includes Qt 5.0.0 in 
 the .app bundle and another includes 5.0.1, and you run both of them, does 
 it mean that you will have duplicates of all the libraries that those apps 
 need, in memory?  It's bad enough that they will be duplicated on disk, but 
 I know it's becoming the norm not to worry about that, in exchange for not 
 having the problems that Windows often does with incompatible DLL versions.  
 But we guarantee binary compatibility, so shouldn't it be OK for an 
 application installer to upgrade the system Qt framework at the same time, 
 the way an application's Windows installer would typically do?  (I'm 
 referring to ordinary users rather than developers)
 
 Usually, there are NO application installers on the Mac.
 
 The regular way is to have application bundles (directories with a certain 
 structure; the name ends on .app and is treated like a single file in the 
 Finder) that contain everything that is needed to run the program, including 
 all libraries and/or frameworks that are not pre-installed on the system. You 
 just put that application binary into a ZIP or (preferrably) a disk image 
 (DMG) and the user just drags and drops the application to a place on the 
 filesystem.
 
 Using frameworks inside an application bundle is possible, but a bit 
 overkill, as one does not need to ship the header files in a release version 
 (it bloats the size of the application bundle too).
 
 
 Cheers
 Volker
 ___
 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] Frameworks on Mac?

2012-11-22 Thread Rutledge Shawn

On 22 Nov 2012, at 12:06 PM, Volker Götz wrote:

 Hi,
 
 Am 22.11.2012 um 11:42 schrieb Rutledge Shawn:
 
 I don't understand either; I thought that frameworks have the advantage of 
 being shared between applications.  If one application includes Qt 5.0.0 in 
 the .app bundle and another includes 5.0.1, and you run both of them, does 
 it mean that you will have duplicates of all the libraries that those apps 
 need, in memory?  It's bad enough that they will be duplicated on disk, but 
 I know it's becoming the norm not to worry about that, in exchange for not 
 having the problems that Windows often does with incompatible DLL versions.  
 But we guarantee binary compatibility, so shouldn't it be OK for an 
 application installer to upgrade the system Qt framework at the same time, 
 the way an application's Windows installer would typically do?  (I'm 
 referring to ordinary users rather than developers)
 
 Usually, there are NO application installers on the Mac.
 
 The regular way is to have application bundles (directories with a certain 
 structure; the name ends on .app and is treated like a single file in the 
 Finder) that contain everything that is needed to run the program, including 
 all libraries and/or frameworks that are not pre-installed on the system. You 
 just put that application binary into a ZIP or (preferrably) a disk image 
 (DMG) and the user just drags and drops the application to a place on the 
 filesystem.

Yeah I know, and that's very convenient, but I've seen installers sometimes 
too.  

We could even offer a way to make it easy for application developers to make 
installers, in order to standardize the Qt framework installation at bit more.  
For example QBS could generate a target to build an installer.  If it will save 
memory on users' systems, it seems like a good thing, right?

Or maybe an application could install or upgrade the framework the first time 
it is run, and then delete its own copy from inside the .app bundle?  I'm sure 
that's unconventional, but I wonder if it's possible.

 Using frameworks inside an application bundle is possible, but a bit 
 overkill, as one does not need to ship the header files in a release version 
 (it bloats the size of the application bundle too).

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Konstantin Tokarev


22.11.2012, 16:04, Rutledge Shawn shawn.rutle...@digia.com:
 On 22 Nov 2012, at 12:06 PM, Volker Götz wrote:

  Hi,

  Am 22.11.2012 um 11:42 schrieb Rutledge Shawn:
  I don't understand either; I thought that frameworks have the advantage of 
 being shared between applications.  If one application includes Qt 5.0.0 in 
 the .app bundle and another includes 5.0.1, and you run both of them, does 
 it mean that you will have duplicates of all the libraries that those apps 
 need, in memory?  It's bad enough that they will be duplicated on disk, but 
 I know it's becoming the norm not to worry about that, in exchange for not 
 having the problems that Windows often does with incompatible DLL versions. 
  But we guarantee binary compatibility, so shouldn't it be OK for an 
 application installer to upgrade the system Qt framework at the same time, 
 the way an application's Windows installer would typically do?  (I'm 
 referring to ordinary users rather than developers)
  Usually, there are NO application installers on the Mac.

  The regular way is to have application bundles (directories with a certain 
 structure; the name ends on .app and is treated like a single file in the 
 Finder) that contain everything that is needed to run the program, including 
 all libraries and/or frameworks that are not pre-installed on the system. 
 You just put that application binary into a ZIP or (preferrably) a disk 
 image (DMG) and the user just drags and drops the application to a place on 
 the filesystem.

 Yeah I know, and that's very convenient, but I've seen installers sometimes 
 too.

 We could even offer a way to make it easy for application developers to make 
 installers, in order to standardize the Qt framework installation at bit 
 more.  For example QBS could generate a target to build an installer.  If it 
 will save memory on users' systems, it seems like a good thing, right?

There's installer of Qt which install Qt frameworks globally to the system. 
However, sharing them between application on end-user system is not a good 
idea, because it may result in conflicts between Qt applications.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Volker Götz

Am 22.11.2012 um 13:03 schrieb Rutledge Shawn:
 
 The regular way is to have application bundles (directories with a certain 
 structure; the name ends on .app and is treated like a single file in the 
 Finder) that contain everything that is needed to run the program, including 
 all libraries and/or frameworks that are not pre-installed on the system. 
 You just put that application binary into a ZIP or (preferrably) a disk 
 image (DMG) and the user just drags and drops the application to a place on 
 the filesystem.
 
 Yeah I know, and that's very convenient, but I've seen installers sometimes 
 too.  
 
 We could even offer a way to make it easy for application developers to make 
 installers, in order to standardize the Qt framework installation at bit 
 more.  For example QBS could generate a target to build an installer.  If it 
 will save memory on users' systems, it seems like a good thing, right?
 
 Or maybe an application could install or upgrade the framework the first time 
 it is run, and then delete its own copy from inside the .app bundle?  I'm 
 sure that's unconventional, but I wonder if it's possible.

While that may ease the live of developers, it will annoy the *users* of the 
application for sure. Mac folks are used to just drag an application bundle and 
drop it somewhere. Installers for applications are rarely used and regarded 
inconvenient. Additionally, if you want to remove something that has been 
deployed with an installer, you're basically lost, as there is NO builtin means 
to do that.

Do it the Mac way on a Mac (application bundle that contains everything) (*1)
Do it the Linux way on Linux (a distro package)
Do it the Windows way on a Windows box (usually an installer)
Don't try to mimic the behavior on one platform on another one just for the 
sake of developers' laziness, but think of a good deployment UX for your 
application's users.

(*1) whether using frameworks or plain dylibs doesn't matter here

Cheers
Volker

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Sorvig Morten
On Nov 22, 2012, at 1:08 PM, Konstantin Tokarev annu...@yandex.ru
 wrote:
 
 22.11.2012, 16:04, Rutledge Shawn shawn.rutle...@digia.com:
 On 22 Nov 2012, at 12:06 PM, Volker Götz wrote:
 
 
 Yeah I know, and that's very convenient, but I've seen installers sometimes 
 too.
 
 We could even offer a way to make it easy for application developers to make 
 installers, in order to standardize the Qt framework installation at bit 
 more.  For example QBS could generate a target to build an installer.  If it 
 will save memory on users' systems, it seems like a good thing, right?
 
 There's installer of Qt which install Qt frameworks globally to the system. 
 However, sharing them between application on end-user system is not a good 
 idea, because it may result in conflicts between Qt applications.

I think the way to go for deployment on Mac is definitively self-contained app 
bundles where each app carries its own copy of Qt. This is what macdeployqt 
creates. Anything else is as you say just going to create conflicts. 
Self-contained bundles are also enforced by the app store. 

It does not really matter if Qt is deployed as frameworks or .dylibs inside the 
bundle.

Morten

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Rutledge Shawn
On 22 Nov 2012, at 1:18 PM, Sorvig Morten wrote:

 On Nov 22, 2012, at 1:08 PM, Konstantin Tokarev annu...@yandex.ru
 wrote:
 
 22.11.2012, 16:04, Rutledge Shawn shawn.rutle...@digia.com:
 Yeah I know, and that's very convenient, but I've seen installers sometimes 
 too.
 
 We could even offer a way to make it easy for application developers to 
 make installers, in order to standardize the Qt framework installation at 
 bit more.  For example QBS could generate a target to build an installer.  
 If it will save memory on users' systems, it seems like a good thing, right?
 
 There's installer of Qt which install Qt frameworks globally to the system. 
 However, sharing them between application on end-user system is not a good 
 idea, because it may result in conflicts between Qt applications.
 
 I think the way to go for deployment on Mac is definitively self-contained 
 app bundles where each app carries its own copy of Qt. This is what 
 macdeployqt creates. Anything else is as you say just going to create 
 conflicts. Self-contained bundles are also enforced by the app store. 

Well if our binary compatibility guarantee is true, then what conflicts do we 
worry about?  If an app depends on new features which were added in a 
point-release, then it will not work with an older Qt, but an application which 
was shipped with the older version ought to work just as well with the newer 
one.  On Windows and Linux we depend on that, right?

Isn't it true that duplicate copies of Qt in every application will result in 
duplicate copies being loaded into RAM too?

I think maybe the operating system could do something about this problem, e.g. 
using hashing to de-duplicate code blocks or some such, but I wonder if that's 
ever been done, or would just be a good thesis topic at this point.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

2012-11-22 Thread Konstantin Ritt
Hi,

Plz check if the rich text editor example shows these Chinese
characters correctly.

Konstantin


2012/11/22 Yang Fan missd...@gmail.com:

 Hi All,

 Maybe it's not so suitable to ask here, since there's no reply in the
 Interest maillist.
 I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
 QtWebkit. But I found it couldn't display Chinese characters correctly on
 Windows, the official example under
 qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
 miss something? Someone has reported this issue before but got no reply.
 https://qt-project.org/forums/viewthread/21022 .
 Any suggestion would be appreciated.

 Regards,
 Fan Yang



 ___
 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] Examples packaging

2012-11-22 Thread Alan Alpert
On Thu, Nov 22, 2012 at 1:52 AM, Kalinowski Maurice
maurice.kalinow...@digia.com wrote:
 Hi,

 We are currently going through the examples for the final Qt 5 packages and 
 as mentioned before, there are some differences compared to Qt 4 packaging.

 Most prominently, examples are packaged via make install and then taken from 
 the prefix directory. This has two problems:
 a) We need to adapt some install rules to also include dependencies, 
 otherwise they would not build on user's target installation
 b) We are packaging a whole bunch of generated binaries (the example binaries 
 themselves) while one would expect users to use qmake/make in any case.

 Also install rules are a bit misused as they need to install the sources, 
 which is what you usually do not want to do and taking example code as a 
 guideline for beginners might lead them into the wrong direction.

 My question is, what are the benefits compared to picking the example source 
 code from the source package directly. Does anybody really want to have 
 prebuilt binaries in the examples directory? Current assumption is that you 
 go through the list via Qt Creator and build the examples are required for 
 testing purposes.

To my knowledge the point of having prebuilt examples is for use in
QtDemo. This demo application did a great job showcasing Qts
functionality even before developers chose to start an IDE.

  As we are so close to the final release, most likely nothing will happen 
 within the 5.0 timeframe, but we should aim for a decision at least for 5.1.

I don't think QtDemo made it into 5.0 :( . If we can bring it back for
5.1 then it's still worth having built examples for it to launch.

--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Examples packaging

2012-11-22 Thread Charley Bay
Maurice spaketh:

 snip,
  My question is, what are the benefits compared to picking the example
 source code from the source package directly. Does anybody really want to
 have prebuilt binaries in the examples directory? Current assumption is
 that you go through the list via Qt Creator and build the examples are
 required for testing purposes.


Alan respondeth:

 To my knowledge the point of having prebuilt examples is for use in
 QtDemo. This demo application did a great job showcasing Qts
 functionality even before developers chose to start an IDE.


+1

IMHO, it's quite important for people to be able to see-and-run the demos
before starting the IDE, before doing anything.

With the new dynamic interfaces, and rich network capability, etc., these
demos should really *attract* developers to adopt Qt, and we want to make
that introduction as easy-and-exciting-as-possible.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

2012-11-22 Thread Qi Liang
At least for me, browser could display simplified Chinese characters correctly 
on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe someone with 
your configuration could verify it works or not.

Have you created bug report?

Regards,
Liang


From: development-bounces+liang.qi=digia@qt-project.org 
[development-bounces+liang.qi=digia@qt-project.org] on behalf of Yang Fan 
[missd...@gmail.com]
Sent: Thursday, November 22, 2012 7:24 AM
To: development@qt-project.org
Subject: [Development] QtWebkit from Qt5 couldn't display Chinese characters 
correctly on Windows


Hi All,

Maybe it's not so suitable to ask here, since there's no reply in the Interest 
maillist.
I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build 
QtWebkit. But I found it couldn't display Chinese characters correctly on 
Windows, the official example under 
qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I miss 
something? Someone has reported this issue before but got no reply. 
https://qt-project.org/forums/viewthread/21022 .
Any suggestion would be appreciated.

Regards,
Fan Yang


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Examples packaging

2012-11-22 Thread Alan Alpert
On Thu, Nov 22, 2012 at 7:04 AM, Charley Bay charleyb...@gmail.com wrote:
 Maurice spaketh:

 snip,

  My question is, what are the benefits compared to picking the example
  source code from the source package directly. Does anybody really want to
  have prebuilt binaries in the examples directory? Current assumption is 
  that
  you go through the list via Qt Creator and build the examples are required
  for testing purposes.


 Alan respondeth:

 To my knowledge the point of having prebuilt examples is for use in
 QtDemo. This demo application did a great job showcasing Qts
 functionality even before developers chose to start an IDE.


 +1

 IMHO, it's quite important for people to be able to see-and-run the demos
 before starting the IDE, before doing anything.

 With the new dynamic interfaces, and rich network capability, etc., these
 demos should really *attract* developers to adopt Qt, and we want to make
 that introduction as easy-and-exciting-as-possible.

On the new features category, we had discussed a bit the next
generation QtDemo in Brisbane. What would be really cool for the QML
demos at least would be to have an editable code pane next to the
running example in the launcher. So you'd start by just playing around
looking at the running examples, but once one catches your interest
you can open up the code and start to play with it directly from there
(it's also a great place for designers to copy'n'paste effects from).

It's blurring the line between IDE and examples launcher, but it still
provides a demo application with that 'easy-and-exciting-as-possible'
introduction.

--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Thiago Macieira
On quinta-feira, 22 de novembro de 2012 07.44.24, Koehne Kai wrote:
  When I was doing the lib renaming, I thought we had concluded that
  frameworks on Mac were not going to be supported anymore.
 
 Can't find it anything on qt-development@. Maybe you are referring to this
 thread on qt-interest
 

I guess I misunderstood or I'm remembering things wrong then.

I think the decision was to remove the global install of Qt to 
/Library/Frameworks. Instead, Qt always comes in a sysroot-style prefix, 
whether it contains frameworks or pure dylibs.

  Imagine my surprise when I finish my first successful build on Mac and
  discover that frameworks are the default...
 
 Did your library renaming break anything with Frameworks, or did you just
 stumble over it?

There was a breakage, but that was avoided by not renaming the libraries when 
frameworks are built.

-- 
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] Frameworks on Mac?

2012-11-22 Thread Konstantin Tokarev


22.11.2012, 16:46, Rutledge Shawn shawn.rutle...@digia.com:
 On 22 Nov 2012, at 1:18 PM, Sorvig Morten wrote:

  On Nov 22, 2012, at 1:08 PM, Konstantin Tokarev annu...@yandex.ru
  wrote:
  22.11.2012, 16:04, Rutledge Shawn shawn.rutle...@digia.com:
  Yeah I know, and that's very convenient, but I've seen installers 
 sometimes too.

  We could even offer a way to make it easy for application developers to 
 make installers, in order to standardize the Qt framework installation at 
 bit more.  For example QBS could generate a target to build an installer.  
 If it will save memory on users' systems, it seems like a good thing, 
 right?
  There's installer of Qt which install Qt frameworks globally to the 
 system. However, sharing them between application on end-user system is not 
 a good idea, because it may result in conflicts between Qt applications.
  I think the way to go for deployment on Mac is definitively self-contained 
 app bundles where each app carries its own copy of Qt. This is what 
 macdeployqt creates. Anything else is as you say just going to create 
 conflicts. Self-contained bundles are also enforced by the app store.

 Well if our binary compatibility guarantee is true, then what conflicts do we 
 worry about?

Example from the past: there were Carbon and Cocoa builds of Qt, and some Qt 
application because of bugs in Cocoa version preferred to ship Carbon.
Example from nowadays: it's possible to build Qt with stlibc++ and libc++, 
which results in binary incompatible dylibs.


 If an app depends on new features which were added in a point-release, then 
it will not work with an older Qt, but an application which was shipped with 
the older version ought to work just as well with the newer one.

Well, newly released Qt version may contain bugs which are showstopper for one 
application, but unnoticeable for another one.

 On Windows and Linux we depend on that, right?

On Windows Qt is always not recommended to be installed system-wide. On Linux 
distro maintainers ensure that all Qt applications, shipped by distro, work 
properly with shipped Qt version. This is not the case for Mac and Windows.


 Isn't it true that duplicate copies of Qt in every application will result in 
 duplicate copies being loaded into RAM too?

Only if both are running at the same time.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread Frank Osterfeld

On Nov 22, 2012, at 1:44 PM, Rutledge Shawn wrote:
 
 Well if our binary compatibility guarantee is true, then what conflicts do we 
 worry about?  If an app depends on new features which were added in a 
 point-release, then it will not work with an older Qt, but an application 
 which was shipped with the older version ought to work just as well with the 
 newer one.

That's the theory. In practice, there are always bugs, regressions, behavioral 
changes. Shipping your own Qt isolates you from all those issues. 

   On Windows and Linux we depend on that, right?

Definitely not on Windows. On Windows, you also ship your own set of Qt DLLs 
when deploying software to end users, installing them in the folder of your 
application, not system-wide. So that's quite similar to OS X.
On Linux, you only get the goodies when providing proper distribution packages 
of your software. And don't tell me deploying for and then supporting all major 
Linux distributions is less an headache than building a Windows installer or a 
.dmg for OS X…

More importantly, let me quote the Mac App Store guidelines [1] (needs 
developer ID to access):

2.14 Apps must be packaged and submitted using Apple's packaging technologies 
included in Xcode - no third party installers allowed

2.15 Apps must be self-contained, single application installation bundles, and 
cannot install code or resources in shared locations

To be accepted on Mac, your application must install, look like and behave like 
a Mac application. People will want to distribute their application via the app 
store.
When in Rome, do as the Romans do - everything else is futile here to me.

[1] https://developer.apple.com/appstore/mac/resources/approval/guidelines.html

-- 
Frank Osterfeld | frank.osterf...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ)  +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions



smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Frameworks on Mac?

2012-11-22 Thread André Pönitz
On Thu, Nov 22, 2012 at 12:44:02PM +, Rutledge Shawn wrote:
 On 22 Nov 2012, at 1:18 PM, Sorvig Morten wrote:
 
  On Nov 22, 2012, at 1:08 PM, Konstantin Tokarev annu...@yandex.ru
  wrote:
  
  22.11.2012, 16:04, Rutledge Shawn shawn.rutle...@digia.com:
  Yeah I know, and that's very convenient, but I've seen installers
  sometimes too.
  
  We could even offer a way to make it easy for application developers
  to make installers, in order to standardize the Qt framework
  installation at bit more.  For example QBS could generate a target to
  build an installer.  If it will save memory on users' systems, it
  seems like a good thing, right?
  
  There's installer of Qt which install Qt frameworks globally to the
  system.  However, sharing them between application on end-user system
  is not a good idea, because it may result in conflicts between Qt
  applications.
  
  I think the way to go for deployment on Mac is definitively
  self-contained app bundles where each app carries its own copy of Qt.
  This is what macdeployqt creates. Anything else is as you say just
  going to create conflicts.  Self-contained bundles are also enforced by
  the app store. 
 
 Well if our binary compatibility guarantee is true, then what conflicts
 do we worry about?  If an app depends on new features which were added in
 a point-release, then it will not work with an older Qt, but an
 application which was shipped with the older version ought to work just
 as well with the newer one.  On Windows and Linux we depend on that,
 right?

The reality is that this guarantee often enough does not hold in
practice. Vendors of binary Qt based application typically test their
setup against one specific (often enough patched) version of Qt which
is then shipped with the application. Users are not expected to switch
Qt versions, except when upgrading the whole application. Insofar are
rules like we can't add symbols in patch releases not much more then
self-inflicted pain without measurable gain.

 Isn't it true that duplicate copies of Qt in every application will
 result in duplicate copies being loaded into RAM too?

Better double memory consumption then unexpected behaviour changes.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Examples packaging

2012-11-22 Thread Sze Howe Koh
On Nov 22, 2012 11:39 PM, Alan Alpert 4163654...@gmail.com wrote:
 On the new features category, we had discussed a bit the next
 generation QtDemo in Brisbane. What would be really cool for the QML
 demos at least would be to have an editable code pane next to the
 running example in the launcher. So you'd start by just playing around
 looking at the running examples, but once one catches your interest
 you can open up the code and start to play with it directly from there
 (it's also a great place for designers to copy'n'paste effects from).

 It's blurring the line between IDE and examples launcher, but it still
 provides a demo application with that 'easy-and-exciting-as-possible'
 introduction.

That sounds like a nifty idea. Would we be able to simply re-use some
code from Qt Creator?


Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

2012-11-22 Thread Yang Fan
Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10,
only Windows version has this problem, so I indicated it on Windows in the
mail subject.
I didn't create a bug report, since I think there may be some setting items
of Qt/QtWebkit could resolve this problem.


On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang liang...@digia.com wrote:

  At least for me, browser could display simplified Chinese characters
 correctly on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe
 someone with your configuration could verify it works or not.

  Have you created bug report?

  Regards,
 Liang

  --
 *From:* 
 development-bounces+liang.qi=digia@qt-project.org[development-bounces+liang.qi=
 digia@qt-project.org] on behalf of Yang Fan [missd...@gmail.com]
 *Sent:* Thursday, November 22, 2012 7:24 AM
 *To:* development@qt-project.org
 *Subject:* [Development] QtWebkit from Qt5 couldn't display Chinese
 characters correctly on Windows


 Hi All,

 Maybe it's not so suitable to ask here, since there's no reply in the
 Interest maillist.
 I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
 QtWebkit. But I found it couldn't display Chinese characters correctly on
 Windows, the official example under
 qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
 miss something? Someone has reported this issue before but got no reply.
 https://qt-project.org/forums/viewthread/21022 .
 Any suggestion would be appreciated.

 Regards,
 Fan Yang



 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development




-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

2012-11-22 Thread Yang Fan
The example under qt5\qtbase\examples\widgets\richtext\textedit seems OK.
It could input Chinese characters, opens a text file contains Chinese
characters and displays correctly.


On Thu, Nov 22, 2012 at 10:34 PM, Konstantin Ritt ritt...@gmail.com wrote:

 Hi,

 Plz check if the rich text editor example shows these Chinese
 characters correctly.

 Konstantin


 2012/11/22 Yang Fan missd...@gmail.com:
 
  Hi All,
 
  Maybe it's not so suitable to ask here, since there's no reply in the
  Interest maillist.
  I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
  QtWebkit. But I found it couldn't display Chinese characters correctly on
  Windows, the official example under
  qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did
 I
  miss something? Someone has reported this issue before but got no reply.
  https://qt-project.org/forums/viewthread/21022 .
  Any suggestion would be appreciated.
 
  Regards,
  Fan Yang
 
 
 
  ___
  Development mailing list
  Development@qt-project.org
  http://lists.qt-project.org/mailman/listinfo/development
 




-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] CI status update

2012-11-22 Thread Fält Simo

  There are a number of changes building up
 for
  both qtlocation and qtconnectivity that I would like to see integrated.
 I was hoping that this would get in:
 https://codereview.qt-project.org/#change,38790
 That should fix both of those failing jobs.
 If that won't happen during next couple of days, we can temporarily disable
 those jobs.

Disabled
qt/connectivity and qt/qtlocation are not in CI at the moment. Changes will get 
merged once Approver or Maintainer will press the Submit Patch Set button in 
Gerrit.

 Simo
 
 
  What sort of time frame are we looking at before the CI system would be
  working for these repositiories?  If it is going to be weeks then I think 
  that
  it would be useful to temporarily turn the CI system off until the solution 
  is
  implemented.
 
  Cheers,
 
  --
  Aaron McCarthy
  ___
  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