Re: [Development] Puzzled by desktop development priorities, Mac OS specifically [Warning: Rant]

[Jake Thomas Petroules]

What we really need is to complete the Relocatable Qt project and use @rpath in 
the install names of Qt frameworks.

Then macdeployqt would not need to exist, or would consist merely of a bunch of 
copy commands.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Aug 8, 2013, at 5:37 AM, Rutledge Shawn  wrote:

> 
> On 8 Aug 2013, at 11:34 AM, qtnext wrote:
> 
>> if I use the script to patch the //, macdeployqt from qt5.1., then script 
>> postmacdeployqt ... it works fine :) ... Thanks a lot :)
> 
> But we need to fix macdeployqt so you don't need so many steps.  Maybe in the 
> future qbs could do everything.
> ___
> 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 reference platforms in the CI for Qt5.2

[Jake Thomas Petroules]

On Aug 7, 2013, at 7:12 AM, Sergio Ahumada  wrote:

> On 08/07/2013 11:47 AM, Sarajärvi Tony wrote:
>> Hi all!
>> 
>> We'd like to change the reference platforms a bit. We have new platforms 
>> coming in and old ones are just that.old.
>> 
>> Changes in short would be to drop OSX 10.6 and Ubuntu 10.04 from our builds. 
>> As new platforms we would bring up OSX 10.9 and Ubuntu 13.04.
>> Also a new platform would be Windows 8.1, which would get one or two 
>> configurations from our Windows 7 builds.
> 
> Does this means that we drop support for OS X 10.6 in Qt 5.2 ?

Why does this keep coming up? We cannot drop support for a platform with 35% of 
the OS X market share.
-- 
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] Setting a Minimum Support OpenSSL Version

[Jake Thomas Petroules]

I assume that this excludes OS X, given that the very latest version still only 
has 0.9.8y.

Are there or have there ever been any plans to implement additional crypto 
backends such
as CommonCrypto (OS X and iOS, the latter of which doesn't have OpenSSL at all) 
and
CAPI/CNG on Windows? SSL in Qt would work out-of-the-box.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Aug 1, 2013, at 11:47 AM, Thiago Macieira  wrote:

> On quinta-feira, 1 de agosto de 2013 13:13:31, Shane Kearns wrote:
>> If there are no objections, lets update the documentation and make sure the
>> binary packages for the next release are using it.
> 
> Since this proposal came from Peter and I assume he discussed it with 
> Richard, 
> and now Shane is endorsing it, that's effectively everyone who has a say in 
> the 
> OpenSSL use in Qt.
> 
> Consider the decision made: Qt 5.2 will require OpenSSL 1.0 as a minimum 
> version.
> -- 
> 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] [Interest] [Announce] Qt 5.1 released

[Jake Thomas Petroules]

Personally I still think it would be far more logical to delegate the ANGLE vs 
OpenGL decision to runtime, by including plugins for both backends with all 
Windows distributions.

Having different packages seems to confuse a lot of Qt developers and 
complicates deployment matters, whereas a plugin based approach would solve 
these issues and also give end users the option to try a different graphics 
backend if the current one isn't working out for them. Many game engines do 
this, so why shouldn't Qt also be able to?
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Jul 4, 2013, at 9:06 PM, Sze Howe Koh  wrote:

> Good find, Mark. Forwarding the typo to the Web mailing list.
> 
> The MinGW package is labelled "Qt 5.1.0 for Windows 32-bit (MinGW 4.8,
> 666 MB)", but the filename is
> qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe -- one of
> them is wrong.
> 
> On a related note, would it be helpful for newcomers if ANGLE-based
> packages to explicitly labelled as such? After all, ANGLE is the odd
> one out -- everything else uses OpenGL.
> 
>Qt 5.1.0 for Windows 32-bit (MinGW 4.8, ANGLE, xxx MB)
>Qt 5.1.0 for Windows 32-bit (MinGW 4.8, OpenGL, xxx MB)
> 
> 
> Regards,
> Sze-Howe
> 
> On 4 July 2013 22:34, Mark  wrote:
>> 
 That's probably a typo in the download page since the actual download
 link does contain opengl in it [1].
 
 [1] 
 http://download.qt-project.org/official_releases/qt/5.1/5.1.0/qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe
> 
> [...]
> 
>> Guess i found a typo then ;)
> ___
> 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] Why custom installer on Mac, why not using @rpath?

[Jake Thomas Petroules]

I like this idea very much and think we should look into it further.

There is a long way we can go with integrating Qt into Apple platforms better 
at every level and this would be a great start.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Jun 18, 2013, at 3:31 PM, Adam Strzelecki  wrote:

>> That might work for when QtCore is bundled with the executable, but it 
>> doesn't 
>> if QtCore is still installed system-wide and the executable (your 
>> application) 
>> is somewhere else completely. How will it find the plugins?
> 
> I am perfectly aware than on some platforms it isn't possible to get path for 
> the executable, requires messing with /proc or it may not even exists. That's 
> why I all stuff below applies to OSX, and maybe can be brought to Windows.
> 
> As a full-time Mac developer I may be biased towards way of OSX, but I think 
> there's something wrong conceptually with Qt Mac frameworks architecture.
> 
> Basically Qt Mac SDK looks like a mixture of contradictory OSX and UNIX 
> concepts, where UNIX libraries use compile time "prefix" (/usr /usr/local 
> /opt /sw), Mac frameworks never expect their location to be some particular 
> path.
> 
> So if libqcocoa.dylib is QtWidgets.framework plugin which is a Mac framework, 
> it may be better idea to keep it as 
> QtWidgets.framework/Version/5/PlugIns/Cocoa.bundle/Contents/MacOS/Cocoa. IMHO 
> Some.app/Contents/PlugIns is reserved for application plugins not for their 
> frameworks.
> 
> This also applies to Qt built-in translations that should be in framework 
> Resources etc. etc.
> 
> So all frameworks know where to look for their plugins translations, etc. 
> etc. because they're carried with them.
> 
> Finally Qt SDK would be just a bunch of frameworks you can (selectively) link 
> to, move around, copy to your app bundle, w/o any extra path tweaking. SDK 
> could be just dmg package of:
> Qt5.1.sdk:
>  Samples/
>  Frameworks/
>  QT Creator.app
> 
> If one don't need some features in the app they can be stripped away from 
> particular framework, i.e. removing Headers/, particular translations in 
> Resources/, particular widget backends in QtWidgets PlugIns/.
> 
> What would be even more cool is to put the "moc", "qmake" tools into 
> QtCore.framework/Versions/5/Support (symlinked to QtCore.framework/Support).
> 
> Altogether this would make Qt SDK 100% OSX friendly. No need for installers, 
> just add QtCore.framework/Versions/5/Support if you want use command line 
> tools or symlink them to /usr/local/bin
> 
> Some examples taken from my box:
> 
> $ ls -l `which ruby`
> lrwxr-xr-x  1 root  wheel  76 26 lip  2012 /usr/bin/ruby -> 
> ../../System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby
> $ ls -l `which java`
> lrwxr-xr-x  1 root  wheel  74 17 kwi 18:17 /usr/bin/java -> 
> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
> 
> Regards,
> -- 
> Adam Strzelecki | nanoant.com | twitter.com/nanoant
> 
> ___
> 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] Clarification on Mac 10.6 support for Qt 5.2

[Jake Thomas Petroules]

According to Xcode the default is libstdc++ anyways.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Jun 12, 2013, at 11:05 AM, Thiago Macieira  wrote:

> On quarta-feira, 12 de junho de 2013 13.38.19, Bruning Michael wrote:
>> As far as I can see, libc++ was never officially supported by Apple on 10.6
>> and to get it built and running from sources, there's some handwork
>> required and things might and probably will break without prior notice. So
>> I would assume it safe to say that there is no libc++ for 10.6.
>>> 
>>> 
>>> If not, we need to turn it off.
>>> 
>>> 
>> 
>> You mean, disable C++11 support on Mac entirely?
> 
> No. Just when we build our official binary packages.
> 
> The build rule should add -no-c++11 to the command-line.
> 
> -- 
> 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] OSX very strange focus problem?

[Jake Thomas Petroules]

QtMacExtras is not integrated into Qt 5.0.2 -- it's due for 5.2, I believe.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Jun 10, 2013, at 6:14 AM, Jose  wrote:

> Hi, 
> 
> I have stumbled upon to an error that does not really make much sense to me, 
> though I am probably missing something. 
> 
> I am working on a qt5 based application, it works find on linux, however when 
> I build it on MAC I get a very strange behavior. The main window contains a 
> qtabwidget which has 4 pages, each of which contains different components. 
> 
> When I start the application the components in the first page do not respond 
> to click/press events. However, if I increase the size of the window to a 
> certain level, components on the right part of the tab start to respond, 
> therefore I can click or interact on them. Same  behavior occurs in every 
> page. I believe there is a focus problem or layout problem but I cannot 
> really get to figure out what it is. 
> 
> Also, is QtMacExtras integrated into qt 5.0.2 or I need to build it and 
> integrate it separately into my project?
> 
> I would appreciate any kind of help.
> 
> Thanks
> ___
> 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] Clarification on Mac 10.6 support for Qt 5.2

