Re: [Development] Decrease amount of qt releases in online installer

[Tomasz Siekierda]

On Wed, 21 Feb 2024 at 11:44, Jani Heikkinen via Development <
development@qt-project.org> wrote:

> Hi,
>
>
>
> Currently, more than 60 Qt releases can be installed from the Qt open
> source online installer (if all installation categories are selected). This
> requires a huge amount of disk space on the mirrors and also causes some
> performance issues with the online installer. That's why I suggest removing
> the older ones from the online installer; these releases can still be found
> in the archive as source packages and offline installers.
>
>
>
> But what are the ones that can be removed? I suggest removing all Qt 5
> except Qt 5.15.x. And maybe we could also remove the oldest Qt6s, e.g. all
> Qt 6.0.x, 6.1.x?
>
>
>
Is this only about Open Source installer or also Commercial one? I'm on Qt
5.12.5 (Commercial) and will continue using this version potentially for
years to come (yeah it sucks but it's not my choice). So it would be nice
to still have it in the installer. I can compile it myself, I know I know,
but the installer is just a lot more convenient.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Leaving The Qt Company

[Tomasz Siekierda]

Many thanks for all your fantastic work on and around Qt! And good luck
with your new startup :-)

On Wed, 18 May 2022 at 10:30, Lars Knoll  wrote:

> Hi all,
>
> Let’s take the big news first. I’ve resigned from my position at The Qt
> Company. More on that and what it means for the Qt Project further below.
>
> But as I’ve spent almost exactly 25 years in the Qt ecosystem, 22 of those
> working for the various companies owning Qt, I hope it’s ok if this gets a
> bit longer and I spend some paragraphs looking back into history.
>
> As said, it’s been almost exactly 25 years, since I first heard about Qt.
> At that time, I read an article in the German C’t computer magazine about a
> new Desktop project for Linux called KDE. The underlying technology being
> used was Qt. As a person that used Linux extensively during his studies, I
> immediately got interested and it didn’t take long until I started my first
> steps learning Qt.
>
> As some of you might know I got involved rather deeply about a year or two
> later, when I started the KHTML project to create a new HTML engine for KDE
> in 1998/1999. That project was later forked by Apple to form the basis for
> their WebKit project, the Safari browser and Google’s Chrome browser. It's
> cool to think that the browser engine(s) that most people use today started
> off as a Qt based project all those years ago.
>
> I remember getting to know some of the people working for Trolltech back
> then at KDE conferences. In the winter of 2000, they invited me over to
> Oslo to have a look at Qt. The company was at that time still tiny with 11
> or 12 employees. I got a great tour of Oslo including the ski jumping
> tournament at Holmenkollen and signed up for the job.
>
> I was originally expecting to spend 2-3 years at Trolltech and then at
> some point move back to Germany. As you all can see, that’s not how it went
> though. I ended up staying in Norway and have been working with and for Qt
> ever since.
>
> Starting with Qt 1.0, Trolltech released the source code to Qt (at that
> time only for Linux/Unix), and the Open Source nature of Qt played a big
> part in its success. I’m very happy that we could continue on that path, by
> over time making all platforms Qt supports available as Open Source as well
> as moving over to more standard and freer licensing (first GPL, later LGPL).
> At the end of the Trolltech years, we started looking into how to make it
> easier for the community to contribute to Qt, and first had a model where
> our users could submit patches to us. That never really worked very well,
> and I’m really happy that we moved over to our current governance model in
> 2011. Since then Qt has truly been an Open Source project.
>
> When Qt got sold by Nokia in 2012, many people considered it a dead
> technology. But I and many of you believed in the technology, and together
> we’ve managed to turn this into a great success.
>
> As you all know, Qt is a dual licensed technology. That Qt has the backing
> of a commercial business behind it, is what made the required investments
> possible to keep the technology competitive.
>
> I’m extremely proud of what we achieved with Qt over the last 10 years. It
> happened because everybody on this list put in a lot of work into making Qt
> one of the best development frameworks on this planet.
>
> Qt is something that I care deeply about. I’ve been with it all the way
> and through all the ups and downs from when Trolltech got its first larger
> investment to now. But seeing what you all are doing, I know it’s in very
> good hands moving forward.
>
>
> Leaving The Qt Company and in the future spending most of my time outside
> the Qt ecosystem has been a difficult decision. But in the end, after those
> 25 years, it does feel very much like the right decision for me. I want to
> try out something else.
>
> So I will be joining a small Norwegian startup with one of the founders of
> Trolltech. While still in Software, it’ll be something rather different,
> not related to C++ or developer tools.
>
>
> So how do things continue from here?
>
> First of all, I’ll still be working for Qt until my summer vacations at
> the end of June.
>
> After that, I will have significantly less time for Qt, but I certainly
> won’t be completely gone. I will continue to read the Qt project mailing
> lists and maybe come by for events such as the Contributor or World Summit.
> Also, feel free to send me a mail at any time, I’ll try to help where I can.
> I will also keep my position as a maintainer for Qt Multimedia. I believe
> the module is now in a decent shape, and I should be able to spend some
> hours per week on it.
>
> But a few hours per week will certainly not be enough to fill the work I’m
> currently doing for Qt. So, I have decided to resign from my position as
> the Chief Maintainer of the Qt project. I’ll send more details around this
> in a separate mail.
>
> I’d like to thank everybody whom I’ve worked with over the 

Re: [Development] Stepping down as QtSerialPort maintainer

[Tomasz Siekierda]

On Wed, 7 Oct 2020 at 09:40, Denis Shienkov 
wrote:

> [...]
>
> Thanks so much for using QtSerialPort, I'm glad it was useful
> to someone.
>

Thanks for all your work, that module is awesome, I've used it many times.


>
> BR,
> Denis
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] char8_t summary?

[Tomasz Siekierda]

On Thu, 11 Jul 2019 at 18:43, Matthew Woehlke 
wrote:

> On 11/07/2019 05.05, Mutz, Marc via Development wrote:
> > There is a cost associated with another string class, too, and it's
> > combinatorial explosion. Even when we have all view types
> > (QLatin1StringView, QUtf8StringView, QStringView), consider the overload
> > set of QString::replace(), ignoring the (ptr, size) variants:
> >
> >{QL1V, QU8V, QSV, QChar} x {QL1V, QU8V, QSV, QChar}
> >
> > that's 16 overloads. And that's without a possible QUtf32StringView.
>
> So?
>
>
I have nothing to say in this discussion, but just want to throw in one
small hint/request/worry:

