Re: [Development] [Qt-creator] Nominating Marco Benelli for Approver status

[Ziller Eike]

> On Apr 13, 2016, at 10:06 AM, Hunger Tobias  
> wrote:
> 
> Hello Qt Developers,
> 
> I hereby nominate Marco Benelli for Approver status. He has put in a lot of
> effort to maintain the QML code inside Qt Creator over the recent month and in

months

> fact is the default assignee for all bugs in that area of Qt Creator.
> 
> He did good work in his area and Qt Creator in general, so I think he has more
> than deserved Approver status by now.

+1

> -- 
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
> Gesellschaft:
> Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> ___
> Qt-creator mailing list
> qt-crea...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller, Principal Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8 at least). Reproducible test case included.

[Ziller Eike]

> On Apr 10, 2016, at 7:22 AM, jaso...@mail-central.com wrote:
> 
> Use of Qt Keyboard shortcuts has been broken in Qt for years.
> 
> There are lots of bugs about it in Qt and KDE projects.
> 
> This one looks close to what I'm seeing,
> 
>   Can't assign keyboard shortcut with Meta modifiers
>   https://bugreports.qt.io/browse/QTCREATORBUG-9846

This bug report is more about that you could not assign such a shortcut in Qt 
Creator to begin with.
That is a different problematic though. To check if Qt (Creator) in principle 
is able to handle a certain shortcut,
you should open Tools > Options > Environment > Keyboard in Qt Creator and 
assign a shortcut there
(e.g. by typing the Qt key sequence into the line edit for the shortcut 
“Ctrl+Meta+Alt+L”).

Br, Eike

> This one got mentioned in a few KDE bugs
> 
>   Qt LineEdit incorrectly truncates "Password" dialog elements when 
> entered with a KDE Custom Shortcut ...
>   https://bugreports.qt.io/browse/QTBUG-24304
> 
> There are lots of others.
> 
> Anyway, the point is -- shortcuts don't work.
> 
> I have a reproducible test case. It's 100% reproducible on 4 machines.  Here 
> anyway.
> 
> The Qt shortcuts fail only when used in Qt-based applications.
> They work fine in NON-Qt apps (GTK, JAVE, etc).
> 
> I can't create a Qt account, can't add to any bug (not that I'm clear on 
> which one).  Posting the testcase here.
> 
> I'm cc'ing to a couple of developer's named I saw in those bugs.  Maybe 
> somebody will stick this in the right place.
> 
> -
> on:
>   /usr/bin/systemsettings5 -v
>   systemsettings 5.6.2
> 
> exec:
>   /usr/bin/systemsettings5
> 
> open:
>   Configure Desktop
>   Workspace
>   Shortcuts
>   Custom Shortcuts
>   Configure Input Actions settings
> 
> in:
>   'Name' pane
> 
> right-click:
>   New
>   Global Shortcut
>   Send Keyboard Input
> 
> rename New action:
>   TEST
> 
> select:
>   TEST
> 
> in:
>   'Trigger' Pane
> 
> click:
>   Shortcut "None"
> 
> enter:
>   Meta-Ctrl-Alt-L
> 
> click:
>   Apply
> 
> in:
>   'Action' Pane
> 
> enter:
>   Shift+3:X
> 
> click:
>   Apply
> 
> (1)
> open:
>   LibreOffice Writer v5.1.2.2.0 10m0(Build:2) document
> 
> press:
>   Meta-Ctrl-Alt-L
>   OUTPUT: "#X"
> 
> (2)
> open:
>   Eclipse Editor v4.6 (Build:I20160405-0800) document
> 
> press:
>   Meta-Ctrl-Alt-L
>   OUTPUT: "#X"
> 
> (3)
> open:
>   KDE Kate v15.12.3 document
> 
> press:
>   Meta-Ctrl-Alt-L
>   OUTPUT: (none); window flashes
> 
> (4)
> open:
>   QtCreator v3.6.0 (based on Qt 5.6.0) document
> 
> press:
>   Meta-Ctrl-Alt-L
>   OUTPUT: (none); window flashes
> -
> 
> If someone knows a bug report that this'll get fixed at, pls post it there, 
> and let us know here.
> 
> Jason

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt Coding Guidelines

[Ziller Eike]

> On Mar 16, 2016, at 20:33, André Somers  wrote:
> 
> 
> 
> Op 16/03/2016 om 16:14 schreef Koehne Kai:
>> Hi there,
>> 
>> We have had quite some discussions about the use of C++11 features and right 
>> API in the past on this mailing list - but if there has been a consensus 
>> (which is sometimes hard to find out), it was often buried pretty deep in 
>> the mailing thread. IMO it would be good to make decisions more explicit, 
>> and write them down also somewhere outside of this list.
>> 
>> We already have the coding conventions page: 
>> https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at 
>> keeping it up to date - and one reason is IMO that, given that it's a wiki 
>> everybody can edit, people in a twist of irony stay away from editing it to 
>> avoid editing wars.
>> 
>> I've been contemplating whether we should instead use some more formalized 
>> decision process. We could have a document uploaded in git, and every change 
>> needs to be reviewed and approved by Lars. While at it, this fresh start 
>> would also be a good opportunity to check whether all the rules in above 
>> wiki page, and the structure of the document in general, can be improved.
>> 
>> As sort of a demo I created
>> 
>> https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md
>> 
>> What do you think? If nobody sees the value in this, I'll refrain from 
>> sinking more time into it.
>> 
> Could work I think. But how do you propose these changes get announced? Who 
> will be added to review such changes?

Changes should still be discussed on this mailing list first (if they are not 
cosmetic). These discussions can result with a change on code review (also 
posted here).
As something that effects the whole of Qt, it must be reviewed by the Chief 
Maintainer == Lars.

(My 2c, we do it similar with Qt Creator, seemed to have worked fine enough so 
far.)

Br, Eike

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

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Ziller Eike]

> On Mar 2, 2016, at 11:23 AM, Milian Wolff <milian.wo...@kdab.com> wrote:
> 
> On Mittwoch, 2. März 2016 10:14:18 CET Ziller Eike wrote:
>>> On Feb 29, 2016, at 1:21 PM, Milian Wolff <milian.wo...@kdab.com> wrote:
>>> 
>>> On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote:
>>> 
>>>> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
>>>> 
>>>>>> The main problems of templated QObject are captured more or less in
>>>>>> this
>>>>>> 
>>>>>> thread:
>>>>>> http://lists.qt-project.org/pipermail/development/2013-March/010288.htm
>>>>>> l
>>>>>> 
>>>>>> Personally I still think it would be a fancy feature, a bit dangerous
>>>>>> to
>>>>>> 
>>>>>> implement maybe even dangerous to use, but really cool :-D
>>>>> 
>>>>> 
>>>>> Thanks for the link. How often is the MOC layout changed in an ABI
>>>>> incompatible way?
>>>> 
>>>> 
>>>> There's no historical pattern. There was a major break from Qt 3 to 4
>>>> and
>>>> smaller one from 4 to 5. Qt 4 did have updates that didn't break the
>>>> ABI;
>>>> the Qt 5.0 update removed the ability to read meta objects created with
>>>> Qt
>>>> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still
>>>> used register-on-load meta objects).
>>>> 
>>>> But since the meta object itself has a version number and the only code
>>>> that
> ever reads the internal data is inside QtCore, so we could make
>>>> changes that change the layout.  We haven't done that: all changes
>>>> between major releases have added things without changing the layout.
>>>> 
>>>> That's the structure layout though. The file itself compares the
>>>> Q_MOC_OUTPUT_REVISION macro for equality (not ordering).
>>> 
>>> 
>>> OK, but changing the layout between major versions is fine as we break ABI
>>> 
> anyways then, no?
>>> 
>>> 
>>>>> I.e. what problems would we get from having to install the
>>>>> moc files?
>>>> 
>>>> 
>>>> Lots.
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Have I convinced you? I'm only getting warmed up. I'm sure I can find
>>>> more
>>>> issues.
>>> 
>>> 
>>> Thanks for the exhaustive, and educative list! I think this should be put
>>> on 
> the Wiki somewhere for future reference.
>>> 
>>> 
>>>>> Alternatively: couldn't moc re-create the required data from included
>>>>> files
>>>>> when they contain templated objects? That would solve the problem as
>>>>> well,
>>>>> no?
>>>> 
>>>> 
>>>> I have no idea what you meant here.
>>>> 
>>>> Or, well, I do have one, but I don't think that I understood correctly
>>>> what
> you're suggesting. I understood that we keep a copy of the header
>>>> file's source in the target application and run moc at runtime to
>>>> dynamically create the meta object, on the fly.
>>>> 
>>>> Since I don't think that's what you're suggesting and since the above has
>>>> so
> many problems (starting with the fact that it doesn't resolve the
>>>> problem), I'm not even going to analyse it.
>>>> 
>>>> Can you clarify what you meant?
>>> 
>>> 
>>> Yes, what I had in mind from my outsiders POV was the following, and I
>>> have no 
> clue whether it is feasible at all:
>>> 
>>> We have the following structure:
>>> 
>>> $path1/lib/foo.h
>>> template Foo : QObject { ...};
>>> 
>>> moc is not doing anything here as the templated QObject is not fully 
>>> specialized.
>>> 
>>> $path2/app/bar.h:
>>> #include 
>>> using Bar = Foo;
>> 
>> 
>> That would break if any other code in the application (possibly in a
>> different library linked to it) has e.g.
> using Blah = Foo;
>> right?
>> That sounds pretty fragile. Especially if an application loads plugins.
> 
> Can you clarify what would break here? Isn't it exactly the same as doing 
> QVector in multiple TUs?

As I understood it, moc would generate the MetaObject for Foo when it sees 
“using SomeAlias = Foo” (or some macro).
So if lib A does it and lib B does it, and they both get linked into the same 
application, there would be two implementations of the static meta object, 
which Thiago said would not work?
But maybe I missed something from the discussion.

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Ziller Eike]

> On Feb 29, 2016, at 1:21 PM, Milian Wolff  wrote:
> 
> On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote:
>> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
 The main problems of templated QObject are captured more or less in
 this
 
 thread:
 http://lists.qt-project.org/pipermail/development/2013-March/010288.html
 
 Personally I still think it would be a fancy feature, a bit dangerous
 to
 
 implement maybe even dangerous to use, but really cool :-D
>>> 
>>> Thanks for the link. How often is the MOC layout changed in an ABI
>>> incompatible way?
>> 
>> There's no historical pattern. There was a major break from Qt 3 to 4 and
>> smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI;
>> the Qt 5.0 update removed the ability to read meta objects created with Qt
>> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still
>> used register-on-load meta objects).
>> 
>> But since the meta object itself has a version number and the only code that
>> ever reads the internal data is inside QtCore, so we could make changes
>> that change the layout.  We haven't done that: all changes between major
>> releases have added things without changing the layout.
>> 
>> That's the structure layout though. The file itself compares the
>> Q_MOC_OUTPUT_REVISION macro for equality (not ordering).
> 
> OK, but changing the layout between major versions is fine as we break ABI 
> anyways then, no?
> 
>>> I.e. what problems would we get from having to install the
>>> moc files?
>> 
>> Lots.
> 
> 
> 
>> Have I convinced you? I'm only getting warmed up. I'm sure I can find more
>> issues.
> 
> Thanks for the exhaustive, and educative list! I think this should be put on 
> the Wiki somewhere for future reference.
> 
>>> Alternatively: couldn't moc re-create the required data from included
>>> files
>>> when they contain templated objects? That would solve the problem as well,
>>> no?
>> 
>> I have no idea what you meant here.
>> 
>> Or, well, I do have one, but I don't think that I understood correctly what
>> you're suggesting. I understood that we keep a copy of the header file's
>> source in the target application and run moc at runtime to dynamically
>> create the meta object, on the fly.
>> 
>> Since I don't think that's what you're suggesting and since the above has so
>> many problems (starting with the fact that it doesn't resolve the problem),
>> I'm not even going to analyse it.
>> 
>> Can you clarify what you meant?
> 
> Yes, what I had in mind from my outsiders POV was the following, and I have 
> no 
> clue whether it is feasible at all:
> 
> We have the following structure:
> 
> $path1/lib/foo.h
> template Foo : QObject { ...};
> 
> moc is not doing anything here as the templated QObject is not fully 
> specialized.
> 
> $path2/app/bar.h:
> #include 
> using Bar = Foo;

That would break if any other code in the application (possibly in a different 
library linked to it) has e.g.
using Blah = Foo;
right?
That sounds pretty fragile. Especially if an application loads plugins.

Br, Eike

> Now when we compile app, moc runs over the fully specialized templated 
> QObject 
> and can instantiate it as needed and put all the required code into the 
> moc_bar.cpp file as it would for a "normal" QObject. I.e. there is no need to 
> install the templated QObject's moc file. This also is close to how an 
> ordinary template is handled by a C++ compiler as far as I know.
> 
> Maybe I'm missing something, but this sounds like an elegant solution? The 
> only downside is increased complexity in moc to find such instantiations. 
> Until clang can be used for moc, we could add a macro, lets say 
> Q_INSTANTIATE(Foo), or similar.
> 
> What do you say? What am I missing that would break my assumptions?
> -- 
> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Supported platforms for Qt 5.8

[Ziller Eike]

> On Feb 20, 2016, at 7:04 PM, Thiago Macieira  
> wrote:
> 
> On sexta-feira, 19 de fevereiro de 2016 21:01:02 PST Knoll Lars wrote:
>> * We drop support for VS2012. This implicitly drops support for WEC2013.
>> Reason is that the compiler is still having rather large problems with it's
>> C++11 support. I hope that we could serve the WEC market rather well with
>> 5.6 and 5.7 for the years to come. In the end, the benefit we get with
>> dropping the compiler will hopefully outweigh the cost (loosing WEC) by a
>> good margin.
> 
> This buys us:
> 
> - delegating constructors
> - "explicit operator" member funcvtions
> - nsdmi
> - initializer_list (not uniform initialisation!)
> - raw strings
> - template alias (using ... = ...)
> - variadic templates
> 
> It would buy us, if we raised to GCC 4.8 too:
> - deleted and defaulted members

Hm, deleted and defaulted members should work fine with gcc 4.7(.3) as well.
Please note that MSVC2013 fails to recognize move constructors and move 
assignment operators as special member functions, so you cannot default or 
delete them.
There is also an issue with perfect forwarding in MSVC2013 (it copies anyway).

>  (nsdmi, delegating constructors, template aliases require GCC 4.7)
> 
> Is it worth it? The only things I'd really want are intialiser lists and 
> variadic templates. Note that without constexpr, initialiser lists' value is 
> limited.
> 
> (I'm assuming Clang minimum version 3.4, as found on FreeBSD, which is 
> feature-complete for C++11)
> 
> -- 
> 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

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] HEADS UP: OSX build requirements for 5.7

[Ziller Eike]

> On Feb 10, 2016, at 6:36 PM, Petroules Jake  
> wrote:
> 
> 
>> On Feb 10, 2016, at 8:11 AM, Tor Arne Vestbø 
>>  wrote:
>> 
>> On 10/02/16 17:06, Thiago Macieira wrote:
>>> On quarta-feira, 10 de fevereiro de 2016 12:00:00 PST Tor Arne Vestbø wrote:
 Does anyone see any issues with this going forward?
>>> 
>>> We need to be sure Qt compiles with the latest Xcode available on each of 
>>> the
>>> OS X versions that Qt can be developed on. Since 10.8→10.11 updating is 
>>> free,
>>> the only extra test is 10.7.  The latest Xcode that can be installed on 10.7
>>> is Xcode 5.1, so it's important we keep building with that.
> 
> Pretty sure the App Store on my 10.7 VM prompts me to upgrade to 10.11 for 
> free as well. I'm on the train without my VM SSD so I can't check right now.
> 

While I think that the whole App Store argument is a valid one for iOS, I think 
the situation on OS X is very different

- The App Store is by far not the only software distribution mechanism on OS X
- There is a market of applications that even cannot be distributed through the 
App Store
- It seems that developers even move away from distributing through the App 
Store on OS X because of various reasons (long review process, no payed 
updates, etc)

> On Feb 10, 2016, at 7:31 PM, Thiago Macieira  
> wrote:
> 
> On quinta-feira, 11 de fevereiro de 2016 02:02:27 PST Tim Blechmann wrote:
>> we have seen funny toolchain bugs, with 10.10 sdk and 10.8 deployment
>> target on 10.8, where std::exceptions could not be caught ... compiling
>> against 10.8 sdk solved that issue.
> 
> Regardless of whether that is a valid approach or not, the fact that people 
> are doing that poses a problem for us. If we write code against the latest 
> toolchain, it may not compile against older ones people might be using.
> 
> That can be because we used new features that aren't present in older ones, 
> even if properly runtime checked.
> 
> Another problem is that the compilers in the old toolchains are older, with 
> older libc++ and with bugs that we aren't testing for.
> 
> If we're going to upgrade our Xcode in all our builds, I would advise we also 
> make it mandatory for everyone else too. Check during configure against the 
> minimum SDK version, that being the *current* at the time of release.

We also do not prevent compilation on , even though that is certainly not CI tested.

Br, Eike

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] What kind of airplane we want to build?

[Ziller Eike]

> On Jan 23, 2016, at 1:12 AM, Kevin Kofler <kevin.kof...@chello.at> wrote:
> 
> Ziller Eike wrote:
>>> I would like that trend to continue. The likely next candidates are
>>> threads, futures and locks.
>> 
>> +1
> 
> I wonder why everyone so far agreed on that. So let me dissent: I think 
> having these things in Qt with Qt-style APIs is a good thing and I don't see 
> why we should discard our solution for the STL one. At most, where it makes 
> sense, we could wrap the STL stuff as we're doing with std::atomic.

The +1 statement above doesn’t mean that there is no room for convenience on 
top of the std features, and integrating them with Qt features like 
signals/slots.

E.g. std::future doesn’t support asynchronous result reporting (some thread has 
at some point to block for getting the result in the end), or progress 
reporting, something that the QFutureInterface, QFuture, QFutureWatcher triple 
provides. (Though, also only partially in Qt. We added more within Qt Creator, 
which was supposed to migrate to Qt but didn’t make it.)
That still means that any Qt solution to that should best only be convenience 
around std::future and std::thread and the async algorithms that will probably 
come to C++ at some point.
We will want to not block ourselves from coming C++ features like 
future.then(...) and so on.

> I find it much nicer and more readable if I can just write sort(v).
> 
> +1!
> 
> And I don't think ranges are the answer here. It's just another layer of 
> overengineered abstraction (as they will surely be implemented as a pair of 
> iterators in practice) when in 99+% of the cases you just want to operate on 
> the whole container anyway.
> 
>> Or "const List foos = transformed(myThings, ::foo);"
>> instead of "List foos; std::transform(myThings.begin(), myThings.end(),
>> std::back_inserter(foos), std::mem_fn(::foo));” (notice that “foos”
>> is also not const in the “pure" std version)
> 
> Wow, the STL version is horrible! std::back_inserter is particularly ugly, 
> and the usual misleading STL name (which suggests "backwards", when actually 
> it means "to the back", so when inserting multiple elements, forward) does 
> not help either.
> 
>> We started some experiments with convenience wrappers for std algorithms
>> for use in Qt Creator when we started requiring C++11:
>> http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h
> 
> Interesting. That could be a starting point for a QtAlgorithms successor.
> 
>>> why do they use C++ if they so hate it?
>> 
>> Maybe they don’t hate it, but still wished it had a less verbose API if
>> you don’t need the verbosity.
> 
> The funny thing is that only redundant boilerplate is verbose in the STL. 
> The stuff that matters, the API names, are horribly terse (e.g. "deque").
> 
> And I don't hate the C++ language, only its standard library. The language 
> is actually great, much better than Java or Python. So, since Qt lets me not 
> touch the STL with a 10-foot pole, I see no problem with using C++. (Qt is 
> also by far the best class library out there.)
> 
>Kevin Kofler
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] What kind of airplane we want to build?

[Ziller Eike]

> On Jan 23, 2016, at 1:47 AM, Thiago Macieira  
> wrote:
> 
> On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote:
>> I feel it's actually TOO rapidly changing. C++11 even threw out C
>> compatibility, not only by not adopting all C99 improvements (e.g. VLAs),
>> but also by subtly interpreting even as simple valid C90 code as "auto x =
>> 1.5;" in an incompatible way. (OK, that code is not valid C++98, but at
>> least a C++98 compiler would tell you what is wrong with it, C++11 just
>> silently gives it a different meaning.)
> 
> I disagree with you on all points here. C++ is *not* moving too fast. In some 
> areas, it's not moving even fast enough: where's the reflection support? 
> Meanwhile, discussions linger in the standards proposal mailing list about 
> how 
> many templates we need for parsing a string to integer.
> 
> Specifically on VLAs, the proposal was added to C++14, but dropped due to 
> disagreement. C++ would have implemented a subset of C99's requirement, but 
> not the controversial parts like taking a sizeof and getting the runtime size 
> and passing them as parameters. The less we talk about
>   void f(int n, char array[static n]);
> the better.
> 
> On auto, it's not a big loss. So what if it's incompatible between C and C++? 
> NO ONE writes "auto" anymore in C, since the only place where you can use it 
> are places where it's redundant. As for the case you showed, even C99 
> deprecated it.
> 
> I miss designated initialisers and that is a shame. When that comes around, 
> the discussion always goes on to talk about named parameters, which meets 
> stiff resistance in the committee.
> 
>> I consider the fix of the "have to write '> >' to close double templates"
>> issue as the most useful improvement in the entire C++11 standard.
> 
> Not variadic templates? Not constexpr? Not decltype? Not rvalue references?

Variadic templates + decltype + SFINAE/type_traits + universal references are 
able to reduce several thousand lines of very limited functionality, 
repetitive, unreadable QtConcurrent code, to probably something like a few 
hundred lines with more features and better behavior (e.g. unlimited arguments 
and argument types, movable types).
I'd see most of 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/concurrent/qtconcurrentstoredfunctioncall.h
 and http://code.qt.io/cgit/qt/qtbase.git/tree/src/concurrent/qtconcurrentrun.h 
would just be gone.

> By the way, if you Google for "C++ most vexing", you'll see a problem that is 
> still not solved and probably won't be.
> 
>> Please do not make major changes to Qt that break all existing code, or even
>> replace it with something entirely different. It causes major pain. There
>> is useful software out there still stuck on Qt 3 years after Qt 4.0.0, and
>> the changes you suggest would be even much worse than the Qt 3 to 4
>> transition.
> 
> We will have to eventually break some things. Compatibility with old code has 
> kept QIODevice stuck in time, unable to move forward and implement important 
> things like zero-copy buffering.
> -- 
> 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

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] What kind of airplane we want to build?

[Ziller Eike]

> On Jan 20, 2016, at 3:12 PM, Marc Mutz  wrote:
> 
> On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote:
>> I think it would be productive for the discussion to build story of what we
>> want to do. A story of the big picture. Maybe as a first step we can show
>> how we tackle problems with Qt 5 and what are the proposed technologies in
>> the future C++ standard. 
> 
> For me, Qt always was "the C++ standard library that C++ lacked". Ever since 
> Qt 3, it also integrated pretty well with the rest of the standard library. 
> That was easy, because pretty much the only thing that the standard library 
> had and Qt didn't were the algorithms, and Qt and the STL algorithms 
> integrated well. And there were conversion functions for pretty much 
> everything to/from std.
> 
> We even deprecated our algorithms when we started requiring full C++98 
> support 
> in 5.0.
> 
> We used to roll our own atomics, but dropped them in 5.7 when we required 
> partial C++11 support. We rolled our own foreach, and now it looks like we're 
> dropping it in favour of range-for.
> 
> I would like that trend to continue. The likely next candidates are threads, 
> futures and locks.

+1

> Now that C++ punches out a new standard every three years, I would change 
> that 
> into "Qt is the part of the C++ standard library that C++ sill lacks". I 
> would 
> like Qt to continue to integrate well with the standard library and phase out 
> its own solutions as the standard library catches up.
> 
> We have been doing that in the past. It's just as C++ standardisation 
> accelerates, so will the need to phase out Qt features that got superseded.
> 
> I perceive, however, that for many people, Qt is what makes them forget 
> they're working on C++, a language they would not otherwise poke at with a 
> long stick. They probably also cannot tolerate writing std::sort(v.begin(), 
> v.end()) instead of qSort(v).

I find it much nicer and more readable if I can just write sort(v).

Or "const List foos = transformed(myThings, ::foo);"
instead of "List foos; std::transform(myThings.begin(), myThings.end(), 
std::back_inserter(foos), std::mem_fn(::foo));”
(notice that “foos” is also not const in the “pure" std version)

We started some experiments with convenience wrappers for std algorithms for 
use in Qt Creator when we started requiring C++11:
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h

>  But Qt is available in D and Python, too, so ... 
> why do they use C++ if they so hate it?

Maybe they don’t hate it, but still wished it had a less verbose API if you 
don’t need the verbosity.

Br, Eike

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Ziller Eike]

> On Jan 19, 2016, at 10:40 PM, Marc Mutz <marc.m...@kdab.com> wrote:
> 
> On Tuesday 19 January 2016 19:56:38 Mathias Hasselmann wrote:
>> Am 19.01.2016 um 15:21 schrieb Ziller Eike:
>>>> On Jan 19, 2016, at 16:09, Marc Mutz <marc.m...@kdab.com> wrote:
>>>> I doubt many people actively use the fact that Qt containers are cheap
>>>> to copy.
>>> 
>>> Each and every developer that uses Qt uses the fact that Qt containers
>>> are cheap to “copy"
>>> 
>>> class A
>>> {
>>> 
>>> public:
>>> QVector something() const;
>>> 
>>> private:
>>> QVector m_something;
>>> 
>>> };
>>> 
>>> QVector A::something() const
>>> {
>>> 
>>> return m_something;
>>> 
>>> }
>> 
>> Good point Eike, thank you.
>> 
>> Marc, wow would one avoid invocation of the copy constructor here?
>> Without handing out pointers or references. Of course.
> 
> It's funny how the same people who think nothing of the per-element memory 
> allocation of QList suddenly become vehement performance critics when it 
> comes 
> to CoW :)

Well, passing around a list and doing something based on its elements happens a 
lot more than actually constructing lists.

But the point is not that you cannot write efficient code with std containers, 
but that changing from CoW to non-CoW _will_ potentially effect basically all 
existing Qt based code.
Even if only N% of the uses are actually noticeably effected, these still need 
to be found and fixed.
Any fix in the API will require investigating and potentially fixing the 
callers of that API. If a Qt-based product is a library, that responsibility is 
then
pushed to Qt’s customers’ customers.

We still haven’t even managed to automatically test for performance regressions 
in _Qt_, afaik?
I think that the argument that people will notice performance issues that 
matter and fix them, and the rest don’t matter or will be found by some tool, 
is too optimistic.

> It likely just doesn't matter, the rest of the C++ community has been working 
> with containers that don't do CoW for the past 20 years and have survived.
> 
> In those cases where it does matter, you'd return by const-&. Or an 
> array_view. And no, that doesn't restrict your freedom to implement the 
> function in any meaningful way, because you can always keep a caching mutable 
> member to hold the result for the next call to the function (memoisation or 
> however it's called), without any loss except the space required for the 
> member.

That awfully sounds like re-implementing CoW logic by hand everywhere where 
someone providing an API thinks it might be worth the effort.

> What about non-arrays? By the time we get around to all this, there will be 
> no 
> containers other than array-compatible ones left, because nothing else will 
> provide the required speed. And if there are, you can write a _view for 
> those, 
> too.
> 
> -- 
> Marc Mutz <marc.m...@kdab.com <mailto:marc.m...@kdab.com>> | Senior Software 
> Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> Development mailing list
> Development@qt-project.org <mailto:Development@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development 
> <http://lists.qt-project.org/mailman/listinfo/development>
-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Ziller Eike]