[Jake Thomas Petroules]

On Jun 5, 2013, at 6:49 AM, Gustavsen Richard  
wrote:

> 
> On Jun 5, 2013, at 5:26 AM, Thiago Macieira  wrote:
> 
>> On terça-feira, 4 de junho de 2013 19.32.57, Jake Thomas Petroules wrote:
>>> Well, Xcode 5.0 will be dropping support for GCC, so the only way to target
>>> 10.6 or below will be with clang + libstc++.
>> 
>> Right, I missed that clang + libstdc++ was still possible with -no-c++11. 
>> It's 
>> a non-default option.
>> 
>> I guess we conclude then:
>> a) we can keep support for 10.6 for the time being, with macx-clang
>> b) we should deprecate macx-g++, since XCode 5.0 will not have that anymore
> 
>> From reading this thread, it seems that 10.6 support is pretty important. 
>> But right now you need to build Qt from sources yourself to get it.
> Is this good enough? It sounds like it would be better if the binary package 
> continued with 10.6 support when so many users still
> has that version.
> Those that need C++11 and don't need to target 10.6 could still build Qt 
> themselves (rather than the opposite)...
> 
> -Richard

Perhaps the Qt Project could distribute two different packages: one libc++ 
based for 10.7+, and one libstdc++ based for 10.6+?

>> 
>>> 10.5 came out in 2007 and was dropped by Qt in 2012. 10.6 came out in 2009
>>> so let's drop 10.6 somewhere around 2015 or even 2016 (I add a year because
>>> of its higher market share). We should have 10.11 by then.
>> 
>> I'm not sure I like that idea. We've always kept support for the past 3 
>> versions of Mac OS X. Until 10.9 now, that meant roughly 6 years of support 
>> from us. If we keep that rate, we should support 10.6 at least until June 
>> 2014.
>> 
>> So, if we keep current practice, Qt 5.3 or 5.4 will drop support for it 
>> anyway. That's 2014, not 2015 or 2016.
>> 
>> Also, please note we're talking about software that switches to Qt 5.2. That 
>> is, we're talking about software released in 2014. And people keep telling 
>> me 
>> that they can't upgrade Qt after a cycle started.
>> 
>> 
>> -- 
>> 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

-- 
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] Clarification on Mac 10.6 support for Qt 5.2

[Jake Thomas Petroules]

On Jun 4, 2013, at 11:26 PM, Thiago Macieira  wrote:

> On terça-feira, 4 de junho de 2013 19.32.57, Jake Thomas Petroules wrote:
>> Well, Xcode 5.0 will be dropping support for GCC, so the only way to target
>> 10.6 or below will be with clang + libstc++.
> 
> Right, I missed that clang + libstdc++ was still possible with -no-c++11. 
> It's 
> a non-default option.
> 
> I guess we conclude then:
> a) we can keep support for 10.6 for the time being, with macx-clang
> b) we should deprecate macx-g++, since XCode 5.0 will not have that anymore

That sounds fine.

>> 10.5 came out in 2007 and was dropped by Qt in 2012. 10.6 came out in 2009
>> so let's drop 10.6 somewhere around 2015 or even 2016 (I add a year because
>> of its higher market share). We should have 10.11 by then.
> 
> I'm not sure I like that idea. We've always kept support for the past 3 
> versions of Mac OS X. Until 10.9 now, that meant roughly 6 years of support 
> from us. If we keep that rate, we should support 10.6 at least until June 
> 2014.
> 
> So, if we keep current practice, Qt 5.3 or 5.4 will drop support for it 
> anyway. That's 2014, not 2015 or 2016.
> 
> Also, please note we're talking about software that switches to Qt 5.2. That 
> is, we're talking about software released in 2014. And people keep telling me 
> that they can't upgrade Qt after a cycle started.

I was being half-sarcastic about 2016, but I do strongly disagree that we 
should indiscriminately support only N number of versions of OS X at a time; 
it's too rigid. I think significantly more weight should be given to the 
version's market share.

PS - adding new OS versions to QSysInfo and such: dev or stable?

> -- 
> 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] Clarification on Mac 10.6 support for Qt 5.2

[Jake Thomas Petroules]

Well, Xcode 5.0 will be dropping support for GCC, so the only way to target 
10.6 or below will be with clang + libstc++.

Supporting 10.6 is a huge priority given that version has the largest market 
share of all OS X versions (about 35%). Do we really want to wipe out over a 
third of potential end-users of Qt-based products? Dropping support for it at 
this point is an absolutely terrible idea, and 10.9 is not even revealed yet.

Secondly, it appears that the patch in question does not force use of libc++ 
("Users who wish to deploy to 10.6 need to build their own Qt, passing 
-no-c++11 to configure.") unless I am missing something.

It would be irrelevant if Snow Leopard were 10 years old; what really matters 
is the fact it maintains a massive 35% market share of OS X versions and 
therefore is critical to provide support for. Most popular software packages 
seem to have recently switched to 10.6 as a minimum (Firefox, Chrome, Skype, to 
name a few).

10.5 came out in 2007 and was dropped by Qt in 2012. 10.6 came out in 2009 so 
let's drop 10.6 somewhere around 2015 or even 2016 (I add a year because of its 
higher market share). We should have 10.11 by then.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Jun 4, 2013, at 6:55 PM, Thiago Macieira  wrote:

> Hello all
> 
> As of 3d0a60aaa4077a8 in Qt 5.2, Qt requires libc++ in order to build on Mac 
> with clang. That means the minimum deployment target for macx-clang is 
> Mac OS X 10.7 now.
> 
> Question: do we want to keep supporting Mac OS X 10.6? If so, for how long?
> 
> And if not, can we drop macx-g++? The g++ compiler that comes bundled with 
> XCode is broken and horribly outdated.
> 
> What do you think?
> 
> PS: OS X 10.9 is expected to be announced at WWDC this month. That means Qt 
> 5.2 will need to support 10.9. At the same time, 10.6's last update will be 
> over 2 years old when 5.2 ships.
> -- 
> 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] Please warn of force pushes...

[Jake Thomas Petroules]

+1

This would make quick code browsing much easier; Gitorious' interface is rather 
cumbersome.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Apr 22, 2013, at 3:44 AM, Qi Liang  wrote:

> At 22/04/2013 03:14, from Thiago Macieira:
>> My server just let me know:
>> 
>>> From git://gitorious.org/qt/qtbase
>> 60fbb00..c5a3cfa  dev-> dev
>> 1f3a67e..f78842a  stable -> stable
>>   ! [rejected]winrt  -> winrt  (non-fast-forward)
>> 
>> PLEASE let the mailing list know every time a history rewrite is about to
>> happen and when it has happened in one of the main repositories.
>> 
> 
> Hi, Thiago,
> 
> Looks like the sync script(s) is running on your server(from codereview to 
> gitorious)? Is it possible also sync the code to github for mirror? github is 
> much more popular than gitorious. Thanks.
> 
> Regards,
> Liang
> ___
> 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] Status of QTimeZone

[Jake Thomas Petroules]

I completely agree with that reasoning. Is it too late to restore the original 
behavior?

I imagine the 5.0.x will be rather short lived with 5.1 coming out so soon so 
it seems like such a change wouldn't be all that terrible.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Apr 15, 2013, at 7:11 AM, Mitch Curtis  wrote:

> On 03/25/2013 10:43 PM, John Layt wrote:
>> 4) The QDateTime QDataStream was changed in 5.0 to write all times as UTC, 
>> but
>> I think this is wrong.  Qt::LocalTime is clearly documented as being the same
>> local time (i.e. ymd hms) regardless of the underlying system time or time
>> zone or any changes in the system zone.  The consistent behaviour when
>> serialising would then be to save and restore as the local time and not its
>> UTC equivalent.  For example if I serialise an alarm time of 7am local time, 
>> I
>> don't expect that to unserialise as 9am because I changed the system time
>> zone.  If I want a time relative to UTC then I would use UTC, Offset or Time
>> Zone.
> 
> Thiago, do you agree with John here?
> 
> I think it makes sense, and the blame lies on me if so, but I did add 
> you (John) as a reviewer: https://codereview.qt-project.org/#change,32966
> ___
> 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] OSX: building against the 10.6 SDK with Qt 5.1?

[Jake Thomas Petroules]

Can't you just set __MAC_OS_X_VERSION_MAX_ALLOWED to 1060 with the 10.8 SDK?
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Apr 3, 2013, at 2:10 PM, Josh Faust  wrote:

> 
> The question is why you want to build against the 10.6 SDK?
> 
> Because it's recommended across the internet as the only way to compile-time 
> check that you're only using 10.6 APIs (and, despite what you say, it does 
> generally work). We started building Qt with it because various configuration 
> options can make Qt build binaries that are incompatible with 10.6 (such as 
> building with clang, which always uses libc++, which is not available on 
> 10.6).
> 
> Now that we have the correct configure options I guess we can rely on the 
> minimum version, but it's painful finding out only at runtime that the 
> version you built is actually not 10.6 compatible.
> 
> Josh
> ___
> 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] Urgent gerrit change for 5.1: closing the Qt Quick feature gap on the desktop