please, if it can be avoided, don't add yet another string-related class to
Qt. Knowing when to properly use QString, QByteArray, QLatin1String,
QStringLiteral, QStringRef and QStringView (I may have missed a few) is
already a challenge. And I imagine for people new to Qt it can even be a
strong deterrent (after all, strings are something you tend to use even in
a simple Hello World - the first app most people see or write in a new
language/ framework).


> The right way to handle this is for those methods to be templated, in
> which case a) the code only needs to be written O(1) times, not O(N)
> times, and b) users can potentially specialize for their own string
> types as well.
>
> If done cleverly, even the (pointer, size) variants should be able to
> wrap the arguments in a View, such that those method definitions are
> trivial.
>
> --
> Matthew
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Opinions on QTBUG-71545

[Tomasz Siekierda]

On Mon, 5 Nov 2018 at 20:32, Konstantin Shegunov  wrote:
>
> Hello,
> Since we couldn't agree, I'd love to see some more opinions about this one.[1]
>
> Specifically:
> 1) Is parenting to the application object a thing?

Never done it myself. But Q*Application is clearly marked as derived
from QObject in the docs, so users can definitely expect it to behave
the same as all other QObjects and clean up it's children properly.

> 1.a) ... and should it be allowed (i.e. accepting the proposed change)?
> 1.b) .. if not allowed, should we put a warning in the documentation that it 
> is wrong and shouldn't be done at all, or at least that it's discouraged.

Either is OK I think, with preference for 1.a). Note: these are not
mutually exclusive - we could have the patch integrated & a warning in
the docs that this is not encouraged.


Disclaimer: I'm not a reviewer, nor approver, barely a contributor
even, so feel free to ignore my opinion.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] wip/cmake status information

[Tomasz Siekierda]

On Mon, 29 Oct 2018 at 13:31, Tobias Hunger  wrote:
>
> Hi!
> [...]
> # Building
>
> The basic way of building with cmake is as follows:
>
> ```
>  cd {build directory}
>  cmake {path to source directory}
>  cmake --build .
> ```

Just a quick question wrt to that snippet: what is the planed way of
building Qt after the whole transition is done? Will it be cmake &&
make, or configure && make, or configure && cmake && make?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Tomasz Siekierda]

> > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda :
> > Hi Alexey, I've just read the QUIP proposal and couldn't find any
> > controversial sentences. Could you elaborate? Which points shall be
> > discussed?
> >
> > > The controversial discrimination protection sentences at least should be 
> > > carefully discussed. It's not some thing that we could accept as easy as 
> > > rewrite.

On Sun, 28 Oct 2018 at 11:34, Alexey Andreyev
 wrote:
>
> Hello, Tomasz! :)
> Thank you for the question!
>
>
> [...]
>
> Do we have any research about effects it leading?
>
> How many discrimination suspicions do we have right now?
>
> How could it be resolved successfully at digital community?
>
> How many misuse examples do we have at open projects since accepting similar 
> rules?
>
> How CoC board are going to protect community from discrimination and 
> harassment?
>
> Are CoC committee ready for "affirmative action"?
>
> [...]

So, as far as I see you have not identified any controversial
sentences either, your questions are more general and have been
answered already (see people reporting on successes of KDE CoC and
problems with kernel one).

Regarding:

> How CoC board are going to protect community from discrimination and 
> harassment?

The text is clear - actions will be taken to stop the discrimination.
That involves technical means (kick / ban) but also more social means
(talking with both parties, trying to mediate, trying to understand
what is going on etc. - all this is mentioned in CoC draft).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Tomasz Siekierda]

> The controversial discrimination protection sentences at least should be 
> carefully discussed. It's not some thing that we could accept as easy as 
> rewrite.

Hi Alexey, I've just read the QUIP proposal and couldn't find any
controversial sentences. Could you elaborate? Which points shall be
discussed?
On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov  wrote:
>
> On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira  
> wrote:
>>
>> The answer to all of those questions needs to be "yes". Anything short of 
>> that
>> means the CoC is powerless and just for show.
>
>
> Which was my point exactly.
>
>>
>> Whether there's a termination of employment or not is out of scope, since the
>> CoC does not rule TQtC employment and what other work there is inside that
>> company.
>>
>>
>> Note also it applies to any company. If you're not welcome anymore in the
>> community where your employer is asking you to do work, that is going to
>> affect your employment.
>
>
> I agree. However my argument was that the QtC being a major contributor to 
> the codebase is going to have to abide by the ruling of the proposed 
> committee, which is a significant commitment (and a major nitpick I admit).
> ___
> 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] Gerrit "no matching cipher found"

[Tomasz Siekierda]

Perfect, that worked! Thanks, Konstantin!

And thanks Thiago for explanation, too.

On Wed, 10 Oct 2018 at 21:43, Thiago Macieira  wrote:
>
> On Wednesday, 10 October 2018 10:43:32 PDT Tomasz Siekierda wrote:
> > I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is
> > correct. And I've used init-repository script to get going.
> >
> > Does anybody know how to fix this? Most probably it's something stupid/
> > trivial.
>
> Most Linux distributions or possibly OpenSSH upstream have begun disabling
> older ciphers by default. Our Gerrit server uses an old version of JGit, which
> uses old ciphers. You need to turn something back on. See Konstantin's reply
> for a suggestion on which one.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Gerrit "no matching cipher found"

[Tomasz Siekierda]

Hi,

it's been a while since I've last pushed to gerrit. I'm getting this:

$ git push gerrit HEAD:refs/for/dev
Unable to negotiate with 54.229.21.112 port 29418: no matching cipher
found. Their offer: aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is
correct. And I've used init-repository script to get going.

Does anybody know how to fix this? Most probably it's something stupid/ trivial.

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

Re: [Development] [Qt-creator] Requesting repository for telemetry plugin in Qt Creator

[Tomasz Siekierda]

Another point: if you do collect usage data, please bear in mind that
sometimes a feature can be used very rarely, but still be vital. In other
words, do not consider a feature as "unnecessary" or "can be deprecated" if
it is not used often.