> On Jan 19, 2016, at 16:09, Marc Mutz  wrote:
> 
> On Tuesday 19 January 2016 14:33:46 Giuseppe D'Angelo wrote:
>> On Tue, Jan 19, 2016 at 3:07 PM, Marc Mutz  wrote:
>>> I'd aggregate the std container instead of inheriting it, but yes, that's
>>> a good idea. I just wrote a mail suggesting essentially the same, only
>>> slower.
>>> But I'd have nothing against going all-in, either.
>> 
>> We can't "suddenly" break CoW, though. Who's going to review the millions
>> of lines of code where copies where happily taken assuming they were cheap?
> 
> Who's reviewing the millions of lines of code where hidden detaches are 
> happily incurred even though they are not cheap?
> 
> I'd say that if you took copies in a tight loop, you'll notice and the 
> profiler 
> will find it for you. And the rest don't matter, or they will be found by 
> Clazy.
> 
> I doubt many people actively use the fact that Qt containers are cheap to 
> copy.

Each and every developer that uses Qt uses the fact that Qt containers are 
cheap to “copy"

class A
{
public:
QVector something() const;
private:
QVector m_something;
};

QVector A::something() const
{
return m_something;
}

Br, Eike

> But yes, Qt API needs to be reviewed with an eye towards this. Then 
> again, Non-Qt C++ would be horribly slow if copying containers was so 
> prohibitly expensive.
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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] RFC: QProcess variant or separate class for launching applications "GUI-style"

[Ziller Eike]

> On Jan 7, 2016, at 10:14 PM, René J. V. Bertin  wrote:
> 
> Sorvig Morten wrote:
> 
>> Another point: Isn't there a fundamental incompatibiity between 
>> LaunchServices
>> and QProcess? LanchServices may ‘activate’ an already running process, while
>> QProcess always starts a new process.

That should be possible to be prohibited with launch flag kLSLaunchNewInstance

> This is something that I think we have not yet taken into consideration. It 
> doesn't necessarily matter for a "startDetached" form of launching though,

If you just care about starting an application and being notified when it 
finishes, without the need for output/input streams or PIDs, then you can 
probably just run “/usr/bin/open -n -W "

Br, Eike

>  where/when you don't care if the detached process is a newly started one or 
> an 
> already running process. It should be possible to detect termination for such 
> a 
> "reused" process too (via an NSNotificationCentre), so I think one could 
> write a 
> class that behaves as the same regardless of whether the process it 
> interfaces 
> with is a newly started process or not.
> 
> Maybe rather a QGuiProcess then? Or is OS X really the only OS where there 
> exists a specific spawning API for GUI apps in addition to a more traditional 
> Posix one?
> 
> NB: a contact at Apple taught me 2 things in this context:
> - app bundle executables may not always start through system() or exec() in 
> the 
> future (which will probably force a redesign of QProcess)
> - even in cases where fork+exec is appropriate, one should rather use 
> posix_spawn(). (This would concern shell scripts, non gui apps or "agents" 
> that 
> should remain in the background until they decide otherwise themselves, etc.)
> 
> R.
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] RFC: more liberal 'auto' rules?

[Ziller Eike]

> On Dec 8, 2015, at 10:46 AM, Ziller Eike <eike.zil...@theqtcompany.com> wrote:
> 
> 
>> On Dec 7, 2015, at 2:41 PM, Knoll Lars <lars.kn...@theqtcompany.com> wrote:
>> 
>> On 07/12/15 15:44, "Development on behalf of Marc Mutz" 
>> <development-boun...@qt-project.org on behalf of marc.m...@kdab.com> wrote:
>> 
>> 
>> 
>>> On Monday 07 December 2015 13:48:58 Ziller Eike wrote:
>>>> I do not think that more usage of ‘auto’ will make any code (or
>>>> refactorings of it) ‘safer’. IMO this is only about convenience and
>>>> readability.
>>> 
>>> std::map<std::string, std::string> stdMap = ...;
>>> 
>>> for (const std::pair<std::string, std::string>  : stdMap)
>>>doSomething(e.first, e.second);
>>> 
>>> for (const auto  : stdMap)
>>>doSomething(e.first, e.second);
>>> 
>>> The second loop is at least two orders of magnitude faster (doSomething() 
>>> is 
>>> an out-of-line no-op).
>> 
>> I think the summary here is that auto gives you one guarantee: It won’t do 
>> an implicit conversion for the initial assignment.

So, directly after the above example in Item 5, Item 6 in Effective Modern C++ 
continues with the examples of how you can shoot yourself in the foot _because_ 
you used auto.

std::vector features(const MyType );
MyType w;
auto someFeatureActive = features(w)[5];
doSomething(someFeatureActive); // < undefined behavior because 
someFeatureActive is _not_ a bool

We have something similar in Qt:

QString a = "ABC";
QString b = "abc";
auto result = a + b;
a.replace("A", "C");
qDebug() << result;

prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is defined, 
because result is not a QString in that case.

So funny/unwanted behavior can occur both because one used the wrong explicit 
type, and because one used auto instead of an explicit type.

> Granted.
> I really wonder though, why it is possible to assign the wrong type to a 
> _reference_ here, even if it is const ?
> I cannot do that with e.g. a std::vector (std::vector v; 
> const std::vector  = v;), so is that some funny thing with 
> std::pair?
> The spirit of the “you can use auto when assigning iterator type” was to mean 
> “you can use auto when assigning long ugly template types” at least in case 
> of ‘known patterns' (of which we do not have too many in Qt API, therefore 
> iterator types). So I think this use of auto is covered by the “spirit” of 
> the rule.
> 
> Br, Eike

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] RFC: more liberal 'auto' rules?

[Ziller Eike]

> On Dec 22, 2015, at 1:28 PM, Marc Mutz <marc.m...@kdab.com> wrote:
> 
> On Tuesday 22 December 2015 11:26:40 Ziller Eike wrote:
>> We have something similar in Qt:
>> 
>>QString a = "ABC";
>>QString b = "abc";
>>auto result = a + b;
>>a.replace("A", "C");
>>qDebug() << result;
>> 
>> prints “CBCabc” instead of “ABCabc” when QT_USE_FAST_OPERATOR_PLUS is
>> defined, because result is not a QString in that case.
>> 
>> So funny/unwanted behavior can occur both because one used the wrong
>> explicit type, and because one used auto instead of an explicit type.
> 
> This is not specific to auto, though:
> 
>QStringView v = QLatin1Char('a');
>const char *data = str.toLatin1(); // implicit conversion by default
>QLatin1String l1 = str.toLatin1();
>QVector v = {0, 1, 2};
>QVector::iterator it = v.begin();
>const QVector v2 = v;
>*it = 1;
>assert(v2.front() == 0); // boom
> 
> It's a general peril when working with C++.

I’m actually not arguing against the use of auto in principle. But I’m arguing 
against introducing auto because it (supposedly?) makes the code safe(r). (That 
context has unfortunately been cut off from the mail at some point.)
C++ is complicated, and type deduction and its results are no exception.
If you know what you are doing, auto can make code more readable and easier to 
write, especially with templated code.
When it makes code more readable or not tends to be pretty subjective it seems, 
so IMO someone just has to decide :)

> Reminds me of the 1970s when we got a law requiring the use of the seat-belt 
> in cars in Germany. My uncle used to tell the story how one of his friends 
> survived a crash because he was ejected from the car since he was _not_ 
> buckled up, just to follow up with the story how another friend was not 
> harmed 
> in a crash because he _was_ strapped in...

Not sure what you want to say with this analogy.
Anyhow, discussions about pros and cons are still necessary. I’m sure that 
there are laws in Germany that supposedly increase security but effectively 
don’t.
I would require that the decision to introduce a law requiring the use of 
seat-belts was based on extensive studies on how seat belts increase or 
decrease the security of a car’s occupants, and how they need to be designed to 
achieve that best. And not on stories at the bar, of how one or the other 
person was either saved or doomed by a seat belt, which you seem to be reminded 
of by the discussion here? ;)

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] New Qt5.6 Beta snapshot available

[Ziller Eike]

> On Dec 12, 2015, at 10:22 AM, anton  wrote:
> 
> Hi,
> 
> just tested the visualstudio 2015 version on windows.
> One thing I noticed:
> 
> In the Designer of a Qt Widgets Application,
> the QWebView Widget is missing.
> 
> Are you aware of this?

Since QtWebKit is deprecated and no binaries are provided, that is expected, 
yes.
Br, Eike

> Thanks
> 
>  Anton
> 
> 
> Heikkinen Jani wrote:
> 
>> Hi all,
>> 
>> 
>> We have finally new qt5.6 beta snapshot available
>> 
>> 
>> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/278/
>> 
>> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/287/
>> 
>> Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/221/
>> 
>> Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/
>> 
>> 
>> 
>> Unfortunately it seems these aren't yet final beta packages, in mac
>> package creator seems to be unusable because of
>> QTBUG-49676 [Reg 5.5->5.6]:
>> Painting of widgets broken when embedding QQuickWidget
>> 
>> 
>> Please test the packages & report all findings in Jira. We are trying to
>> get beta out as soon as possible so please inform all new beta blockers to
>> me immediately.
>> 
>> 
>> br,
>> 
>> Jani
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] RFC: more liberal 'auto' rules?

[Ziller Eike]

> On Dec 7, 2015, at 2:41 PM, Knoll Lars <lars.kn...@theqtcompany.com> wrote:
> 
> On 07/12/15 15:44, "Development on behalf of Marc Mutz" 
> <development-boun...@qt-project.org on behalf of marc.m...@kdab.com> wrote:
> 
> 
> 
>> On Monday 07 December 2015 13:48:58 Ziller Eike wrote:
>>> I do not think that more usage of ‘auto’ will make any code (or
>>> refactorings of it) ‘safer’. IMO this is only about convenience and
>>> readability.
>> 
>> std::map<std::string, std::string> stdMap = ...;
>> 
>> for (const std::pair<std::string, std::string>  : stdMap)
>> doSomething(e.first, e.second);
>> 
>> for (const auto  : stdMap)
>> doSomething(e.first, e.second);
>> 
>> The second loop is at least two orders of magnitude faster (doSomething() is 
>> an out-of-line no-op).
> 
> I think the summary here is that auto gives you one guarantee: It won’t do an 
> implicit conversion for the initial assignment.

Granted.
I really wonder though, why it is possible to assign the wrong type to a 
_reference_ here, even if it is const ?
I cannot do that with e.g. a std::vector (std::vector v; 
const std::vector  = v;), so is that some funny thing with 
std::pair?
The spirit of the “you can use auto when assigning iterator type” was to mean 
“you can use auto when assigning long ugly template types” at least in case of 
‘known patterns' (of which we do not have too many in Qt API, therefore 
iterator types). So I think this use of auto is covered by the “spirit” of the 
rule.

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

Re: [Development] RFC: more liberal 'auto' rules?

[Ziller Eike]

> On Dec 4, 2015, at 8:01 PM, Olivier Goffart  wrote:
> 
> On Friday 4. December 2015 15:39:01 Curtis Mitch wrote:
>>> -Original Message-
>>> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
>>> Olivier Goffart
>>> Sent: Friday, 4 December 2015 2:25 PM
>>> To: development@qt-project.org
>>> Subject: Re: [Development] RFC: more liberal 'auto' rules?
>>> 
>>> On Friday 4. December 2015 14:11:48 Oswald Buddenhagen wrote:
 On Fri, Dec 04, 2015 at 02:07:10PM +0100, Marc Mutz wrote:
> And as an aside, since it has been mentioned in this thread: in
> Python _all_ variables are 'auto'. All. Without exception. Are
> Python programmers more intelligent? Or do they just tolerate more
> pain? :)
 
 i'd suggest the latter.
 no, really. people use external static checkers because the language
 lacks the feature.
 the lack of static typing is a common feature of scripting languages
 and makes them convenient to a degree, but it is an utter nightmare
 for any "real" software development. i really wouldn't want to go there.
>>> 
>>> But auto is still staticaly typed.
>>> 
>>> 
>>> When you have code like
>>> 
>>>   foo->bar()->setFaz(m_factory->createFaz(foo->bar()->type()));
>>> 
>>> You don't see any type.
>>> 
>>> This code that use auto is not less readable. Even if you don't know
>>> what's the type of bar without looking it up.
>>> 
>>>  auto *bar = foo->bar();
>>>  bar->setFaz(m_factory->createFaz(bar->type()));
>> 
>> Isn't this kind of a bad example, because there was no type declared/visible
>> in the first place?
> 
> Precisely my point!   
> There is no type visible before and nobody complains.  So why should one 
> suddenly complains there are no types in the second snippet
> 
>> Anyway, if you're going to take the time to move the result of foo->bar()
>> onto its own line, why not just declare a type? What benefit does auto give
>> here?
>> 
>> I really dislike hiding types behind a generic keyword.
> 
> Because the type is redundent and it's one reason less to make errors:
> Using 'int' instead of 'quint64' or 'size_t', or QString instead of 
> QByteArray 
> is way to frequent. (and the compiler won't complain)

The compiler will then still not complain if you pass that ‘auto’ variable to a 
function taking ‘int’ (or QString, if you don’t have NO_CAST_...), will it?
So in the end people will still just need to know what they are doing, or, 
since IDE support is mentioned several times in this thread, use an IDE with 
stricter warning policy.
(The default setting for the Clang code model in Qt Creator is to warn when 
assigning or comparing 'unsigned int' and ‘int' etc ;) )

> It is also refactoring-proof.  Because you might want to change the name of 
> the type from "FazManager" to "FazHolder", and then you need to touch less 
> code in your refactoring. 

On the other hand if you are changing the return value of a function, there 
will be cases where it would be better if you (and anyone using your function) 
had to explicitly look at the usages.

I do not think that more usage of ‘auto’ will make any code (or refactorings of 
it) ‘safer’. IMO this is only about convenience and readability.

Br, Eike

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

Re: [Development] Proposal to change connectSlotsByName behavior

[Ziller Eike]

> On Dec 4, 2015, at 00:05, Benjamin TERRIER  wrote:
> 
> Hi everyone,
> 
> This message follows an exchange I've had with Thiago on a bug report:
>https://bugreports.qt.io/browse/QTBUG-49749
> 
> 
> In the current state, QMetaObject::connectSlotsByName() tries to find,
> for each slot named "on__" in a given
> object,
> a child object named " and connect the signal to the
> slot. Moreover the documentation says that the search is recursive so
> any
> descendant QObject is looked up (not only direct children).
> 
> My issue here is that the search is done by instantiation order
> (depth-first search) which means that if 2 (or more) children have the
> same name one has
> to know which one is instantiated first to know which one will be
> connected. And of course imposing on the developer to use unique names
> throughout
> a QObject hierarchy is not feasible in particular if he/she is using a
> third-party library and might not know the object names used
> internally.
> 
> This can lead to various hazardous situation, for instance, in a
> perfectly working software, one can break the behavior of the main
> window by simply adding
> a widget in a grand-grand-child widget.
> Or worse if the UI is made using Qt Designer, the behavior of the
> application can be changed by simply reordering the widgets in the
> layout as it will also
> change their creation order.
> An application could even break at runtime if a user enables a plugin
> or set an HMI element visible.
> 
> In my opinion it also breaks encapsulation as the naming in a widget
> can alter the signal/slot connections in another widget.

That is inherent to the “feature”, independent of how the search order is.

> My proposal is to change the behavior of connectSlotsByName to do a
> breadth-first search. In this case, if a direct child is a match it
> will be used
> for the connection regardless of possible matches deeper in the
> hierarchy. Doing so would solve the situations stated above and
> restore encapsulation.

Even though your suggestion would make the issue less prominent, it would not 
actually solve it.
It still highly depends on how the different UI parts are combined. UI from 
e.g. a plugin does not necessarily end up further down in the hierarchy than 
the widget that you wanted to connect to originally.

main
- group box
- - some other widget that is used for grouping
- - - some button (a) that you want to connect to
- plugin specific widget
- - some button with same object name as (a)

Aside from not being able to guard against things like 
myWidget->setParent(window()) anyhow.

IMO:
1. connectSlotsByName is a misfeature. Try not to use it at all.
2. If you really must use it (for what?), use _unique_ object names. E.g. by 
pre- or appending a random sequence of characters, or by using long object 
names that describe where they are used 
(choosePathForSpecificSettingInMainApplicationButton).
3. I don’t see why the risk of breaking existing applications would be worth it 
for a behavior change that does not really fix the issue. Even with your 
proposed change you must do (1) or (2), but then you don’t need the proposed 
change.

Br, Eike

> It seems that Thiago's opinion is that it can not be changed as this
> behavior has been here since Qt 4 and it might break existing
> applications.
> 
> On my side I think it's at least a buggy and error prone behavior or
> even a flawed design and that it must be changed as soon as possible.
> About the risk of breaking existing applications,
> I think making the change is less risky for Qt users as in the current
> state every Qt software can break with any change to an object name or
> instantiation order.
> Also as Qt Designer does push the users to use the connectSlotsByName
> mechanism, it is even possible to generate an example of this
> "unwanted" behavior
> without writing a single line of code (see attached zip in the bug report).
> 
> 
> Regards,
> 
> Benjamin
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] could not find or load the Qt platform plugin "cocoa"

[Ziller Eike]

> On Oct 28, 2015, at 3:09 PM, Gil Moses  wrote:
> 
> Hi,
> 
> I've built Mac universal binaries of v5.5.1 (built separately for i386 and 
> x86_64, then used lipo).
> Built and ran my Qt app (Xcode 5, Mavericks), and got this error:
> 
> . could not find or load the Qt platform plugin "cocoa".
> 
> Further diagnosis using DYLD_PRINT_LIBRARIES and QT_DEBUG_PLUGINS prints this 
> when running the app:
> 
> ==
> 
> QFactoryLoader::QFactoryLoader() checking directory path 
> "/Library/Application Support/Waves/WavesQtLibs_5.5.1/plugins/platforms" ...
> QFactoryLoader::QFactoryLoader() looking at "/Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib"
> Found metadata in lib /Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib, metadata=
> {
> "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
> "MetaData": {
> "Keys": [
> "cocoa"
> ]
> },
> "className": "QCocoaIntegrationPlugin",
> "debug": false,
> "version": 328961
> }
> 
> 
> Got keys from plugin meta data ("cocoa")
> QFactoryLoader::QFactoryLoader() checking directory path 
> "/Volumes/Data/p4client/ProAudio/dev_main/ProAudio/Products/Release/Apps/CODEX
>  App.app/Contents/MacOS/platforms" ...
> dyld: loaded: /Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib
> dyld: unloaded: /Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib
> loaded library "/Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib"
> QLibraryPrivate::loadPlugin failed on "/Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib" : "Cannot 
> load library /Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib: 
> (dlopen(/Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib, 5): 
> Library not loaded: @rpath/QtGui.framework/Versions/5/QtGui\n  Referenced 
> from: /Library/Application 
> Support/Waves/WavesQtLibs_5.5.1/plugins/platforms/libqcocoa.dylib\n  Reason: 
> image not found)”

libqcocoa.dylib does not find @rpath/QtGui.framework/Versions/5/QtGui
What is the RPATH of the executable that you try to run? (check with “otool 
-l”, look for LC_RPATH entries)

Br, Eike

> This application failed to start because it could not find or load the Qt 
> platform plugin "cocoa".
> 
> Available platform plugins are: cocoa.
> 
> Reinstalling the application may fix this problem.
> Abort trap: 6
> 
> 
> 
> I verified that the Qt frameworks (especially the QtGui mentioned in the 
> error) and libqcocoa.dylib are universal i386 & x86_64.
> 
> Any ideas?
> 
> Thanks, 
> Gil Moses
> Waves Ltd.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Ziller Eike]

> On Oct 16, 2015, at 9:10 AM, Poenitz Andre  
> wrote:
> 
> 
> Marc Mutz wrote:
>>> I think too we should embrace the standard library more and don't replicate
>>> their features.
>> 
>> So you think that QStringView is too experimental and _at the same time_
>> replicating the standard. Sounds paradoxal to me.
> 
> It's not paradoxical at all. It would be a new implementation with the usual 
> need for maturing even if it implements a well-known standard concepts.
> 
> And there is indeed room for actual experiments, e.g. when it comes 
> structure layout. Pointer+int offset is not the only possible choice. 
> 
> You cannot do that in Qt proper, due to BC promises.

And there would also be some room in Qt Creator to experiment with and gather 
experience on how all this fits with corresponding API changes, which I also do 
not see how that could be done in Qt without lots of #ifdefs.

> Compile-time opt-in
> is a way to exempt it from BC, but then your main reason to have it in Qt 
> and not in Creator, namely 'more widespread use', is void, as barely anyone 
> will opt in. You'll get more public exposure (with less risk!) if it's used by
> default in Creator code for a while before the then-matured implementation
> goes to the library.
> 
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Ziller Eike]

> On Oct 14, 2015, at 5:14 PM, Matthew Woehlke  wrote:
> 
> On 2015-10-14 10:30, André Somers wrote:
>> Op 14-10-2015 om 15:59 schreef Matthew Woehlke:
>>> STL should change. In Qt and Python, you can use negative indices to
>>> refer to a distance (length) relative to the end (length) of the string.
>>> In STL you can't do that, which is a significant limitation by
>>> comparison. Please don't drop this useful functionality!
>> 
>> I'm not so sure anymore. Do you really think that for instance passing 
>> in a negative _from_ in QString::indexOf to search from the back of the 
>> string is intuitive API? I don't.
> 
> Huh? Of course it is.
> 
>  s.indexOf('c', 5); // find 'c', forward, starting at offset 5
>  s.indexOf('c', -5); // find 'c', forward, starting at offset N-5

So from where does 
s.indexOf(‘c’, i-2)
search?
This is similar to integer overflow, and I think utilizing that in an API leads 
to less readable and potentially unexpectedly behaving code.

Anyhow this seems to be only vaguely related to the things that are discussed 
in this thread.

Br, Eike

> A negative offset -K is exactly the same as N + 1 - K (N = length of
> string). It just saves having to write that out yourself. It *doesn't*
> change the behavior of the function. (I think you are confusing
> tail-relative offset with reverse operation, which is totally different
> and orthogonal.)
> 
> Even STL supports this, partially, for -1; string::npos is generally
> equivalent to -1 in Qt.
> 
> Bah. Okay, apparently Qt actually *doesn't* support tail-relative, but
> just treats n<0 like string::npos. That could be improved for Qt 6
> though, but only if n is signed.
> 
> -- 
> Matthew
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt 5.5.0 build issues on OS X : rpath

[Ziller Eike]

> On Sep 29, 2015, at 10:27, Jake Petroules  
> wrote:
> 
> 
>> On Sep 28, 2015, at 2:40 PM, Thiago Macieira  
>> wrote:
>> 
>> On Monday 28 September 2015 21:30:33 Massimo Callegari wrote:
 Can you explain what broke for you?
>>> 
>>> Since Qt 4.8 and up to Qt 5.4.2 I was using the install_name_tool procedure
>>> as described here: http://doc.qt.io/qt-5/osx-deployment.html
>>> With prebuilt Qt 5.5.x clang64, QtFrameworks don't use absolute paths
>>> anymore, but instead they use @rpath, so calling something like this
>>> 
>>> install_name_tool -change @rpath/QtCore.framework/Versions/5/QtCore
>>> @executable_path/../Frameworks/QtCore.framework/Versions/5/QtCore
>>> myapp.app/Contents/MacOs/myapp
>>> appears not to be working. (and not needed anymore)
>> 
>> Does the tool report an error now? Is that what broke?
> 
> With `install_name_tool -change A B C`, if the dependent shared library 
> install name A does not exist in the Mach-O file C, it's a no-op and the tool 
> returns 0.
> 
>> 
>>> If Qt is built with -rpath, then an application is in charge to tell Qt how
>>> to resolve @rpath, thus the need of adding QMAKE_LFLAGS +=
>>> -Wl,-rpath,@executable_path/../Frameworks
>> 
>> And if you don't do that do your executable, the loading fails?
> 
> Correct. But you're supposed to add that.
> 
>> What if we add an extra rpath to Qt libs as @executable_path/../Frameworks? 
>> Would this make loading work?
> 
> No. The rpath list is embedded in the loading binary A, and specifies where 
> the loading binary A looks for its dependents. If a dependent shared library 
> install name B contains the placeholder '@rpath', that placeholder is 
> substituted for each rpath in loading binary A's rpath list (recursively 
> replacing other placeholders like @executable_path and @loader_path if 
> present) until a match is found.
> 
> This would only help QtGui find QtCore, for example. The loading binary A 
> still has to find a Qt library in the first place.

It would help to let qmake automatically add rpath 
@executable_path/../Frameworks to application binaries.

On the other hand this would lead to people deploying their applications with 
the _absolute_ rpath to the Qt libs as on the build machine still present 
(because it works). I think we should avoid that.

Br, Eike

> Please refer to 
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
> 
>> Jake, Morten: as a stop-gap, is there a configure-time switch to revert to 
>> the 
>> old behaviour? This change seems to be too much for a patch release. It 
>> should 
>> be left for 5.6.0 only.
> 
> ./configure -no-rpath -- that switch has been there since the beginning of 
> time. I don't remember if that also sets CONFIG+=absolute_library_soname by 
> default.
> 
> It's also useless, because you virtually never want that (unless you are 
> MacPorts, Debian, etc.), and the changes required on the application side are 
> both less intrusive and easier to deal with anyways, in addition to being the 
> correct workflow on Apple platforms and not breaking code signing.
> 
>> -- 
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>  Software Architect - Intel Open Source Technology Center
>> 
> 
> -- 
> Jake Petroules - jake.petroules at petroules.com
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt 5.5.0 build issues on OS X : rpath

[Ziller Eike]

> On Sep 29, 2015, at 10:16, Jake Petroules  
> wrote:
> 
> 
>> On Sep 28, 2015, at 2:30 PM, Massimo Callegari  
>> wrote:
>> 
>> On Monday 28 September 2015 19:09:11 Massimo Callegari wrote:
 But please guys, when introducing such an important change, you are 
 warmthly
 invited to mention it in a visible place.
>> 
>>> It's in the changelog.
>> 
>>> But I confess the line you're referring to does not indicate that anything 
>>> should break. Qt being build with rpath should enable more, but not remove 
>>> functionality that existed.
>> 
>>> Can you explain what broke for you?
> 
> From what I can see, nothing is "broken" for him in the sense he is not 
> limited from doing anything he was previously able to do.
> 
>> Since Qt 4.8 and up to Qt 5.4.2 I was using the install_name_tool procedure 
>> as described here:
>> http://doc.qt.io/qt-5/osx-deployment.html
>> With prebuilt Qt 5.5.x clang64, QtFrameworks don't use absolute paths 
>> anymore, but instead they use @rpath, so calling something like this
>> 
>> install_name_tool -change @rpath/QtCore.framework/Versions/5/QtCore
>> @executable_path/../Frameworks/QtCore.framework/Versions/5/QtCore
>> myapp.app/Contents/MacOs/myapp
>> appears not to be working. (and not needed anymore)
> 
> Do not do that. You *want* the @rpath version; using anything but rpath-based 
> install names on Apple platforms is an obscure edge case. If you think you 
> need that, you almost certainly don't.
> 
> We need to start code-signing our official releases to stop people from doing 
> this. :)
> 
>> If Qt is built with -rpath, then an application is in charge to tell Qt how 
>> to resolve @rpath, thus the need of adding QMAKE_LFLAGS += 
>> -Wl,-rpath,@executable_path/../Frameworks
>> 
>> I might got it wrong, but at least this is what I got and how I made it work 
>> back again.
>> If there is a proper and official way to deploy any Qt5 version in a unique 
>> way, please point me to the right documentation.
> 
> That is the right way and always has been. Ideally you should use:
> 
>   QMAKE_RPATHDIR = @executable_path/../Frameworks
> 
> instead of specifying the linker flag manually, but the idea is the same.
> 
> These are basic aspects of OS X development which Qt doesn't add anything 
> special to, and so the deployment process for Qt 5 frameworks is identical to 
> the deployment process for "any other OS X framework".
> 
> Basically, make sure your app has @executable_path/../Frameworks in its rpath 
> list, and don't touch the Qt frameworks or the install names that get linked 
> into your binary. If you are ever using install_name_tool to post-process 
> your binary, you are probably doing something wrong, or your dependencies are 
> doing something wrong (for example, Qt < 5.5).
> 
> I agree we should update the "OS X Deployment" documentation (and possibly 
> link to Apple documentation on dyld and rpaths, and how they work).
> 
>> Obviously I am talking about deploying a Qt application and the Qt 
>> Frameworks into a DMG package, to be run on a machine that doesn't have Qt 
>> installed.
>> 
>> I am using OSX 10.10.5 and XCode 7, if this can add any value.
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> In closing, always use @rpath-based install names, and never use 
> install_name_tool.