[Jake Thomas Petroules]

QQuickLiquidCrystalDisplayNumber, really? We aren't Cocoa devs. :) Is there a better name that can be used? "LCD number" is rather vague as it is; it could refer to a style like this as well, for example:How about, QQuickSegmentedNumber, as the digits are drawn in line segments?
-- Jake PetroulesChief Technology OfficerPetroules Corporation · www.petroules.comEmail: jake.petrou...@petroules.com

On Apr 1, 2013, at 3:43 PM, Knoll Lars  wrote:On 4/1/13 5:05 PM, "Thiago Macieira"  wrote:On segunda-feira, 1 de abril de 2013 13.22.57, Tvete Paul wrote:The missing feature, which was regrettably not picked up during theComponents API review, has been part of Qt from the very beginning. Tounderline its importance, consider that it was added to Qt beforefonts and text rendering.  I have therefore submitted the newcomponent to gerrit, and hope the CI system will not causetoo many problems. https://codereview.qt-project.org/52659Hi PaulHaven't you got the story mixed up? I know you were there in those days,but from what I've been told, the LCD widget was added *because* Qt had notext rendering and we needed a way to show the score in the tetris game. Soyes, it pre-dated text rendering, but there's a causal relationship.In any case, I'm all for feature completeness and capturing the desktopexperience in QML. Therefore, I support this change. Yet, I have toinsist that we hear from Lars before accepting it.I've discussed this with Paul before, and we agree that feature paritybetween widgets and Qt Quick Controls is extremely important.But I think Frederik has a good point. We try to get away from abbreviatednames in Qt, so let's give at least the QML type a proper (nonabbreviated) name.Cheers,Lars___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposition for a new Q_OS_ define

[Jake Thomas Petroules]

On Mar 25, 2013, at 5:11 AM, Sorvig Morten  wrote:

> On Mar 23, 2013, at 1:51 AM, Jake Thomas Petroules 
>  wrote:
> 
>> I'd like to suggest that we add a new Q_OS_ define.
>> 
>> Currently, for Apple platforms, we have:
>> 
>> Q_OS_DARWIN
>> Q_OS_DARWIN32
>> Q_OS_DARWIN64
>> Q_OS_IOS
>> Q_OS_MAC
>> Q_OS_MAC32
>> Q_OS_MAC64
>> Q_OS_MACX
>> 
>> The first three are very straightforward. Q_OS_DARWIN is defined for both 
>> Apple platforms, OS X and iOS, with specific defines for 32 and 64 bit. iOS 
>> -- also straightforward; means iOS.
>> 
>> Then we get confusing. You'd think Q_OS_MAC is defined for OS X only, but 
>> it's just a synonym for Darwin, which makes it mostly useless. Further 
>> confusing is Q_OS_MACX which even more strongly implies that  it refers to 
>> OS X, but again it's simply a synonym for Darwin.
>> 
>> This results in a ton of #if defined(Q_OS_MAC) && !defined(Q_OS_IOS), which 
>> is very counterproductive. I propose that we add a Q_OS_OSX define (and 
>> Q_OS_OSX32 / Q_OS_OSX64) which is only defined for OS X. This would be quite 
>> helpful, I think.
>> 
>> Any objections? If not, dev or stable?
> 
> My initial thoughts are that the current situation is manageable and that 
> "very counterproductive" is an overstatement. 
> 
> We recently started differentiating between "mac" and "macx" on the qmake 
> level (d28073d9). A quick grep shows that "Q_OS_MACX" is currently used in 
> two places in Qt (qsharedpointer.cpp and tst_qmlvisual.cpp). Re-purposing it 
> to mean "OS X" only should be doable.
> 
> Morten


That sounds reasonable. I didn't know we could change the meaning of an 
existing ifdef, but it makes sense to be in line with the corresponding changes 
to qmake.
-- 
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] Proposition for a new Q_OS_ define

[Jake Thomas Petroules]

On Mar 25, 2013, at 5:11 AM, Sorvig Morten  wrote:

> On Mar 23, 2013, at 1:51 AM, Jake Thomas Petroules 
>  wrote:
> 
>> I'd like to suggest that we add a new Q_OS_ define.
>> 
>> Currently, for Apple platforms, we have:
>> 
>> Q_OS_DARWIN
>> Q_OS_DARWIN32
>> Q_OS_DARWIN64
>> Q_OS_IOS
>> Q_OS_MAC
>> Q_OS_MAC32
>> Q_OS_MAC64
>> Q_OS_MACX
>> 
>> The first three are very straightforward. Q_OS_DARWIN is defined for both 
>> Apple platforms, OS X and iOS, with specific defines for 32 and 64 bit. iOS 
>> -- also straightforward; means iOS.
>> 
>> Then we get confusing. You'd think Q_OS_MAC is defined for OS X only, but 
>> it's just a synonym for Darwin, which makes it mostly useless. Further 
>> confusing is Q_OS_MACX which even more strongly implies that  it refers to 
>> OS X, but again it's simply a synonym for Darwin.
>> 
>> This results in a ton of #if defined(Q_OS_MAC) && !defined(Q_OS_IOS), which 
>> is very counterproductive. I propose that we add a Q_OS_OSX define (and 
>> Q_OS_OSX32 / Q_OS_OSX64) which is only defined for OS X. This would be quite 
>> helpful, I think.
>> 
>> Any objections? If not, dev or stable?
> 
> My initial thoughts are that the current situation is manageable and that 
> "very counterproductive" is an overstatement. 
> 
> We recently started differentiating between "mac" and "macx" on the qmake 
> level (d28073d9). A quick grep shows that "Q_OS_MACX" is currently used in 
> two places in Qt (qsharedpointer.cpp and tst_qmlvisual.cpp). Re-purposing it 
> to mean "OS X" only should be doable.
> 
> Morten


That sounds reasonable. I didn't know we could change the meaning of an 
existing ifdef, but it makes sense to be in line with the corresponding changes 
to qmake.
-- 
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

[Development] Proposition for a new Q_OS_ define

[Jake Thomas Petroules]

I'd like to suggest that we add a new Q_OS_ define.

Currently, for Apple platforms, we have:

Q_OS_DARWIN
Q_OS_DARWIN32
Q_OS_DARWIN64
Q_OS_IOS
Q_OS_MAC
Q_OS_MAC32
Q_OS_MAC64
Q_OS_MACX

The first three are very straightforward. Q_OS_DARWIN is defined for both Apple 
platforms, OS X and iOS, with specific defines for 32 and 64 bit. iOS -- also 
straightforward; means iOS.

Then we get confusing. You'd think Q_OS_MAC is defined for OS X only, but it's 
just a synonym for Darwin, which makes it mostly useless. Further confusing is 
Q_OS_MACX which even more strongly implies that  it refers to OS X, but again 
it's simply a synonym for Darwin.

This results in a ton of #if defined(Q_OS_MAC) && !defined(Q_OS_IOS), which is 
very counterproductive. I propose that we add a Q_OS_OSX define (and Q_OS_OSX32 
/ Q_OS_OSX64) which is only defined for OS X. This would be quite helpful, I 
think.

Any objections? If not, dev or stable?
-- 
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] Tons of warnings in the Cocoa plugin

[Jake Thomas Petroules]

Not the only way...

There's [NSApplicationDelegate applicationDockMenu:], and dock tile plugins (we 
should look into bundling a default dock tile plugin in Qt apps!).

Dock tile plugins have the added benefit of having the menu show up when the 
app isn't open (more like Windows jump lists).

https://developer.apple.com/library/mac/#documentation/Carbon/Conceptual/customizing_docktile/CreatingaDockTilePlug-in/CreatingaDockTilePlug-in.html
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Mar 22, 2013, at 4:51 AM, Sorvig Morten  wrote:

> 
> On Mar 21, 2013, at 10:55 PM, Thiago Macieira  
> wrote:
> 
>> Someone who knows about this, could you please take a look?
>> 
>> The first and third warnings are scary.
> 
> Fixed most of them: 
> 
> https://codereview.qt-project.org/51868
> https://codereview.qt-project.org/51869
> https://codereview.qt-project.org/51870
> https://codereview.qt-project.org/51871
> https://codereview.qt-project.org/51872
> https://codereview.qt-project.org/51873
> 
> Two exceptions:
> 
> [NSApp setAppMenu] is inherited from Qt 4 and is as far as I can see the only 
> way to keep that Qt 4 feature/API working (see 51871).
> 
> I also left the color-space related ones. My plan is to take a closer look at 
> color space support at some point after I return from my leave (which means 
> after summer), and leave the current code as-is until then. 
> 
> Morten
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] [Releasing] Starting preparations for Qt 5.1

[Jake Thomas Petroules]

I think we should just postpone the extras 'till 5.2, yes.