For example, I mostly do mobile and desktop apps, but I still do want the
remote linux deployment to work smoothly for rare occasions when I need to
use it.

On 22 February 2018 at 20:05, André Pönitz  wrote:

>
> On Thu, Feb 22, 2018 at 04:42:55PM +0300, Konstantin Tokarev wrote:
> > 22.02.2018, 16:39, "Ryein Goddard" :
> > > This might be nice to make pretty charts to show to managers, but to be
> > > completely honest I think it is 100% useless.
>
> I fully subscribe to that.
>
> > > If you don't know what people
> > > are using your software for, or how then you aren't communicating with
> > > them.  You know once upon a time companies just talked with people to
> figure
> > > out what they wanted and what they were having difficulties with.  Why
> not
> > > just take a few surveys a year?
> >
> > Well, there are things that are hard to report via survey, e.g. rate of
> > crashes or memory leaking in clangbackend
>
> Any number for a "measured" value for rate of crashes or memory leaks
> is uninteresting for me when I run into the problem myself reqularly.
> And trust me, I do.
>
> As someone who has been working on Qt Creator for more than a decade I
> *do* know
> about issues in the IDE by my own use of it, by the significant backlog of
> bug
> reports in JIRA, and by interacting with (sometimes referred to as
> "talking to")
> actual users.
>
> The currently 399 open issues assigned to me personally would already be
> enough
> to keep me busy for approximately a $WHILE, full time, not including time
> spent in
> review processes etc.
>
> I certainly do not need another input channel that makes me spent time on
> guessing how the information that "user A spent at time B an amount of C
> minutes
> working on project named D" will translate into making my work more
> efficient
> nor in how to improve Qt Creator in general. In fact, I consider all of
> that
> irrelevant and detrimental and would strongly prefer to *not* get access
> to such
> information, and neither to anyone's interpretation what bug report this
> information may relate to.
>
> That makes a clear -1 from my side for technical reasons already.
>
> Neither legal nor ethical considerations are likely to improve that.
>
> Andre' (not speaking for any company etc etc)
> ___
> 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] [BB++] Now is 3.5x faster than Node.JS

[Tomasz Siekierda]

On 25 July 2017 at 03:09, Phil Bouchard  wrote:
> That's why you have to put chances on your side. Regarding the GC all you
> have to do is look at the logs:
> http://www.war-worlds.com/blog/2012/06/on-android-garbage-collection-can-kill-you

What killed the performance in this case was not GC but bad design,
unfit for the platform. Read the article through, and the comments. In
the end, the author got comparable performance on Android and desktop
(while Android was still using GC). Additionally, the post is from 5
years ago, a lot could have been improved in that period.


Mind you, the bb++ idea seems tempting. JS is not the nicest language
around, it would be cool to have an alternative, esp. if the learning
curve is small and benefits large. I'd just prefer it to be compiled
at compile time (at the same time when C++ part is compiled), cause
shipping the compiler with an app seems wasteful at best.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery?

[Tomasz Siekierda]

On 30 November 2016 at 17:14, Friedrich W. H. Kossebau  wrote:
>
> And seeing that KDE uses /usr/share/doc/HTML for documentation in html/
> docbook(?) format I am for now proposing
> /usr/share/doc/QCH

Sounds good.

And just to add my voice - I think automatic pickup of QCH files is
something very worth introducing (and not only on Linux).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 5.5.1 ChangeLog contains important information, please make sure it's in the announcement

[Tomasz Siekierda]

On 23 September 2015 at 21:47, Thiago Macieira
<thiago.macie...@intel.com> wrote:
> On Wednesday 23 September 2015 08:42:55 Tomasz Siekierda wrote:
>> * Fixed a minor source-incompatibility between Qt 5.4 and 5.5.0
>> involving sets of functions overloaded on QTime and some integer or
>> QDate and some integer."
>>
>> Sorry, what? This could use some rephrasing
>
> Lack of parentheses in the language...
>
> sets of functions overloaded on (QTime and some integer) or
> (QDate and some integer)
>
> commit eda79a467ee7e45f3de63973b633e2a790b613eb
> Author: Marc Mutz <marc.m...@kdab.com>
> Date:   Thu Jun 25 22:34:58 2015 +0200
>
> QDate/QTime: fix SiC introduced by adding new non-explicit ctors
>
> The new constructors were added in c94d41d9 to help
> constexpr'ify QDate and QTime. Even though private,
> they participate in overload resolution and break
> function pairs overloaded on QDate and int or
> QTime and int.
>
> Mark them explicit.
>
> [ChangeLog][QtCore][QDate/QTime] Fixed a minor source-incompatibility
> between Qt 5.4 and 5.5.0 involving sets of functions overloaded on
> QTime and some integer or QDate and some integer.
>
> Change-Id: I65a09aaca2b083cda90255c24cc72ef51119d3b1
> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoff...@woboq.com>
>
> diff --git a/src/corelib/tools/qdatetime.h b/src/corelib/tools/qdatetime.h
> index 78ec2b1..6651efd 100644
> --- a/src/corelib/tools/qdatetime.h
> +++ b/src/corelib/tools/qdatetime.h
> @@ -59,7 +59,7 @@ public:
>  StandaloneFormat
>  };
>  private:
> -Q_DECL_CONSTEXPR QDate(qint64 julianDay) : jd(julianDay) {}
> +explicit Q_DECL_CONSTEXPR QDate(qint64 julianDay) : jd(julianDay) {}
>  public:
>  Q_DECL_CONSTEXPR QDate() : jd(nullJd()) {}
>  QDate(int y, int m, int d);
> @@ -138,7 +138,7 @@ Q_DECLARE_TYPEINFO(QDate, Q_MOVABLE_TYPE);
>
>  class Q_CORE_EXPORT QTime
>  {
> -Q_DECL_CONSTEXPR QTime(int ms) : mds(ms)
> +explicit Q_DECL_CONSTEXPR QTime(int ms) : mds(ms)
>  #if defined(Q_OS_WINCE)
>  , startTick(NullTime)
>  #endif

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

Re: [Development] 5.5.1 ChangeLog contains important information, please make sure it's in the announcement

[Tomasz Siekierda]

On 23 September 2015 at 08:08, Knoll Lars  wrote:
>
> On 23/09/15 06:12, "Thiago Macieira"  wrote:
>>Also, please don't link to individual modules' changelogs. People won't
>>read
>>that. I prepared a master changelog, which you can find at
>>
>>https://codereview.qt-project.org/#/c/126113/1/dist/changes-5.5.1-master
>>

"- QDate/QTime:
* Fixed a minor source-incompatibility between Qt 5.4 and 5.5.0
involving sets of functions overloaded on QTime and some integer or
QDate and some integer."

Sorry, what? This could use some rephrasing ;-)