Actually you should use install_name_tool to remove the absolute rpath to the 
Qt libs on the build machine from your application binaries.

> -- 
> Jake Petroules - jake.petroules at petroules.com
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt LTS C++11 plans

[Ziller Eike]

 On Aug 18, 2015, at 08:49, Thiago Macieira thiago.macie...@intel.com wrote:
 
 On Monday 17 August 2015 23:25:05 Jake Petroules wrote:
 I haven't a clue why people would bother using old OS X platforms for
 development, *especially* now that they don't charge for it. Plus I think
 submitting to app stores requires the latest Xcode anyways so there's
 another point against it.
 
 Right. In the past, the thinking was that people wouldn't upgrade because it 
 would require them to pay for it. That reason is now gone.
 
 They may still complain if the newer versions of OS X no longer run on some 
 older hardware. But isn't it true that all 64-bit capable Intel Mac can run 
 the latest OS X? Or is there any hardware that would have upgraded to 10.8 
 but 
 not further?

10.9 did not increase hardware requirements:

10.8: https://support.apple.com/en-us/HT202575
10.9: https://support.apple.com/en-us/HT201364

 
 -- 
 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

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] QtCS: Notes from Modern C++ session

[Ziller Eike]

 On Jun 16, 2015, at 16:52, Matthew Woehlke mw_tr...@users.sourceforge.net 
 wrote:
 
 On 2015-06-12 17:45, Thiago Macieira wrote:
 On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote:
 On Friday 12 June 2015 08:08:51 André Somers wrote:
 Not available for use are:
 * = default,
 * = deleted,
 
 Where are these not supported? I have code that (AFAIK) has been using
 these already, and IIRC our compiler requirements are lower.
 
 GCC requires 4.7 for this. I think we were discussing whether our minimum is 
 4.6 or 4.7.
 
 Again... really? I have code using '= default' that sometimes¹ is built
 on GCC *4.4*. '= delete' seems to be accepted also. (Now... it may be
 that '= default' is actually broken, i.e. generates bad code, but based
 on a very simple test I just whipped up, '= delete' at least seems to
 work. This is with gcc44-c++-4.4.7-1.el5.)
 
 (¹ Well... it's 'intended to work on GCC 4.4' and does occasionally get
 tested, but maybe not often or - as far as verifying that it actually
 runs correctly - well.)
 
 Did it get broken by 4.6 or something like that?

Actually this is not supported in VS2012
https://msdn.microsoft.com/en-us/library/hh567368.aspx

And Thiago’s link actually lists it under VS2013 as well :)

http://code.woboq.org/qt5/qtbase/src/corelib/global/qcompilerdetection.h.html#851

 Besides being inline (template, dontcha know), isn't there an option to
 disable those? (Maybe not std::exception one, but at least the Qt -
 STL container conversions?)
 
 QT_NO_STL isn't supported since 5.0.
 
 Ah... don't use it, hadn't paid attention or noticed :-).
 
 -- 
 Matthew
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Compiling for iOS, qtdeclarative and others fail

[Ziller Eike]

 On May 23, 2015, at 05:03, Ariel Molina ar...@edis.mx wrote:
 
 Hi, 
 
 I solved the problem, just want to share,
 
 On Wed, May 20, 2015 at 12:16 PM, Edward Sutton edward.sut...@subsite.com 
 wrote:
 I understand the config commands used to build Qt packages are here:
 
 http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config
 
 
 I just followed your suggestion but using opensource [1], please Have a look 
 at my configure output [2].
 
 It installed on /usr/local
   • make -j8, took two hours, went OK
   • cd qtbase,  sudo make install, OK
   • cd qtimageformats, sudo make install, OK
   • cd qtquick1, sudo make install, OK
   • cd qtquickcontrols, sudo make install OK
   • cd qtdeclarative, FAILS: http://i.imgur.com/QOAaEgJ.png
 The error is:
 === BUILD TARGET xmlpatterns OF PROJECT xmlpatterns WITH CONFIGURATION Debug 
 ===
 Check dependencies
 Code Sign error: No provisioning profiles found: No non–expired provisioning 
 profiles were found.
 CodeSign error: code signing is required for product type 'Application' in 
 SDK 'iOS 8.3’

xmlpatterns module probably builds the “xmlpatterns” and “xmlpatternsvalidator” 
for the target environment (in your case iOS), and therefore tries to sign 
these applications.
Similar for “qml.app”.

 Just out of curiosity I went into these (in exact order)
   • qtxmlpatterns, FAILS with same error
   • qtmultimedia, qtgraphicaleffects, qtsensors, qtsvg, qtcanvas3d, 
 qtlocation, qtwebchannel, qtwebsockets, qt3d, OK
 However I found a fix, I went into qt/xmlpatterns/tools/xmlpatterns


 and did a normal non-sudo make, and it found my developer credentials.

If you use sudo, the process is running as root, and root doesn’t have your 
“normal” user’s developer credentials installed of course.
Did you build Qt with a simple “make” (as normal user, without “install”) 
before you tried to install?

 There, make install worked. But not on the parent, qtxmlpatterns.
 
 So the fix i implemented is I went into /usr/local and changed ownership of 
 Qt-5* to my user, then did all installs without sudo, then it finds my Apple 
 Developer credentials, it installs cleanly. Problem solved :)
 
 Thank you for your time!
 
 Ariel
 
 [1] 
 http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config/configure_ios_opensource
 [2] http://pastebin.com/83vtcLzH
 [3] Fails snapshot: http://i.imgur.com/QOAaEgJ.png
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] 5.4.1 OSX macdeployqt FAIL

[Ziller Eike]

 On May 10, 2015, at 9:08 PM, mark diener rpzrpz...@gmail.com wrote:
 
 Well, it looks like the big weakness in OSX deployment is macdeployqt and we 
 are on version 5.4.1+ 
 
 I was able to change my macdeployqt command line FROM:
 
 macdeployqt ./testdep.app/ -qmldir=/macdev/qdev/testdep/ -verbose=2 enter
 
 TO:
 
 macdeployqt testdep.app/ -qmldir=/macdev/qdev/testdep/ -verbose=2 enter
 
 And it WORKED!
 
 The only difference between the two is the period and forward slash in front 
 of the testdep.app reference.
 
 I think it should be registered with the maintainer of macdeployqt that the 
 tool is subject to falling down on its knees
 with just the slightest syntax variation. YIKES!

- https://bugreports.qt.io

Thanks  Br, Eike

 Who is the maintainer of macdeployqt?
 
 
 On Sun, May 10, 2015 at 9:57 AM, mark diener rpzrpz...@gmail.com wrote:
 Hello:
 
 Has someone gotten macdeployqt to actually work and create a self running 
 bundle
 that successfully runs on OSX ?
 
 If yes, please share your command line for macdeployqt.
 
 
 My macdeployqt command line:
 
 macdeployqt ./testdep.app/ -qmldir=/macdev/qdev/testdep/
 
 my otool dump of the bundle after macdeployqt:
 
 mds-MacBook-Pro:buildosx md$ otool -L ./testdep.app/Contents/MacOS/testdep 
 ./testdep.app/Contents/MacOS/testdep:
 @executable_path/../Frameworks/QtQuick.framework/Versions/5/QtQuick 
 (compatibility version 5.4.0, current version 5.4.1)
 @executable_path/../Frameworks/QtGui.framework/Versions/5/QtGui 
 (compatibility version 5.4.0, current version 5.4.1)
 @executable_path/../Frameworks/QtCore.framework/Versions/5/QtCore 
 (compatibility version 5.4.0, current version 5.4.1)
 
 /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
  (compatibility version 1.0.0, current version 1.0.0)
 /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
 (compatibility version 1.0.0, current version 275.0.0)
 @executable_path/../Frameworks/QtQml.framework/Versions/5/QtQml 
 (compatibility version 5.4.0, current version 5.4.1)
 @executable_path/../Frameworks/QtNetwork.framework/Versions/5/QtNetwork 
 (compatibility version 5.4.0, current version 5.4.1)
 @executable_path/../Frameworks/QtWidgets.framework/Versions/5/QtWidgets 
 (compatibility version 5.4.0, current version 5.4.1)
 /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
 (compatibility version 1.0.0, current version 1.0.0)
 /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility 
 version 1.0.0, current version 1.0.0)
 /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 
 104.1.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
 1213.0.0)
 
 Added directories to my bundle:
 
 Contents
 Frameworks   (QtCore, QtGui, QtNetwork, QtPrintSupport, QtQml, 
 QtQuick, QtWidgets)
 PlugIns  (bearer, imageformats, platforms, printsupport, quick)
 Resources - qml - Qt/ Qtquick/ QtQuick.2/
 
 When executing the program after macdeployqt
 
 applicationDirPath(): /macdev/qdev/buildosx/testdep.app/Contents/MacOS 
 QLibraryInfo::PrefixPath: /macdev/qdev/buildosx/testdep.app/Contents 
 QLibraryInfo::LibrariesPath: /macdev/qdev/buildosx/testdep.app/Contents/lib 
 QLibraryInfo::PluginsPath: 
 /macdev/qdev/buildosx/testdep.app/Contents/PlugIns 
 QLibraryInfo::Qml2ImportsPath: 
 /macdev/qdev/buildosx/testdep.app/Contents/Resources/qml 
 QQmlApplicationEngine failed to load component
 qrc:/main.qml:1 module QtQuick plugin qtquick2plugin not found
 
 Anybody gotten through this OSX Ugliness?
 
 Mark
 
 ###
 
 Here is the simple source code:
 
 #include QApplication
 #include QQmlApplicationEngine
 
 #include QLibraryInfo
 #include QString
 #include QDebug
 
 int main(int argc, char *argv[])
 {
 QString gval ;
 QApplication app(argc, argv);
 
 QQmlApplicationEngine engine;
 
 gval = QApplication::applicationDirPath() ;
 qDebug()  applicationDirPath():  gval  endl ;
 
 gval = QLibraryInfo::location(QLibraryInfo::PrefixPath) ;
 qDebug()  QLibraryInfo::PrefixPath:  gval  endl ;
 
 gval = QLibraryInfo::location(QLibraryInfo::LibrariesPath) ;
 qDebug()  QLibraryInfo::LibrariesPath:  gval  endl ;
 
 gval = QLibraryInfo::location(QLibraryInfo::PluginsPath) ;
 qDebug()  QLibraryInfo::PluginsPath:  gval  endl ;
 
 gval = QLibraryInfo::location(QLibraryInfo::Qml2ImportsPath) ;
 qDebug()  QLibraryInfo::Qml2ImportsPath:  gval  endl ;
 
engine.load(QUrl(QStringLiteral(qrc:/main.qml)));
 
return app.exec();
 }
 
 Here is the simple QML:
 
 import QtQuick 
 2.4
 
 import QtQuick.Controls 
 1.3
 
 import QtQuick.Window 
 2.2
 
 import QtQuick.Dialogs 
 1.2
 
 import QtQuick.Layouts 
 1.1
 
 
 
 ApplicationWindow 
 {
 
 title: qsTr(Hello World
 )
 
 width: 
 640
 
 height: 
 480
 
 visible: 
 true
 
 
 
 menuBar: MenuBar 
 {
 
 

Re: [Development] Qt Creator uses _qt_autotest_force_engine_poller?

[Ziller Eike]

 On Apr 21, 2015, at 11:46 AM, René J.V. Bertin rjvber...@gmail.com wrote:
 
 Hi,
 
 I know I should ask this on the QC ML (but I'd prefer not to sign up for just 
 an occasional question like this):
 
 Is there a (good) reason why DocumentManagerPrivate::linkWatcher() forces the 
 use of a polling watcher?

The reason is https://bugreports.qt.io/browse/QTBUG-15522

Br, Eike

 
 Mainly asking because I just noticed that this approach can lead to 
 significant CPU use when the IDE is otherwise idle, which is ... unfortunate. 
 
 R.
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Removing the -c++11 option from configure

[Ziller Eike]

 On Mar 21, 2015, at 7:40 PM, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 
 We'd like to make Qt build unconditionally with the latest version of the C++ 
 standard that is supported by the compiler. That implies removing the -c++11 
 option so that the -no-c++11 option goes away too.
 
 Possible drawbacks:
 - Inability to test non-C++11 codepaths in the CI
   = We can add a hidden option for the CI
 


 - OS X support without libc++ may go away
   = I need more information on this

I think the only problem would be, if you compiled on 10.7+ and expected it to 
run on 10.6, which we no longer support since 5.4 anyhow, if I remember 
correctly.

 Advantage:
 - Will turn on C++14 for recent GCC and Clang
 
 Anything I missed? Opinions?
 
 -- 
 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

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Ziller Eike]

 On Feb 20, 2015, at 10:04 AM, André Somers an...@familiesomers.nl wrote:
 
 Bo Thorsen schreef op 20-2-2015 om 09:03:
 Andrés question about how this would change the API is a lot more 
 interesting. I so far haven't seen a single case where someone has 
 described how access to lambdas might improve the API.

Well, the new connect style is also already improved API.

 If they are 
 there, I'd love to see them, because maybe this would teach me 
 something I haven't figured out yet.
 
 One example I could come up with as a potential new API is 
 QSortFilterProxyModel. Currently, it requires subclassing to change the 
 sort or the filter functions: it supplies protected filterAcceptsRow, 
 filterAcceptsColumn and lessThan functions. I think that it would be 
 much more convenient if these filters and the comparator could be 
 supplied as a function object (a lambda, or a functor, or a std::mem_fn, 
 anything callable as a function). While this wasn't all that practical 
 in the past, I think C++/11 makes this much more convenient than 
 subclassing.

We start using these kind of patterns more and more in Qt Creator.

Another example in Qt might be

virtual QWebView * 
QWebView::createWindow(QWebPage::WebWindowType type) [protected]

which could instead be a setWindowFactory function (same in QWebEngine).

 This could of course just be added, instead of replacing. But that would 
 mean API bloat. Downside of replacing is of course: you break old code.
 
 I think that if we go over the Qt classes, we'll find more examples of 
 where a subclass or a separate function that you need to write could be 
 replaced with a more modern API.
 
 André
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Ziller Eike]

 On Feb 10, 2015, at 10:51 AM, Marc Mutz marc.m...@kdab.com wrote:
 
 On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote:
 On Feb 9, 2015, at 3:40 PM, Marc Mutz marc.m...@kdab.com wrote:
 
 On Monday 09 February 2015 09:54:12 Smith Martin wrote:
 This is the kind of thing we should add to the documentation, but can
 you elaborate? I mean, illustrate the meaning of locality of
 reference, wildly mixing insertions, lookups, and removals, and
 batch updates and separate them from lookups, time-wise.
 
 There is a book, Effective STL, and an online paper, What every
 programmer needs to know about memory. I don't think that it's the job
 of the Qt docs to explain what every programmer needs to know about
 memory, because it is not specific to Qt.
 
 The Qt documentation also doesn't give many details on Unicode. It's
 assumed that people using it know the basics.
 
 You will also not find in the Qt docs that signed integer overflow is
 undefined behaviour.
 
 The Qt docs are not a CS text book :)
 
 That QMap is implemented based on a RB tree is mentioned in a single
 sentence in the beginning of the description of the class, which is the
 sentence that nobody ever reads (because it tends to contain useful
 information like The QList class is a template class that provides
 lists.”).
 
 It is followed by a short (but longer) comparison between QMap and QHash,
 which in turn is linked to a relatively long section that compares the
 complexity of Qt’s different containers. So, fact is that the Qt docs *do*
 explain more than “QMap is a RB tree” (and I think that is good so). And
 since they talk a lot about algorithmic complexity, it would probably be
 useful to mention a few other things that concern performance differences
 as well. In ~5 sentences. I really can’t see how that could hurt.
 
 Actually you sounded like you’d like to educate people about this also
 “outside of CS courses” (by sending them to their manager etc), so do you
 have a different, realistic proposal?
 
 The topic of this thread is guidelines for Qt code, not code using Qt.

Qt code is code using Qt. Qt developers are Qt users.
Qt developers (read: contributors) also read Qt documentation to find out which 
data structures to use for solving which problem.

 We 
 don't want to impose writing Q_DECL_CONSTEXPR everywhere possible for users 
 of 
 Qt. Likewise, if they want to use QMap, then that's fine. A profiler will 
 tell 
 them if they made a mistake that matters.
 
 The situation is different for Qt code:

Actually not much, since there are many other libraries than Qt out there that 
use Qt and therefore must also “optimize for everything”.

 Consider a recent example: QString::multiArg(). It used a QMap. Now it uses a 
 QVarLengthArray (introduced in 7b5ba56b0ab55fcaf79fbf9aad70bf767c938e15). A 
 very naïve benchmark (I'm allowed to say that, it was my choice). was sped up 
 by 30%. The naïviteé in the benchmark is that this includes repeated 
 allocation of a handful of QString arguments from short (C) string literals 
 each time through the loop, which probably dominates the result.
 
 We don't know what Qt is being used for, so we need to optimize everything. 
 One user surely will run multiArg() in a tight loop and that will dominate 
 his 
 runtime. As every C++ library that's any good, we cannot be sloppy when it 
 comes to efficiency.
 
 So, no, I don't think we should discuss everthing ever written about C++ 
 efficiency in the Qt docs.

Nobody has claimed that we should.

 But we need to point it out to each other in code 
 reviews and become better at not writing sloppy code.

Nobody has claimed that we shouldn’t.
Discussing in the documentation which classes are best used in which use cases, 
might reduce the need to educate people over and over again in code reviews 
though. And reviews could be abbreviated to “don’t use QMap in this case, read 
link to Qt documentation”, instead of discussing the same thing over and over 
again.

 IOW: We need to start thinking about our algorithms and data structures 
 again[1], but this time in the new world of caches and multithreading where 
 the only fast data structure is an array.[2]
 
 Thanks,
 Marc
 
 [1] http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic-
 Computation/dp/0130224189
 
 [2] http://vimeo.com/97337258
 
 -- 
 Marc Mutz marc.m...@kdab.com | Senior Software Engineer
 KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
 www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
 KDAB - Qt Experts - Platform-Independent Software Solutions

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Ziller Eike]

 On Feb 9, 2015, at 3:40 PM, Marc Mutz marc.m...@kdab.com wrote:
 
 On Monday 09 February 2015 09:54:12 Smith Martin wrote:
 This is the kind of thing we should add to the documentation, but can you
 elaborate? I mean, illustrate the meaning of locality of reference,
 wildly mixing insertions, lookups, and removals, and batch updates and
 separate them from lookups, time-wise.
 
 There is a book, Effective STL, and an online paper, What every programmer 
 needs to know about memory. I don't think that it's the job of the Qt docs 
 to 
 explain what every programmer needs to know about memory, because it is not 
 specific to Qt.
 
 The Qt documentation also doesn't give many details on Unicode. It's assumed 
 that people using it know the basics.
 
 You will also not find in the Qt docs that signed integer overflow is 
 undefined 
 behaviour.
 
 The Qt docs are not a CS text book :)

That QMap is implemented based on a RB tree is mentioned in a single sentence 
in the beginning of the description of the class, which is the sentence that 
nobody ever reads (because it tends to contain useful information like The 
QList class is a template class that provides lists.”).

It is followed by a short (but longer) comparison between QMap and QHash, which 
in turn is linked to a relatively long section that compares the complexity of 
Qt’s different containers.
So, fact is that the Qt docs *do* explain more than “QMap is a RB tree” (and I 
think that is good so). And since they talk a lot about algorithmic complexity, 
it would probably be useful to mention a few other things that concern 
performance differences as well. In ~5 sentences. I really can’t see how that 
could hurt.

Actually you sounded like you’d like to educate people about this also “outside 
of CS courses” (by sending them to their manager etc), so do you have a 
different, realistic proposal?

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Deprecating modules with 5.5

[Ziller Eike]

 On Feb 6, 2015, at 09:21, Simon Hausmann simon.hausm...@theqtcompany.com 
 wrote:
 
 On Friday 6. February 2015 08.42.53 André Somers wrote:
 Knoll Lars schreef op 5-2-2015 om 16:28:
 But we don’t have much of a choice, if we want to deliver an up to date
 web engine.
 
 Perhaps it is time to ask the question then: do we want to do that? Do
 we really need to?
 
 It seems to me, that it isn't really possible to do. Not in a way that
 doesn't require huge effort in support or pissing off everybody not on
 one of the large main stream platforms. And the question might be: why
 should Qt deliver an up-to-date web engine exactly? Do we really think
 that people are going to use Qt to build advanced browsers? Sure, some
 might (KDE comes to mind...), but you are right in your observation that
 the technology is moving too fast and is developed between giants like
 Google, Apple and Microsoft who could not care less about other uses or
 other platforms than their own.
 
 All the while Qt is spending effort to catch up, deprecating compilers
 and platforms because they can't take the latest Javascript engine to
 it, users are hapily using browers like Firefox and Chrome.
 
 Perhaps it is time to conclude that Qt just can't compete in this race
 if it doesn't want to be crushed between the giants playing this field.
 Perhaps it is just time to settle for indeed a simpler goal: don't try
 to provide a fully integrated full-fledged web engine, but instead
 settle once again for a simpler alternative that we _can_ support and
 that can be used for things like showing embedded help or showing simple
 sites, and perhaps an API to wrap and embed the native web view provided
 by the platform but with limited integration.
 
 What simpler alternative do you have in mind?

One possibility that would cover the use case of “show some simple styled html 
without javascript” case (e.g. documentation browsers) would be to give 
QTextBrowser some love again, fix some bugs there, and extend some of the css 
and html features in it. That definitely would be “offline first”, except that 
anyone who cares could of course fetch content from the web for it (the text 
browser based help viewer backend in Qt Creator also fetches content from the 
help database, so that already works fine ;) )

 This catch up race is _exactly_ the reason why we decided to build on top 
 of 
 Chromium and don't look at it as just a HTML/CSS renderer anymore but as an 
 entire platform. Unfortunately that means the platform is wide and comes with 
 a lot of code, fortunately it almost entirely eliminates the catch up race.
 
 And yes, there is a surprising interest among the users of Qt to use an up-to-
 date implementation of the web platform in their Qt application. Not 
 necessarily to build a web browser that competes with Chrome, Safari and the 
 lot.
 
 
 Simon
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Deprecating modules with 5.5

[Ziller Eike]

 On Feb 3, 2015, at 8:33 AM, Knoll Lars lars.kn...@theqtcompany.com wrote:
 
 Hi,
 
 I’d like to mark a few modules as deprecated with 5.5, and most likely
 remove them from the binary packages with 5.6. These modules are:
 
 * Qt WebKit

As long as WebEngine is not (yet?) a “full replacement of Qt WebKit 
functionality, most notably
https://bugreports.qt.io/browse/QTBUG-44221
we should still include Qt WebKit in our binary packages.
Assistant and Qt Creator will otherwise only have a QTextBrowser backend for 
displaying help,
leading to broken looking documentation, since that does not even roughly 
support the CSS that
we use in Qt documentation.

Br, Eike

 * Qt Declarative (Qt Quick 1)
 * Qt Script
 
 All of these modules are by now a couple of years old, don’t receive
 updates above the bare minimum and have a replacement that is actively
 being developed in Qt 5.
 
 Cheers,
 Lars
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Ziller Eike]

 On Jan 18, 2015, at 10:24 PM, Kevin Kofler kevin.kof...@chello.at wrote:
 
 Konstantin Ritt wrote:
 There is no need for moc/rcc/uic to be suffixed. In fact, they are an
 internal build tools invoked by qmake and thus they should normally reside
 in libexec dir (or you may query qmake for its specific libexec dir path
 to invoke them manually) -- just like GCC's cc1 or fixincl.
 
 That is just not true. Many Qt programs out there are NOT built using qmake, 
 but more flexible build systems. Those build systems need to call those 
 tools themselves. Even Qt itself is experimenting with qmake replacements 
 (see e.g. QBS). cc1 is almost never invoked directly (only through gcc), but 
 this is not true for moc, rcc, uic etc. So hiding them in a non-PATH 
 directory is not an ideal solution (even if that directory can be found by 
 invoking qmake).

I don’t know how you could use QBS to support your case of renaming the Qt 
tools. To use a specific Qt version with QBS, you configure a profile in QBS 
with the corresponding paths to the binaries/libraries/etc. I do not see how 
QBS would benefit from renamed tool names, actually it would get more 
complicated.

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Ziller Eike]

 On Jan 18, 2015, at 6:34 AM, Kevin Kofler kevin.kof...@chello.at wrote:
 
 Thiago Macieira wrote:
 Now we have a legacy to keep, so we can't accept a radical change. Only
 incremental improvements.
 
 You will find that very few deployments out there in the real world use 
 qtchooser. The widely-used RHEL most definitely does not, it inherits the 
 exact same Qt setup Fedora uses. (In fact, the maintainers from Red Hat were 
 also against using qtchooser in Fedora.) Operating systems other than 
 GNU/Linux also do not use qtchooser. So doing away with it would only make 
 the world more uniform.

Though doing away with qtchooser would make the world more uniform

 You, the Qt Project, need to accept that qtchooser has just not caught on, 
 it was an attempt that turned out a failure, and needs to be replaced by a 
 better and much simpler solution (just renaming the binaries).

 I do not see how a more uniform world would support your case of renaming 
the binaries.
No other OS would benefit from it. To the contrary, it would make it more 
complicated there.
Which is most probably also the reason why there is no interest in having 
qtchooser on other OSes.
There is just no problem that it solves there.

Br, Eike

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

-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Compiler warnings

[Ziller Eike]

On Oct 17, 2014, at 7:26 PM, Mathias Hasselmann math...@taschenorakel.de 
wrote:

 
 
 Am 17.10.2014 um 18:31 schrieb Thiago Macieira:
 On Friday 17 October 2014 13:06:39 Milian Wolff wrote:
 enum Foo {
 Bar = 1, Baz = 2
 };
 
 Foo foo = static_castFoo(3);
 
 Now what do you do without a default clause?
 
 Shoot the developer who abused the API.
 
 If the function accepts enum values 1 and 2 and you pass a 3, you deserve the
 undefined behaviour.
 
 That is the same as passing a bool that doesn't contain exactly values 0 or 1
 or passing an uninitialised pointer.
 
 We have to handle all regular conditions. We don't have to guard against
 stupidity.
 
 
 I don't think this example has to do with stupidity. To me this just 
 seems like a minimal example of typical integration problems that happen 
 in real world.

If you need to convert between integers and enum values (or one enum and 
another), and you care about safety of your application (i.e. always), do 
explicit conversion with an if on the integer (switch on that other enum), and 
do the error handling at the place where the conversion happens.

 Far fetching I'd talk about distributed services, reading 
 files written by a different program version, and such. Also Qt already 
 deals with such issues where it is obvious:
 
 const char * QVariant::typeToName(int typeId) [static]
 Converts the int representation of the storage type, typeId, to its
 string representation.
 
 Returns a null pointer if the type is QVariant::Invalid(obsolete)
 or doesn't exist.
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] QSettings refactor updates

[Ziller Eike]

On Oct 10, 2014, at 8:16 PM, Adam Light acli...@gmail.com wrote:

 
 
 On Fri, Oct 10, 2014 at 7:25 AM, Ziller Eike eike.zil...@theqtcompany.com 
 wrote:
 
 On Oct 10, 2014, at 3:37 PM, Adam Light acli...@gmail.com wrote:
 
  On the flip side, our large Qt application runs on Mac and Windows and 
  we're intentionally using QSettings with INI format on both platforms for 
  consistency. Since the storage of settings is really an implementation 
  detail (users should hopefully never need to edit the settings files 
  themselves), it's easier for us if the settings are stored the same way on 
  all platforms.
 
 Qt Creator intentionally used ini format for “consistency” as well, but:
 * Since the paths are different through the platforms (Windows XP vs Windows 
 vs Linux vs OS X), and have to be, there is not much consistency in the end 
 after all, and
 * Uninstallation process involves manually removing settings and application 
 data, at least on OS X, and there are even uninstallation tools out there 
 which do it for you, if the application follows the platform convention
 
 So there are IMO very good reasons why someone would want their application 
 to follow platform conventions for application settings. Possibly with a way 
 to opt-in or opt-out.
 
 
 Sure, I understand why a developer might want an application to be able to 
 follow platform conventions. I'm just making the case that I think there are 
 valid reasons to *not* follow platform conventions as well. Currently 
 QSettings makes it relatively easy for the developer to decide. But if this 
 new class is eventually going to replace QSettings, I feel that the option 
 should remain for the developer to force the settings to be saved in a 
 consistent way across platforms, not always using the platform convention. 
 Otherwise it's a loss of functionality.