QtWindowsExtras needs a ton more work - Ivan Vizir's big Windows 7 features 
commit is still not ready and likely won't for a while. I believe he said he is 
planning a second commit with more of them since thumbnail toolbars were left 
out of his first one for reasons of time. Like Morten said, QtMacExtras needs a 
lot more polish too. Unfortunately he and I are the only ones working on it.

As for the operators, I remember there was a discussion on IRC suggesting we 
simply declare the methods and operators and forward declare the types 
necessary in QtCore/QtGui, and implement them in QtWindowsExtras/QtMacExtras. 
Then the former need not link to any additional libraries.

My vote is for constructors and conversion operators on (the all caps types are 
Win32 types):

QString <=> NSString
QPoint <=> CGPoint, NSPoint, POINT
QSize <=> CGSize, NSSize, (there's no `SIZE` afaik)
QRect <=> CGRect, NSSize, SIZE
QMargins <=> MARGINS

Darwin has a lot of image types. UIImage converters are not strictly necessary 
since UIImage has easy methods to/from CGImageRef since iOS 2.0. However, 
something like: `inline UIImage* QImageToUIImage(const QImage &image) { return 
[UIImage imageWithCGImage:QImageToCGImage(image)]; }` would save typing so I 
think we should add them anyways. Similar story with CIImage (except there's no 
CIImage -> CGImageRef and can't be from the looks of the API).

QIcon <=> HICON
QImage/QPixmap <=> HBITMAP, CGImageRef, NSImage, UIImage, CIImage
QString <=> CFStringRef, NSString

Anything else?

After all this, though, I think we should still implement the constructors and 
operators in terms of free functions so that the converters are also usable by 
Qt 4.

Are there any objections to this? Can we start adding constructors and 
operators to QtCore and QtGui?
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Mar 19, 2013, at 2:52 AM, Sorvig Morten  wrote:

> 
> On Mar 18, 2013, at 5:05 PM, Knoll Lars  wrote:
> 
>> On 3/18/13 4:58 PM, "Laszlo Papp"  wrote:
>> 
>>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire 
>>> wrote:
>>> 
>>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>>> failures.
>>> See https://codereview.qt-project.org/#change,48905.
>>> 
>>> 
>>> 
>>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
>> 
>> + Mac and X11 extras. Yes, these are known.
> 
> 
> QtMacExtras is currently not in a releasable state. It's missing 
> documentation, some examples and needs some general polish and bug fixes. 
> 
> I think we also need to resolve the "native type" converters discussion to 
> know which API's goes into QtMacExtras. 
> 
> Since we are running out of time for 5.1 - should we postpone it to 5.2?
> 
> Morten
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt for iOS - iOSStyle

[Jake Thomas Petroules]

On Mar 18, 2013, at 8:26 AM, Mediator Software  
wrote:

> In "the real world", Qt on iOS is being used primarily to port existing 
> QtWidget 
> applications to the iPad, not to write new ones (nor to do anything on any 
> other 
> iOS platforms). There is a single customer using QML on iOS, once again 
> porting 
> an existing app. My opinion is that an iOS style for QtWidgets would be a 
> waste 
> of time

One man's trash, another man's treasure.

> Why? Judging from existing Qt apps on iOS, noone is using platform styling 
> anyway.

They should.

> All existing ported apps have custom UIs developed with QtWidgets. They 
> don't look like iOS, fusion or anything else. They have their own UI.

Which generally looks out of place and terrible. This includes Apple's stock 
apps
like Notes. I hope Jony Ive gets rid of all this skeumorphic design.

See, people argue that there are many Apple stock apps that use totally custom
styling, therefore everyone should do that, screw native controls, they don't 
matter.
However there's a decent handful of stock apps that use almost exclusively 
native
styling: Settings, Phone, Messages, Mail, Calendar, Contacts, Safari and at 
least
in my opinion those are some of the most well designed and best looking apps
on the system.

Not every app should be styled native. Not every app should be styled custom.
Some should use a combination of both. It all depends on what's appropriate
for the situation at hand. All I'm asking is that people recognize that we need
a balance here. We can provide both options.

> The same 
> goes for QML, but there I can see a use for iOS QML components.

So can I. I may work on this in the future as well. Right now the focus is 
widgets.
What we really need a new styling system that can act as a backend for both
QStyle/widgets and QML.

> So what's the 
> problem with making iOS styled QtWidgets? They will never ever look and 
> behave 
> the same as the native components (maybe a button, but how about a list view? 
> And what is a combo box on iOS?). You're safer with a custom UI in that case 
> because Apple will "fail" you if you "confuse" the user (if it looks like a 
> UIKit widget it must behave *exactly* like a UIKit widget).

They will definitely look the same. As for behave, that's a little harder but 
it can
still be done.

A combo box is a UIPickerView. There's no rule that requires a QComboBox to look
like a rectangle with a down arrow that pops up a menu when you click it. I 
think
substituting the appearance/behavior of a UIPickerView for QComboBox makes
sense as their functional equivalence is roughly the same.

There are plenty of comments in the Qt documentation that make note of
platform specific exceptions, or a property's lack of effect on one platform
or another. iOS may have more of these than other platforms. That's OK.

> Sometimes it would be nice to use actual UIKit controls in Qt applications 
> (eg. 
> UIWebView), but have them behave like Qt widgets (signals/slots etc.). For 
> Qt4iOS on Qt4 (and soon on Qt5), custom QWidget wrappers have been developed 
> for 
> some UIKit controls. This gives you the *actual* UIKit control (pixel perfect 
> with its exact behaviour), but let's you use Qt layouts/logic etc. IMHO 
> that's 
> the way forward for Qt widget apps that look like UIKit apps. I intend to do 
> something similar with QML (embedding a UIKit control in a QML item). There's 
> no 
> reason why wrappers (C++ or QML) couldn't be developed for all UIKit widgets. 
> There's not that many of them.

Yes, this could certainly be useful. It's one option, not the only one. I'd 
actually like
to see more of these on desktop platforms -- especially Mac, since Qt has no
QSearchField or QSegmentedControl (we should!), which are quite nice.

> IMHO, it would be most useful to make QtQuick components for iOS. Someone has 
> already made a set, but it's unclear what their plans are. You can see a demo 
> video here:
> 
> https://docs.google.com/file/d/0B2qhh3gqs-wzaEJvV3A4TjVTQWc/edit?pli=1
> https://docs.google.com/file/d/0B2qhh3gqs-wzXzRlNmdUN0thcTA/edit

Almost everything looks wrong. The UISwitch text is misaligned and the fonts
on the toolbars look strange. Smells like an attempted custom drawing.



Again, I've already started on QIosStyle and it's working pretty nicely.
https://codereview.qt-project.org/#change,51167

Once I've uploaded some of the functionality I've been working on,
I encourage you to give it a try. It might make you change your mind
about QIosStyle being a waste of time. :)
-- 
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] [Releasing] Starting preparations for Qt 5.1

[Jake Thomas Petroules]

Don't you mean Mac and Windows? I thought X11 was added a while ago.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Mar 18, 2013, at 12:05 PM, Knoll Lars  wrote:

> On 3/18/13 4:58 PM, "Laszlo Papp"  wrote:
> 
>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire 
>> wrote:
>> 
>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>> failures.
>> See https://codereview.qt-project.org/#change,48905.
>> 
>> 
>> 
>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
> 
> + Mac and X11 extras. Yes, these are known.
> 
> In addition, we need to get qt5.git updated to recent sha1's of all qt
> modules.
> 
> Cheers,
> Lars
> 
> ___
> 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] [Releasing] Starting preparations for Qt 5.1

[Jake Thomas Petroules]

Don't you mean Mac and Windows? I thought X11 was added a while ago.

Sent from my iPhone

On Mar 18, 2013, at 12:05 PM, Knoll Lars  wrote:

> On 3/18/13 4:58 PM, "Laszlo Papp"  wrote:
> 
>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire 
>> wrote:
>> 
>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>> failures.
>> See https://codereview.qt-project.org/#change,48905.
>> 
>> 
>> 
>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
> 
> + Mac and X11 extras. Yes, these are known.
> 
> In addition, we need to get qt5.git updated to recent sha1's of all qt
> modules.
> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt for iOS - iOSStyle

[Jake Thomas Petroules]

Me again. I thought I'd announce that I've pushed the first QIosStyle commit to 
Gerrit: https://codereview.qt-project.org/#change,51167 I will be doing all 
work on the class here in the public eye until it is done and ready to be 
merged (hopefully before 5.2 at the latest, 5.1 if we're lucky). I'd greatly 
appreciate any feedback and testing during the development process.

I've added a few of you as reviewers who are obviously relevant, and another 
person who expressed interest in testing the functionality.

Back to the QStyle and UIKit documentation I go.
-- 
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] Qt for iOS - iOSStyle

[Jake Thomas Petroules]

On Mar 13, 2013, at 1:43 PM, Bache-Wiig Jens  wrote:

> Exactly. Being able to do pixel perfect layouts within the Qt Quick designer 
> is one of the arguments against an IOS QStyle implementation. I would like to 
> be able to see and run my apps _exactly_ as they would look on the device, 
> without having to test  and deploy on an IOS emulator through XCode.