In general, though, thanks for doing this, a master changelog is a
good idea, more convenient than the old system.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QNoDebug - available but undocumented

[Tomasz Siekierda]

On 31 July 2015 at 10:26, Smith Martin martin.sm...@theqtcompany.com wrote:
 qdebug.cpp should contain a comment like this:

 /*!
   \class QNoDebug
   \internal
 */

Well, it does not contain this comment.

Olivier Goffart:
 It's a fake class that replaces QDebug when QT_NO_DEBUG_OUTPUT is defined.
 That way the code compiles but is optimized away.

Thanks for the explanation. I've asked because I've been surprised to
see it being used in some project like this:

#ifdef DEBUG_FETCHER
#define fetcherDebug qDebug()
#else
#define fetcherDebug NoDebug()
#endif

as a temporary solution to enable debug output of a new feature.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QNoDebug - available but undocumented

[Tomasz Siekierda]

Hi,

just a quick observation: QNoDebug class can be used in code (compiles,
works fine), but there is no documentation for it.

Is that intentional? Shouldn't it be either hidden (made private) or
documented? Although I have just learned about it's existence by accident,
it looks like it can be quite useful, so I vote for adding some docs.

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

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Tomasz Siekierda]

On 17 July 2015 at 11:02, André Somers an...@familiesomers.nl wrote:
 But I separated key and values into different containers, so even at optimum,
 you get two cache hits instead of one with QHash. As Ossi pointed out in the
 review, that's probably a pessimisation unless you have a very loaded
 container. Likewise, OptionalT, required to mark entries as empty or
 occupied, isn't optimized at all. all but doubling the space required for 
 most
 keys because of the pairing with a bool.

 As I said, it's WIP.

 What might also be a consideration when making a container like this, is
 that I find the key is often (not always of course) already part of the
 value data structure. For instance, if I store employee records and key
 them by id, that id is also in the record itself. It would be nice to
 have a fast and friendly key-based container that could handle that
 without duplicating the data...

Woah, a big +1 to that!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Quick Controls for Embedded

[Tomasz Siekierda]

On 8 April 2015 at 17:35, Oswald Buddenhagen
oswald.buddenha...@theqtcompany.com wrote:
 On Wed, Apr 08, 2015 at 04:39:52PM +0200, Frederik Gladhorn wrote:
 On Wednesday, April 08, 2015 04:30:23 PM Oswald Buddenhagen wrote:
 so ideally we find the perfect new name for both module and
 repository. Sadly we didn't manage to come up with a great name in a
 few hours of brain storming.

 i think quick controls 2 will work just fine. it's not like people are
 not used to asynchronous versioning in the qt quick world.

 but anyway, here are some more ideas:
 - the classic: qt quick controls NG
 - the diet: qt quick controls light
 - the thesaurus: qt quick widgets
 - the cynic: qt quicker controls

I like QtQuick.LightControls.

In general, since both sets are drastically different (in way they
look like, in the way they perform, in styling capabilities, etc.) I
do not think giving them similar names (Controls 1 and Controls 2) is
a good idea - it may strongly confuse the users. Not everybody follows
the mailing list and blog, so if you name them similarly you can
expect a flood of questions like I'm trying to use the new Controls,
but X does not work, and Y looks different, while Z can't read my
style definition etc.
___
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

[Tomasz Siekierda]

On 20 February 2015 at 12:52, Alejandro Exojo s...@badopi.org wrote:
 El Thursday 19 February 2015, Tomasz Siekierda escribió:
 So those companies/ users of QNX are not willing to upgrade their OS,
 compiler, but they are willing to upgrade Qt?

 I think the main problem with requiring a very up to date Qt is that sometimes
 only newer versions of Qt have bugfixes.

Same is true for the OSes and compilers...

In any case, I don't mind much. It would be nice to see Qt deprecate
old compilers, but if the general public says no, then so be it.
___
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

[Tomasz Siekierda]

On 19 February 2015 at 14:17, Rafael Roquetto rafael.roque...@kdab.com wrote:
 One of the many reasons for that is that many of those systems running QNX 
 are homologated and
 changing/upgrading involves lots of different process apart from the technical
 stuff.

So those companies/ users of QNX are not willing to upgrade their OS,
compiler, but they are willing to upgrade Qt?

In my experience, people who stick to old versions of operating
systems are also not very keen on upgrading other software as well...
so for them, it should not matter, whether the newest Qt version will
drop old compiler support or not.
___
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?)

[Tomasz Siekierda]

On 20 January 2015 at 05:23, Thiago Macieira thiago.macie...@intel.com wrote:
 On Tuesday 20 January 2015 00:47:50 Lisandro Damián Nicanor Pérez Meyer wrote:
 I think there is a point which we might be missing in this long thread. For
 Qt5 we are not asking for a simple rename because that *would* break stuff
 for other people, and that's not fair. What we ask is *adding* an
 executable with a suffixed -qt5, be it as a symlink where the OS allows it
 or as copy of the executable if there is no other way out.

 You're forgetting the documentation. It's not just adding the symlink or new
 binary. We have to tell people that this is what they should use.

 If we're going to do this, we should do it for ALL operating systems and all
 builds, plus adapt Qt Creator.

I know this is not high on the priority list, but please also consider
new users of Qt (there are many of them!), who often try to learn
using old books and forum posts, and look into the documentation only
when threatened with fire. And updates to docs and examples often come
months/ years after a change in Qt happens.

Right now an instruction that can be given to any noob is:
if you want to compile your project, just run
qmake
make/ nmake/ mingw32-make/ jom

Now that is already confusing to a lot of people (what? What does
make/ nmake/ jom mean? Which should I choose?). I imagine changing
this instruction to:
if you want to compile your project, just run
qmake/ qmake-qt5/ qmake-qt6
make/ nmake/ mingw32-make/ jom