Then we agree ;)

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] QSettings refactor updates

[Ziller Eike]

On Oct 13, 2014, at 10:30 AM, Morten Johan Sørvig morten.sor...@digia.com 
wrote:

 
 On 10 Oct 2014, at 13:27, Ziller Eike eike.zil...@theqtcompany.com wrote:
 
 
 On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig morten.sor...@digia.com 
 wrote:
 
 
 Mac people: do we need access to plist files?
 
 Plist is the format for application and other settings on OS X, and there 
 are native tools for nicely editing these. Ini is highly alien on OS X.
 So, I’d answer yes.
 
 On the other hand, git uses the ini file format for the config files also 
 on OS X.
 
 git is a command line tool, and used by a very specific audience.
 
 I see this as two separate use cases: 
 1) Cross-platform API for managing application settings.
 
 We regularly have people which complain that Qt Creator application settings 
 do not follow platform convention on OS X, because they do not find a qt 
 creator plist in ~/Library/Preferences, or actually there is one that 
 contains some settings coming from Qt (NSNavLastRootDirectory, 
 PMPrintingExpandedState, some WebKit stuff, and a few more), but not the 
 actual application settings.
 
 2) API for reading native settings, following the conventions of the 
 platform
 
 What kind of native settings are you thinking about here (on OS X)?
 
 If I may re-state my point it is that OS X settings is more than the Plist 
 file format: NSUserDefaults has special behaviors for sandboxing, iCloud 
 sync, the iOS Settings app, etc. Perhaps the best way to use NSUserDefaults 
 from a Qt app is QUrl::toNSURL() and QString::toNSString() (i.e. enable it 
 don’t wrap it).
 
 In that light supporting ini+json only is a project with a well-defined small 
 scope. Creating a class that wraps the native  settings is a much larger 
 project.

Ok, right, if it is feasible to wrap such native settings” in a cross-platform 
API at all.

So, from my perspective (1) should be able to generate something that users 
expect from an application they install (on OS X that’s a plist in 
~/Library/Preferences),
and (2) is nothing we should aim for (at least not at the moment, and since 
this seems even conceptionally different on different platforms, I’m not sure 
that at all).

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] osx search paths with 5.3.2

[Ziller Eike]

On Oct 13, 2014, at 4:55 PM, Matt Broadstone mbroa...@gmail.com wrote:

 Hi all,
 
 I've been using qt 4.8.6 for quite some time on my macbook installed
 from homebrew with no problem whatsoever. I decided over the weekend
 to upgrade my install to the latest qt5 build which on homebrew is
 5.3.2. Everything installed, qmake ran and I was able to successfully
 build qjsonrpc on my mac. Cool.
 
 Now, I've got another test app that links to qjsonrpc, and when I
 build that it turns out that I'm no longer able to find anything in
 /usr/include or link to anything in /usr/lib. I naturally assumed this
 was an issue with the compiler's search paths, but then why did 4.8.6
 work? Hmm, okay, let's just use Qt's distributed 5.3.2 binaries, maybe
 homebrew got it wrong... Same problem. I went through a diff of the
 mkspecs dirs of both versions and couldn't see anything that would
 obviously cause this.
 
 Has anyone using Qt on mac run into this problem? Running out of ideas here!

Hard so say anything without knowing what the things are that are not found.
General hints are: Have a look at the actual compiler command lines and look 
for the -I and -F s, and run qmake with “qmake -d -d -d” to get detailed 
information on which files are pulled in and how specific qmake variables get 
their values.

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] osx search paths with 5.3.2

[Ziller Eike]

On Oct 13, 2014, at 5:23 PM, Matt Broadstone mbroa...@gmail.com wrote:

 On Mon, Oct 13, 2014 at 11:07 AM, Ziller Eike
 eike.zil...@theqtcompany.com wrote:
 
 On Oct 13, 2014, at 4:55 PM, Matt Broadstone mbroa...@gmail.com wrote:
 
 Hi all,
 
 I've been using qt 4.8.6 for quite some time on my macbook installed
 from homebrew with no problem whatsoever. I decided over the weekend
 to upgrade my install to the latest qt5 build which on homebrew is
 5.3.2. Everything installed, qmake ran and I was able to successfully
 build qjsonrpc on my mac. Cool.
 
 Now, I've got another test app that links to qjsonrpc, and when I
 build that it turns out that I'm no longer able to find anything in
 /usr/include or link to anything in /usr/lib. I naturally assumed this
 was an issue with the compiler's search paths, but then why did 4.8.6
 work? Hmm, okay, let's just use Qt's distributed 5.3.2 binaries, maybe
 homebrew got it wrong... Same problem. I went through a diff of the
 mkspecs dirs of both versions and couldn't see anything that would
 obviously cause this.
 
 Has anyone using Qt on mac run into this problem? Running out of ideas here!
 
 Hard so say anything without knowing what the things are that are not found.
 General hints are: Have a look at the actual compiler command lines and look 
 for the -I and -F s, and run qmake with “qmake -d -d -d” to get detailed 
 information on which files are pulled in and how specific qmake variables 
 get their values.
 
 Br, Eike
 
 
 Hi Eike,
 Thanks for the quick response. The things that are not found are for
 isntance, /usr/include/qjsonrpc/qjsonrpcmessage.h. I can fix this
 manually by adding /usr/include to my INCLUDEPATH - no problem, but
 definitely wasn't a requirement on the exact same machine with the qt
 4.8.6 install (maybe a more basic question: is this just something
 that changed in 5.x mkspecs?).

Could be that it changed in Qt 5 mkspecs, since /usr/include actually is not 
required as an include path by the Qt libraries.
Also, the Qt4 binary packages are installed systemwide, I’m not sure if that 
was just /usr/local/include, or also /usr/include.
So, all in all, it looks to me like the Qt 5 behavior is the expected one, and 
adding INCLUDEPATH=/usr/include(/qjsonrpc) is the way to go.

Br, Eike

 My compile lines with 4.8.6 installed
 add -I/usr/include to the compile lines, while the 5.3.2 install does
 not. Additionally, adding -L/usr/lib to my LIBS line in the pro file
 with 5.3.2 still breaks and can't find files that are definitely
 there. I'll pour through this qmake -d -d -d now and see if I can
 provide any more information.
 
 Matt
 
 --
 Eike Ziller, Senior Software Engineer - Digia, Qt
 Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
 Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
 Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, 
 HRB 144331 B

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] QSettings refactor updates

[Ziller Eike]

On Oct 10, 2014, at 12:48 AM, Thiago Macieira thiago.macie...@intel.com wrote:

 On Thursday 09 October 2014 19:43:08 Tomaz Canabrava wrote:
 Please be kind, this is the first step to contributing to qt that I'm
 trying. :)
 
 First, I'v implemented the rationale that thiago asked me to do on the
 other thread:
 
 Settings format: .ini ( current settings uses native format, should I
 implement that too or the reasoning here is 'be simple'? )
 
 I think we should stick to .ini only. Access to the Windows registry should 
 be 
 done via QSettings or via a dedicated class.

I think it would not be good to create a new API for settings, and 
simultaneously force us to keep the old API because the new API doesn’t cover 
the old use cases.
So, if Windows registry access should not be done through the new settings API 
(which I can’t tell), we should have a dedicated API for it at the same time 
the new settings API is introduced.

 Mac people: do we need access to plist files?

Plist is the format for application and other settings on OS X, and there are 
native tools for nicely editing these. Ini is highly alien on OS X.
So, I’d answer yes.

Br, Eike

 Usage on code:
 
 Open a QConfig, get the root() group, fill some values,
 if a value is changed a 'dirty' flag will be set on that particular group.
 upon destruction it will generate a binary json representation to be kept
 in memory
 when .sync() it will forcefully sync on disk
 when the QConfigCore object is destroyed, it will also flush on disk.
 
 Working code example of usage:
 
 int main(int argc, char *argv[])
 {
QConfig config;
 
QConfigGroup root = config.root();
 
 Make sure a reference is not needed.
 
 
QConfigGroup window = root.group(window);
window.setValue(width, 800);
window.setValue(height, 600);
window.setValue(x, 100);
window.setValue(y,100);
window.setValue(opacity, 55);
 
QConfigGroup font = root.group(fonts);
font.setValue(family, san-serif);
font.setValue(pointSize, 9);
font.setValue(bold, true);
font.setValue(italic, true);
 
QConfigGroup plasmoids = root.group(plasmoids);
for(int i = 0; i  5; i++){
QConfigGroup plasmoid = plasmoids.group(QString::number(i));
plasmoid.setValue(name, name_ + QString::number(i));
plasmoid.setValue(width, rand() % 100 + 100);
plasmoid.setValue(value, rand() % 100 + 100);
}
 }
 
 Any tougths?
 
 Looks good!
 
 -- 
 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

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] QSettings refactor updates

[Ziller Eike]

On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig morten.sor...@digia.com 
wrote:

 
 Mac people: do we need access to plist files?
 
 Plist is the format for application and other settings on OS X, and there 
 are native tools for nicely editing these. Ini is highly alien on OS X.
 So, I’d answer yes.
 
 On the other hand, git uses the ini file format for the config files also on 
 OS X.

git is a command line tool, and used by a very specific audience.

 I see this as two separate use cases: 
 1) Cross-platform API for managing application settings.

We regularly have people which complain that Qt Creator application settings do 
not follow platform convention on OS X, because they do not find a qt creator 
plist in ~/Library/Preferences, or actually there is one that contains some 
settings coming from Qt (NSNavLastRootDirectory, PMPrintingExpandedState, 
some WebKit stuff, and a few more), but not the actual application settings.

 2) API for reading native settings, following the conventions of the platform

What kind of native settings are you thinking about here (on OS X)?

 To what degree was QSettings successful in combining these? Focusing on 
 ini+json as supported formats will certainly simplify the implementation work.
 
 Morten
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] QSettings refactor updates

[Ziller Eike]

On Oct 10, 2014, at 3:37 PM, Adam Light acli...@gmail.com wrote:

 On Fri, Oct 10, 2014 at 4:27 AM, Ziller Eike eike.zil...@theqtcompany.com 
 wrote:
 
 On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig morten.sor...@digia.com 
 wrote:
 
 
  Mac people: do we need access to plist files?
 
  Plist is the format for application and other settings on OS X, and there 
  are native tools for nicely editing these. Ini is highly alien on OS X.
  So, I’d answer yes.
 
  On the other hand, git uses the ini file format for the config files also 
  on OS X.
 
 git is a command line tool, and used by a very specific audience.
 
  I see this as two separate use cases:
  1) Cross-platform API for managing application settings.
 
 We regularly have people which complain that Qt Creator application settings 
 do not follow platform convention on OS X, because they do not find a qt 
 creator plist in ~/Library/Preferences, or actually there is one that 
 contains some settings coming from Qt (NSNavLastRootDirectory, 
 PMPrintingExpandedState, some WebKit stuff, and a few more), but not the 
 actual application settings.
 
 
 On the flip side, our large Qt application runs on Mac and Windows and we're 
 intentionally using QSettings with INI format on both platforms for 
 consistency. Since the storage of settings is really an implementation detail 
 (users should hopefully never need to edit the settings files themselves), 
 it's easier for us if the settings are stored the same way on all platforms.

Qt Creator intentionally used ini format for “consistency” as well, but:
* Since the paths are different through the platforms (Windows XP vs Windows vs 
Linux vs OS X), and have to be, there is not much consistency in the end after 
all, and
* Uninstallation process involves manually removing settings and application 
data, at least on OS X, and there are even uninstallation tools out there which 
do it for you, if the application follows the platform convention

So there are IMO very good reasons why someone would want their application to 
follow platform conventions for application settings. Possibly with a way to 
opt-in or opt-out.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt for iOS: Management Retina vs Non-Retina Images

[Ziller Eike]

On Oct 6, 2014, at 1:59 PM, Robert Iakobashvili corobe...@gmail.com wrote:

 Gentlemen,
 If images are placed to resource file,
 is there any option for an automatic management
 of using either Retina or non-Retina images
 using Apple's naming convention or the manual
 management is the only option like for Mac OS X?
 
 Here's an example of what Qt developers
 are doing:
 http://qt-project.org/forums/viewthread/44805/
 
 Are there any other approaches or
 best practices?


Just use

Image {
source: “foo.png”
}

and it will try “f...@2x.png” on 2x screens on OS X and iOS automatically.

Br, Eike

 Thank you.
 
 Kind regards,
 Robert
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Important OSX 10.9.5 10.10 codesign changes

[Ziller Eike]

On Oct 7, 2014, at 8:43 AM, Robert Iakobashvili corobe...@gmail.com wrote:

 On Mon, Sep 22, 2014 at 1:03 PM, Sorvig Morten morten.sor...@digia.com 
 wrote:
 
 On 19 Sep 2014, at 11:28, Sorvig Morten morten.sor...@digia.com wrote:
 
 This will indeed receive attention in the coming days. There are already 
 some patches attached to the QTBUGs. I’ll post back here once we have a 
 complete patch set ready. Target branches are Qt 5.3 and Qt 4.8.
 
 I’m using QTBUG-32896 as a metabug to track the effort.
 
 Here’s the current patch set (5.3):
 
 qmake - framework bundle hierarchy (QTBUG-32895): 
 https://codereview.qt-project.org/95454
 qmake - “_debug in CFBundleExecutable  (QTBUG-32894): 
 https://codereview.qt-project.org/95455
 qmake - add CFBundleVersion: https://codereview.qt-project.org/95456
 macdeployqt - “Current” version symlinks: 
 https://codereview.qt-project.org/#/c/95442/
 
 Are these patches sufficient? If not, what’s missing?
 
 Morten
 
 
 I see that they were integrated to 5.3.
 But when I get the 5.3 branch from git, the last commits seen in log are
 dated August and these patches have been merged on October 1.
 
 git clone git://gitorious.org/qt/qt5.git qt-5
 cd gt5
 git checkout 5.3
 
 Shall I take some another branch or switch to something?

The commits referenced for the submodules in the qt5.git are always a bit 
behind. To get the absolutely latest commit for a submodule, go into that 
submodule and checkout the corresponding branch there:

cd qt5/qtbase
git checkout 5.3
git pull

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

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt for iOS: Management Retina vs Non-Retina Images

[Ziller Eike]

On Oct 8, 2014, at 9:18 AM, Robert Iakobashvili corobe...@gmail.com wrote:

 On Wed, Oct 8, 2014 at 10:03 AM, Ziller Eike
 eike.zil...@theqtcompany.com wrote:
 
 On Oct 6, 2014, at 1:59 PM, Robert Iakobashvili corobe...@gmail.com wrote:
 
 Gentlemen,
 If images are placed to resource file,
 is there any option for an automatic management
 of using either Retina or non-Retina images
 using Apple's naming convention or the manual
 management is the only option like for Mac OS X?
 
 Here's an example of what Qt developers
 are doing:
 http://qt-project.org/forums/viewthread/44805/
 
 Are there any other approaches or
 best practices?
 
 
 Just use
 
 Image {
source: “foo.png”
 }
 
 and it will try “f...@2x.png” on 2x screens on OS X and iOS automatically.
 
 Br, Eike
 
 
 Thank you for your response.
 This is a widget-based application, though.

QIcon does automatic loading of @2x images afair. QPixmap and QImage only set 
the devicePixelRatio corresponding to the file name automatically, but you have 
to define yourself if you want to load a @2x or not.

Br, Eike

 Kind regards,
 Robert

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] QUrl setPath Qt4 vs Qt5

[Ziller Eike]

Just for completeness ;)

https://bugreports.qt-project.org/browse/QTBUG-27728


On Sep 28, 2014, at 9:52 AM, Samuel Gaist samuel.ga...@edeltech.ch wrote:

 
 On 28 sept. 2014, at 03:26, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 
 On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote:
 Hi,
 
 Following a post on the forum, I've checked and there's been a behavior
 change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the
 C++ API changes chapter.
 
 If I understood correctly:
 
 QUrl example1(http://www.example.com;);
 example1.setPath(pub/something);
 
 makes example1 invalid in Qt 5 due to the fact that pub/something is a
 relative path (following QUrl documentation and test) but in Qt 4 the
 result is http://www.example.com/pub/something;.
 
 Should it be considered bug in Qt 4 that needs fixing ? However fixing it
 might break existing application that could be relying on that behavior. In
 this case, simply add the API break in Qt 5's documentation ?
 
 Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important 
 and 
 would require a major change.
 
 QUrl in Qt 4 has quite a few known issues with encoding and decoding of 
 delimiters too. And its QString constructor is a completely flawed design 
 and 
 should never be used.
 
 QUrl changed considerably in Qt 5 to comply better with the URL 
 specifications 
 and with brokenness out there. If we add anything to the documentation, it 
 would be the previous sentence, with no extra details.
 
 I remember now following a discussion about that matter some time ago.
 
 Fine for me. I'll update the API change doc to include that so future users 
 won't be surprised.
 
 Samuel
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation)

[Ziller Eike]

On Sep 2, 2014, at 9:01 AM, Rutledge Shawn shawn.rutle...@digia.com wrote:

 
 On 1 Sep 2014, at 8:32 PM, Thiago Macieira wrote:
 
 On Monday 01 September 2014 12:50:23 Graham Labdon wrote:
 Hi
 My application is internationalized, however, in some circumstances I need
 the English version of the string no matter what translator is being used.
 Anyone have any suggestions on how to achieve this?
 
 You have the English text. The way to get the English text from that is to 
 use 
 it as-is.
 
 Don't translate, don't transform it in any way.
 
 Some projects like to use programmer shorthand for strings and then leave 
 the final text up to a different team.  Such teams tend to be capricious and 
 change the English text multiple times (PR and marketing reasons), so it's an 
 advantage not to treat the English text as the key for looking up the 
 translation.  (And then the shorthand can be written in any language the 
 programmer likes, too.)

If your english translation is done in a separate .qm file (i.e. you do not use 
the tr-keys for the english text), your application can create a separate 
QTranslator that you use to load the english translation separately. You just 
do NOT INSTALL that translator into your app, but instead use that translator 
directly yourself if you want to access a specific english translation, with 
englishTranslator.translate(context, text, ..).

 I had a previous job like that.  They had their own cross-platform 
 cross-toolkit translation system, so I wasn't allowed to use tr() at all, and 
 they convinced me that their way was better.  They wanted to have all the 
 strings for all the languages inside the binary.  And there was a utility to 
 generate an enum for the shorthand strings.  Imagine opening up Designer and 
 creating a button, and setting its label to BUTTON_OK.  Then you run uic.  
 Then you post-process the generated header file and make it do something like 
 tr(BUTTON_OK), which will use the enum to look up the actual string at 
 runtime, in a fixed-length array in which all strings for a particular 
 language are stored.
 
 - Since the header modification is part of the build process, it costs the 
 developer no time at all if the translation team wants to change the English 
 text.  They do their work independently, and then the application is 
 re-built. 

Since the text that is put in tr() is just used as a fallback, there is nothing 
preventing anyone from providing a separately created english translation (or 
change individual texts if they are supposed to change). In  “your” code that 
tries to load the correct translation for the current locale, you can fallback 
to loading this english translation instead of using the tr-key fallback. Of 
course you might end up with lots of strings in your application that are only 
used as a key.

 - At runtime, this kind of lookup is much more efficient than the usual Gnome 
 and KDE ways of looking around the filesystem for separate translation files 
 (but at the cost of bloating the binary somewhat). 

I would have thought that it is possible to use qrc to add your .qm files to 
your binary if you really want? Since you define yourself in your app where to 
look for translations.

 - It is clear to everyone when the translation mechanism is not working or 
 there is an un-translated string: you see the enum shorthand strings instead 
 of the correct strings - no need to wait for a non-English-speaking tester to 
 discover it.

Linguist keeps track of which strings actually have been translated in some 
language, so the check “do all strings have translations is easily automated. 
I’d expect any translation tool to do that tracking ;). For the check if the 
translation is actually good/correct you need a native speaker of the 
corresponding language for testing anyhow in the end.

 - There will never be a user who cannot use the app because it wasn't 
 installed correctly and therefore the translation file was not found: the 
 strings are guaranteed to be present as long as someone did the translation 
 work before it shipped.
 
 The current way of using separate translation files should be kept as a 
 fallback mechanism though, so that people in countries which were neglected 
 by the development team can still do their own translations.  This is the 
 good part of the KDE way, that the translation work can be distributed to 
 lots of people around the world.  But it's also possible that they could 
 contribute their work back to the original git repo, so that some future 
 build of the application will have those strings built-in.
 
 I think it's a worthwhile goal that at least commercial Linux binaries ought 
 to be self-contained and portable, so that there is no installation process 
 beyond putting the binary in some directory which is in your path.  It 
 wouldn't hurt if the free software community had the goal of zero-install 
 binaries too.  The strings could be packaged as compressed resources, 

Re: [Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation)

[Ziller Eike]

This was cross-posted :/
My answer will possibly not end up on the interest mailing list.

On Sep 2, 2014, at 10:31 AM, Ziller Eike eike.zil...@digia.com wrote:

 
 On Sep 2, 2014, at 9:01 AM, Rutledge Shawn shawn.rutle...@digia.com wrote:
 
 
 On 1 Sep 2014, at 8:32 PM, Thiago Macieira wrote:
 
 On Monday 01 September 2014 12:50:23 Graham Labdon wrote:
 Hi
 My application is internationalized, however, in some circumstances I need
 the English version of the string no matter what translator is being used.
 Anyone have any suggestions on how to achieve this?
 
 You have the English text. The way to get the English text from that is to 
 use 
 it as-is.
 
 Don't translate, don't transform it in any way.
 
 Some projects like to use programmer shorthand for strings and then leave 
 the final text up to a different team.  Such teams tend to be capricious and 
 change the English text multiple times (PR and marketing reasons), so it's 
 an advantage not to treat the English text as the key for looking up the 
 translation.  (And then the shorthand can be written in any language the 
 programmer likes, too.)
 
 If your english translation is done in a separate .qm file (i.e. you do not 
 use the tr-keys for the english text), your application can create a separate 
 QTranslator that you use to load the english translation separately. You just 
 do NOT INSTALL that translator into your app, but instead use that translator 
 directly yourself if you want to access a specific english translation, with 
 englishTranslator.translate(context, text, ..).
 
 I had a previous job like that.  They had their own cross-platform 
 cross-toolkit translation system, so I wasn't allowed to use tr() at all, 
 and they convinced me that their way was better.  They wanted to have all 
 the strings for all the languages inside the binary.  And there was a 
 utility to generate an enum for the shorthand strings.  Imagine opening up 
 Designer and creating a button, and setting its label to BUTTON_OK.  Then 
 you run uic.  Then you post-process the generated header file and make it do 
 something like tr(BUTTON_OK), which will use the enum to look up the actual 
 string at runtime, in a fixed-length array in which all strings for a 
 particular language are stored.
 
 - Since the header modification is part of the build process, it costs the 
 developer no time at all if the translation team wants to change the English 
 text.  They do their work independently, and then the application is 
 re-built. 
 
 Since the text that is put in tr() is just used as a fallback, there is 
 nothing preventing anyone from providing a separately created english 
 translation (or change individual texts if they are supposed to change). In  
 “your” code that tries to load the correct translation for the current 
 locale, you can fallback to loading this english translation instead of using 
 the tr-key fallback. Of course you might end up with lots of strings in your 
 application that are only used as a key.
 
 - At runtime, this kind of lookup is much more efficient than the usual 
 Gnome and KDE ways of looking around the filesystem for separate translation 
 files (but at the cost of bloating the binary somewhat). 
 
 I would have thought that it is possible to use qrc to add your .qm files to 
 your binary if you really want? Since you define yourself in your app where 
 to look for translations.
 
 - It is clear to everyone when the translation mechanism is not working or 
 there is an un-translated string: you see the enum shorthand strings instead 
 of the correct strings - no need to wait for a non-English-speaking tester 
 to discover it.
 
 Linguist keeps track of which strings actually have been translated in some 
 language, so the check “do all strings have translations is easily 
 automated. I’d expect any translation tool to do that tracking ;). For the 
 check if the translation is actually good/correct you need a native speaker 
 of the corresponding language for testing anyhow in the end.
 
 - There will never be a user who cannot use the app because it wasn't 
 installed correctly and therefore the translation file was not found: the 
 strings are guaranteed to be present as long as someone did the translation 
 work before it shipped.
 
 The current way of using separate translation files should be kept as a 
 fallback mechanism though, so that people in countries which were neglected 
 by the development team can still do their own translations.  This is the 
 good part of the KDE way, that the translation work can be distributed to 
 lots of people around the world.  But it's also possible that they could 
 contribute their work back to the original git repo, so that some future 
 build of the application will have those strings built-in.
 
 I think it's a worthwhile goal that at least commercial Linux binaries ought 
 to be self-contained and portable, so that there is no installation process 
 beyond putting the binary

Re: [Development] Does Qt support customed web browser with self-defined Internet protocols??

[Ziller Eike]

On Aug 26, 2014, at 4:02 AM, quinn.wj.xie quinn.wj@gmail.com wrote:

  
 Hello, everyone at development@qt-project
  
 I have a question and want some suggestions. Right now I am learning Qt 
 programming. And I was wondering if Qt supports a customed web browser. 
 Because our lab is working on a new Internet protocol and the teacher asks me 
 to test if a browser can analyze it. So I have to make a new browser all by 
 myself and make sure it works with this new protocol instead of TCP/IP. Since 
 I am a green hand on Qt, I don't know whether this can work out.
 Would you mind giving me some advice on this project?

As far as I understand it, you can implement your own way for retrieving data 
from anywhere with QtWebKit, through implementing your own 
QNetworkAccessManager. We do that e.g. for the help viewer in Qt Creator, which 
retrieves data from a help database instead.

You can probably just start with the ??simple browser example?? in Qt, which 
already implements a minimal browser, and also already provides its own network 
access manager, which you can modify to suit your purposes.

https://qt.gitorious.org/qt/qtwebkit-examples/source/5.3:examples/webkitwidgets/browser


Br, Eike

 Thanks a lot.
 Please contact me: quinn.wj@gmail.com
  
 Quinn Xie
 School of Electronic and Information Engineering
 Beijing Jiaotong University
 Beijing 100044, China
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Gesch?0?1ftsf??hrer: Mika P?0?1lsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Debug Qt on Mac

[Ziller Eike]

On Aug 25, 2014, at 3:09 AM, Jake Petroules jake.petrou...@petroules.com 
wrote:

 `export DYLD_IMAGE_SUFFIX=_debug` before running your application. Simple as 
 that. Note that this option will be ignored if DYLD_ROOT_PATH is set.
 
 See 
 https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
  for related documentation.

And if you use Qt Creator, there is a checkbox for it in the run configuration 
settings for qmake/.pro based projects :)

 -- 
 Jake Petroules - jake.petroules at petroules.com
 Chief Technology Officer - Petroules Corporation
 
 On 2014-08-24, at 11:33 AM, Jan Sundermeyer sunde...@gmx.de wrote:
 
 After compiling Qt from git on mac, debugging an application which was
 build against that Qt-version does not allow debugging of Qt-functions
 though of all other internal application functions.
 Seems that the build is not linked against the debug-version of the qt libs.
 How can that be done ?
 ___
 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

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] QOptional

[Ziller Eike]

On Aug 21, 2014, at 5:16 PM, Marc Mutz marc.m...@kdab.com wrote:

 On Thursday 21 August 2014 16:52:05 Thiago Macieira wrote:
 But I'd like QOptionalQString o = QString() result in a null
 (disengaged)  QOptional too.