By that logic we should get rid of QAndroidStyle, QGtkStyle, QWindowsStyle, 
etc. That's not an argument against an implementation merely existing. You can 
use the Fusion style for your project, and I'll use the iOS style for mine. 
There's no reason we can't have the best of both worlds.

Now on the technical issues, to use your own sentence against you, "it's not as 
bad as you think". You don't need to install event handlers within the style 
and do frame by frame updating hacks. All the iOS widgets inherit from 
UIControl, where you can set the highlighted (when you touch down), selected, 
and enabled/disabled states of a control; no need to fake input events to do 
it. Control styling is also more flexible than it seems. You can in some cases 
retrieve images for the individual parts of a control. A lot of the standard 
graphics can also be replaced with custom images, and through that 
functionality you can use trickery to do things like draw a slider's track and 
knob separately. The controls also provide some degree of metrics information 
(like text margins), and you can use trickery to do things like draw the 
backgrounds for left, middle, and right sections separately for a 
UISegmentedControl in selected and unselected states. Or the divider. I could 
even give you a slider with two knobs if you wanted. I've already started 
writing code for this and have been pleased with the results so far.

Also, I just have to respond to this: "it completely falls apart when you try 
to render something slightly complex like a slider, unless you update the 
position of the native handle and re-grab it on each frame" The second part of 
your sentence answers the first. I don't see how that's a problem at all. That 
is essentially the same way any styling API works - each frame, you tell it to 
render. Any internal state it might update as part of that process is not your 
concern. I know this is not the case but HITheme could be using a NSSlider 
internally, for example, and you'd never know it.

So, to summarize:

As Morten said, "The way to prove us wrong is of course to step up and 
implement (and maintain) such a style.". Therefore, I will implement and 
maintain QiOSStyle. Of course any help would be appreciated as well.

Now, I want to stress this fact: I'm trying to support everyone's use cases, 
not exclude anyone at the expense of others. QStyle is used by both widgets AND 
QtQuick.Controls. All of these use cases are perfectly valid: widgets + custom 
style, widgets + native style, QML + custom style, QML + native style.

So, the only thing left to say is that I hope the issue is not whether 
QiOSStyle is welcome in QtGui at all, but simply whether it can be technically 
achieved and whether there is someone to do the work. If it's the latter, then 
we're all set and can end the discussion, since I will do it. Otherwise, 
QiOSStyle will be on GitHub. I'd much prefer it to be upstreamed. 

PS - To everyone debating the merits of widgets vs QML in general: this thread 
is about the implementation of an iOS QStyle to draw native-looking controls 
for QWidgets AND QtQuick.Controls. Could you please continue those discussions 
in a different thread?
-- 
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] Qt for iOS - iOSStyle

[Jake Thomas Petroules]

I'm already working on some preliminary testing for QIosStyle. I don't know how 
long it'll be before I have something on Gerrit but it will come.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Mar 12, 2013, at 7:52 AM, Sorvig Morten  wrote:

>> 
>> Another good example of iOS app that does not quite follow the native UI is
>> LinkedIn. I really like it, and I agree with you when you say some design
>> alternatives can actually look even better than the stock native style based
>> ones. But I am assuming this is not the point in this discussion - the point
>> is: is it possible to implement a QStyle based iOS style? I would go for yes.
>> Now, is there enough manpower and does it make sense? I don't know, then it's
>> up to whoever will (not) be doing it.
>> 
>> There might be a dozens of reasons not to go down that road - complexity, 
>> lack
>> of manpower or whatever may turn up. But assuming it will look half baked and
>> place that as a main reason makes me scratch my head.
> 
> 
> Complexity, maintenance burden and lack of manpower are the main reasons 
> against, yes. And I think Jens summed up the technical issues well.
> 
> The way to prove us wrong is of course to step up and implement (and 
> maintain) such a style.
> 
> Morten
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt for iOS - iOSStyle

[Jake Thomas Petroules]

On Mar 11, 2013, at 5:36 PM, Raul Metsma  wrote:

> here is one other solution
> http://docs.appcelerator.com/titanium/latest/
> javascript and native looking widgets under ios


Perhaps we could look into this.


On Mar 11, 2013, at 11:37 AM, Thiago Macieira  wrote:

> On segunda-feira, 11 de março de 2013 07.41.02, Jake Thomas Petroules wrote:
>> Jens claimed on the blog that the native look and feel matters less in the
>> mobile world because each app is fullscreen. I agree that it matters less,
>> but I disagree that it matters little enough for us to ignore it. I'd much
>> rather use real iOS-looking controls than simply slap on Fusion.
> 
> The whole point is that you shouldn't use QtWidgets at all on mobile 
> platforms. Just don't.


I never said anything about widgets. I'm talking about QiOSStyle which would 
also be used by QtQuick.Controls just like Jens is doing now for the desktop.

QiOSStyle would power both widgets and QML controls, just like how the others 
work.


On Mar 11, 2013, at 3:54 PM, Rafael Roquetto  wrote:

> Why not? I agree that QtQuick is usually the way to go for implementing mobile
> UI, but that doesn't exclude QtWidgets for any reasons a developer may wish to
> use it. When we did the BlackBerry port, we did implement a BlackBerry style,
> which could achieve native look and feel decently. This comes really handy
> when you are porting apps from the desktop.
> I think implementing a native iOS style wouldn't be hard. I don't know much
> about iOS development, but if what Jake says about being able to render
> controls to off-screen buffers, then it should be completely feasible.
> Of course, even better would be a set of QML components, but these are not
> mutually exclusive approaches.


My thoughts exactly.


Another thing is, there seem to be some private classes named like 
_UISearchBarAppearanceStorage in UIKit. Obviously, we can't use these in the 
final product, but perhaps we could play around with them during development in 
order to try and break controls down into their individual components (colors, 
images) which we can cache manually in QiOSStyle. There are messages such as: 
imageForIcon:state:, searchFieldBackgroundImageForState:, separatorImage, etc., 
which potentially look relevant. https://github.com/nst/iOS-Runtime-Headers


Also, this is about native control styling. So... let's focus on that and not 
turn this into a widgets vs QML debate. Like Rafael said, the two are not 
mutually exclusive.
-- 
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

[Development] Qt for iOS - iOSStyle

[Jake Thomas Petroules]

By the way, I don't know if you saw my comments on your "Qt for iOS Preview" 
blog post, but...

You stated that because there is no HITheme-like API on iOS, that creating 
QiOSStyle would be "not possible".

However, we can render any UIView into a buffer using [UIView drawInRect:] 
which we should utilize to provide as much support for native styling as that 
allows us to.

Jens claimed on the blog that the native look and feel matters less in the 
mobile world because each app is fullscreen. I agree that it matters less, but 
I disagree that it matters little enough for us to ignore it. I'd much rather 
use real iOS-looking controls than simply slap on Fusion. Apple users are 
commonly noted to be extremely particular about very small UI defects. If we 
spend the time to go "oh, the text alignment in QLineEdit is one pixel too low 
on OS X", and actually take the time to fix it, iOS should be no different.

So... why can't we use [UIView drawInRect:]? Qt 5 uses the same approach with 
NSScroller on OS X for drawing the Lion/ML scrollbars 
(10c6f015f45092040c281bb90a65179f598a00b1).

Native styling is important wherever you are. Not everything is a fancy web app 
or fancy QML game with custom graphics. Although I've not tested it 
extensively, Qt seems to have a completely functional style implementation for 
Android that look like native controls for the theme my phone uses, and the 
themes that other phones use, on those phones. We wouldn't want Qt/Android apps 
to look the same on every device, or like something else.

Same idea with iOS. It has a theme. That theme should be adhered to in order to 
maintain the same level of quality and refinement that Qt applications are able 
to achieve on other platforms.

Apple should give us headers and documentation for CoreUI.framework and the 
_UIClassNameAppearanceStorage classes in UIKit. That would make life a bit 
easier. :)
-- 
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

[Development] Situation with QMacCocoaViewContainer / QMacNactiveWidget in Qt 5

[Jake Thomas Petroules]

Are QMacCocoaViewContainer and QMacNativeWidget going to be implemented in some 
Qt 5.x? I understand we currently have some implementation in QtMacExtras, 
however the header files are still there in Qt 5 Widgets, and documented (but 
you obviously can't link since they are not implemented) - 
https://qt-project.org/doc/qt-5.0/qtwidgets/qmaccocoaviewcontainer.html, 
https://qt-project.org/doc/qt-5.0/qtwidgets/qmacnativewidget.html.

I imagine we will be letting QtMacExtras provide these widgets. If that's the 
case why are the headers still in Qt 5 and why are they documented as being 
part of QtWidgets?

Jake Petroules
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] Qt Platform Extras

[Jake Thomas Petroules]

I suppose it would not be a detriment. Where do you draw the line? Which 
platforms, what functions and types?

Here are some candidate types for constructors and conversion operators on 
their corresponding Qt types, which I can think of off the top of my head:

Windows:
POINT
RECT
HICON
HBITMAP