I think this makes the just run expression rather laughable.
Transition from Qt4 to Qt5 was already painful for people learning to
code, for whom even simple things like add QT+=widgets to .pro file;
don't run this example, it has not been updated yet; sorry, the
deployment process has been changed completely is a challenge.

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

Re: [Development] RFC: Improved Q_ENUM

[Tomasz Siekierda]

On 15 December 2014 at 14:38, Olivier Goffart oliv...@woboq.com wrote:
 Any opinions or comments?

Quick and simple comment from me: this feature sounds great! A big,
shiny +1 from me. It will come in handy in many projects I am involved
with.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Is QMap Broken

[Tomasz Siekierda]

 On 06. 11. 14 09:13, André Somers wrote:
 Tomasz Siekierda schreef op 6-11-2014 09:10:
 To store 2 items at a single position in list/ vector, you can use
 QPair, like this: QLIstQPairtype1, type2 ()
 Better yet, just use a struct then. QPair in my experience results in
 badly readable code. Who will ever remember down the line what was
 first, and what was second? And the moment you end up needing a third
 item, QPair is insufficient anyway.

Yeah I agree, that sounds much better. Thanks.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

[Tomasz Siekierda]

 This was discussed to exhaustion in Qt 5's development process. The 
 conclusion
 is to remain at status quo since there is no good, technical solution.

 I’d think that the solution could be to use a dedicated class for file 
 names, perhaps with a base class for uninterpreted platform strings.

Ugh, that begins to sound like Java. Let's have a wrapper for a
wrapper... please don't go that way.

  How do you pass it on the command-line? Mind you, QProcess takes a
  QStringList
  for arguments.

 It look as if we’d need something like QPlatformString that’s a “thin”
 wrapper
 around a QByteArray on unices, and around QString on Windows.

 No, thanks! :)

I fully agree with no, thanks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Contribution proposal: Dispatcher class

[Tomasz Siekierda]

On 24 September 2014 11:34, Sune Vuorela nos...@vuorela.dk wrote:
 On 2014-09-24, Yam Marcovic ymar...@gmail.com wrote:
 However, I will say I don't want to force people to give their sources away
 if they use it.

 So a license along the lines of 'this license is here for formal purposes;
 but feel free to do anything you want with this,' is good enough as far as
 I'm concerned.

 I think the formal way of expressing this is either the MIT, 2 or
 3-clause BSD licenses.

 http://opensource.org/licenses/BSD-3-Clause
 http://opensource.org/licenses/BSD-2-Clause
 http://opensource.org/licenses/mit-license.html

 /Sune

This is probably the simplest you can go: WTFPL http://www.wtfpl.net/about/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt use under LGPL and exceptions to it

[Tomasz Siekierda]

Hi,

one of our forum users has spotted a curious discrepancy in Qt
licensing texts. It turns out, that the online docs have this
paragraph at the bottom of LGPL license text:
Digia Qt LGPL Exception version 1.1

As a special exception to the GNU Lesser General Public License
version 2.1, the object code form of a work that uses the Library
may incorporate material from a header file that is part of the
Library. You may distribute such object code under terms of your
choice, provided that the incorporated material (i) does not exceed
more than 5% of the total size of the Library; and (ii) is limited to
numerical parameters, data structure layouts, accessors, macros,
inline functions and templates.