Why would that be?
The optional got a QString value assigned. It shouldn’t care about more.

 Too clever for a general optional class, IMO:
 
  QOptionalQString qs = QString();
  QOptionalstd::string ss = std::string();
 
 qs will be disengaged and ss will be engaged. Hard to explain in the docs. 
 Impossible to anticipate for new users of the class. Death row for template 
 code.

I agree.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Ziller Eike]

On Aug 12, 2014, at 4:25 PM, Adam Strzelecki o...@java.pl wrote:

 Okay, Phase II.
 
 (1) Introduce bundle_frameworks CONFIG option, and set it default for 
 rpath shared builds on iOS  OS X

Can we please already now turn a cross-platform hat on, and at least think 
about options that at least do not right away block using the same for non-OS X?

We already have/had the mess with DEPLOYMENT/INSTALLS with 
desktop/meego/symbian, I don’t want us ending up with the same again... 
(https://qt.gitorious.org/qt-creator/qt-creator/source/9471d96e572c527bf85a2ca82ebd49bbf6f3c162:share/qtcreator/templates/shared/deployment.pri)

I do not see any reason why one shouldn’t be able to turn on copying Qt libs 
next to the application binary on Windows even without any changes on how Qt is 
built there. And usage of $ORIGIN on Linux doesn’t sound like a too bad idea to 
me either. “bundle_frameworks” already disqualifies using the same config 
option on anything non-OS X. (Aside from that, what is with dylib builds of Qt?)

 (2) Introduce bundle make target, when bundle_frameworks CONFIG is set, 
 it is added to all
 
 (3) Make's bundle will copy (update if not there) all used Qt frameworks to 
 app's bundle Frameworks and used plugins to Plugins (currently implemented as 
 separate macdeployqt)
 
 NOTES:
 
 * Since qmake knows which Qt libraries and plugins are used bundle target 
 it will generate following Makefile entries
 
   all: Sample.app bundle
 
   bundle: Sample.app/Frameworks/QtCore.framework
 mkdir -p Sample.app/Frameworks  cp -r 
 $$[QT_INSTALL_LIBS]/QtCore.framework Sample.app/Frameworks
 ...
 
 Of course this example is simplification, since we don't need to copy headers 
 and we need to take debug versions or release. So there will be more commands 
 in practice.
 
 * One can disable bundle_frameworks via CONFIG -= bundle_frameworks, so 
 existing workflow where executable is given rpath pointing to Qt libraries
 
 * If disabled, one can still do make bundle that is equivalent to current 
 macdeployqt and bundle target will also add install_name_tool -rpath 
 replacement steps


 one can still do make bundle that is equivalent to current macdeployqt


Actually there is one huge difference between the two, and I’m not sure how 
this would work with the make target: a) macdeployqt works on all libraries 
that are in the bundle the moment it is executed, and b) it is possible to tell 
macdeployqt to make other executables/applications also use the same bundled Qt.

(a) e.g. the Qt Creator build creates the application, and a whole bunch of 
plugin dylibs with DESTDIR in the bundle. The rpaths should just be correct 
from the start, probably no problem there, but some libraries there add 
dependencies to the Qt libraries that are needed. The main application is 
pretty minimal. So, depending on dylib target sub-.pro files, the list of Qt 
libraries to bundle with the *application* needs to change.

(b) e.g. we have quite a few tools shipped in the Qt Creator bundle, which are 
either used by Qt Creator internally (e.g. for iOS device detection, starting 
the simulator,...), or shipped for convenience (the qbs that Qt Creator is 
linked against, etc). We definitely do not want to have separate Qt frameworks 
for these, but want them to use the frameworks from the Qt Creator application. 
With macdeployqt we tell it about the additional executables, and macdeployqt 
takes care of bundling additional required Qt frameworks, and fixing install 
names/rpaths correspondingly. 



-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Ziller Eike]

On Aug 13, 2014, at 11:07 AM, Oswald Buddenhagen oswald.buddenha...@digia.com 
wrote:

 On Tue, Aug 12, 2014 at 07:08:45PM -0400, Jake Petroules wrote:
 On 2014-08-12, at 06:50 PM, Adam Strzelecki o...@java.pl wrote:
 I agree that such facility should be provided internally while
 implementing Phase II changes.
 
 (1) Add qmake options QMAKE_EMBEDDED_FRAMEWORKS,
 QMAKE_EMBEDDED_LIBRARIES, QMAKE_EMBEDDED_PLUGINS, each taking a
 list of absolute paths and/or objects; applies to any qmake bundle
 target, app, framework, etc. Does nothing for non-bundle targets.
 Does nothing outside of OS X and iOS.
 
 Makes sense.
 
 yes. except that i want these to be called QMAKE_BUNDLE_*.
 this is irrespective of x-platform use. i like the idea of calling the
 functionality bundling.
 
 (1a) objects (don't know what this is called in qmake but INSTALLS works 
 similarly) meaning:
 
 weirdlib.src = /Library/Frameworks/WeirdLib.framework
 weirdlib.dst = $$join($$QMAKE_EMBEDDED_FRAMEWORKS_LOCATION, 
 SubFolderForSomeReason)
 weirdlib.headers = true
 weirdlib.variants = debug release
 QMAKE_EMBEDDED_FRAMEWORKS += weirdlib /Library/Frameworks/Sparkle.framework
 
 Thumbs up. Good idea.
 
 i'm not so sure about the details.
 the thing is that the .dst specification is way too precise, thus
 making x-platform use impossible. even the existing QMAKE_BUNDLE_FILES
 isn't that precise (which enables supporting ios and osx bundles without
 changes to the project ... provided somebody bothers to polish up the
 qmake changes that are supposed to make this actually work).
 
 (4) User's OWN responsibility (NOT qmake's) to set QMAKE_RPATHDIR
 for their application/library/framework to whatever they like -
 @executable_path/../Frameworks, $$[QT_INSTALL_LIBS],
 /Library/Application Support/FooBar/Frameworks, etc.
 
 I disagree here. This should work out of the box for any simple or
 existing Qt app, regardless what Qt modules it uses. Requiring
 changes to existing projects is bad idea.
 
 I disagree that it's a bad idea, but putting on my qbs hat for a
 moment and thinking about Export { } I'm willing to concede here.
 
 i don't understand what this has to do with qbs Export {}.
 
 (1) NO changes are made to USER targets by qmake, ever. That means
 qmake MUST NOT set any rpaths in user targets unless EXPLICITLY
 given by the user with QMAKE_RPATHDIR (currently you are doing this
 but only as a transitionary measure and it will be removed once
 support for copying frameworks is added).
 
 Correct me if I am wrong, but changes are needed to all existing
 projects or/and user environment (DYLD_...), otherwise their freshly
 built app won't start and we get plenty of post why may app no
 longer starts with new Qt release.
 
 Use the QT qmake variable to determine what frameworks to copy by
 default and you don't have this problem.
 
 i'm kind of losing at least one of you guys here.
 it's beyond obvious that existing projects *will* need at least one
 modification: CONFIG += bundle_qt (and possibly additional
 QMAKE_BUNDLE_* for non-qt dependencies). there is no way i'd allow
 a major behavior change like making this the default.
 and when these options are enabled, it seems pretty much a no-brainer


 that qmake would also automatically add the right rpaths to make these
 bundled dependencies actually useful. why would you ever *not* do that?

Afaics the suggestion is to never have the absolute path to the Qt frameworks 
added to the rpath at all. Which would make the rpaths *only* be useful for the 
bundled dependencies. So, when not using the “bundle stuff” option, it would 
require setting either DYLD_ in the run environment, or explicitly adding 
the absolute Qt path to your binaries’ rpath, to be able to run the result. I 
still do not see why the absolute path shouldn’t be added when _not_ bundling 
Qt though.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Ziller Eike]

On Aug 13, 2014, at 12:32 PM, Adam Strzelecki o...@java.pl wrote:

 Ziller Eike wrote:
 
 Can we please already now turn a cross-platform hat on, and at least think 
 about options that at least do not right away block using the same for 
 non-OS X?
 
 Sure, this is just a proposition, bundle_qt (proposed in latter posts) 
 seems to match it better.
 
 I do not see any reason why one shouldn’t be able to turn on copying Qt libs 
 next to the application binary on Windows even without any changes on how Qt 
 is built there. And usage of $ORIGIN on Linux doesn’t sound like a too bad 
 idea to me either. “bundle_frameworks” already disqualifies using the same 
 config option on anything non-OS X. (Aside from that, what is with dylib 
 builds of Qt?)
 
 Sure I do agree, that it should work for Windows too. But Windows is out of 
 my scope. Anyone eager to do similar changes for Windows?
 
 (a) e.g. the Qt Creator build creates the application, and a whole bunch of 
 plugin dylibs with DESTDIR in the bundle. The rpaths should just be correct 
 from the start, probably no problem there, but some libraries there add 
 dependencies to the Qt libraries that are needed. The main application is 
 pretty minimal. So, depending on dylib target sub-.pro files, the list of Qt 
 libraries to bundle with the *application* needs to change.
 
 If we put bundled Qt library as Makefile target dependency either of 
 executable, plugin or whatever. Each of this targets will trigger copy of 
 missing libraries.
 
 (b) e.g. we have quite a few tools shipped in the Qt Creator bundle, which 
 are either used by Qt Creator internally (e.g. for iOS device detection, 
 starting the simulator,...), or shipped for convenience (the qbs that Qt 
 Creator is linked against, etc). We definitely do not want to have separate 
 Qt frameworks for these, but want them to use the frameworks from the Qt 
 Creator application. With macdeployqt we tell it about the additional 
 executables, and macdeployqt takes care of bundling additional required Qt 
 frameworks, and fixing install names/rpaths correspondingly. 
 
 As long it is same framework then it has single Frameworks folder, therefore 
 there will be no doubling.
 

Discussed on IRC with Jake:
If QMAKE_EMBEDDED_FRAMEWORKS also worked for e.g. dylib targets, it would be 
possible to specify it also in the .pro files of bundled libraries and 
executables, and put the result into the main app bundle with smth like 
weirdlib.dst = $$QTCREATOR_FRAMEWORK_PATH” (where QTCREATOR_FRAMEWORK_PATH is 
set in qtcreator.pri, which is already pulled in by all bundled libs, plugins 
and executables).
That way the plugins, libraries and other executables could specify the things 
necessary to bundle for them themselves.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

[Development] crash when activating timers

[Ziller Eike]

For Qt Creator we get the following crash reported:
https://bugreports.qt-project.org/browse/QTCREATORBUG-11262

It seems to happen randomly, on unix (i.e. OS X and Linux) but possibly not on 
Windows, at least Qt 5.2.1 and later, and the seemingly only person in the 
Berlin office which also gets this crash once in a while, can only reproduce it 
with the binary package that we provide on downloads.qt-project.org.

The backtrace doesn’t give much insight either, except that it happens when 
activating timers:

Program received signal SIGSEGV, Segmentation fault.
0x76536545 in QCoreApplication::notifyInternal(QObject*, QEvent*) () 
from /home/usuario/Qt/Tools/QtCreator/bin/../lib/qtcreator/libQt5Core.so.5
(gdb) bt
#0  0x76536545 in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /home/usuario/Qt/Tools/QtCreator/bin/../lib/qtcreator/libQt5Core.so.5
#1  0x76585fdc in QTimerInfoList::activateTimers() () from 
/home/usuario/Qt/Tools/QtCreator/bin/../lib/qtcreator/libQt5Core.so.5
#2  0x765867ed in ?? () from 
/home/usuario/Qt/Tools/QtCreator/bin/../lib/qtcreator/libQt5Core.so.5
#3  0x752a93b6 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x752a9708 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x752a97ac in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x76586fc4 in 
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () 
from /home/usuario/Qt/Tools/QtCreator/bin/../lib/qtcreator/libQt5Core.so.5
#7  0x765352cb in 
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from 
/home/usuario/Qt/Tools/QtCreator/bin/../lib/qtcreator/libQt5Core.so.5
#8  0x7653933e in QCoreApplication::exec() () from 
/home/usuario/Qt/Tools/QtCreator/bin/../lib/qtcreator/libQt5Core.so.5
#9  0x0040a561 in ?? ()
#10 0x757d4de5 in __libc_start_main (main=0x4068f0, argc=1, 
ubp_av=0x7fffdf78, init=optimized out, fini=optimized out, 
rtld_fini=optimized out, stack_end=0x7fffdf68)
at libc-start.c:260
#11 0x0040aa01 in ?? ()
#12 0x7fffdf68 in ?? ()
#13 0x001c in ?? ()
#14 0x0001 in ?? ()
#15 0x7fffe2e9 in ?? ()
#16 0x in ?? ()
(gdb) 

So my question: Does anyone have any idea how this could possibly happen, how 
we could reproduce and/or debug and fix it?

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] crash when activating timers

[Ziller Eike]

On Aug 13, 2014, at 5:07 PM, Daniel Teske daniel.te...@digia.com wrote:

 On Wednesday 13 Aug 2014 08:05:52 Thiago Macieira wrote:
 On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote:
 So my question: Does anyone have any idea how this could possibly happen,
 how we could reproduce and/or debug and fix it?
 
 I also got a bug report that is similar:
 https://bugreports.qt-project.org/browse/QTBUG-40636
 
 It's right now in need info state. There's nothing I can do with what's
 reported there or by your backtrace. Any chance we can convince people to
 run Creator inside valgrind?
 
 Also, please store the debug files from the build somewhere.
 There is a valgrind log attached to the creator bug.


https://bugreports.qt-project.org/secure/attachment/38930/qtcreator-valgrind-output.txt

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Ziller Eike]

On Aug 11, 2014, at 11:15 PM, Jake Petroules jake.petrou...@petroules.com 
wrote:

 On 2014-08-11, at 10:42 AM, Ziller Eike eike.zil...@digia.com wrote:
 
 
 In a terminal session, simply:
 
 $ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/path/to/Qt/Frameworks
 $ open /apps/MyApp.app
 
 In Creator, just click run and this will be handled automatically. In qbs 
 just type `qbs run -p foo` and this will be handled automatically.
 
 This won't work for apps launched directly via Finder/Dock.
 
 Like I said, that doesn't matter. It didn't work in Qt 4 and the fact that 
 it works in Qt 5 is a mere side effect. No one will notice.
 
 Qt 4 worked exactly like Qt 5 does in this regard.
 
 I think your memory might be off.

From the “user” perspective no.

 server:~ jakepetroules$ otool -L 
 /Library/Frameworks/QtGui.framework/Versions/Current/QtGui
 /Library/Frameworks/QtGui.framework/Versions/Current/QtGui:
   /usr/local/Trolltech/Qt-4.8.6/lib/QtGui.framework/Versions/4/QtGui 
 (compatibility version 4.8.0, current version 4.8.6)

That’s the absolute path to the default install prefix when building Qt 4.
If you do a -developer-build, the install prefix is the build directory, and 
the id is the corresponding absolute path to the lib.
The Qt 4 binary installer actually installs Qt libraries that have a relative 
path as id and references, e.g. 

/Library/Frameworks/QtGui.framework/QtGui:
QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current 
version 4.8.6)
QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, 
current version 4.8.6)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 152.0.0)

Which works because they are installed in a default search path.
That’s the installer from 
http://download.qt-project.org/official_releases/qt/4.8/4.8.6/ , so I have no 
idea how you got the install that you see.

So, it was never necessary to set any environment variables or to run your 
application through an IDE with Qt 4 on Mac, it was always possible to just run 
your application through Finder etc.

   /usr/local/Trolltech/Qt-4.8.6/lib/QtCore.framework/Versions/4/QtCore 
 (compatibility version 4.8.0, current version 4.8.6)
   /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
 (compatibility version 2.0.0, current version 152.0.0)
   /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
 1.2.3)
   /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
 (compatibility version 45.0.0, current version 1038.0.0)
   /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
 version 7.9.0)
   /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
 625.0.0)
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
 version 123.0.0)
   /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 
 227.0.0)
   
 /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
 (compatibility version 1.0.0, current version 44.0.0)
   
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
 (compatibility version 150.0.0, current version 550.0.0)
   
 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
  (compatibility version 1.0.0, current version 38.0.0)
   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
 (compatibility version 300.0.0, current version 751.0.0)
 server:~ jakepetroules$ stat /usr/local/Trolltech/Qt-4.8.6
 stat: /usr/local/Trolltech/Qt-4.8.6: stat: No such file or directory
 
 Notice the install name prefix differs from the actual installation 
 directory. It might be the case that it worked only because Qt 4 installed by 
 default in the system-recognized /Library/Frameworks and dyld falls back to 
 that path (among others) despite a completely different absolute soname. (Odd 
 behaviour in any case!)



 Most people build Qt apps on OS X using some IDE, most likely Qt Creator. 
 Are you seriously telling me you click build, go find the build directory, 
 and launch the app in Finder?
 
 I very often start my developed app (Qt Creator) from 
 Finder/Spotlight/Launchbar. For example when I want to show someone 
 something, and I currently do not have Qt Creator open, or have Qt Creator 
 open with a different application or branch of the application.
 
 Yeah well with the Phase II changes (copy frameworks to the bundle) this 
 point becomes moot.

Yes, that’s good. I just wanted to clarify what is ridiculous and what not.

 Also, nothing stops you adding an absolute runpath search path to your own 
 app (QMAKE_RPATHDIR += $$[QT_INSTALL_LIBS]), just that qmake must NOT do this 
 automatically.
 
 That's ridiculous. You click the run button. If you're willing to go 
 through all the former effort you can easily export DYLD_LIBRARY_PATH at 
 the beginning of your terminal session

Re: [Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Ziller Eike]

On Aug 3, 2014, at 12:39 AM, Jake Petroules jake.petrou...@petroules.com 
wrote:

 On 2014-08-02, at 05:04 AM, Adam Strzelecki o...@java.pl wrote:
 
 Please don't exaggerate the performance implications of copying a few 
 frameworks on the first build (…)
 
 This can be done, but discussion is going off-topic.
 
 Let us try first to move Qt frameworks to use @rpath  remove some 
 unnecessary operations while keeping current workflow with minimal changes 
 to the code. Therefore I hereby propose to (1) keep rpath to Qt SDK in built 
 app executable, (2) not copy anything on build, (3) make macdeploy modify 
 ONLY executable removing absolute rpath (instead fixing frameworks), and (4) 
 just copy needed frameworks and (5) optionally sign whole bundle.
 
 This will not require any wrappers, environment variables or changes in Qt 
 Creator to run your app. Only Qmake and macdeploy need to be changed. 
 
 Frankly I don't see anything wrong with keeping full path to SDK in 
 executable when it isn't yet completely bundled. And the initial intention 
 was to NOT touch Qt SDK modules once they are built.
 
 Once this is done  working we can follow this discussion and think what can 
 be done next.
 
 -- 
 Adam
 
 This isn't off topic at all. @rpath, copying frameworks, DYLD_ environment 
 variables are all inseparably linked and very much part of the same 
 discussion and overall issue. Your proposal to simply add @rpath and do 
 nothing else has no benefits. What problem does it solve, other than deleting 
 a bit of code from macdeployqt that currently works and will continue to work 
 without maintenance? None. There is no point in doing it unless we go all the 
 way and make the Qt SDK completely relocatable.
 
 I understand you want to start by completing one objective at a time, but 
 keep in mind each of these objectives is part of a greater overall goal. 
 Alone, they are pointless.
 
 Actually you CAN add Info.plist to bundle-less apps using the linker 
 arguments: `-sectcreate __TEXT __info_plist Info.plist` which will embed it 
 in the binary. All OS X APIs handle this transparently. Though, 
 LSEnvironment is not a good solution for the problem we are trying to solve 
 here.
 
 I was expecting that ;) But wasn't your intention to not modify binary once 
 it has been built and not hardcode any paths into it?
 
 Yes, which is why I said LSEnvironment is not a good solution.
 
 Why would you do any of these things?
 
 Because you dislike adding absolute rpath to Qt SDK in built binary during 
 dev process.
 
 All of those things involve hardcoding absolute paths *somewhere*. There 
 should be no absolute paths *anywhere* except environment variables that are 
 automatically set per-session.
 
 Inject? DYLD_LIBRARY_PATH is an environment variable. You simply set it 
 in the process's environment before spawning.
 
 It is not so simple, first of all as you shown it works only from console, 
 but if you launch it via GUI you need this variable to be set in launchd. As 
 ~/.launchd.conf doesn't work anymore since Lion only permanent solution is 
 to use /etc/launchd-user.conf which require admin to create/modify.
 
 Secondly DYLD_LIBRARY_PATH has strong security implications as the path is 
 searched BEFORE default locations. So it does in fact let you inject/replace 
 libraries. This is the reason dyld disables that for any process running 
 under root account.
 
 man dyld
 
 DYLD_LIBRARY_PATH
 
  The dynamic linker searches these directories BEFORE it searches the 
 default locations for libraries.
 
 What might be considered there is DYLD_FALLBACK_FRAMEWORK_PATH.
 
 This is another excuse - there are no real security implications in practice. 
 If you're even thinking about this, your machine has already been compromised 
 and you no longer own it. Remember that this is a development time concern, 
 too, and has nothing to do with a production environment.
 
 The security conscious Apple Inc. doesn't seem to think it's a big problem 
 either, because Xcode sets it during development (see below).
 
 I'm curious in what realistic scenario you think this is a real problem.
 
 
 In a terminal session, simply:
 
 $ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/path/to/Qt/Frameworks
 $ open /apps/MyApp.app
 
 In Creator, just click run and this will be handled automatically. In qbs 
 just type `qbs run -p foo` and this will be handled automatically.
 
 This won't work for apps launched directly via Finder/Dock.
 
 Like I said, that doesn't matter. It didn't work in Qt 4 and the fact that it 
 works in Qt 5 is a mere side effect. No one will notice.

Qt 4 worked exactly like Qt 5 does in this regard.

 Most people build Qt apps on OS X using some IDE, most likely Qt Creator. Are 
 you seriously telling me you click build, go find the build directory, and 
 launch the app in Finder?

I very often start my developed app (Qt Creator) from 
Finder/Spotlight/Launchbar. For example when I want to show someone 

Re: [Development] Converting types in Qt

[Ziller Eike]

On Jul 16, 2014, at 1:45 PM, Poenitz Andre andre.poen...@digia.com wrote:

 Olivier Goffart wrote:
 Jędrzej Nowacki wrote:
 [...]
 What is wrong with string - int or bytearray - int?
 
 At the very least, _implicit_ conversions should not lose data,
 i.e. a  A a1;  B b = a1; A a2 = b; round trip ideally should yield
 a1 == a2.
 
 If I am ready to give up information, I'd like to need to say so
 in the code explicitly. (And yes, part of the deed is done in the
 core language, but even there compilers start to nag about it.)
 
 André, QVariant conversions are not implicit, they are explicit.
 
 I am aware of that. I tried to answer the question of What is wrong 
 with string - int or bytearray - int”. 

QVariant::operator== is not symmetric :( :( :(

 QDateTime dateTime = QDateTime::currentDateTime();
QTime time = dateTime.time();

qDebug()  (QVariant(dateTime) == QVariant(time));
qDebug()  (QVariant(time) == QVariant(dateTime));

--
false
true

 We admittedly left the original context here (and in other parts of the 
 discussion), but the question was posed in context that I read an 
 example of an conversion that one would always consider convenient
 to have, and I started with At the very least, _implicit.. supposedly 
 setting the context of the answer.
 
 Anyway. To summarize my position in the original context: QVariant 
 is as it is. It is convenient at times, and it is already too convenient 
 at times. Easy type conversion is a different use case than Type 
 agnostic storage. QVariant does a bit of both, only the second one
 has ever been useful _to me_, I have been bitten by the first. As 
 there are typically also more direct ways to convert types than to 
 pass through QVariant, I consider the possibility to do type conversion
 through QVariant a mis-feature, and adding even more conversion 
 abilities would be a step into the wrong direction _for me_. This is 
 a personal opinion.
 
 Andre'

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Converting types in Qt

[Ziller Eike]

On Jul 17, 2014, at 2:38 PM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:

 On Thursday 17 of July 2014 13:33:49 Daniel Teske wrote:
 On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
 On Thursday 17 of July 2014 10:51:03 you wrote:
 QVariant::operator== is not symmetric
 
 QDateTime dateTime = QDateTime::currentDateTime();
 
QTime time = dateTime.time();
 
qDebug()  (QVariant(dateTime) == QVariant(time));
qDebug()  (QVariant(time) == QVariant(dateTime));
 
 --
 false
 true
 
 We could make it symmetric, if you want.
 
 A equals operator that is not symetric is broken. Such a class cannot be
 reliably used in std nor qt containers. Or do you know which way around,
 QList::contains uses the equals operation?
 
 The example above shows what happens in case of a missing conversion, in this 
 case QTime can be converted to QDateTime, but the QDateTime can not be 
 converted to the QTime. Fail.

Actually, adding a conversion QTime - QDateTime wouldn’t help, because that 
conversion cannot “invent” the correct missing date information.
So, QVariant(dateTime) == QVariant(time) would still fail, because the date of 
the datetime that is created when converting time-datetime will not be the 
same as the original datetime.
In the presence of lossy conversions, you need to do conversions in both 
directions to make operator== symmetric.

 
 The operator was / is / will be broken. Even if we make it symmetric, it will 
 remain conceptually broken. It should compare QVariants and then (maybe) the 
 wrapped value, while currently it tries a fuzzy comparison of the wrapped 
 value only.  It should look more or less like that:
 
 bool operator ==(const QVariant left, const QVariant right)
 {
   return left.userType() == right.userType()  
 !QMetaType::compare(left.constData(), rigth.constData(), left.userType());
 }
 
 To make it more ridiculous, currently it would not work as QMetType::compare 
 do not know about built-in types :P
 
 There are few ways to fix it, sorted from the smallest impact on a user code 
 base to a-bomb size:
 - Add conversion QDateTime - QTime (Up to now only Olivier agreed with me 
 that it is ok to add a new conversions)
 - If two QVaraints are not equal we can check if swapping left and right 
 sides 
 helps. Inefficient, another behavior change and as odd as the current 
 behavior. 
 Nothing to gain really.
 - Always compare QVariants twice left to right and right to left. Terribly 
 inefficient, more sensible output. Big behavior change as most of comparison 
 would return false.
 - Allow comparisons of the same types or if there is explicitly registered 
 comparisons otherwise return false. Completely different behavior then the 
 current one.
 - Do not allow QVariant comparison, we can not support custom types if they 
 do 
 not register conversion anyway so why bother.
 
 Cheers,
  Jędrek
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Converting types in Qt

[Ziller Eike]

On Jul 17, 2014, at 1:28 PM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:

 On Thursday 17 of July 2014 10:51:03 you wrote:
 QVariant::operator== is not symmetric
 
 QDateTime dateTime = QDateTime::currentDateTime();
QTime time = dateTime.time();
 
qDebug()  (QVariant(dateTime) == QVariant(time));
qDebug()  (QVariant(time) == QVariant(dateTime));
 
 --
 false
 true
 
 We could make it symmetric, if you want. My recommendation is to not use the 
 comparison at all. If you want more features of QVariant you can look into 
 isNull() this is a perfect randomizer :P.


 The whole discussion took wrong 
 direction. I didn't want to discuss QVariant API, which is not fixable, even 
 Qt6 would not help, to much staff depends on it. 

Well, the discussion is still sort of the same (and sort of not). The original 
question was, if we can/should add new type conversions, and/or which kind of 
conversions these could be. I think the investigations here about the API and 
workings of QVariant give some hints on what an answer to that might be.
There is no need to expose the brokenness of the API even more by adding 
conversions that trigger it.

operator== would be less bad if there were only symmetric and lossless 
conversions, so do not introduce any additional lossy or asymmetric conversions.
Also, the uses of QVariant::toString (fromString), that we have found in Qt 
Creator ((de)serialization of QVariantMaps), definitely break if this 
conversion is *not* lossless (or not symmetric).

int - long” kind of conversions might be sort of ok-ish, since the actual 
conversion can still fail if the long doesn’t fit into int, i.e. for values 
that actually fit into both types the conversion is lossless, for values that 
do not fit into both types, the conversion fails in one direction, and is not 
possible to start with in the other direction.
Since this can only be found out during runtime, I’d try to avoid that though, 
and definitely not put that into the extreme.

I would avoid conversions between containers that do not have the exact same 
type. QLinkedListT  =  QVectorT” maybe, “QLinkedListint  =  
QVectorlong” ... no.

Do not add conversions that do not have a “canonical way” to do it, and which 
do not have a corresponding toXXX function without parameters in the 
corresponding types.
The exception to the “canonical way rule *might* be toString/fromString 
conversions, because of its usefulness. There is no canonical way to convert 
bool - string, but it might be useful for things like (de)serialization. (I’m 
not very convinced of toString conversion being very useful in the MVC context, 
actually, except maybe for quick-hack-debugging. For production you should be 
in better control of what you show to your user. I’m only half-convinced about 
its usefulness for (de)serialization.) Taking QString out of the rule has the 
disadvantage that it makes it harder if you actually want to hold string “data” 
in your variant (for which you would want saner conversion rules).

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Converting types in Qt

[Ziller Eike]

On Jul 15, 2014, at 7:36 PM, Olivier Goffart oliv...@woboq.com wrote:

 On Tuesday 15 July 2014 10:38:52 Poenitz Andre wrote:
 Olivier Goffart wrote:
 Jędrzej Nowacki wrote:
  1. Are we allowed to add new conversions?
 
 The question is tricky because adding a new conversion is a
 behavior
 change, as this code:
 if (variant.canConvert(QMetaType::int)) ...
 may work differently. If we add custom types into the mix,
 everything
 
 is even more complex.
 
 I'd say yes, for sensible conversion
 You are right that it is a behaviour change, but i think it is worth
 changing it.
 Why?
 
 On one hand you promise binary compatibility. On the other hand
 behaviour changes are proposed to be done on an nice to have
 base?
 
 Do we really think that's ok to disallow changing some int foo() { return
 42; } to some int bar() { return 42; } that's easy to discover at build
 time, but it's fine to change int foo() { return 42; } to int foo() {
 return -1; } ?
 
 It's always a dilemma. We have to look at how likely we are to break 
 applications and I don't think adding a conversion is likely to cause 
 breakages.
 
 so Qt can know it and use it. For certain types we can do much better,
 
 because we can automatically convert some types. For example:
 QVectorchar - QLinkedListint
 
 QVectorchar v; v.append(130);
 QLinkedListint l = /*someSensibleAutomatedConversion*/(v);
 
 assert(l.first() == 130) ?  Depends ?
 
 QVariant(char(130)).toInt() already exists. You may argue that it is not 
 sensible but that's another issue.
 I guess the example is more between QVectorT1 - QLinkedListT2 when there 
 exist a conversion from T1 to T2
 
 A conversion may be arbitrary. For example, most of the
 conversions
 
 to QString. Should bool(false) - QString return False, 0,
 false?
 What about precision of, for example, double - QString ?
 
 We use common sense on a case by case basic.
 
 I tend to believe the common sense in type conversion land is pretty
 close to avoid to do it automatically, prefer to make it explicit.
 
 Already now it's far too easy to make mistakes based on the nice
 and easy QByteArray - QVariant - QString conversions when
 accidentally writing QByteArrays into QSettings and reading QStrings
 back. There shouldn't be more of that.
 
 What's the mistake here? Wrong encoding? Bad performances?

wrong values  unexpected results

 When one use QVariant, it is because we want to enjoy dynamic typing and nice 
 conversions.

I don’t think we have a single place in Qt Creator where we want automatic 
conversions when using QVariant. A search for QVariant(Map) returns 5400 hits.
In the map case, we usually expect the one retrieving the value for a key to 
know the exact type of what was thrown in (that’s usually the same class, or 
related classes), and then we use item models and QSettings which we use in the 
same way.

Even if automatic conversion might be interesting (when, actually?), then the 
point is:

There is no API in QVariant to support the common use case of getting the value 
*without* automatic conversion.

 We use common sense on a case by case basic.


Either there is no “common sense” common to me, or this rule has failed in the 
past already ;)