Darwin (OS X + iOS):
CGPoint
CGSize
CGRect
NSPoint
NSSize
NSRect
CGImageRef
CIImage
NSImage
NSString
and CFArrayRef/NSArray <-> QList ?

I'm not sure about other platforms/environments like X11, Wayland, or perhaps 
GNOME.

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Mar 1, 2013, at 4:24 AM, Sorvig Morten  wrote:

> 
> On Mar 1, 2013, at 8:27 AM, Jake Thomas Petroules 
>  wrote:
> 
>> Why are we discussing adding conversion operators from/to native objects in 
>> QtCore/QtGui? The methods that did so were removed in Qt 5 in order to 
>> increase modularity, why would we go the opposite direction again?
> 
> The argument for would be along the lines of: We went too far in the name of 
> modularity. Adding conversion operators to QtCore and QtGui makes it easier 
> to mix Qt and native development. It makes Qt better.
> 
> I'm positive to the idea myself, and so far I haven't seen really convincing 
> arguments against. I don't think adjusting the course of Qt 5 is a big 
> problem.
> 
> Morten
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt Platform Extras

[Jake Thomas Petroules]

Why are we discussing adding conversion operators from/to native objects in 
QtCore/QtGui? The methods that did so were removed in Qt 5 in order to increase 
modularity, why would we go the opposite direction again?
 
Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Mar 1, 2013, at 2:21 AM, Sorvig Morten  wrote:

> 
> On Mar 1, 2013, at 12:28 AM, Thiago Macieira  
> wrote:
> 
>> On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote:
>>> On Feb 28, 2013, at 4:50 PM, Thiago Macieira 
>>> 
>>> wrote:
 On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote:
> I'm probably missing something obvious here, but why are these not with
> the class that they convert from?
> 
> - conversion operator (or toFoo function if expensive)
> - constructor (explicit if expensive)
 
 Because we cannot assure that the library that contains the class in
 question is actually linking to the necessary libraries.
 
 This is the case on Mac OS X. QtGui does not link to ApplicationServices,
 so it does not have access to CGRect.
>>> 
>>> Well, we can make QtGui link to ApplicationServices if needed - It already
>>> links to CoreFoundation. Why would it be a problem in practice?
>> 
>> Because we can't do the same for other architectures and windowing systems.
>> 
> 
> Which ones?
> 
> It seems reasonable to divide the platform set in two then:
> 
> 1) The platform can guarantee the presence of certain libraries at runtime. 
> QtCore and QtGui can contain conversion functions to native types.
> 
> 2) It's uncertain what libraries you'll find.  No conversion functions.
> 
> In other words, optimize for the capabilities of each platform instead of 
> using the lowest common denominator.
> 
> Morten
> 
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt Platform Extras

[Jake Thomas Petroules]

Why is that...?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 25, 2013, at 11:12 AM, Joerg Bornemann  wrote:

> On 25/02/2013 16:27, Jake Thomas Petroules wrote:
> 
>> I'd prefer Qt namespace with no platform indicators, i.e.:
>> 
>> Qt::toHICON
>> Qt::toHBITMAP
>> Qt::toCGImageRef
>> Qt::toNSString
>> 
>> It's obvious to which platform each function belongs; there's no need to 
>> qualify it beyond necessary. If WinRT introduces an NSString class and OS X 
>> adds HBITMAPs only then should we think about adding the platform name to 
>> the function. :)
> 
> That means we're restricting ourselves to type conversion functions?
> A function that's potentially useful on more than one platform wouldn't be 
> possible.
> 
> 
> BR,
> 
> Joerg

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

Re: [Development] Qt Platform Extras

[Jake Thomas Petroules]

I'd prefer Qt namespace with no platform indicators, i.e.:

Qt::toHICON
Qt::toHBITMAP
Qt::toCGImageRef
Qt::toNSString

It's obvious to which platform each function belongs; there's no need to 
qualify it beyond necessary. If WinRT introduces an NSString class and OS X 
adds HBITMAPs only then should we think about adding the platform name to the 
function. :)

Also, despite that qt_mac_set_dock_menu is around for backwards compatibility, 
how about we introduce a second name for it, like Qt::setDockMenu and deprecate 
the original or otherwise advise against its usage? Then we can both maintain 
compatibility and not force usage of a disgustingly named function.

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 25, 2013, at 6:03 AM, Joerg Bornemann  wrote:

> On 25/02/2013 09:35, Sorvig Morten wrote:
> 
>> - Stand-alone function namespace:
>> * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”)
>>  -OR-
>> * QPlatform::toType(“QWindows::toHBITMAP”, "QMac::toCGImageRef")
> 
> I vote for the latter naming scheme. We should not simulate namespaces 
> by cluttering the function names.
> Looking at the Windows example, it might be wise to call the platform 
> namespaces QtPlatform, not QPlatform to make the namespace QtWindows and 
> the class QWindow easier distinguishable.
> 
> 
> BR,
> 
> Joerg
> 
> ___
> 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] QtWindowsExtras

[Jake Thomas Petroules]

So right now we've got:

qtwinextras: qt/dev
qtmacextras: playground/master
qtx11extras: qt/master

I take it qtx11extras is pretty much "finished", so that makes sense. And 
seeing from the past discussion, qtwinextras being in qt on dev makes sense. 
But now qtmacextras is sticking out like a sore thumb; seems to me like it 
should be in qton the dev branch. Are we going to do anything about this?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 15, 2013, at 7:03 AM, Laszlo Papp  wrote:

> On Fri, Feb 15, 2013 at 11:58 AM, Laszlo Papp  wrote:
> There is also a well documented and "robust" solution for that, too.
> 
> I meant "workaround" for sure. :-) 
> ___
> 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] QtWindowsExtras

[Jake Thomas Petroules]

Thank you, Lars!

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 14, 2013, at 4:16 PM, Knoll Lars  wrote:

> Well, I already gave that my approval some days ago in another thread.
> 
> I've now created the repository.
> ssh://codereview.qt-project.org:29418/qt/qtwinextras.git.
> 
> Cheers,
> Lars
> 
> On 2/14/13 9:23 PM, "Jake Thomas Petroules" 
> wrote:
> 
>> Ah, I see.
>> I've only recently started contributing to the Qt Project so I'm not
>> familiar with everything yet. Sorry about that!
>> 
>> Jake Petroules
>> Petroules Corporation (www.petroules.com <http://www.petroules.com>)
>> Email: jake.petrou...@petroules.com
>> Telephone: +1 (970) 587-3821
>> 
>> 
>> 
>> On Feb 14, 2013, at 3:20 PM, Laszlo Papp  wrote:
>> 
>> 
>> On Thu, Feb 14, 2013 at 7:59 PM, Jake Thomas Petroules
>>  wrote:
>> 
>> I was under the impression we were already waiting for step 4 since there
>> have been a decent number of messages on the mailing list regarding this
>> proposal, and everyone seems to know what the module is for and why we
>> need it. Anyways, is this what you want?
>> 
>> 
>> 
>> 
>> I was referring to "As we have a QtMacExtras and QtX11Extras, could
>> someone please create a QtWindowsExtras as well?" which did not follow
>> the rules, and that you were asking about repository creation when you
>> did not even get a +1 yet.
>> 
>> 
>> Request for new playground module for Qt
>> Description: a module for Windows-specific helper functions and classes
>> that were removed from Qt 4; this is the Windows counterpart to the
>> already existing qtmacextras and qtx11extras modules.
>> Playground project name: qtwindowsextras (although the guidelines say the
>> name should not include Qt, qtmacextras and qtx11extras do, and I think a
>> similar exception should be made for the Windows library)
>> 
>> 
>> 
>> 
>> This is not necessary now, and that is why I wrote: in the future.
>> 
>> I hope a maintainer can approve this soon.
>> 
>> Laszlo
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 

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

Re: [Development] QtWindowsExtras

[Jake Thomas Petroules]

Ah, I see.

I've only recently started contributing to the Qt Project so I'm not familiar 
with everything yet. Sorry about that!

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 14, 2013, at 3:20 PM, Laszlo Papp  wrote:

> On Thu, Feb 14, 2013 at 7:59 PM, Jake Thomas Petroules 
>  wrote:
> I was under the impression we were already waiting for step 4 since there 
> have been a decent number of messages on the mailing list regarding this 
> proposal, and everyone seems to know what the module is for and why we need 
> it. Anyways, is this what you want?
> 
> I was referring to "As we have a QtMacExtras and QtX11Extras, could someone 
> please create a QtWindowsExtras as well?" which did not follow the rules, and 
> that you were asking about repository creation when you did not even get a +1 
> yet.
>  
> Request for new playground module for Qt
> 
> Description: a module for Windows-specific helper functions and classes that 
> were removed from Qt 4; this is the Windows counterpart to the already 
> existing qtmacextras and qtx11extras modules.
> Playground project name: qtwindowsextras (although the guidelines say the 
> name should not include Qt, qtmacextras and qtx11extras do, and I think a 
> similar exception should be made for the Windows library)
> 
> This is not necessary now, and that is why I wrote: in the future.
> 
> I hope a maintainer can approve this soon.
> 
> Laszlo

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

Re: [Development] QtWindowsExtras

[Jake Thomas Petroules]

I was under the impression we were already waiting for step 4 since there have 
been a decent number of messages on the mailing list regarding this proposal, 
and everyone seems to know what the module is for and why we need it. Anyways, 
is this what you want?

Request for new playground module for Qt

Description: a module for Windows-specific helper functions and classes that 
were removed from Qt 4; this is the Windows counterpart to the already existing 
qtmacextras and qtx11extras modules.
Playground project name: qtwindowsextras (although the guidelines say the name 
should not include Qt, qtmacextras and qtx11extras do, and I think a similar 
exception should be made for the Windows library)

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 14, 2013, at 1:55 PM, Laszlo Papp  wrote:

> Please read the rules (and follow in the future): 
> http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt
> 
> Seems, no maintainer gave a +1 yet. You need to get one first. :-)
> 
> On Fri, Jan 18, 2013 at 5:47 PM, Jake Thomas Petroules 
>  wrote:
> As many OS/WM utility methods were removed from Qt 5, we need to reimplement 
> their functionality in the QtWindowsExtras, QtMacExtras, and QtX11Extras 
> libraries.
> 
> For example, in QtMacExtras we have a unified toolbar implementation that 
> replaces setUnifiedTitleAndToolbar(), and converter functions to replace 
> QPixmap::toMacCGImageRef(), QPixmap::fromMacCGImageRef() as well as other 
> type conversions, etc. Morten also has some clipboard functionality pending 
> as well as a utility function to set the dock menu to a QMenu, native 
> widgets, and some other stuff. Similarly, QtX11Extras has QX11Info ported 
> from Qt 4 and I imagine may have more functionality in the future..
> 
> Windows is no different, and there is a lot that could fit into such a 
> library, including but not limited to:
> 
> * Replacements for native API converter functions (QPixmap::toWinHBITMAP(), 
> QPixmap::fromWinHBITMAP(), QPixmap::toWinHICON(), QPixmap::fromWinHICON()... 
> I think there was also a QMenu::wceMenu() that gave an HMENU and a similar 
> function for Windows itself (not CE) would be great)
> * Taskbar functionality for Windows 7/8 (jump lists, overlay icons, progress 
> indicators, thumbnail toolbars, thumbnail tab previews)
> * DWM interaction (enable/disable composition, extend frame into client area)
> 
> This is important functionality usable by a large number of Windows apps, 
> clearly evidenced by the former presence of some of this functionality in Qt 
> 4. I have a decent amount of code implementing much of this functionality 
> already, just awaiting contribution...
> 
> I'm sure there is more I haven't thought of as well. Perhaps some Windows 8 
> APIs?
> 
> Jake Petroules
> Petroules Corporation (www.petroules.com)
> Email: jake.petrou...@petroules.com
> Telephone: +1 (970) 587-3821
> 
> On Jan 18, 2013, at 12:16 PM, Laszlo Papp  wrote:
> 
>> On Thu, Jan 17, 2013 at 8:58 PM, Jake Thomas Petroules 
>>  wrote:
>> As we have a QtMacExtras and QtX11Extras, could someone please create a 
>> QtWindowsExtras as well?
>> 
>> Could you please elaborate about the use case?
>> 
>> Laszlo
> 
> 

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