(link: 
http://qt-project.org/doc/qt-5/lgpl.html#digia-qt-lgpl-exception-version-1-1)

However, this paragraph is *not present* in the license file on
gitorious, and the LGPL exception placed in a separate file
(LGPL_EXCEPTION.txt) has a completely different wording:

Digia Qt LGPL Exception version 1.1
As an additional permission to the GNU Lesser General Public License version
2.1, the object code form of a work that uses the Library may incorporate
material from a header file that is part of the Library. You may distribute
such object code under terms of your choice, provided that:
(i) the header files of the Library have not been modified; and
(ii) the incorporated material is limited to numerical parameters, data
structure layouts, accessors, macros, inline functions and
templates; and
(iii) you comply with the terms of Section 6 of the GNU Lesser General
Public License version 2.1.
Moreover, you may apply this exception to a modified version of the Library,
provided that such modification does not involve copying material from the
Library into the modified Library's header files unless such material is
limited to (i) numerical parameters; (ii) data structure layouts;
(iii) accessors; and (iv) small macros, templates and inline functions of
five lines or less in length.
Furthermore, you are not required to apply this additional permission to a
modified version of the Library.

(link: 
https://qt.gitorious.org/qt/qtbase/source/4cb03924c113c74b99e18c7347278600a011e917:LGPL_EXCEPTION.txt)

Those 2 exceptions seem to contradict themselves, in my opinion (the
first one restricts our rights, while the other one expands them). Can
anybody throw some light on what is going on here? Which LGPL
exception should be followed by the users? Both? Or only the one
distributed with the source code?

Please see the original discussion here:
http://qt-project.org/forums/viewthread/44082/

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

Re: [Development] Qt use under LGPL and exceptions to it

[Tomasz Siekierda]

On 22 June 2014 15:43, Thiago Macieira thiago.macie...@intel.com wrote:
 Em dom 22 jun 2014, às 11:08:40, Tomasz Siekierda escreveu:
 Those 2 exceptions seem to contradict themselves, in my opinion (the
 first one restricts our rights, while the other one expands them). Can
 anybody throw some light on what is going on here? Which LGPL
 exception should be followed by the users? Both? Or only the one
 distributed with the source code?

 An exception cannot restrict the rights. Both expand: both are granting you
 the right to distribute binaries that incorporate a certain amount of code
 from Qt into the binary. That is necessary due to the nature of inline and
 template functions -- most C++-based projects carry an LGPL exception like
 that.

 In any case, the one in the source code is the valid one.

Thanks, that is what I suspected.

So the one in the documentation should probably be updated. Maybe I'll
push a fix if I find some spare time to do it.

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

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

[Tomasz Siekierda]

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/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Harmonizing the Qt 5.x Documentation

[Tomasz Siekierda]

On 11 March 2014 10:01, Pasion Jerome jerome.pas...@digia.com wrote:
 Hello all,

 Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1
 documentation
 to Qt 5 documentation. Subsequently, we will remove the 5.0 and 5.1
 documentation
 from qt-project.org and we will place future Qt 5.x documentation in
 Qt 5 (http://qt-project.org/doc/qt-5/).

Nothing much to say, apart from a +1 from me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Fwd: Qt open source license in product

[Tomasz Siekierda]

On 5 March 2014 10:13, Ramakanthreddy Kesireddy
ramakanthreddy.kesire...@techmahindra.com wrote:
 I have read something like below:

 Applications using Qt that use the open-source licenses need to follow the
 same license, so their source would need to be made available.

 We are using Qt Open source license under LGPL v2.1 + execption.



 Do we need to make our application source code available in this regard?

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

Re: [Development] GCompris goes the Qt Quick route

[Tomasz Siekierda]

On 9 February 2014 14:56, Bruno Coudoin bruno.coud...@gcompris.net wrote:
 Hi,

 For those who don't know me, I am the author of the educational software
 GCompris (http://gcompris.net). The project started in 2000 and is based
 on Gtk+.

 As you imagine, many users are requesting us a tablet version of
 GCompris and I tried to evaluate the different technical possibilities
 to bring GCompris to this world.

 After some research, I found that the Qt Quick technology was an
 excellent choice for the future of GCompris. Sadly there is no easy
 migration path and this implies a full rewrite. It is true that the
 migration will take time, probably several years but this is something
 we have to do if we want to stay relevant in the coming years.

 Expect our little community to be around to gather help on Qt Quick.

 Bruno.

Hi and congratulations! I'm pleased to hear that and I hope you won't
have reasons to regret your decision :)

If you will need help on your quest, feel free to ask on Interest
mailing list and/ or qt-project.org forums.

Have a great time and happy coding!
sierdzio
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] Gerrit disapproval messages

[Tomasz Siekierda]

On 26 January 2014 09:06, Orgad Shaneh org...@gmail.com wrote:
 Hi,

 Following this discussion from about a year ago,

 gerrit has recently accepted a wording change for default -1 and -2
 Code-Review labels.

 The scores are now:
 -1 - I would prefer this is not merged as is
 -2 - This shall not be merged

 I suggest configuring qt-project gerrit to something similar.

 Opinions?

A big +1 from me. I know this might sound unimportant or even silly
for people with some Gerrit experience, but the current wording really
does put off newbies. I can definitely remember the rejection I felt
when I've first seen a -1 for my patch ;) The thing is that in gerrit
it's not so easy (especially when you see it for the first time) to
actually notice that the text is just a standard template. One assumes
it comes directly from the reviewer, and the lyrics used are not very
nice :)

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

Re: [Development] [Qt-creator] Gerrit disapproval messages

[Tomasz Siekierda]

On 26 January 2014 20:41, Thiago Macieira thiago.macie...@intel.com wrote:
 On domingo, 26 de janeiro de 2014 18:31:18, Tomasz Siekierda wrote:
  The scores are now:
  -1 - I would prefer this is not merged as is
  -2 - This shall not be merged
 
  I suggest configuring qt-project gerrit to something similar.
 
  Opinions?

 A big +1 from me. I know this might sound unimportant or even silly
 for people with some Gerrit experience, but the current wording really
 does put off newbies. I can definitely remember the rejection I felt
 when I've first seen a -1 for my patch  The thing is that in gerrit
 it's not so easy (especially when you see it for the first time) to
 actually notice that the text is just a standard template. One assumes
 it comes directly from the reviewer, and the lyrics used are not very
 nice

 -1 actually means I think this needs change, but if someone else approves it,
 I'm not against it

Sure, I know that now, and with that knowledge I don't really mind the
current text (or any other one: when I see -1, I simply know what it
means). That is why I say it's about newcomers. Getting one's head
around all the bureaucracy required to submit a patch to Qt (making
sure the patch is sent correctly to Gerrit is especially scary) is
pretty hard already. If one then sees the current text for -1 and -2,
one can really get discouraged enough to abandon the idea of sending
more patches. I know that from my own experience, and from several
hints I got from some users of our forums.

I do think we should get back to the actual question in the topic, though :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5, Widget move events, and the bug that won't die

[Tomasz Siekierda]

On 13 January 2014 21:12, Alex Montgomery apmontgom...@gmail.com wrote:
 Hello,

 I understand that Widgets are considered complete in Qt5, and no new
 features are going to be added, but it's seeming more and more like the
 actual position of developers is that Widgets are fully deprecated.

I have no comment on the actual issue, but I think you are wrong in
claiming that widgets are effectively deprecated. See the what's new
in Qt 5.2 in QtWidgets section, for example:
https://qt-project.org/doc/qt-5/whatsnew52.html#qt-widgets
and the list of bugfixes:
https://qt.gitorious.org/qt/qtbase/source/7edb5f22bf78cf2691145ab4160998c7b7f9416a:dist/changes-5.2.0#L387

there is quite a lot going on in Widgets :)

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

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

[Tomasz Siekierda]

On 27 November 2013 10:09, Koehne Kai kai.koe...@digia.com wrote:
 Subject: Re: [Development] New Qt 5.2 snapshot build #172

 Hi all.

 I find this one: https://bugreports.qt-project.org/browse/QTBUG-35002

 I cannot remember any other related to 5.2 RC1 installer fonts. Do you see 
 this is blocking RC1? I agree this don't   give good first impression but 
 still I am wondering if this is bad enough to delay to RC1...

 I don't think so. Let's try to upgrade the Qt used in the IFW, but it 
 shouldn't block the RC1.

This is a known Qt bug. Affects me with Qt 4.8.5 on OS X Mavericks.
See here for a possible solution
http://successfulsoftware.net/2013/10/23/fixing-qt-4-for-mac-os-x-10-9-mavericks/

Or go directly to the bug report
https://bugreports.qt-project.org/browse/QTBUG-32789

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

Re: [Development] Rebuilding Qt5 after adding -prefix fails to link due to missing zlib options

[Tomasz Siekierda]

On 11 April 2013 19:46, Jan Kundrát j...@flaska.net wrote:
 I've managed to accidentally reproduce this error on two machines (Gentoo 
 Linux, gcc 4.6.x,... and a RHEL6 clone). Can I somehow requse what I've built 
 so far, or do I have to clear everything and wait again? :)