bool - string ?
bytearray - int/long/double ?
keysequence - int ?
string - bool ?
string - bytearray ?
string - int ?

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] Converting types in Qt

[Ziller Eike]

On Jul 16, 2014, at 11:28 AM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:

 On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
 [...]
 When one use QVariant, it is because we want to enjoy dynamic typing and
 nice  conversions.
 
 
 I don’t think we have a single place in Qt Creator where we want automatic
 conversions when using QVariant. A search for QVariant(Map) returns 5400
 hits. In the map case, we usually expect the one retrieving the value for
 a key to know the exact type of what was thrown in (that’s usually the same
 class, or related classes), and then we use item models and QSettings which
 we use in the same way. 
 Even if automatic conversion might be interesting (when, actually?), then
 the point is:
 
 There is no API in QVariant to support the common use case of getting the
 value *without* automatic conversion.
 
 Nobody asked for it, It should be easy to implement something equal to this;
 
 Q_ASSUME(variant.userType() == qMetaTypeTargetType()); 
 TargetType data = variant.valueTargetType();
 
 I believe such new api make sense, we can add it.
 
 
 We use common sense on a case by case basic.
 
 
 
 Either there is no “common sense” common to me, or this rule has failed in
 the past already ;)
 
 bool - string ?
 bytearray - int/long/double ?
 keysequence - int ?
 string - bool ?
 string - bytearray ?
 string - int ?
 
 Br, Eike
 
 What is wrong with string - int or bytearray - int?

First of all I wondered what bytearray - int does at all. Convert the first 
byte in the byte array to an int, if bytearray.size() == 1 (which would be 
consistent with QStringList-QString)?
bytearrays are not strings after all…

Otherwise bytearray/string - int has similar problems as string - bool and 
string - bytearray:
There is no canonical “right” way to do it, and it can fail depending on the 
actual *value*. Does QVariant::canConvert actually take that into account? Is 
there any other possibility to find out if it went wrong? Does it interpret 
0xa1 ? Will 076 be interpreted as octal or decimal?
Does it convert “ퟷ” (U+1D7F7) to 1 ? ;)
All in all it creates more questions than it solves problems.

There are no QKeySequence::toInt(), QString::toBool(), QString::toByteArray() 
functions btw, and QString/QByteArray::toInt(…) take arguments. I think one 
prerequisite for possible conversions (automatic or not) should be, that a 
corresponding ::to… function without any arguments in the corresponding type 
would survive an API review, and actually is added as well. Then one also has a 
place to look for documentation how the actual conversion is done.

Br, Eike

 -- 
 Eike Ziller, Senior Software Engineer - Digia, Qt
 Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
 Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
 Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg,
 HRB 144331 B 
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] Converting types in Qt

[Ziller Eike]

On Jul 16, 2014, at 11:58 AM, Konrad Rosenbaum kon...@silmor.de wrote:

 On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote:
 Olivier Goffart wrote:
 It's always a dilemma. We have to look at how likely we are to break
 applications and I don't think adding a conversion is likely to cause
 breakages.
 
 Type safety is a safety net that catches errors very early in the
 software production and deployment cycle, and one of the features
 that makes a programming language usable for the development
 of large applications at a reasonable pace.
 
 I feel I need to clear up some misconceptions here: the kind of type safety 
 offered by C++ is a possibility, but not a necessity for fast and safe 
 development of large applications. I've done Smalltalk for quite some time - 
 it does not have a static type system like C++ and development is still 
 faster than in most C++ based environments - I'd even go as far as saying it 
 is slightly faster to develop with Smalltalk than it is to develop with Qt 
 (I still prefer Qt for its more modern API). The key is usually great 
 documentation, good tooling, good APIs and fast turn-around from adding a 
 few lines to seeing them in action (in the last point C++ can't even hope to 
 compete with Smalltalk, the other three are quite good with Qt).
 
 Implicit type conversions kill type safety. This is widely recognized
 as a bad thing. In case of C++ some are unavoidable due to the
 C legacy, but e.g. for user-defined conversion operators we now got
 explicit, _because_ people learned the hard way that implicit
 conversions are causing more trouble than wanted.
 
 Let's not mix up too much here: type conversions are necessitated by the 
 fact that C++ has static typing - otherwise you would not get much done with 
 it - from the Smalltalk point of view C++ is not polymorphic. Implicit type 
 conversions are necessitated by the fact that programmers (like me) are lazy 
 bastards and don't like to read lines which are longer than a couple of 
 words.
 
 The explicit keyword is just a way of telling the compiler that a 
 constructor is NOT a type conversion - however, I'm not entirely sure 
 whether it was such a brilliant idea to have two kinds of implicit user 
 defined conversion (constructors and type operators). 
 
 So, just get used to the idea of prefixing each constructor with an 
 explicit and only consider removing it again afterwards.
 
 This is a kind of convenience I don't need, and I pretty much prefer
 the inconvenience of having to spell out type conversions explicitly.
 
 Reminds me of the early days of Java - almost every cast was explicit and 
 you wrote endless lines of casts just to get a very simple resource.
 
 Thanks, but no thanks.
 
 In short: you need a certain amount of convenience to not hinder the 
 programmer. Too much magic in the background and it is just as bad. The 
 difficulty seems to be to define the ideal point between convenience and 
 shooting yourself into the foot all the time.
 
 As long as QVariant mirrors the abilities of C++ (i.e. only using implicit 
 conversions that are also available in plain C++, plus maybe a few very 
 obvious ones, like toString) we are fine. More and we'll get weird bug 
 reports, less and programmers will constantly bitch about it.
 
 BTW: you can already implicitly cast QByteArray-QString, so why not allow 
 it through QVariant?

This can be considered an API fail, which is why you can explicitly turn off 
these type of conversions for your applications by defining QT_NO_CAST_TO_ASCII 
QT_NO_CAST_FROM_ASCII (which we e.g. do for Qt Creator).

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] Converting types in Qt

[Ziller Eike]

On Jul 16, 2014, at 1:30 PM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:

 On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
 I don’t think we have a single place in Qt Creator where we want automatic
 conversions when using QVariant. A search for QVariant(Map) returns 5400
 hits. In the map case, we usually expect the one retrieving the value for a
 key to know the exact type of what was thrown in (that’s usually the same
 class, or related classes), and then we use item models and QSettings which
 we use in the same way.
 
 From performance point of view it is good to avoid any conversions. I would 
 say even more, if you know all types in your application there is no point in 
 using QVariant. Sometimes it is not possible, and sometimes one just don't 
 want be bothered. 
 
 I made an extremely unfair experiment.  I switched off all conversions in Qt 
 and I recompiled QtCreator. To be honest I expected that it would crash at 
 startup, but no (impressive!). I was able to use menu and open dialogs, 
 nothing more. From the stderr I could deduct that a QVariant conversion was 
 used in reading xml, qws files and in animations.

True, we use QVariant::toString for an easy way to write the value of the 
key-value pairs of basic types in qtversions.xml, profiles.xml, .pro.user, and 
the sessions (.qws)
Even there we keep the type information though, and use that to explicitly 
convert the variants in the map back to the right type when reading the file, 
so type conversion should never be outside the reader/writer in that case. What 
the conversion saves us, is a few case statements in the reader/writer.

  data
  variableQtVersion.0/variable
  valuemap type=QVariantMap
   value type=int key=Id10/value
   value type=QString key=NameQt 5.3/value
   value type=QString 
key=QMakePath/Users/Shared/qt/qt/5.3/64/qtbase/bin/qmake/value
   value type=QString 
key=QtVersion.TypeQt4ProjectManager.QtVersion.Desktop/value
   value type=bool key=isAutodetectedfalse/value
  /valuemap
 /data

No idea what happens in animations, but I’d suppose that any conversions there 
would be accidentally.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1

[Ziller Eike]

On Jul 16, 2014, at 4:03 PM, Sze Howe Koh szehowe@gmail.com wrote:

 On 7 July 2014 19:11, Frederik Gladhorn frederik.gladh...@digia.com wrote:
 Mandag 7. juli 2014 10.02.55 skrev Ziller Eike:
 On Jul 7, 2014, at 11:17 AM, Frederik Gladhorn frederik.gladh...@digia.com
 wrote:
 Mandag 7. juli 2014 07.10.00 skrev Koehne Kai:
 
 No. When running an installer (online or offline), Qt Creator is a
 compulsory component (although Qt itself is non-compulsory). I remember
 someone saying that Qt Creator is made compulsory because of
 interdependencies between the Maintenance Tool and Qt Creator.
 
 What are these dependencies? I'm willing to have a go at reducing this
 coupling, if I know where to look. I believe one of them is for the
 installer to register auto-detected kits. Instead of having the
 installer perform this registration, would it make sense for it to
 simply
 add a search path to a global Qt Creator config file, and let Qt
 Creator search for and register new copies of Qt at startup?
 
 Registration of Qt versions, kits, and toolchains is indeed the primary
 problem. We call Qt Creator's sdktool.exe in the
 installation/deinstallation scripts of the Qt versions  the mingw
 toolchains .
 
 I'm not sure doing too much (file system) magic on Qt Creator startup
 though is the right thing to do, since it will slow down every launch.
 
 Alternatives that have been discussed in the past:
 
 1. Move the sdktool.exe out of the Qt Creator package, into a separate
 one,
 and only make this one mandatory. That means though we'd need to ship
 separate Qt libraries for this tool only, effectively increasing the size
 of a 'default' installation.
 
 2. Don't deregister/register toolchains and kits in the qt packages, but
 in
 separate virtual (i.e., hidden) packages that are only installed if both
 the resp. Qt version package and the Qt Creator package gets installed
 (AutoDependOn in IFW speak). This will only be a workaround though for
 new
 packages ... already released qt versions will still have a hard
 dependency
 on Qt Creator.
 
 3. Accept the fact that, if people first install a Qt version / toolchain
 and _later on_ install Qt Creator, the toolchain  Qt version won't show
 up.
 
 4. I still think on Windows using the registry would be the way around
 this. On Linux and Mac the respective .config dirs. Python for examples
 does this on installation on Windows and can then be found by looking it
 up in the registry.
 This solution is imho portable and allows all Qt versions to be found by
 all Creator instances as well as other tools (qtchooser would be a good
 candidate to make use of the same mechanism).
 
 Since there are no “system wide” config dirs that would mean using something
 like /etc (/opt ? /usr/local?) on Linux, /Library/Preferences on Mac, and
 “current_machine” registry on Windows for “system wide” installations, and
 “.config” on Unix and “current_user” registry on Windows for “user”
 installations.
 
 Qt should offer a good enough settings API for this. That said, I guess it's
 currently not the case and we should polish/rewrite/replace/extend QSettings
 to make it work.
 
 Not quite system-wide, but Qt Creator already uses a profile-wide
 config dir, no? I was under the impression that
 %APPDATA%/Roaming/QtProject was the place where all Qt Creator
 instances store their settings (on Windows).

That’s per user, so it cannot be used for an installer that installs for all 
users.


 That would make things much more complicated, and possibly force that
 information to be compatible between versions of Qt Creator (it’s btw not
 only about Qt versions here, also all the other things that are specified
 for kits).
 
 This is a valid point. I wonder if it wouldn't be possible to use XML/JSON in
 a way that it's extensible enough. Worst case the settings need a migration
 path to newer versions - many tools do that - let you upgrade but now
 downgrade. Should you then want to downgrade to older Qt Creator versions you
 may have to re-configure the kits.
 
 I think that's a reasonable compromise. I don't imagine that
 downgrading Qt Creator would be a frequent activity, especially after
 it becomes a deselectable component of Qt installers.

Especially if Qt Creator can be deselected, and all Qt Creator installs read 
the same configuration for the Qt versions, it becomes vital that installing a 
newer Qt does not make the global Qt Creator configuration unreadable by older 
Qt Creator versions. Assume I have a Qt Creator install that I use and that 
works, now I want to try some newer or other Qt, and install that without 
upgrading my Qt Creator (why should I). That’s exactly my point.

 Also, I currently have 5 offline Qt installers installed simultaneously for
 testing. Using a “machine/user wide” registration mechanism, instead of an
 “installation wide” registration mechanism would basically disallow that.
 
 I think we (those developping Qt and Creator etc.) are still the minority

Re: [Development] Converting types in Qt

[Ziller Eike]

On Jul 16, 2014, at 5:04 PM, Thiago Macieira thiago.macie...@intel.com wrote:

 On Wednesday 16 July 2014 15:01:53 Ziller Eike wrote:
 No idea what happens in animations, but I’d suppose that any conversions
 there would be accidentally.
 
 QPropertyAnimation is based on modifying QVariants, isn't it?

True, but I’d claim that that shouldn’t need automatic conversions between 
types.
If I create a QPropertyAnimation on a “qreal” property, and set “qreal” start 
and end values, then there should not happen any automatic conversions.
If I’d set end value “10.0” (i.e. QString), then I’d consider that very bad 
style. Maybe we have some int/real conversions happening there, which could at 
least argued to not do much harm.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] [Qt-creator] Qt Creator Doesn't Show Error(s)

[Ziller Eike]

On Jul 14, 2014, at 1:46 PM, steveg2...@gmail.com wrote:

 This is from the Application Output widow

Have a look at your run configuration in projects mode then, because it looks 
like you are running mingw32-make.exe when pressing “run” in Qt Creator, 
instead of your application.
(http://qt-project.org/doc/qtcreator-3.1/creator-run-settings.html)

Br, Eike

  
  
 -- Original message--
 From: Sze Howe Koh
 Date: Mon, Jul 14, 2014 6:45 AM
 To: Steve Gold;inter...@qt-project.org;
 Cc: Qt Creator Group;Qt Development Group;
 Subject:Re: [Development] Qt Creator Doesn't Show Error(s)
  
 Hi,
 
 On 14 July 2014 05:15, Steve Gold 
  wrote:
  I am building an app on Windows 8 64bit with Qt 5.3.1 and Qt Creator 3.1.2.
  I have a main.cpp that calls main.qml that calls Tests.qml that uses other
  QML and JavaScript files. I have
 
  Component.onCompleted: {
console.log(“Starting Testsl”);
. . .
  }
 
  and other statements in Tests.qml. The app builds and the runs but all that
  is shown is a very small window and there is NO output. “Starting Tests” is
  not displayed. I get the message
 
  The process C:\Qt\Qt5.3.1\Tools\mingw482_32\bin\mingw32-make.exe
  exited normally.
 
 Sounds like you're looking at the Compile Output pane. Switch to the
 Application Output pane instead.
 
 
 Regards,
 Sze-Howe
 
 P.S. This kind of question (How do I use X?) is more suited for the
 Interest mailing list. The Development and Qt Creator lists are for
 discussing the implementation of Qt and Qt Creator respectively.
 
 
 ___
 Qt-creator mailing list
 qt-crea...@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Support for your evaluation of Qt

[Ziller Eike]

On Jul 11, 2014, at 6:21 AM, Christian Gagneraud chg...@gna.org wrote:

 On 11/07/2014 11:22 a.m., Thiago Macieira wrote:
 On Friday 11 July 2014 10:05:03 Christian Gagneraud wrote:
 Boot To Qt for Embedded Linux (Not talking about android here), is based
 on Yocto (which is open-source), there exists a Qt5 layer (Dedicated
 Yocto sub-project), and I think that Digia should be the official
 maintainer of this project. Digia could work hand and hand with Silicon
 Company like Intel, Texas Instrument, Freescale, Xilinx (these companies
 maintain their own SoC specific Yocto layers). Everyone would win if the
 Qt5 Layer was in a good shape and tested on platform based on the
 above-mentioned SoC's manufacturers.
 Today, these SoC manufacturers provide SDKs (Linux kernel + cross
 toolchain + demo image) and few provide a SDK that contains Qt5. I think
 it is Digia's role to help spread the Qt technology on embedded Linux.
 
 Participating in Yocto by maintaining the Qt5 layer and working on Boot to Qt
 are orthogonal to each other.
 
 Digia could do both if it wanted to.
 
 Well at least before they started Boot to Qt w/ Android, working on 
 boot to Qt implied polishing the Yocto Qt5 layer or writing another one 
 from scratch. They obviously did some work on that and it's a pity that 
 nothing have been given back to the community. That was my point.
 
 Or someone else could do the maintaining of the Qt 5 layer in Yocto. I don't
 see the problem with that either: the Qt Project has a lot of people from
 different companies collaborating together. We don't depend on Digia doing
 everything.
 
 No, Qt doesn't depend on Digia, but Digia depends on Qt!
 When you look at their Qt Enterprise Embedded, it's Qt, QtCreator, 
 QtSimulator, GNU, Linux, Android,  with a pinch of Enterprise 
 plug-in's and add-on's all well packed together.

You should have a look at commit reality in Qt: 
http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png
and Qt Creator: 
http://www.macieira.org/~thiago/qt-stats/current/creator.employer.relative.png

Br, Eike

 
 Besides, IIRC the Boot to Qt project was trying to use the Android base layer
 because that's the best BSP that most silicon vendors provide. Notably, the
 vendors not participating in Yocto.
 
 They might have switched to Android (Well, apparently not really [1], 
 Yocto is used both for targeting Android and Pure Embedded Linux), but 
 AFAIK you can boot to Qt in less than 0.5s with a bare embedded Linux 
 (using Yocto or similar), whereas it takes 10 times longer with Android.
 
 Having said all these, Digia has its own business model, maybe I was 
 expecting Digia to behave much like Nokia, my mistake.
 
 Chris
 
 [1] 
 http://linuxgizmos.com/qt-embedded-gui-adds-yocto-recipes-hops-up-emulator/
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1

[Ziller Eike]

On Jul 6, 2014, at 3:52 AM, Sze Howe Koh szehowe@gmail.com wrote:

 On 4 July 2014 00:14, Thiago Macieira thiago.macie...@intel.com wrote:
 On Thursday 03 July 2014 10:35:30 Koehne Kai wrote:
 Right, the files are still there. But to allow parallel installation (which
 is probably what you want if you e.g. are after regression testing) we'd
 need to repackage the old Qt 5.3.0 binaries , giving it a new installation
 path, changing Qt Creator kit / Qt version id's , names ...
 
 It's certainly possible, but I'm not sure whether it's really worth it,
 given that we still have offline installers.
 
 I can understand the benefits of the new approach. As the new releases
 come, the number of options in the installer would keep increasing so
 the new approach keeps that in check.
 
 Unfortunately there are downsides too:
 
 1) Developers who face regressions (not just testers) are now in an
 awkward position, and need to install an extra copy of Qt Creator (see
 below)
 
 2) In Qt Creator, the Qt version and kit are still listed as Qt
 5.3.0, even though it has been upgraded to Qt 5.3.1. Since it is an
 auto-detected entry, the user cannot change the name.

Hi,
Since it is an auto-detected entry, the user cannot change the name.” is 
actually wrong (you _can_ change the name), and that is actually the reason why 
the bug Qt version and kit are still listed as “Qt 5.3.0”” exists ;)

Br, Eike

 Is it possible to use the offline installer to install 5.3.0 into the 
 existing
 installation and not install a new Qt Creator?
 
 No. When running an installer (online or offline), Qt Creator is a
 compulsory component (although Qt itself is non-compulsory). I
 remember someone saying that Qt Creator is made compulsory because of
 interdependencies between the Maintenance Tool and Qt Creator.
 
 What are these dependencies? I'm willing to have a go at reducing this
 coupling, if I know where to look. I believe one of them is for the
 installer to register auto-detected kits. Instead of having the
 installer perform this registration, would it make sense for it to
 simply add a search path to a global Qt Creator config file, and let
 Qt Creator search for and register new copies of Qt at startup?
 
 
 Regards,
 Sze-Howe
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1

[Ziller Eike]

On Jul 7, 2014, at 11:17 AM, Frederik Gladhorn frederik.gladh...@digia.com 
wrote:

 Mandag 7. juli 2014 07.10.00 skrev Koehne Kai:
 -Original Message-
 From: development-bounces+kai.koehne=digia@qt-project.org
 [...]
 1) Developers who face regressions (not just testers) are now in an
 awkward
 position, and need to install an extra copy of Qt Creator (see
 below)
 
 Right, that's the main drawback. We could maybe have a 'Show all' section in
 the settings dialog or so that would show/hide such patch level releases
 though ... will bring this up with the Release Team.
 2) In Qt Creator, the Qt version and kit are still listed as Qt 5.3.0,
 even though it has been upgraded to Qt 5.3.1. Since it is an
 auto-detected entry, the user cannot change the name.
 
 Yeah, that's something we should fix in the next Qt Creator release.
 
 Is it possible to use the offline installer to install 5.3.0 into the
 existing installation and not install a new Qt Creator?
 
 No. When running an installer (online or offline), Qt Creator is a
 compulsory component (although Qt itself is non-compulsory). I remember
 someone saying that Qt Creator is made compulsory because of
 interdependencies between the Maintenance Tool and Qt Creator.
 
 What are these dependencies? I'm willing to have a go at reducing this
 coupling, if I know where to look. I believe one of them is for the
 installer to register auto-detected kits. Instead of having the
 installer perform this registration, would it make sense for it to simply
 add a search path to a global Qt Creator config file, and let Qt
 Creator search for and register new copies of Qt at startup?
 
 Registration of Qt versions, kits, and toolchains is indeed the primary
 problem. We call Qt Creator's sdktool.exe in the
 installation/deinstallation scripts of the Qt versions  the mingw
 toolchains .
 
 I'm not sure doing too much (file system) magic on Qt Creator startup
 though is the right thing to do, since it will slow down every launch.
 
 Alternatives that have been discussed in the past:
 
 1. Move the sdktool.exe out of the Qt Creator package, into a separate one,
 and only make this one mandatory. That means though we'd need to ship
 separate Qt libraries for this tool only, effectively increasing the size
 of a 'default' installation.
 
 2. Don't deregister/register toolchains and kits in the qt packages, but in
 separate virtual (i.e., hidden) packages that are only installed if both
 the resp. Qt version package and the Qt Creator package gets installed
 (AutoDependOn in IFW speak). This will only be a workaround though for new
 packages ... already released qt versions will still have a hard dependency
 on Qt Creator.
 
 3. Accept the fact that, if people first install a Qt version / toolchain
 and _later on_ install Qt Creator, the toolchain  Qt version won't show
 up.
 
 
 4. I still think on Windows using the registry would be the way around this. 
 On Linux and Mac the respective .config dirs. Python for examples does this 
 on 
 installation on Windows and can then be found by looking it up in the 
 registry.
 This solution is imho portable and allows all Qt versions to be found by all 
 Creator instances as well as other tools (qtchooser would be a good candidate 
 to make use of the same mechanism).

Since there are no “system wide” config dirs that would mean using something 
like /etc (/opt ? /usr/local?) on Linux, /Library/Preferences on Mac, and 
“current_machine” registry on Windows for “system wide” installations, and 
“.config” on Unix and “current_user” registry on Windows for “user” 
installations.

That would make things much more complicated, and possibly force that 
information to be compatible between versions of Qt Creator (it’s btw not only 
about Qt versions here, also all the other things that are specified for kits).

Also, I currently have 5 offline Qt installers installed simultaneously for 
testing. Using a “machine/user wide” registration mechanism, instead of an 
“installation wide” registration mechanism would basically disallow that.

Br, Eike

 
 I think both 1. and 2. are be feasible ... 3. might end up in more bug
 reports / annoyed users than the current 'forced' installation, so I'm
 personally not keen to implement this.
 
 
 Regards
 
 Kai
 ___
 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

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org

Re: [Development] Make WebKit an add-on

[Ziller Eike]

On Jun 20, 2014, at 8:53 AM, Rutledge Shawn shawn.rutle...@digia.com wrote:

 
 On 20 Jun 2014, at 08:32, Knoll Lars lars.kn...@digia.com wrote:
 
 Hi,
 
 Currently Qt WebKit and Qt WebKit Widgets are marked in our documentation
 as Qt Essentials. I’d like to propose to move them to the add-on category
 for 5.4.
 
 There are several reasons for that, the main ones being:
 
 * Qt WebKit is not supported on Android, iOS and WinRT
 * We can’t develop it much further (esp we can't update with newer
 versions of webkit), as the webkit project has moved into a different
 direction
 * Qt WebEngine is going to replace it over time
 
 Unless someone has a very good reason against changing this, I’d like to
 change the status of the 2 modules in time before the 5.4 branch is being
 created.
 
 Will all of our own usage of WebKit (such as in Assistant and Creator) be 
 replaced with WebEngine in time for 5.4?