Re: [Development] Qt 5.1 feature set and freeze date

[Jake Thomas Petroules]

I would certainly like to see that contributed to playground so that all 
interested parties may contribute. Any timeframe on when someone can get the 
repository created?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 14, 2013, at 2:58 AM, Ivan Vizir  wrote:

> Hello, 
>  
> There're no problems with Qt Windows Extras. As I said somewhen in January, I 
> plan to contribute to Qt my code, when it's done. Current results you can see 
> at http://github.com/dtf/QtWindowsExtras .
>  
> For now features what are ready are:
> — progress bar indicator;
> — overlay icons;
> — thumbnails for tabs;
> — thumbbar button panels;
> — jump lists (not yet pushed to GitHub).
>  
> Featurens that are going to be done:
> — interactive wrapper around jump lists, maybe using Platform Menu.
> — adapting code so it could be used with QtQuick (that means moving from 
> using QWidgets to QWindow and/or splitting code to two versions — for widgets 
> and for qt quick respectively).
>  
> I thought I could finish module following Qt module guidelines and then 
> propose it for review, but if you want to see Qt Windows Extras as a part of 
> Qt 5.1, we could move it to Qt Playground and work on it together.
>  
> 14.02.2013, 09:38, "André Somers" :
> Op 13-2-2013 18:24, Jake Petroules schreef:
> QtWindowsExtras is something I plan to contribute to heavily. What things 
> would folks like to see in there besides the image conversion functions? I 
> suggested Windows 7 task bar features a little while back, and I believe that 
> there is a Windows counterpart to QMacPasteboardMime that needs replacing as 
> well.
> Those taskbar features would be quite welcome. There currently is 
> http://www.strixcode.com/q7goodies/ of course, but that is quite expensive 
> for what you get if you ask me.
> 
> A way to manipulate the color of the progress-bar in the windows style would 
> also be welcome, though I am not sure that belongs in such an add-on. Windows 
> supports states for a progress bar, like error or paused that result in a red 
> or a yellow bar instead of the default green one. You can also see that in 
> the task bar. 
> 
> Support for extending the native file dialog in windows would be awesome, but 
> perhaps that's out of scope or something that would idealy be available on 
> more platforms.
> 
> André
> 
> 
> 
> On Wednesday, February 13, 2013, Knoll Lars wrote:
> 
> 
> On 2/13/13 10:08 AM, "Friedemann Kleint" 
> wrote:
> 
> >Hi,
> >
> >we also plan to start Qt Windows Extras to bring at least the missing
> >image conversion  functions ( QTBUG-27103 ) back provided we can find
> >someone to create the repository ;-) .
> 
> Ok. Sergio can hopefully help with the repo. Do you think you can get it
> into a decent state for adding to 5.1 by 1st of March?
> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> 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

Re: [Development] Qt/3D

[Jake Thomas Petroules]

I think you are looking for: 
http://lists.qt-project.org/mailman/listinfo/interest

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 11, 2013, at 6:33 PM, Federico J. Fernández 
 wrote:

> All,
> 
> I want to know what is the best place to ask questions about the Qt3D 
> library. 
> 
> Probably the best resource is not this list, but I couldn't find another more 
> specific mailing list.
> 
> Thanks.
> 
> --
> federico
> ___
> 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] QtWindowsExtras

[Jake Thomas Petroules]

As we have a QtMacExtras and QtX11Extras, could someone please create a 
QtWindowsExtras as well?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

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

Re: [Development] Reviews needed before android integration in two weeks

[Jake Thomas Petroules]

Surely you meant darwin-g++-macx. :)

I don't think the Android mkspec warrants having Linux in it simply because 
it's such a radically different system in many ways. Custom C++ library, 
different executable format, custom packaging tools, custom UI stack, the fact 
that native apps can't even be run standalone without Java glue (at least 
before 2.3)... it's much further from Linux than Maemo is. As a comparison, 
BlackBerry's mkspec does not include QNX.

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 5, 2013, at 7:10 AM, Eskil Abrahamsen Blomfeldt 
 wrote:

> On 02/05/2013 12:49 PM, Friedemann Kleint wrote:
>> - Nokia is also mentioned along with names of former employees in the 
>> json style parser under widgets/styles.  Btw, I am generally wondering 
>> about it, it seems to add a new Json parser. Could it be replaced by 
>> the Json classes of QtCore?
> 
> We have a task about that. I think it either needs to be replaced by 
> Qt's json classes or put into 3rdparty.
> 
>> 
>> -  Compilation of the branch under Windows fails with the attached 
>> log. Something is probably wrong with #ifdefing/profiles?
> 
> Great, thanks!
> 
> Simon Hausmann wrote:
>> Let's put it this way: linux-g++* is just as fuzzy as android-g++* in what it
>> means. But we're not in the business of creating mathematical formulas, we're
>> in the business of making life easier for software developers. If we can make
>> it easier for people to port their app to Android, why don't we do it?
> 
> I don't have any very strong opinion either way, so whatever the 
> majority decides is fine by me, but since there's a disagreement: Could 
> you please elaborate on what makes linux-android-g++ (or 
> linux-g++-android for symmetry with maemo) simpler for the developer 
> compared to android-g++?
> 
> Technically I don't think Android is considered a Linux-distribution. 
> Wouldn't this be similar to renaming the OSX mkspec to "macx-g++-darwin"?
> 
> -- Eskil
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt Windows Extras and Jump Lists

[Jake Thomas Petroules]

As if it's possible for COM to be beautiful? :)

I looked over your code briefly and it looks pretty nice.