Wrong ML. This is better suited for Interest list. Short story: clean
and run configure again. Easy with git, harder if you use tarballs
(although maybe make confclean works now, I have not checked). Invest
in a good CPU if possible - with make -j9 Qt5 compiles in about 23
minutes (15-18 minutes if you're using clang) on my notebook.

Long story: you can probably do some qt.conf magic to use what you
already have, but I'm not experienced there so I cannot help.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Taking the new download system into production

[Tomasz Siekierda]

On 5 April 2013 16:01, Turunen Tuukka tuukka.turu...@digia.com wrote:
[..]
 We
 are also looking into leveraging torrents as an additional way of
 downloading files.

 I hope we continue to receive more mirrors for Qt Project in the coming
 weeks. If you are interested in mirroring Qt, see instructions how to become
 a mirror from the Qt Project wiki. Also, feel free to ask you local mirror
 providers to start mirroring Qt. The more mirrors, the merrier.

Can't mirror myself, but I'll be more than happy to join the torrent
swarm as a seeder :)

Cheers for this update,
Tom
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposition for a new Q_OS_ define

[Tomasz Siekierda]

On 23 March 2013 01:51, Jake Thomas Petroules
jake.petrou...@petroules.com wrote:
 I'd like to suggest that we add a new Q_OS_ define.

 Currently, for Apple platforms, we have:

 Q_OS_DARWIN
 Q_OS_DARWIN32
 Q_OS_DARWIN64
 Q_OS_IOS
 Q_OS_MAC
 Q_OS_MAC32
 Q_OS_MAC64
 Q_OS_MACX

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

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

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

 Any objections? If not, dev or stable?

Sounds good to me, although adding another macro might just confuse
people even more.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 答复: [Qt-interest] QMultiHash

[Tomasz Siekierda]

On 7 March 2013 10:58, pengliang(彭亮) pengli...@founder.com wrote:
 2.   so I need to use Qmaplong,Qstring,

 I found qt source code below, so I think Qhashlong,Qstring is ordered by
 long, am I right?

That's probably just the hash value. As far as you - user - are
concerned, this is arbitrarily ordered.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about Qt5 and android official release plans

[Tomasz Siekierda]

On 5 March 2013 16:46, Oleg Shalnev oleg.shal...@gmail.com wrote:
 Does anyone know about of plans for official Qt5 release for android
 platform.

Qt 5.1 will sport a preview version, AFAIK. You can test it already by
checking out newest sources from git. Same goes for iOS port.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Remote use of resources for cross-platform checking of solutions.

[Tomasz Siekierda]

On 2 March 2013 18:41, Denis Shienkov scap...@yandex.ru wrote:
 For remote access, suggest using TeamViewer.

 Or, if this is not possible, may be someone of the users (from
 community) can be provide the resources of its OS to solve problems?

I don't own a Mac, but I have one at my work place. I could test some
stuff myself for you, but I'm afraid getting a remote session will not
be possible (company network, firewalls, etc.). And, I'm there only in
office hours, of course (~7-15 CET/ CEST).

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

Re: [Development] Proposal - QtSerialPort graduation from the Playground

[Tomasz Siekierda]

Hi,

I just want to drop in with a little thank you and basically to share my
thoughts about QtSP. Last week I've built a project using QtSerialPort
(with Qt4) to communicate with an Arduino board, and tested it on Linux
(Ubuntu and Kubuntu) and Windows (7 and embedded), on numerous PCs (VM,
laptop, embedded board, standalone PC). Works like a charm - installation
is easy, API very clear, easy to grasp and done in Qt-style, documentation
is good (maybe not fully mature, but more or less complete) and in general
it just works.

Good job, people, congratulations! I'm happy to see this becoming part of
Qt.

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

Re: [Development] Cleaner code base patches

[Tomasz Siekierda]

On 28 January 2013 09:57, Thiago Macieira thiago.macie...@intel.com wrote:
 Options are:

 1) always with -developer-build
 2) on by default on -developer-build, but the CI disables it
 3) completely optional, CI enables it
 4) completely optional, not enabled by the CI

 I favour options 1 or 2.

I would vote for 1), but it can cause problems in bigger releases
(remember amount of warnings before Qt5 alpha?).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5 for Android developer mailing list

[Tomasz Siekierda]

 Having a separate list is caring about others like me who are not
 interested in the Android port development. ;-)

A list for Necessitas already exists (for a long time), along with a
Google Group.
https://mail.kde.org/mailman/listinfo/necessitas-devel
https://groups.google.com/forum/#!forum/android-qt

Can't they be used, especially if the aim is to make it only a
temporary thing? Or is the plan to keep Necessitas separate from Qt
Project port?

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

Re: [Development] [Interest] Future of Qt Opensource SDK?

[Tomasz Siekierda]

 A couple of people have requested this:
 http://lists.qt-project.org/pipermail/releasing/2012-September/000634.html
 This is from the Director of Qt RD at Digia, so I think you can count
 on it. The SDK is dead for non commercial customers. If you disagree,
 you just might have found your new pet project :)

I think it would be a good idea to remove the SDK from qt-project's
Downloads page, then. On the forums I have to instruct several people
a week that they should download libraries and Creator separately
(quite literally, really - this week alone there were at least 4
threads started by people having queries about the SDK).

The problem is that the SDK is still the topmost link on the page, so
most people, and especially newbies, click it. Would be good to either
remove it, or - better - simply move it to bottom of the page or to
some Archive  or Legacy section.

Cheerio,
sierdzio

PS. Pinging the development so that hopefully someone responsible for
this site sees this. Sorry for the noise.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML Component inheriting?

[Tomasz Siekierda]

 What i really miss in QML is the ability to let a component inherit
functionality from another component.

This is already a feature: just create your components in separate files
and use this:

// BaseButton.qml
Item
{
   property int someNum: 100
   ... the basics for a button.
}

// SpecialButton.qml
BaseButton // SpecialButton
{
   somenum: 500
   ... A BaseButton adjusted for special cases
}