I don’t know when it will be possible to actually create a WebEngine backend 
for the help viewer in Qt Creator, but I did some work in Qt Creator 3.2 to 
make that technically easy (we already had an additional “QTextBrowser” based 
backend before, but it was a ifdef mess).

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B 

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

Re: [Development] New class for QtWidgets: ColumnResizer

[Ziller Eike]

On Jun 12, 2014, at 6:51 PM, Oswald Buddenhagen oswald.buddenha...@digia.com 
wrote:

 On Thu, Jun 12, 2014 at 04:08:17PM +0200, Aurélien Gâteau wrote:
 Olivier Goffart wrote:
 But just wondering if it would not be better to have that as an API within
 QGridLayout such as
  QGridLayout::setAlignedWith(QGridLayout*)
 
 The class works with QFormLayout as well, so I don't think moving the 
 feature into QGridLayout would be a good idea.
 
 they have a common base class, you know ...
 
  QLayout::linkDimension(QLayout *other, Qt::Orientation orientation = 
 Qt::Horizontal)
 
 (the second parameter is actually a flag field).
 
 and for more fine-grained control one could consider (not sure this makes
 sense):
 
  QLayoutItem::linkDimension(QLayoutItem *other, Qt::Orientation orientation = 
 Qt::Horizontal)
 
 but then, i wonder whether you are fixing the right problem to start
 with. usually, one would create a big master layout, and embed
 sublayouts spanning multiple cells in the areas that are not supposed to
 be contrained by the grid.

In principle I like the idea of being able to work with a “master” grid. That’s 
something I wished e.g. for Qt Creator’s preferences dialog, where we use group 
boxes to group options, and these contain either something like what form 
layout does, or lists of checkboxes etc, or a mix.
Currently it is basically impossible to align the content in the vertically 
layouted group boxes.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Bringing Qt's high-dpi support to more platforms

[Ziller Eike]

On May 23, 2014, at 6:03 PM, m...@rpzdesign.com wrote:

 Sorvig:
 
 From the latest new front:
 
 http://bgr.com/2014/03/18/nexus-9-specs-details/
 
 Digitimes on Tuesday cited its own research arm in reporting that Google
 will launch two new Nexus tablets in 2014. In addition to an updated
 Nexus 7, Google is reportedly prepping a new 8.9-inch Nexus tablet that
 will feature a Retina-busting screen with better-than-2K resolution.
 
 So will your HIGH DPI modification support the coming high res Android
 stuff too?

The retina support that currently is in Qt/Mac (which would be extended to the 
other platforms) supports any float scale factor for HiDPI.

 Cheers,
 
 md
 
 
 On 5/23/2014 3:20 AM, Sorvig Morten wrote:
 Over the past year-and-a-half we’ve implemented high-dpi scaling for Qt on 
 Mac OS  X and iOS. Now we have an excellent opportunity to bring this 
 support to other platforms.
 
 A quick recap for those unfamiliar: This high-dpi mode is an alternative to 
 the traditional DPI scaling. In the traditional approach the application is 
 presented with an DPI value used to multiply font sizes, layouts etc. In the 
 new mode the operating system provides Qt with a scale factor which is used 
 to scale graphics output: allocate larger buffers and set a scaling 
 transform.
 
 The advantage of this approach is that that vector graphics and fonts scale 
 automatically and existing applications tend to work unmodified. Raster 
 content handling is a neutral point - the app author needs to provide 
 high-resolution artwork but this is manageable. A typical disadvantage is 
 confusion caused by the existence of two coordinate systems: “Are these 
 style hints in device independent or device pixels? 
 
 Looking at other platforms:
 
 - WinRT: Already uses high-dpi scaling as of change aeea02ff10 .
 
 - Wayland: Version 1.2 added wl_output::scale, which we can use. This change 
 implements high-dpi scaling for the backing store:
 
 https:/codereview.qt-project.org/#change,63600
 
 -  Platform independent support: We can bring high-dpi support to any 
 platform by adding a coordinate translation layer to QWindow and 
 QWindowSystemInterface and making minor modifications to the platform 
 plugins.  See the following changes:
 
 https://codereview.qt-project.org/#change,86107
 https://codereview.qt-project.org/#change,86108
 
 Some preliminary testing has been done with the XCB platform plugin:
 * KDE Frameworks 5: http://imgur.com/a/JhXSX#sUGYZmB
 * Qt Creator: http://i.imgur.com/EEwdPTD.png
 
 This also allows testing any scale factor on any hardware by setting an 
 environment variable.
 
 
 Adding support to QtWayland looks like a win to me. Do we want to add 
 platform-indepent support to Qt?

Yes! :)

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Ziller Eike]

On Apr 28, 2014, at 8:12 PM, Alan Alpert 4163654...@gmail.com wrote:

 On Mon, Apr 28, 2014 at 7:36 AM, Sze Howe Koh szehowe@gmail.com wrote:
 On 25 April 2014 18:18, Joerg Bornemann joerg.bornem...@digia.com wrote:
 On 25-Apr-14 04:21, Sze Howe Koh wrote:
 
 I consider QML and JavaScript to be different languages. JavaScript
 can be embedded into QML to extend QML's capabilities, just like how
 it can be embedded into HTML to extend HTML's capabilities.
 
 
 Yep, I hear people keep repeating the mantra QML is declarative. It's just
 QML/JS that isn't. Does that buy us anything tooling-wise? No. Because,
 even though this thought is true in essence, in practice you have to use the
 JS part.
  People throw handwritten QML files full of clever hacks at Qt Creator's
 QmlDesigner and wonder why it doesn't fully understand the magic, even
 though everything is deemed declarative (== toolable).
 
 To check if I've understood you correctly: You've found that
 classifying QML as declarative distorts developers' expectations of
 the tools?
 
 Do you think it will help if we rebrand QML as a markup language or
 a multi-paradigm language, instead of a declarative language?
 
 One of the original meanings of QML was Qt Markup Language. But markup
 implies less interactivity, and multi-paradigm implies that you need
 to read several more paragraphs to understand what it is. So while
 declarative is not strictly accurate, I feel it captures the spirit
 better (for humans, not tools. Tools should treat it as markup, and if
 there are any tools reading this I'm sorry to confuse you ;) ).
 
 Some user interface markup languages (e.g. XAML, MXML, HTML) allow
 imperative code to be embedded within declarative code.
 
 
 On 26 April 2014 23:39, André Pönitz apoen...@t-online.de wrote:
 On Fri, Apr 25, 2014 at 10:21:04AM +0800, Sze Howe Koh wrote:
 On 24 April 2014 00:35, André Pönitz apoen...@t-online.de wrote:
 On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
 QML is a declarative language
 
 Are you considering sequences of JavaScript statements, especially control
 flow statements, as declarative?
 
 Andre'
 
 Of course not. :-)
 
 Right. With the obvious consequence for .qml files containing such.
 
 Within a .qml file, JavaScript is in no way an optional extension of some
 declarative QML language. QML and JavaScript are _inseparably_ tied
 together in the QML/JS hybrid contents of a .qml file.
 
 A quick grep in qtdeclarative/examples/quick/demos e.g. finds the pattern
 'if (' in 30 out of 88 .qml files. All nine examples are affected. And
 that's not just an accident, as pure declarative QML features like
 ScriptAction, or on{Triggered,Clicked,Loaded,...} handlers _require_
 immediate use of JavaScript.
 
 To clarify, I do agree with you that QML is extremely limited without
 JavaScript for its intended role in Qt Quick.
 
 It's just that the two of us had applied the label QML to different
 parts of the language framework. This is addressed at the bottom of
 this email.
 
 
 I was highlighting the fact that their declarative
 structures make QML or HTML+CSS good for describing a GUI's looks.
 This is in contrast to imperative languages like C++ or JavaScript or
 PHP -- I don't want to use any of these to describe a GUI's looks.
 
 Not wanting to use imperative languages like [...] JavaScript [...] to
 describe a GUI's look is fine with me, but how on earth is that an
 argument _in favour_ of .qml?
 
 You could have made the point declarative structures are good for GUI
 description for Qt Widget's .ui files, after all, .ui files contents
 pretty much _is_ declaring layout nesting and property values.
 
 That was not my argument.
 
 My original comment about declarativeness was in response to the
 apples-to-oranges comparison between UnrealScript and QML. [1] Marius'
 point was (I believe), Epic Games dropped UnrealScript for C++,
 therefore we too should stay with C++ instead of moving to QML. I was
 trying to say that they aren't comparable because UnrealScript is for
 scripting games while QML is for crafting GUIs. I used QML's
 declarative nature to justify my position that it is a GUI-crafting
 language.
 
 My actual argument in favour for QML was that it lets us express our
 intent much more concisely than other languages. This argument was
 made while we were on the topic of UI development efficiency, with
 Android XML+Java and the Qt Graphics View Framework as the reference
 points. [1, 2]
 
 Note also, I contended that Qt Quick can now fully replace the
 Graphics View Framework, but is not yet ready to fully replace widgets
 [2].
 
 Graphics View wasn't really made for UIs, and for it's intended use
 (multi-view MDI CAD programs?) it's still better than QtQuick. Which
 was made for UIs, so can replace Graphics View there.
 
 It's the QtQuick Controls module which should fully replace widgets.
 But I agree it's not yet ready (and anyone who complains that they'll
 still need their C++ widgets 

Re: [Development] Project ERROR: Could not resolve platform name for SDK 'macosx10.8'

[Ziller Eike]

On Apr 7, 2014, at 12:26 PM, Amit Biran am...@waves.com wrote:

 Hello,
 
 I'm trying to build on MacOS any of the Example Qt projects.
 
 OSX: 
10.8.5 (Mountain Lion)
 Qt Creator Info: 
Based on Qt 5.2.1 (Clang 5.0 (Apple), 64 bit)
Built on Jan 31 2014 at 06:00:56
 Xcode Info: 
Version 4.6.3 
 
 I am getting the following error:
Project ERROR: Could not resolve platform name for SDK ‘macosx10.8'

Last time I had that, it was because I had broken my perl setup (didn’t find 
XML extensions anymore).
You might want to try if https://codereview.qt-project.org/82393 helps you 
(which avoids perl in the first place).

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] [Announce] Qt Creator 3.1 RC1 released

[Ziller Eike]

On Apr 4, 2014, at 10:51 AM, Tomasz Siekierda sierd...@gmail.com wrote:

 On 3 April 2014 10:47, List for announcements regarding Qt releases
 and development annou...@qt-project.org wrote:
 We are happy to announce the Qt Creator 3.1 RC1 release
 
 Blog: http://blog.qt.digia.com/blog/2014/04/03/qt-creator-3-1-rc1-released/
 Download: 
 http://download.qt-project.org/development_releases/qtcreator/3.1/3.1.0-rc1/
 
 --
 Eike Ziller, Senior Software Engineer - Digia, Qt
 
 Thanks :)
 
 BRW: Source tarballs are missing. See
 https://qt-project.org/forums/viewthread/40915/

ups. fixed. 

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Branches and time based releases

[Ziller Eike]

On Feb 25, 2014, at 6:40 PM, Thiago Macieira thiago.macie...@intel.com wrote:

 Em ter 25 fev 2014, às 11:33:00, Oswald Buddenhagen escreveu:
 I.e., nothing changes. I propose this branch stay named dev, for clarity
 of purpose, not master.
 
 i don't think the clarity buys us much. like the rest of the branch
 naming stuff, it is really a minor detail for the average contributor.
 otoh, the deviation from the default leads to *every* project so far
 having to rename their master branch upon promotion to being an official
 part of qt.
 
 They should instead start with a branch called dev. That means there's no 
 renaming necessary later on.
 
 It equally solves the problem.
 
 I still feel we're solving the wrong problem. Or, we can say we're
 working around the problem because really solving it is not within our
 means right now.
 
 even if we could optimize CI to the point where a forward-merge would
 reliably go through in half an hour (which i think is a realistic target
 when we actually concentrate on that, but we likely won't get there
 within the next months), we still have a) that half-hour lockdown which
 is weird in itself and b) the administrative overhead of implementing
 the lockdown (fiddling with gerrit permissions).
 so even in the optimal case, branching would be *still* cleaner than
 downmerging.
 
 If it passes reliably within half an hour, no lockdown is necessary. The 
 lockdown is only necessary today so the people doing the merging don't have 
 to 
 tear their hair out to keep track of two moving targets.
 
 If Δt tends to 0, Δchanges also tends to zero, which means it's effectively 
 frozen in time.
 
 Also, we don't need to pass within half an hour. We just need to pass on the 
 first try.
 
 probably not unexpectedly, i don't like that.
 thiago insists on the forward merge, and all other things being equal,
 the number of commits wouldn't go down, so we would arrive at a
 significant number of duplicated commits.
 
 I really insist that the tag is part of the past history.
 
 note that there is an alternative to the forward merge that thiago at
 least didn't reject outright last time i proposed it: create a shadow
 tag on the stable branch which marks the last commit that went into a
 particular release (but obviously also already contains commits that
 were not released at that time). that would make the cherry-pick
 solution more palatable.
 
 I'm fine with that, as long as I can check out the tag and get the actual 
 contents of the release. Very often, when looking at bugs or other issues, 
 I'll do git show v5.x.y:src/corelib/foo/bar.cpp and see if the issue was 
 already there.
 
 But I think you're suggesting something like this:
 
 A--B--C--D-- 5.3
\--E--F
 
 If F is tagged v5.3.1, then B is tagged branchpoint-5.3.1. That means D 
 gets 
 described as branchpoint-5.3.1-2-gXX.
 
 Maybe it could be tagged branchpoint-5.3.2. Maybe instead C should be the 
 Bump version commit and be tagged.
 
 I dislike duplicating the number of tags in the repository. It will create 
 confusion. So I would prefer the merge back, since the duplication of commits 
 doesn't cause confusion, regardless of the number of them.
 
 release. The fact that we're changing the names of the branches does not
 invalidate the reason why we chose HEAD to point to stable back in 2011:
 people should be presented with the most currently relevant yet stable
 release available when they clone the repository. And given 2½ years of
 experience on this, I can confidently say that this is also the this is
 the branch that most of our developers spend time on.
 
 i would argue that this is one of the branch-related things that really
 don't matter for the vast majority of contributors. a reasonable
 developer makes a conscious decision about his target branch rather than
 cloning and just hacking away.
 
 And I would argue the opposite.
 
 A reasonable developer is not what you get in the #qt channel. There are lots 
 of people checking out Git repositories and building their own Qt, without 
 really understanding what they're doing. In the past two weeks or so, I've 
 caught a lot of non-contributors building with -developer-build without 
 understanding what it did, just because they found that in some wiki page.

Maybe they did not follow “some wiki page”, but
http://qt-project.org/wiki/Building_Qt_5_from_Git ?
Because that is exactly what is written there, and that page is really our 
reference page on how to build Qt5 from git.
It also explicitly states “git checkout stable”, btw.

 That means when we create 5.x from dev, someone needs to go and update
 all the Gerrit and Gitorious repositories' HEAD.
 
 only if you volunteer to either do that yourself, or write (and
 maintain) a http client script that reliably does it for us.
 
 I'm not the one proposing the branch name change. The people proposing that 
 should take into account the work required to keep this working in their 
 proposal and plan 

Re: [Development] Remove OSX 10.6 Build?

[Ziller Eike]

On Jan 26, 2014, at 8:10 PM, Robert Knight robertkni...@gmail.com wrote:

 In regards to users of Mac OS Qt applications: I’m am extremely confident 
 that more Mac OS applications would be/have been written in Qt,
 if the priority for native looking widget support was higher. Mac OS users 
 are notorious for their attention to detail and noticing a non-native LF.
 Forcing application developers to resort to Objective C/Cocoa/style sheet 
 hacks/whatever in order to make the UI look and behave more
 native sort of defies the notion of a cross platform framework.
 
 Indeed. In terms of diverting resources away from supporting older
 versions of OS X this is probably going be much more compelling for Qt
 users than talk of being able to use C++11, ARC, newer naive APIs etc.
 inside Qt itself.
 
 As an aside, in a company with enough resources to have product
 designers, the designers are highly likely to be using Macs and their
 impressions of Qt apps there tend to carry over to discussions about
 what platforms to base other versions of a cross-platform app on. So
 if Digia want to sell commercial licenses to use Qt on iOS, Android
 etc. investment in Mac LF may be quite worthwhile.

So what’s the relationship of that discussion on quality of Qt on OS X, to the 
discussion on supporting 10.6 or not?
Dropping support for 10.6, and making it possible to clean up that code, would 
in the mid-term free up resources that would make it possible to spend more 
resources on better OS X integration in general (or, would make the existing 
resources more efficient in doing so)?

 On 23 January 2014 21:35, Jan Farø jan.fa...@gmail.com wrote:
 
 On 24/01/2014, at 03.46, Alexis Menard men...@kde.org wrote:
 
 
 
 
 On Thu, Jan 23, 2014 at 5:16 PM, Jan Farø jan.fa...@gmail.com wrote:
 
 
 I don’t think anybody has mentioned the lack of ability to upgrade
 hardware - mostly because of financial issues, I suppose. 10.6 is as far as
 I know the last Mac OS to support 32 bit systems. Previous versions of my
 own software supported PPC and down to Mac OS 10.4, which gave me a
 considerable user base from that segment. Percentages aside, there’s still a
 LOT of people sitting with old hardware, simply because they cannot afford
 to upgrade.
 
 
 But is that a significant part of the Mac OS X users or users of Mac OS X Qt
 applications? I seriously doubt so. Let's be realistic, less and less
 software are supporting PPC nowadays, the best you can get is a 32/64 bits
 binary for Mac OS. Last machines from Apple with 32 bits only processor :
 2006.
 
 One other point is that Qt5 is about QML and is pushing towards its usage on
 the desktop with better components for it with a modern GL scene graph.
 Running on outdated graphic cards with outdated graphic drivers is also not
 something people want to bother testing and fixing.
 
 
 I completely agree in regards to PPC support.
 
 In regards to users of Mac OS Qt applications: I’m am extremely confident
 that more Mac OS applications would be/have been written in Qt, if the
 priority for native looking widget support was higher. Mac OS users are
 notorious for their attention to detail and noticing a non-native LF.
 Forcing application developers to resort to Objective C/Cocoa/style sheet
 hacks/whatever in order to make the UI look and behave more native sort of
 defies the notion of a cross platform framework.
 
 
 Again let's balance the cost of the maintenance of the code of 10.6 vs
 supporting few users stuck in the past? If they must stick in the past for
 various reasons (financial or others) then they can just use Qt4, it works
 just fine for Mac OS 10.6 or even Qt5 released versions. Why such users
 would care of modern Qt5 applications?
 
 
 Qt4 looks suboptimal on Mac OS. It still has problems with some of the list
 widgets. Among other things. Qt5 has several showstopper issues on Mac OS,
 some of which seems to finally being taken seriously (5.2.1?). You can’t
 ship a quality application on Mac OS with Qt5.0 - Qt.5.2.0.
 
 
 
 ___
 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

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] [Qt-creator] Qt Creator 3.2 dropping support for Mac OS X 10.6

[Ziller Eike]

On Jan 23, 2014, at 7:16 PM, Adam Light acli...@gmail.com wrote:

 All but one developer at my (smallish) company is still using OSX 10.6.8 
 because we need 10.6 to be able to build the current shipping version of our 
 main product. We all use Qt Creator, so a Creator 3.2 that would not work on 
 10.6 would be a problem for us.

Noted. Let’s see how many others shout.

Can you please explain to me though, why you develop on 10.6? You could still 
target 10.6 from newer OS versions, and have your nightly build / product build 
machine on 10.6 to be on the safe side for the actual builds, and have a 
testing machine on 10.6.

If you use 10.6 for development, you also use all the other old, no longer 
updated tools from Apple (gcc, gdb, instruments etc etc). (Can you even test 
retina/HiDPI on 10.6?)

Also note that Qt Creator 3.1 already will no longer support Apple’s gdb, and 
support for the very old lldb, that you can still somehow get from the paid 
developer program for 10.6, will be limited.

Br, Eike

 Adam
 
 
 On Thu, Jan 23, 2014 at 4:29 AM, Daniel Teske daniel.te...@digia.com wrote:
 Hi,
 
 Let's make this:
  Qt Creator 3.2:
   - drop support for compiling  running Qt Creator on 10.6
 
  We want to start using C++11 also in Qt Creator, and 10.6 is the only thing
  preventing that. Since 10.6 is deployment target only for Qt, we don’t
  necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric
  way of looking at Qt Creator).
 
 a actual independant proposal (since it doesn't really depend on what qt
 supports) and cross post it to qt-creator for some wider exposure.
 
 Actually using C++11 would also mean bumping the minimum supported compiler
 for *compiling* Qt Creator. That's somewhat separate, but I would assume we
 would require at least lamba and auto support for compiling Qt Creator 3.2.
 
 That means MSVC 2010, clang 3.1 or g++ 4.5 if I remember correctly.
 
 daniel
 ___
 Qt-creator mailing list
 qt-crea...@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/qt-creator
 
 ___
 Qt-creator mailing list
 qt-crea...@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Remove OSX 10.6 Build?

[Ziller Eike]

On Jan 21, 2014, at 2:56 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote:

 On 21/01/14 13:36 , Sorvig Morten wrote:
 I realize that if I’m the only one who want’s to keep supporting 10.6
 then that’s not going to work. The most important thing to me is to
 have a somewhat predictable deprecation plan. For example (and at the
 risk of making this example “the plan”):
 
 5.3 - Remove support from binary packages. 5.4 - 10.6 support is
 deprecated. 5.5? - Remove support.
 
 5.3:
 
  - Remove support from binary packages
  - No CI
  = In practice, deprecated, so let's be explicit about it for 5.3
 
 5.4
 
  - Bump the dev branch to 5.4
  - Remove 10.6 code as see fit
  - Apply 10.6 fixes to 5.3.x (stable) as normal
 
 The message is Qt 5.3 deprecates 10.6 support (but is available for 
 source builds for the lifetime of 5.3), and 5.4 will remove it.”

I’d support this plan, and additionally throw in:

after 5.3 / Qt Creator 3.2:
 - drop support for compiling  running Qt Creator on 10.6

We want to start using C++11 also in Qt Creator, and 10.6 is the only thing 
preventing that. Since 10.6 is deployment target only for Qt, we don’t 
necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric way 
of looking at Qt Creator).

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] How long until clang memory model is ready?

[Ziller Eike]

On Jan 22, 2014, at 8:31 PM, Cristian Adam cristian.a...@here.com wrote:

 On 22.01.2014 19:35, ext Olivier Goffart wrote:
 Regarding the use of libclang for the code model in Qt creator, there 
 was no progress in a long time. 
 
 I think the clang code model branch has been merged into master:
 http://lists.qt-project.org/pipermail/qt-creator/2013-December/003028.html
 
 The next version of Qt Creator should have the clang code model as a 
 plugin.

That’s correct. In Qt Creator master branch (i.e. 3.1 series) you can choose 
the code model of different languages to use clang as a code model backend, or 
Qt Creator’s built-in. (If you pointed Qt Creator to libclang (and dev headers) 
at Qt Creator compile time.)

Br, Eike


-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Remove OSX 10.6 Build?

[Ziller Eike]