Implementing something like QtDockTile is somewhat odd because the it was 
developed as a series of plugins with a single QDockTile API. I think the 
abstraction of these platform features into a single logical API is useful, 
however I'm not sure we can do that easily with the current QWindowsExtras / 
QMacExtras / QX11Extras trio. QDockTile as a class would have to go into QtGui 
to make proper use of that abstraction, but then you have the problem of 
backporting it to Qt 4. Or you could duplicate the header across all 3 
libraries which isn't exactly ideal. I guess the best approach is to just 
forego having it as a single API and just have a series of individual classes 
for the functionality of each platform in each of the Q***Extras libraries.

Then there's the problem of where the Unity portion goes *at all*. Not 
QX11Extras since it's not window system specific but DE-specific, and I doubt 
anyone would want to create a QUnityExtras (although I certainly wouldn't be 
opposed - it'll have to go somewhere).

The QPixmap-and-friends conversion functions is a big one that definitely 
belongs in QWindowsExtras. I already mentioned that in my initial proposal to 
create a QWindowsExtras library, and Morten Sørvig and I both have some changes 
pending to add similar conversion functions in QMacExtras.

So yes, the Windows 7 jump lists, etc., functionality should definitely be 
implemented in QWindowsExtras in my opinion. The questions I see that need 
answering are:

* Is there a place for a QDockTile abstraction on top of Windows 7 taskbar 
features, OS X Dock features and Unity launcher features (while still having 
the individual APIs available)?
* Where would the Unity functionality go? Do we need a QUnityExtras as well?

What do others think?

Either way, I don't think anyone would disagree that we need a QWindowsExtras. 
Could someone create it in playground/qwindowsextras so those of us interested 
in contributing can begin submitting code?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Jan 24, 2013, at 5:40 PM, Ivan V.  wrote:

> Something more beautiful. :) 
> 
> Firstly, there's no need in C-style abstractions.
> Secondly, there will be implemented some more features. 
> And it won't be designed as a pugin for plugin, which uses library wrapped by 
> another library.
> 
> I've already done some features. Code is here: 
> https://github.com/dtf/QtWindowsExtras
> Alsio, it is going to include various conversion functions, which where 
> removed from QPixmap in Qt5, as was asked here: 
> http://lists.qt-project.org/pipermail/development/2013-January/009390.html .
> 
> But that's not the topic. The only thing I would like to know is if it is ok 
> to include in Qt code, which, I think, is some kind of hack. What do you 
> think?
> 
> 25.01.2013, 00:30, "Jake Thomas Petroules" :
>> Ah, I'm familiar with the project from which it was forked. If this is not 
>> the code that is going to be a proposal for QWindowsExtras then what is?
>> 
>> Jake Petroules
>> Petroules Corporation (www.petroules.com)
>> Email: jake.petrou...@petroules.com
>> Telephone: +1 (970) 587-3821
>> 
>> On Jan 24, 2013, at 5:14 PM, Ivan V.  wrote:
>> 
>>>  Of course it is.
>>>  Here is the project: https://github.com/dtf/QtDockTile
>>>  Here is the somewhat ugly code, which was born by cloudy consciousness: 
>>> https://github.com/dtf/QtDockTile/tree/master/src/plugins/windows
>>> 
>>>  Note that it is not the code that is going to be a proposal for Qt Windows 
>>> Extras.
>>> 
>>>  25.01.2013, 00:07, "Jake Thomas Petroules" :
>>>>  Interesting. Is your wrapper open source and where might one find it?
>>>> 
>>>>  Jake Petroules
>>>>  Petroules Corporation (www.petroules.com)
>>>>  Email: jake.petrou...@petroules.com
>>>>  Telephone: +1 (970) 587-3821
>>>> 
>>>>  On Jan 24, 2013, at 4:34 PM, Ivan V.  wrote:
>>>>>   Hello, Jake,
>>>>> 
>>>>>   The main "unusualness" about our wrapper is that it not only wraps 
>>>>> ICustomDestinationList COM-interface, but also allows programmer to put 
>>>>> there QActions and use it like with some kind of menus. What it does it 
>>>>> stores these actions, gives them unique id's, and those id-s puts into 
>>>>> command-line argument to rundll32, which after activation of jumplist 
>>>>> item calls a procedure

Re: [Development] Qt Windows Extras and Jump Lists

[Jake Thomas Petroules]

Ah, I'm familiar with the project from which it was forked. If this is not the 
code that is going to be a proposal for QWindowsExtras then what is?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Jan 24, 2013, at 5:14 PM, Ivan V.  wrote:

> Of course it is.
> Here is the project: https://github.com/dtf/QtDockTile
> Here is the somewhat ugly code, which was born by cloudy consciousness: 
> https://github.com/dtf/QtDockTile/tree/master/src/plugins/windows 
> 
> Note that it is not the code that is going to be a proposal for Qt Windows 
> Extras.
> 
> 25.01.2013, 00:07, "Jake Thomas Petroules" :
>> Interesting. Is your wrapper open source and where might one find it?
>> 
>> Jake Petroules
>> Petroules Corporation (www.petroules.com)
>> Email: jake.petrou...@petroules.com
>> Telephone: +1 (970) 587-3821
>> 
>> On Jan 24, 2013, at 4:34 PM, Ivan V.  wrote:
>> 
>>>  Hello, Jake,
>>> 
>>>  The main "unusualness" about our wrapper is that it not only wraps 
>>> ICustomDestinationList COM-interface, but also allows programmer to put 
>>> there QActions and use it like with some kind of menus. What it does it 
>>> stores these actions, gives them unique id's, and those id-s puts into 
>>> command-line argument to rundll32, which after activation of jumplist item 
>>> calls a procedure, which then finds respective action by id and triggers 
>>> it. It's pretty common mechanism of transforming this unusable "Jump 
>>> Lists", which is only list of shortcuts, into something more usable.
>>>  ___
>>>  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

Re: [Development] Qt Windows Extras and Jump Lists

[Jake Thomas Petroules]

Interesting. Is your wrapper open source and where might one find it?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Jan 24, 2013, at 4:34 PM, Ivan V.  wrote:

> Hello, Jake,
> 
> The main "unusualness" about our wrapper is that it not only wraps 
> ICustomDestinationList COM-interface, but also allows programmer to put there 
> QActions and use it like with some kind of menus. What it does it stores 
> these actions, gives them unique id's, and those id-s puts into command-line 
> argument to rundll32, which after activation of jumplist item calls a 
> procedure, which then finds respective action by id and triggers it. It's 
> pretty common mechanism of transforming this unusable "Jump Lists", which is 
> only list of shortcuts, into something more usable.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Qt Windows Extras and Jump Lists

[Jake Thomas Petroules]

Hi Aleksey,

I'm not sure I follow - "we have an unusual jump lists wrapper" - who exactly 
are you referring to? If you could elaborate a little more that would be great.

Thanks,

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Jan 24, 2013, at 3:59 PM, Aleksey Sidorov  wrote:

> We have an unusual Jump Lists wrapper, which transforms so called Task Lists 
> into a interactive menu, which is somewhat widely used now. The question is — 
> should we implement this in Qt Windows Extrasr or default behavour wrapper is 
> preferred?
> ___
> 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] QtWindowsExtras

[Jake Thomas Petroules]

As many OS/WM utility methods were removed from Qt 5, we need to reimplement 
their functionality in the QtWindowsExtras, QtMacExtras, and QtX11Extras 
libraries.

For example, in QtMacExtras we have a unified toolbar implementation that 
replaces setUnifiedTitleAndToolbar(), and converter functions to replace 
QPixmap::toMacCGImageRef(), QPixmap::fromMacCGImageRef() as well as other type 
conversions, etc. Morten also has some clipboard functionality pending as well 
as a utility function to set the dock menu to a QMenu, native widgets, and some 
other stuff. Similarly, QtX11Extras has QX11Info ported from Qt 4 and I imagine 
may have more functionality in the future..

Windows is no different, and there is a lot that could fit into such a library, 
including but not limited to:

* Replacements for native API converter functions (QPixmap::toWinHBITMAP(), 
QPixmap::fromWinHBITMAP(), QPixmap::toWinHICON(), QPixmap::fromWinHICON()... I 
think there was also a QMenu::wceMenu() that gave an HMENU and a similar 
function for Windows itself (not CE) would be great)
* Taskbar functionality for Windows 7/8 (jump lists, overlay icons, progress 
indicators, thumbnail toolbars, thumbnail tab previews)
* DWM interaction (enable/disable composition, extend frame into client area)

This is important functionality usable by a large number of Windows apps, 
clearly evidenced by the former presence of some of this functionality in Qt 4. 
I have a decent amount of code implementing much of this functionality already, 
just awaiting contribution...

I'm sure there is more I haven't thought of as well. Perhaps some Windows 8 
APIs?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Jan 18, 2013, at 12:16 PM, Laszlo Papp  wrote:

> On Thu, Jan 17, 2013 at 8:58 PM, Jake Thomas Petroules 
>  wrote:
> As we have a QtMacExtras and QtX11Extras, could someone please create a 
> QtWindowsExtras as well?
> 
> Could you please elaborate about the use case?
> 
> Laszlo

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

Re: [Development] QtWindowsExtras

[Jake Thomas Petroules]

As we have a QtMacExtras and QtX11Extras, could someone please create a 
QtWindowsExtras as well?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development