// FancyButton.qml
BaseButton //FancyButton
{
   ... Fancy button with special effects, shaders and whatever you can
think of
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Move QAction from QtWidgets to QtGui

[Tomasz Siekierda]

Hi,

just a quick note regarding this:

 Would it not be possible to split QAction in two classes, just like
QApplication was split? We could perhaps create a QCoreAction

I think a better name would be QSimpleAction. Runs off the tongue a
bit more smoothly, plus the Core in the name will certainly make it
more associated with QtCore in peoples' minds, while you propose it to
go into QtGui. Otherwise, +1 from me for that idea, QAction is
seriously useful stuff.

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

[Development] MouseArea::onWheel event documented but not working (Qt5)

[Tomasz Siekierda]

Hi,

sorry for double posting but this is relevant for both Qt5 ML (as part of
testing) and Qt-qml (since that is where the issue lies). I am trying to
use the wheel event available in QtQuick 2.0  Qt5 in QML. Here is a code
snippet:

MouseArea {
id: whatever

onWheel: {
ScenarioLogic.aMethod(mouse); // both mouse and event do not
work
}
}

The event variable (according to docs, it should be named mouse, but I
have also tried event - to no avail) does not seem to be declared. Error
message: ReferenceError: mouse is not defined. I am using Qt5 build from
git, commit I7a10dca9ee8bc2158e9d211feb4005a29fb7b419 from 16 May 2012.
Platform is Kubuntu 12.04 x64 with standard xcb backend. The mouse area is
inside a Flickable, if that changes anything. Other mouse events work
without problems.

A quick search did not reveal any existing bugs for that. Is this bug
known? If not, I will create a bug report right away.

Cheers, have a good weekend guys,
sierdzio
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] MouseArea::onWheel event documented but not working (Qt5)

[Tomasz Siekierda]

On 2 June 2012 18:15, Luís Gabriel Lima luis.gabr...@openbossa.org wrote:

 Hi Tomasz,

 The correct event variable name is wheel and not mouse. I'll fix the docs.
 You can see an example in 
 examples/quick/mousearea/mousearea-wheel-example.qml.


 Cheers,
 --
 Luís Gabriel
 OpenBossa - INdT

Ah, OK, that was it. Many thanks!

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

[Development] Possible bug in signals and slots handling in QML.

[Tomasz Siekierda]

Hi,

in a recent conversation on QtDN, we have identified a possible bug in
QML (Qt Quick 1, that is. It's possible that the both issues affect
QtQuick2 too). We have also identified a confusing situation that can
be easily clarified in QDoc. First, a link to the discussion, then a
short recap on what is going on. Link:
http://developer.qt.nokia.com/forums/viewthread/12980/#69773

1. Capitalisation of private properties on slots.
Let's consider an example:
property int __test: 0
on__test: {} // does not work!
on__Test: {} // does work

I think, and it seems others back me here, that this is not exactly
intuitive. Usually, the first character gets capitalised, but in this
case, it's the third one. It can stay this way, of course, as it's not
a biggie, but it would be nice to update the documentation to prevent
problems in the future. Do you agree?

2. Signals and slots.
Using underscores in signals does work, but no default handler is
being generated. I'll use Lukas Geyer's example from the thread:
Item {
signal publicSignal
signal __privateSignal

onPublicSignal: { console.debug('onPublicSignal') }

Component.onCompleted: {
publicSignal();  // does work
__privateSignal();  // does work too
}

on__PrivateSignal: { console.debug('on_privateSignal') }   // does
not work, undefined property
on__privateSignal: { console.debug('on_privateSignal') }   // does
not work, undefined property
}

Is that an intended behaviour? Or maybe the handlers are being
created, but using a different naming scheme?

Best regards, and a happy new year,
sierdzio
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Possible bug in signals and slots handling in QML.

[Tomasz Siekierda]

@Craig:
Good to know, thanks. To be honest, I don't think anybody actually
tried double underscores for signal name, in the conversation on QtDN
it just cropped up as a sort of what if scenario.

But, to take it one step further - does that really matter in QML?
MOC, AFAIK, is using signals by their name (string), and QML code does
not get through C++ compiler.

@Martin:
 1. The capitalization of the first alpha character after the underscore is 
 deliberate.  Signal handlers are defined as being 'on' followed by a capital 
 letter.  Since underscore has no capital, it must be the first non-underscore 
 letter.

OK. If I don't forget to, I'll look into Qt5 docs to see if this is
stated there.

 2. on__PrivateSignal does work in Qt 5.0.  We won't be changing this in 
 earlier Qt versions.

Right, good to know.

I'll quote both of you on QtDN, to keep others updated - if you don't
mind. If you do, please write to stop me :)

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

[Development] Adding QML to qmake variables

[Tomasz Siekierda]

Hi,

working on some QML project now (my, I haven't suspected that Qt Quick
is THAT gorgeous... wow, thank you, Trolls, for making it!), an idea
struck me, that there is no variable in QMake to add QML files to the
project. While I am aware, that both DEPLOYMENTFOLDERS and OTHER_FILES
can be used to do just that, I feel QML deserves a separate keyword
just as much as source, headers, ui files do.

Now, this is not just about a keyword being there, there are 2 things
I have in mind here:
a) it would make Qt Creator show QML files in project (and maybe JS files, too?)
b) it would take care to copy those files during build (much like
DEPLOYMENTFOLDERS do, although this variable is not available in
official documentation, as far as I can see)

Alternatively, b) option could be added to OTHER_FILES.

Any thoughts? Good/ moderate/ insane idea? Or maybe it was already
discussed and rejected (a quick search did not give me any positive
results here).

Sadly, I have no experience in QMake development, so I won't be able
to help in implementation much, at least not without some initial
guidance (where to start).

Cheers,
sierdzio

PS. Blimey, I've just checked, and OTHER_FILES is also not documented...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Possible QDoc bug - no doc generated for a static overloaded method

[Tomasz Siekierda]

Hi,

as Andre suggested, I am bringing an issue for attention here. My
original post: http://developer.qt.nokia.com/forums/viewthread/8914/

QDoc does not generate documentation for
QWebServiceMethod::invokeMethod() static overloaded function, while
the other (non-static) overload works fine. No error or warning is
being raised, too. The app itself works flawlessly, at least when it
comes to that method.

Cpp file that the problem lies in:
https://gitorious.org/qwebservice/qwebservice/blobs/master/QWebService/sources/qwebservicemethod.cpp
Resulting QDoc file:
https://gitorious.org/qwebservice/qwebservice/blobs/master/QWebService/html/qwebservicemethod.html

Is this a QDoc bug or have I missed something? I've gone through a few
examples in Qt5 sources, and I can't see what's wrong with my code.
Removing \overload does not solve the problem.

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