On Jan 21, 2014, at 3:01 PM, Mohamed Fawzi fawzi.moha...@digia.com wrote:

 
 On 21 Jan 2014, at 14:25, Jake Petroules jake.petrou...@petroules.com
  wrote:
 
 On Jan 21, 2014, at 7:36 AM, Sorvig Morten morten.sor...@digia.com wrote:
 
 On 21 Jan 2014, at 11:51, Simon Hausmann simon.hausm...@digia.com wrote:
 
 That depends on how much time we spend releasing Qt :) 
 
 I realize that if I’m the only one who want’s to keep supporting 10.6 then 
 that’s not going to work. The most important thing to me is to have a 
 somewhat predictable deprecation plan. For example (and at the risk of 
 making this example “the plan”):
 
 5.3 - Remove support from binary packages.
 5.4 - 10.6 support is deprecated.
 5.5? - Remove support.
 
 I also think that it looks reasonable, but I would also find announcing now 
 that 5.4 drops 10.6 support ok (I don't see this big need for deprecated but 
 still there if one knows long enough before).
 Anyway another thing (with ARC support) is also C++11.
 Is it clear when we will begin to require C++11?

 Because supporting C++11 in 10.6 is *very* tricky (one might try to ship 
 libc++, but system library will still use libstdc++ and I am not sure if 
 binary compatibility with the version shipped in 10.6 is guaranteed.

You can’t compile C++11 code if you use deployment target 10.6 (the Apple tools 
prevent that), so “ship libc++” is out of question. The only maybe-possible 
path would be to use custom GNU libs instead of the Apple-provided ones, but I 
do not think that we want to support that in any way.

++ Eike

 Fawzi
 
 I think this is relatively reasonable. By 5.5 (mid-2015, right?) we will 
 have or almost have OS X 10.11 which is three versions into the OS X free 
 pricing model. Given the fast uptake of OS X Mavericks in just a few short 
 months, by then it seems to me that it will be the ideal time to say goodbye 
 to the last of the Leopards. The gap between Snow Leopard and Lion is also 
 probably the most technically significant between any two recent versions of 
 OS X, so when it's 10.7's time to go we may not even need any code changes.
 [...]
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Remove OSX 10.6 Build?

[Ziller Eike]

On Jan 21, 2014, at 3:15 PM, Sorvig Morten morten.sor...@digia.com wrote:

 On 20 Jan 2014, at 21:21, deDietrich Gabriel gabriel.dedietr...@digia.com 
 wrote:
 The truth is, market share doesn’t mean anything. Point in case: According 
 to the link above, OS X is less than 8% of the total market share. Should we 
 then drop the Mac port completely?
 
 Good question! Possible arguments for not discontinuing the Mac port:
 
 - The holistic view. The single platform is not that important, but as a part 
 of a comprehensive platform support package it becomes valuable.
 - The 8% OS X users represent a group we want to target.
 - We can use the Mac port to make Qt better. Case in point the high-dpi 
 support developed for OS X can be used on Wayland as well.

- A good part of the OS X port is useful for the iOS port, and on the 
smartphone market the numbers are pretty different

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Debugging into Qt binaries

[Ziller Eike]

On Jan 11, 2014, at 5:55 AM, Kuba Ober k...@mareimbrium.org wrote:

 On Jan 10, 2014, at 6:07 AM, Ziller Eike eike.zil...@digia.com wrote:
 
 On Jan 9, 2014, at 6:05 PM, Kuba Ober k...@mareimbrium.org wrote:
 
 I’m trying to figure out the most constructive way of ensuring that an OS X 
 build of Qt, installed with the source code, can be actually debugged by 
 stepping into the C++ source code in the Qt library. So far I can only step 
 into disassembly. This doesn't work out of the box on a fresh install of Qt 
 5.2, and it really has never worked with Qt 5 builds. I never got it 
 working for a Qt 4 build either.
 […]
 
 Please see my comment on QTBUG-28496:
 
 basically to solve this completely, including debugging into Qt code, we 
 need to
  • make sure we package the debugging symbols (dsymutil, or maybe 
 there's a compiler flag that does that during link-time?)
  • think about if the debugging symbols should be in a separate 
 component, it will make the package significantly larger I guess (like Qt 
 libraries 4.8.4 for Mac (185 MB) and debug libraries (480 MB))
  • make it actually find the Qt sources. I've no clue at the moment how 
 to achieve that with apple's gdb, or if we can patch the debug info in the 
 dsym at install time
 /quote
 
 Eike, this is very helpful! So far I’ve simply rebuilt Qt locally and are 
 using that for debugging. Is the build script used to build a Qt distribution 
 package available, and if so, where? 
 
 Thanks, Kuba Ober

The scripts used to build Qt are on gerrit 
(https://codereview.qt-project.org/#admin,project,qtsdk/qtsdk,info), and on 
gitorious here https://qt.gitorious.org/qtsdk/qtsdk .
All starts with packaging-tools/build_wrapper.py in there, e.g. 
handle_qt_release_build()

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Debugging into Qt binaries

[Ziller Eike]

On Jan 9, 2014, at 6:05 PM, Kuba Ober k...@mareimbrium.org wrote:

 I’m trying to figure out the most constructive way of ensuring that an OS X 
 build of Qt, installed with the source code, can be actually debugged by 
 stepping into the C++ source code in the Qt library. So far I can only step 
 into disassembly. This doesn't work out of the box on a fresh install of Qt 
 5.2, and it really has never worked with Qt 5 builds. I never got it working 
 for a Qt 4 build either.
 
 For Qt 5.2, the Debugger Log pane is full of messages like the below:
  Could not find object file 
 /work/build/qt5_workdir/w/s/qtbase/src/widgets/.obj/debug/qtabbar.o - no 
 debug information available for qtabbar.cpp”.
 Presumably this is because the Qt build has debug info, but the paths in the 
 debug info refer to paths on the build host.

The Qt libraries do not ship the debug information. They are left behind in the 
object (.o) files on the build machines.

 Is there a magic incantation for gdb that would let it translate those object 
 file locations to locations on the installed variant of Qt? This is 
 presumably not the same as the incantations needed to translate source file 
 locations...
 
 Is there no way of getting it working out of the box? Is it an oversight? Or 
 nobody has time to deal with this? Any pointers on where to start? I would at 
 least like to have a working procedure assembled that ends up with Qt being 
 debuggable. This is quite puzzling since there are debug libraries installed 
 for all the Qt frameworks, and I have the sources installed as well.
 
 Isn’t it a reasonable expectation that this should work out of the box as 
 long as you install the sources when installing the official Qt build?


Please see my comment on QTBUG-28496:

quote
basically to solve this completely, including debugging into Qt code, we need to
• make sure we package the debugging symbols (dsymutil, or maybe 
there's a compiler flag that does that during link-time?)
• think about if the debugging symbols should be in a separate 
component, it will make the package significantly larger I guess (like Qt 
libraries 4.8.4 for Mac (185 MB) and debug libraries (480 MB))
• make it actually find the Qt sources. I've no clue at the moment how 
to achieve that with apple's gdb, or if we can patch the debug info in the dsym 
at install time
/quote

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] The Software shall be used for Good, not Evil statement in Qt sources

[Ziller Eike]

On Dec 18, 2013, at 5:35 PM, Lisandro Damián Nicanor Pérez Meyer 
perezme...@gmail.com wrote:

 Hi! I would like to now if it's acceptable for the project to have 3rd party 
 code with the following statement in 3rd party sources:
 
 The Software shall be used for Good, not Evil”

Does it come with definitions of “good” and “evil” ?

 
 At first I thought it wouldn't, but Sune Vuorela pointed me out that it 
 *might* be a problem for Digia, so I'm asking here just in case.
 
 The actual source is Source/WebInspectorUI/Scripts/jsmin.py in the qtwebkit's 
 submodule.
 
 Kinds regards, Lisandro.
 
 -- 
 Hola, soy su amigo Chespirito. Cuando estaba yo en el vientre de mi madre,
 ella sufrió un accidente que la puso al borde de la muerte. El médico le
 dijo: -Tendrás que abortar. Y ella respondió: -¿Abortar yo? Jamás.
 Es decir, defendió la vida, mi vida. Y gracias a ello estoy aquí.
  Roberto Chespirito Gómez Bolaños
  http://es.wikipedia.org/wiki/Chespirito
 
 Lisandro Damián Nicanor Pérez Meyer
 http://perezmeyer.com.ar/
 http://perezmeyer.blogspot.com/
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Dropping XP?

[Ziller Eike]

On Dec 11, 2013, at 6:27 AM, Jonathan Liu net...@gmail.com wrote:

 On 10 December 2013 18:34, Koehne Kai kai.koe...@digia.com wrote:
 
 -Original Message-
 From: development-bounces+kai.koehne=digia@qt-project.org
 [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
 Behalf Of Thiago Macieira
 Sent: Monday, December 09, 2013 11:24 PM
 To: development@qt-project.org
 Subject: [Development] Dropping XP?
 
 As Kenneth reminds us[1], Microsoft is ending the security updates for
 Windows XP in April 2014. That's about when we plan to release Qt 5.3.
 
 Actually ANGLE (one of the OpenGL backends we have for Windows) doesn't 
 support Windows XP already now, which is why e.g. Qt Creator 3.0 will not 
 support it either in 5.2.
 
 Another option would be to build Qt Creator 3.0 for Windows using
 desktop OpenGL and have an option in the installer to install the Mesa
 LLVMpipe software renderer. I have written some instructions for cross
 compiling Mesa for Windows here:
 http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows

I think even if Qt will still support Windows XP (as a deployment platform) it 
is completely fine if the pre-built Qt Creator packages do not. At least I 
don’t think we should at this point start investing a lot of time on this.
Of course if someone writes down instructions on how one can build Qt Creator 
even for Windows XP somewhere in our wiki (or maybe even extending/fixing the 
README in Qt Creator’s sources), that’d be a perfectly welcome addition ;)

My 2 1/2 cents,
Eike

 
 Regards,
 Jonathan
 
 
 Should we stop supporting Windows XP? Is there anything we can improve in
 our codebase if we do?
 
 I don't know about the codebase, but given the feedback for Qt Creator there 
 are still a lot of people using XP even as a development platform ... so I'd 
 expect quite some backslash if we completely drop support for Windows XP, at 
 least for 'traditional' QWidget based apps.
 
 My 2 cents
 
 Kai
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Dropping XP?

[Ziller Eike]

On Dec 11, 2013, at 11:57 AM, Jonathan Liu net...@gmail.com wrote:

 On 11/12/2013 8:03 PM, Ziller Eike wrote:
 On Dec 11, 2013, at 6:27 AM, Jonathan Liu net...@gmail.com wrote:
 
 On 10 December 2013 18:34, Koehne Kai kai.koe...@digia.com wrote:
 -Original Message-
 From: development-bounces+kai.koehne=digia@qt-project.org
 [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
 Behalf Of Thiago Macieira
 Sent: Monday, December 09, 2013 11:24 PM
 To: development@qt-project.org
 Subject: [Development] Dropping XP?
 
 As Kenneth reminds us[1], Microsoft is ending the security updates for
 Windows XP in April 2014. That's about when we plan to release Qt 5.3.
 Actually ANGLE (one of the OpenGL backends we have for Windows) doesn't 
 support Windows XP already now, which is why e.g. Qt Creator 3.0 will not 
 support it either in 5.2.
 Another option would be to build Qt Creator 3.0 for Windows using
 desktop OpenGL and have an option in the installer to install the Mesa
 LLVMpipe software renderer. I have written some instructions for cross
 compiling Mesa for Windows here:
 http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows
 I think even if Qt will still support Windows XP (as a deployment platform) 
 it is completely fine if the pre-built Qt Creator packages do not. At least 
 I don’t think we should at this point start investing a lot of time on this.
 Of course if someone writes down instructions on how one can build Qt 
 Creator even for Windows XP somewhere in our wiki (or maybe even 
 extending/fixing the README in Qt Creator’s sources), that’d be a perfectly 
 welcome addition ;)
 You don't need to do anything special for building Qt Creator for Windows XP.
 The Qt libraries just need to be built targetting desktop OpenGL.
 If you have proper OpenGL 2.1 drivers, run Qt Creator as normal.
 If you don't, copy Mesa's opengl32.dll to same folder as qtcreator.exe and 
 then run Qt Creator.

Well, then rephrase “build Qt Creator” to “use Qt Creator”, or something 
similar. Point is, there is no guarantee that a prebuilt Qt Creator just runs 
on your WinXP installation.

 Regards,
 Jonathan
 
 
 My 2 1/2 cents,
 Eike
 
 Regards,
 Jonathan
 
 Should we stop supporting Windows XP? Is there anything we can improve in
 our codebase if we do?
 I don't know about the codebase, but given the feedback for Qt Creator 
 there are still a lot of people using XP even as a development platform 
 ... so I'd expect quite some backslash if we completely drop support for 
 Windows XP, at least for 'traditional' QWidget based apps.
 
 My 2 cents
 
 Kai
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt Creator and External Library

[Ziller Eike]

On Dec 9, 2013, at 9:02 PM, Thiago Macieira thiago.macie...@intel.com wrote:

 On segunda-feira, 9 de dezembro de 2013 20:19:55, Comp wrote:
 I created a QMake project in Qt Creator and added an external library 
 (POCO), autocompletion seem to work, but then when compiling I get the 
 error message fatal error: Poco/File.h: No such file or directory, 
 even though QtC picked the right include path automatically. What could 
 be the problem and how can I solve this?
 
 I'm on windows 7 64 bit using QtC 3 built on Dec 9 2013 at 04:13:40, 
 from revision 674e7c9b0c.
 
 Hello Comp
 
 Your issue does not seem to be related to Qt's own development. Please use 
 the 
 inter...@qt-project.org mailing list for your question.

(or possibly the qt-creator@ mailing list)

 
 -- 
 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

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] OpenGL drivers

[Ziller Eike]

On Nov 30, 2013, at 10:29 PM, Mark Gaiser mark...@gmail.com wrote:

 On Fri, Nov 29, 2013 at 7:01 PM, Thiago Macieira
 thiago.macie...@intel.com wrote:
 On sexta-feira, 29 de novembro de 2013 12:27:44, Sletta Gunnar wrote:
 So, I'm asking that if you encounter issues with flickering, crashes, bad
 rendering and similar, help us track which things are problematic by filing
 a bugreport on bugreports.qt-project.org and use the label driverissue in
 the task. Please  include OS, windowing system, graphics hardware and
 driver version. And since most of the workarounds have been applied to Qt
 5.2, do test against the 5.2 RC1 or later.
 
 Do you consider fonts looking the wrong size to be bad rendering and a driver
 issue? Fonts in the Creator welcome screen look to be of a different size 
 than
 the rest of Creator.
 
 I'd consider it a font issue only, not a driver issue.
 
 
 What you refer to are probably the fonts rendered through QML. By
 default QML renders fonts with the distance field stuff [1]. It
 looks awesome on mobile, but looks horrible on the desktop. This has
 been known for a while [2] but apparently there is no effort ongoing
 to improve the situation for the desktop users.
 
 Globally setting the QML_DISABLE_DISTANCEFIELD variable makes it use
 the native font system again and makes it look nice:)

We are already using native text rendering in Qt Creator’s welcome screen, so 
that won’t change anything for it.

Br, Eike

 [1] 
 http://blog.qt.digia.com/blog/2011/07/15/text-rendering-in-the-qml-scene-graph/
 [2] https://bugreports.qt-project.org/browse/QTBUG-28993
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] OpenGL drivers

[Ziller Eike]

On Dec 2, 2013, at 4:44 PM, Thiago Macieira thiago.macie...@intel.com wrote:

 On segunda-feira, 2 de dezembro de 2013 14:26:29, Thomas Hartmann wrote:
 Hi,
 
 yes, this was a conscious decision. Does it create usability issues for you?
 
 Usability? That's debatable. My eyesight is still pretty good, so I can read 
 it. And I never read the project names on the Projects page (I only use the 
 sessions feature). The project names and paths have blurry fonts because 
 they're way too small. 
 
 So I have to ask: why can't we use regular font size? It's not like we're 
 out of screen real estate...
 
 It definitely creates an aesthetic issue, which is subjective, though.

Well, we definitely tell it to use such horizontally squashed fonts.

family “Helvetica”, pixelSize: 13

Using pixelSize instead of some point size is probably questionable though.
 

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Qt SDK for Mac OS X (was: New Qt 5.2 snapshot build #172)

[Ziller Eike]

On Nov 27, 2013, at 9:28 PM, Adam Strzelecki o...@java.pl wrote:

 So that would always contain the Qt sources, documentation and examples too?
 
 Yes, Kai wrote he sees no point to be able to not install docs  examples 
 together with SDK as suggested in QTBUG-34870. So once Qt Creator isn’t 
 there, bundled frameworks use @rpath, is there any point to have an installer 
 that just copies files if Finder serves this purpose just fine?

Except for the open question of registering the stuff in Qt Creator, for the 
current opensource installers we probably wouldn’t need more than that.
There are other installers though, either from Digia, or other companies 
(enterprise Qt packages, SailfishOS SDK, …) which have other requirements. 
Meaning that we need to have some kind of Qt installers for Mac anyhow.
Another thing that I think we should actually do in an installer, even though 
we currently do not, is to do system checks and warn users if these are not 
fulfilled. E.g. I think you should not install the Qt5 packages on Mac OS X 
10.6 with Xcode 3.x, since that Xcode version’s install_name tool can’t handle 
MachO headers of binaries created on 10.8 (where we build the Qt binaries).

 I just want to mention here that there *is* the plan to get rid of the 
 requirement to install Qt Creator from the installers.
 There are several possible ways to solve that and I think the discussion of 
 what is the preferred way to do it is not over yet, but I think there is 
 overall consensus that it should be done.
 
 Great to hear!

The currently discussed ideas here still involve the installer though.

 “double-click .qtsdk to register only works if you have exactly one Qt 
 Creator install on your machine. Of course there still would be “drag qtsdk 
 thing into Qt Creator” etc, but I don’t really see the advantages.
 
 Correct me if I am wrong but there’s single ~/.config/…/QtCreator file, so 
 even we have several QtCreators all of them gonna see some SDK registered by 
 the other.

Using ~/.config for that only works for single user installs. Which is not 
great especially if you install Qt Creator into /Applications and copy the SDKs 
into it. Registering SDKs would need to be done in Qt 
Creator.app/Contents/Resources/QtProject/… to make it available to all users of 
the Qt Creator that the SDK was copied into.

 Of course triggering registration and copy Qt5.x.y-spec.qtsdk with Qt Creator 
 requires Qt Creator to be there. It may be explicitly written on .dmg 
 background image. We can even put link to Qt Creator download too for 
 convenience. I have ready bash scripts that do all the layout and dmg build.
 
 Still Qt5.x.y-spec.qtsdk would be just a normal folder containing whole SDK 
 for given target. So you can always drag  copy it anywhere you want and use 
 it from command line if you don’t like Qt Creator.
 
 What’s more since dmg is mounted RO HFS filesystem, so you can even try the 
 toolchain without copying it anywhere, which isn’t possible right now.

If the Qt is at some point truly relocatable, we can just provide the 7z (or in 
dmg, or whatever format) of the component that is packaged in the installer in 
addition, for people which just want to extract and use that from the command 
line without bothering about installers. That would be indeed be no additional 
effort then.

 I’d guess that the more common case would be that people double-click Qt 
 Creator without double-clicking the .qtsdk (which they have no idea what 
 it’s supposed to be).
 
 If Qt Creator is installed you will not see .qtsdk extension and instead of 
 folder icon you will see some custom icon that will intuitively make you 
 click on it.
 
 If it is not installed it will look as regular folder and Finder will let you 
 step into it when you double click it.
 
 This is how it works for many other apps and it works well.
 
 I’m convinced that the AppStore is the only reason why Xcode is having 
 “everything in the bundle” nowadays. Not because it would make sense 
 usability-wise.
 
 Aside „everything is in the bundle” and simple install  updates, it is also 
 easier to manage multiple SDK or Xcode Betas, being just separate .app, you 
 drag around trash or overwrite. It is far more simple that previous .pkg 
 based installer that requires launching command line uninstall-devtools to 
 get rid of stuff.

It is easier for people who solely develop using Xcode.
And the last part is because for whatever reason Apple never cared to add some 
sort of uninstall into installers.

 Also now switching between command line toolchain versions is as simple as 
 selecting it from combo in Xcode Prefs or launching some fancy extra manager 
 apps, but there is also xcode-select.

That is independent from where the SDKs are installed.

 I don’t think the normal user of Xcode cares if the SDK was installed within 
 the Xcode.app or not. It’s not that Xcode didn’t come as a installer for 
 years, and it’s not that installers are completely 

Re: [Development] Qt SDK for Mac OS X (was: New Qt 5.2 snapshot build #172)

[Ziller Eike]

On Nov 28, 2013, at 12:53 PM, Adam Strzelecki o...@java.pl wrote:

 There are other installers though, either from Digia, or other companies 
 (enterprise Qt packages, SailfishOS SDK, …) which have other requirements. 
 Meaning that we need to have some kind of Qt installers for Mac anyhow.
 
 Agreed. If you have dedicated machine for dedicated tools that works both for 
 software providers and end-users.

I don’t know how what you say relates to what I said above.

 E.g. I think you should not install the Qt5 packages on Mac OS X 10.6 with 
 Xcode 3.x, since that Xcode version’s install_name tool can’t handle MachO 
 headers of binaries created on 10.8 (where we build the Qt binaries).
 
 install_name_tool step is not necessary.

It was an example. We’ll always have issues that would be good to warn about 
(e.g. outdated Xcode, which we don’t really support,…)

 
 Using ~/.config for that only works for single user installs. Which is not 
 great especially if you install Qt Creator into /Applications and copy the 
 SDKs into it. Registering SDKs would need to be done in Qt 
 Creator.app/Contents/Resources/QtProject/… to make it available to all users 
 of the Qt Creator that the SDK was copied into.
 
 Again we are speaking about 3 different scenarios:
 (1) no Qt Creator - no need to register anything
 (2) single user, has multiple Qt Creator, and/or wants SDK to be at some 
 place she/he wants, then Qt Creator needs to be somehow informed where is it 
 (double click to register)
 (3) multi user workstation (i.e. computer room at university) - you put SDKs 
 inside Qt Creator (Xcode way), we don’t need to explicitly tell Qt Creator 
 about new SDK, because it can figure out that

Also in your case (3) some (administrator) user needs to put/install the SDKs 
inside Qt Creator. Actually I don’t think 23 are different at all. Why should 
we do different things in these cases? It just creates inconsistencies, and 
makes it harder to test.

 If the Qt is at some point truly relocatable, we can just provide the 7z (or 
 in dmg, or whatever format) of the component that is packaged in the 
 installer in addition, for people which just want to extract and use that 
 from the command line without bothering about installers. That would be 
 indeed be no additional effort then.
 
 That would be nice compromise. Would it be possible to put regular directory 
 instead of installer.dat (which you say is 7z archive) in Mac dmg? So once Qt 
 SDK is relocatable I can just copy or run SDK myself, but installer can still 
 be used by the others?

I don’t see principle problems with that, but that’s more a question/request to 
the installer framework guys. I don’t quite see the problem with requiring that 
people who just want the relocatable Qt binary archive download exactly that to 
begin with. We already provide that for the Qt Creator standalone version for 
all installers (since Qt Creator is relocatable): 
http://download.qt-project.org/snapshots/qtcreator/master/latest/installer_source/

 It is easier for people who solely develop using Xcode.
 And the last part is because for whatever reason Apple never cared to add 
 some sort of uninstall into installers.
 
 For whatever reason Apple never made its installer to be able to uninstall 
 stuff. Actually it does degraded, pkgutil no longer can remove installed 
 files. That’s a pity indeed. Fortunately OSX still follows well-known 
 directories schema and still you’ve boms listing what files and where were 
 installed.
 
 Anyhow, developer.apple.com/downloads still has “Command Line Tools (OS X 
 Mavericks) for Xcode”.
 
 Yes I find it confusing too. I wish they stick with Xcode only.

I could imagine that it’s useful e.g. if you do automated generation of build 
vms (I think installers support silent/headless install), and also Xcode *is* 
overhead for e.g. pure build slaves.

 There the application itself (without any command line tools) is what 99% of 
 the users care about.
 
 That’s why fortunately this is just optional.

You cut something off here. I meant for e.g. TextMate, most people care about 
the app, not the command line tools. I claim that’s different with Qt and Qt 
Creator.

 (…) it would be additional functionality implemented in Qt Creator that 
 already is implemented in the installer.
 
 You mean Maintenance Tool? Installer is gone once I eject SDK dmg.

See below :)

 I have no idea if it has some command line interface? Then so, then ok. It 
 may be a use for these who don’t want Qt Creator, otherwise why not putting 
 everything in one place? Actually turning Maintanance Tool into Qt Creator 
 plugin.

MaintenanceTool is basically a copy of the installer without the data.
Reg. command line interface you can have a look at
./MaintenanceTool.app/Contents/MacOS/MaintenanceTool —help

e.g. 
--checkupdates   Check for updates and 
return an XML file of the available updates

which we use for the “online update 

Re: [Development] Qt 5.2 RC1 candidate packages available

[Ziller Eike]

On Nov 28, 2013, at 2:36 PM, Heikkinen Jani jani.heikki...@digia.com wrote:

 Hi all,
  
 We have finally Qt 5.2 RC1 candidate packages available in 
 http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-28_179/ . 
 Mirroring is ongoing so it is possible that all packages aren’t visible yet 
 but will be soon …

and similar with 
http://download.qt-project.org/snapshots/qtcreator/3.0.0-rc1/rc1-candidate_2013-11-28_179/
for the Qt Creator standalone packages.

 These packages will be RC1 packages if there isn’t any new RC1 blocker found 
 during testing. Target is to release RC1 tomorrow so please check packages as 
 soon as possible.
  
 Please report your testing effort via 
 http://testresults.qt-project.org/forms/release-testing  form and in case of 
 new bugs report those in JIRA https://bugreports.qt-project.org .
  
 Change after previous packages:
 https://codereview.qt-project.org/72647 (workaround for 
 https://bugreports.qt-project.org/browse/QTBUG-35143 : Scene graph threaded 
 render loop deadlocks on X11)
  
  
 Br,
 Jani
  
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] New Qt 5.2 snapshot available

[Ziller Eike]

On Nov 27, 2013, at 3:01 PM, Ola Røer Thorsen o...@silentwings.no wrote:

 Hi,
 
 maybe QtCreator should be added to the test report form? It has entries for 
 Designer and Assistant already. 
 
 I'm not able to run QtCreator from this snapshot. Bug report here,
 https://bugreports.qt-project.org/browse/QTCREATORBUG-10931

Looks like https://bugreports.qt-project.org/browse/QTBUG-35143 ?

Br, Eike

 Cheers,
 Ola
 
 
 
 2013/11/27 Heikkinen Jani jani.heikki...@digia.com
 Hi,
 
  
 
 We have new Qt 5.2 snapshot packages available in 
 http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-27_176/ 
 (mac installers)  
 http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-27_177/ 
 (Windows  linux ones)
 
  
 
 These packages are considered to be really close to RC1 release packages.
 
  
 
 Please report your testing effort via 
 http://testresults.qt-project.org/forms/release-testing  form and in case of 
 new bugs report those in JIRA https://bugreports.qt-project.org .
 
  
 
 Qt5 changes in these packages:
 
 * qtbase 40290b0...9b8570c (14):
 
  Fix deadlock when disconnecting connections made with function pointers
 
  Fix formatting in the platform-specific changes part of the ChangeLog
 
  Reflow the ChangeLog part for QtNetwork
 
  Update ChangeLog for 5.2.0 [QtDBus]
 
  Fix a race that occurred as we unlock the mutex to destroy the functor in 
  ~QObject
 
  iOS: Update statusbar visibility and screen properties before window 
  geometry
 
  iOS: Prefer window states over geometry-heuristics when laying out windows
 
  iOS: Dont warn about QBackingStore::resize() != window.size() for widgets
 
  iOS: Dont enable translucent statusbar for iOS6 on iPads
 
  Revert Android: Use native platform menus.
 
  iOS: close keyboard upon hitting key done
 
  Update ChangeLog for 5.2.0 [QtCore]
 
  Update ChangeLog for 5.2.0 [QtWidgets]
 
  Update changelog for 5.2.0 RC1
 
  
 
 * qtdoc 08b4755...6bd1511 (2):
 
  Doc: Fixed missing links in iOS, Android, WinCE, and Mac OS X pages.
 
  Added changelog for 5.2.0 release
 
  
 
 * qtwebkit fb02f6e...840e281 (2):
 
  Account for when the QGraphicsView is a top level widget
 
  WebKitQML examples does not work on Mac
 
  
 
 Br,
 
 Jani
 
 
  
 
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] New Qt 5.2 snapshot build #172

[Ziller Eike]

On Nov 27, 2013, at 12:06 PM, Adam Strzelecki o...@java.pl wrote:

 Jake Petroules wrote:
 But what exactly do you include in the offline installer?
 
 Thanks for detailed insight. I think I am all way with /Applications/Qt 
 Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ because of simple reason 
 that on OSX you don’t need elevated permissions to put anything into 
 /Applications (comparing to /Library).
 
 1st of all I wouldn’t call it installer, but it would be DMG bundle with nice 
 background  layout:
 
 1. Drag to Application to install
  [Qt Creator.app] == [/Applications]
 
 2. Then double click to install SDK:
  {mkspec}-{version}.qtsdk

So that would always contain the Qt sources, documentation and examples too?
I just want to mention here that there *is* the plan to get rid of the 
requirement to install Qt Creator from the installers. There are several 
possible ways to solve that and I think the discussion of what is the preferred 
way to do it is not over yet, but I think there is overall consensus that it 
should be done.

 Where online bundle would have just (1) Qt Creator bare app + Qt Creator Mac 
 plugin that downloads offline .dmg-s for iOS, Android or whatever, mounts dmg 
 and copies .qtsdk.
 
 We can easily have helper (i.e. written in Apple Script) embedded in Qt 
 Creator.app that is bound to .qtsdk extension, that simply launches Finder 
 copy into /Applications/Qt Creator.app/Contents/SDKs or wherever it is 
 placed, then ejects the .dmg.

“double-click .qtsdk to register only works if you have exactly one Qt Creator 
install on your machine. Of course there still would be “drag qtsdk thing into 
Qt Creator” etc, but I don’t really see the advantages.

 What’s more cool, we can figure out the case user have not dragged yet .app 
 into /Application but clicks on the .qtsdk and show „please drag Qt Creator 
 into your Applications first”.

I’d guess that the more common case would be that people double-click Qt 
Creator without double-clicking the .qtsdk (which they have no idea what it’s 
supposed to be).

 As for Xcode compatibility sake,

I’m convinced that the AppStore is the only reason why Xcode is having 
“everything in the bundle” nowadays. Not because it would make sense 
usability-wise. I don’t think the normal user of Xcode cares if the SDK was 
installed within the Xcode.app or not. It’s not that Xcode didn’t come as a 
installer for years, and it’s not that installers are completely alien on OS X. 
And actually Apple now needs to provide and maintain two “installers”: 
Xcode.app with its package management, and the separate CommandLineTools 
package, which is still available (for a reason).

 we can make in Qt Creator a button [Install Command Line Tools] which will:

The “Install Command Line Tools” thing in Xcode is one of the things that are 
really *bad* usability-wise now. Apple doesn’t care, because for Apple this is 
the “if you are not using Xcode we don’t care much” path, but I don’t think we 
want to follow that.

 (1) install symlink to qmake into /usr or /usr/local
 (2) install symlinks to all .frameworks into /Library/Frameworks

I’m actually glad that we got rid of system wide installs (that we did for 
Qt4), so I don’t think system wide installs would be a good direction to go. 
It’s also not very common to do that on OS X.

 Again we can make it as Qt Creator plugin, rather putting it into base code.
 
 Since these are symlinks, even if we trash Qt Creator.app (and all SDKs 
 within) these will be dangling, but not occupying any space on the disk.

That would be highly unintuitive (after all it is supposed to be *installed*), 
and counter productive to the “I don’t want Qt Creator” case (you can’t 
“install the tools” and trash Qt Creator). Again, Apple doesn’t care with 
Xcode, I think we should.

 Finally regarding maintenance burden: actually there would be less, because 
 we will get the .qtsdk helper and Qt Creator plugin just once. Then making 
 OSX Qt bundles will be less work, since it would be what it done right now 
 minus creating Qt installer framework based installer app.

I can’t follow that calculation.
We’d still need the online installer functionality *somewhere*. Which would 
functionality-wise be mostly what the current installer framework does, so we’d 
still need to maintain installer framework for Mac, or the exact same 
functionality in a Qt Creator plugin: Component management (what is available 
on the remote repository, what is installed, what should be installed + 
deinstalled), downloading and installing components (even if the last is just 
unpackaging some package somewhere), uninstalling components.

 Adding plugins into the respective frameworks would simplify deployment 
 significantly. macdeployqt's task would be reduced to inspecting the 
 frameworks the app links against, and copying the framework folders into the 
 bundle. Don't need to think about plugins, don't need to mess with install 
 names. It just