Re: [Interest] What don't you like about Qt?

[Jean-Michaël Celerier]

On Tue, Nov 15, 2016 at 12:32 PM, Roland Hughes  wrote:

> This was old school grind it out trouble shooting which is not allowed
> under Agile.


My two cents: "$FOO is not allowed" *screams* "not agile".
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Roland Hughes]

This would be the second 2 fatal flaws with Agile.

Developer's choice

1 and done mentality/management. Actually that is better than some of 
the Agile groups at equipment manufacturers, some of them demand their 
developers commit 3 completed stories per day.


Big ugly Ogre on steroids type bugs don't get fixed, they simply rot 
until the product/company goes away. Moral is high but product quality 
is low.


On my current project, counting by the calendar, various team members, 
myself included, have put in over 1 month tracking down a memory leak 
problem. Each of us have found various parts of it, but there was 
nothing Agile about it. This was old school grind it out trouble 
shooting which is not allowed under Agile. Valgrind was near useless 
because it slowed the target down enough to require nearly a full 
overnight run but with Valgrind and the app running you ran out of 
memory within a few hours.


We may well have found the last piece of it on Friday, but, it will take 
some time to be sure. Grinding through the code by hand is a chore, 
especially when the project has north of 1 million lines and is growing 
daily.


---

Sorry for any discontinuity here. Started this reply many weeks ago, but 
have been heads down in the typical Agile catastrophe, no time to 
respond. Well, no time until now. Finally gave up and left the project.


No project started with Agile can ever be saved. Period!

Rather than continue this discussion here I'm going to dust off a title 
I hadn't scheduled for completion until 2019. I had done bits and pieces 
on it but this conversation has told me it is definitely time to finish 
and release it.


The T-Shirt was right.

http://www.zazzle.com/careful_or_youll_end_up_in_my_novel_t_shirt-235587332634897053

"The Phallus of Agile and Other Ruminations"  ISBN 978-0-9823580-9-2


On 10/04/2016 06:31 PM, interest-requ...@qt-project.org wrote:

There isn't, because developer selects the bugs they're going to fix. There's
common procedure.

My procedure is: I'll fix everything that is assigned to me, the moment it's
assigned, if I can. If I couldn't within one day, I won't be able to until
there's more information posted.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

> In years prior it was not uncommon to find major corporations with teams 
> of 40+ developers, many of them consultants, developing systems for 
> internal consumption. Large projects took (and still take) a minimum of 
> 7 years to spec, develop, test, install and finally settle in. During 
> that entire time the development costs were booked as assets. Now, under 
> the 1985 accounting rules change, they have to deliver "something" to 
> book as an asset. This means they skip the design because the detailed 
> design required for a successful project of any real size cannot be done 
> inside of a quarter. Instead they bang out absolutely useless chunks 
> shifting the salaries of people not even remotely involved in the 
> process into the Agile project so it can all be booked as an asset each 
> quarter.

In your last few emails, you've made some good points that I agree with. But 
this last paragraph reminds me of one of my favorite quotes: "Consultants: Why 
be part of the solution when you can be part of the problem?" The fact is 
consultants rarely have a vested interest when working solely on billable 
hours, and indeed this is what Agile addresses in several aspects:
1. Demos - show that it is done by end of sprint
2. Huddles 
- identify and eliminate blockers daily
- bidding of tasks to the fastest implementer

Taken all together, the former environment where opaque lazy consultants could 
thrive bilking hours from contracts (particularly federal) is eliminated and 
replaced where they must be transparent. The results speak for themselves. 

Now what you describe about the shifting is a problem unrelated to Agile 
software development. But it does sound like the business aspect is picking up 
on the Agile methodology. Speculatively, I suggest that it's because they have 
a greater level of transparency (and may be better execution?) so it's easier 
to justify to the higher-ups. Also, businesses are applying Agile to business 
practices because they see results. 

To repurpose a Stephen Colbert quote: "Reality has well-known [Agile] bias." 
For better or worse, Agile (and specifically the transparency aspect) is here 
to say. No longer can developers hide until the last minute to announce another 
last-minute delay. 



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jan Krause]

Am 18.10.2016 um 13:41 schrieb Viktor Engelmann:
I'm not even on board for TDD, because tests don't help you against 
interlocking-issues, data races, etc. and are only of limited use 
against many others like dangling pointers, subsequent memory 
corruption, UI freezing, etc.
This is a really interesting argumentation... what helps against these 
errors?... or how do you check your implementation??... debugging, 
running the app and checking the console, open the ui -> some clicks 
with the mouse and see what happens or what else do you do -> are tests 
at the end ...

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Roland Hughes]

On 10/18/2016 07:00 AM, interest-requ...@qt-project.org wrote:

  It's hard to
know when you're really done because you don't really have metrics to tell
you--or the customer--when the project/is/  done.
Per the 1985 accounting rules change, if you have a definition of "done" 
you cannot book the expense as an asset until you meet that definition.


http://www.fasb.org/summary/stsum86.shtml

Many of the biggest trumpets for Agile come from products of the 90s, 
the first era where nobody was expected to take responsibility for 
anything. Without a definition of "done" no matter how bad or useless 
something was it could _not_ be classified a failure because "it wasn't 
done."


Everybody gets a ribbon just for showing up.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Roland Hughes]

On 10/18/2016 07:00 AM, interest-requ...@qt-project.org wrote:

I'm not even on board for TDD, because tests don't help you against
interlocking-issues, data races, etc. and are only of limited use
against many others like dangling pointers, subsequent memory
corruption, UI freezing, etc.
Tests can only prove the existence of bugs, not the absence (Linus
Torvalds doesn't even use debuggers, for the same reason)
At the end of the day, you need competent developers for complex tasks -
no programming language, no framework, no SDLC will ever change that.
I'm totally against TDD because everything about it is a myth _and_ 
because it is a massive waste of developer time. Marketing types like it 
because they can say "our software undergoes X-thousand tests with every 
check-in" but those tests prove nothing. I recently stumbled onto a 
"test" where a developer connected to the finished() signal of a post() 
but not the error(). No matter how the post() exited they were marking 
that chunk of data in the database as successfully sent. This was their 
interpretation of the "story" and it resulted in significant data loss 
because data on the device exists for only a limited number of days but 
the back end has many TB available.


Let us not forget what NASA's venture into faster-cheaper-splat taught 
the world about TDD.

http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/
Both groups worked from their "stories" relentlessly testing their 
components without an overall architecture document.


There is _exactly_ one reason major companies are switching to Agile and 
it has nothing to do with the viability of the model. Agile is the only 
legal way to cheat accounting regulations.

http://www.fasb.org/summary/stsum86.shtml


This Statement specifies that costs incurred internally in creating a 
computer software product shall be charged to expense when incurred as 
research and development until technological feasibility has been 
established for the product. Technological feasibility is established 
upon completion of a detail program design or, in its absence, 
completion of a working model. Thereafter, all software production costs 
shall be capitalized and subsequently reported at the lower of 
unamortized cost or net realizable value. Capitalized costs are 
amortized based on current and future revenue for each product with an 
annual minimum equal to the straight-line amortization over the 
remaining estimated economic life of the product.



In years prior it was not uncommon to find major corporations with teams 
of 40+ developers, many of them consultants, developing systems for 
internal consumption. Large projects took (and still take) a minimum of 
7 years to spec, develop, test, install and finally settle in. During 
that entire time the development costs were booked as assets. Now, under 
the 1985 accounting rules change, they have to deliver "something" to 
book as an asset. This means they skip the design because the detailed 
design required for a successful project of any real size cannot be done 
inside of a quarter. Instead they bang out absolutely useless chunks 
shifting the salaries of people not even remotely involved in the 
process into the Agile project so it can all be booked as an asset each 
quarter.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jean-Michaël Celerier]

On Tue, Oct 18, 2016 at 1:41 PM, Viktor Engelmann 
wrote:

>
> A key part in that article: *"A complex back-end data services hub — a
> piece of software with zero actual, living, breathing end-users — has to be
> described in terms of “user” stories. Does something sound off-key to you?
> It should, because user stories are great for user interfaces but poor,
> confusing and often misconstrued for non-observable behavior." *


Uh ? User story is just just a pretty name for sequence diagram. I think
that you would need those especially in a 'complex back-end data services
hub'.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Viktor Engelmann]

Am 18.10.2016 um 12:31 schrieb Roland Hughes:
> https://gcn.com/blogs/reality-check/2013/11/healthcare-agile.aspx
>
> Contrary to your opinion, Healthcare.gov is a shining example of the
> faster-cheaper-splat that is Agile.

A key part in that article: /"A complex back-end data services hub — a
piece of software with zero actual, living, breathing end-users — has to
be described in terms of “user” stories. Does something sound off-key to
you? It should, because user stories are great for user interfaces but
poor, confusing and often misconstrued for non-observable behavior." /

That's precisely what I said earlier - Agile is good for front-ends, but
not for back-ends.

I'm not even on board for TDD, because tests don't help you against
interlocking-issues, data races, etc. and are only of limited use
against many others like dangling pointers, subsequent memory
corruption, UI freezing, etc.
Tests can only prove the existence of bugs, not the absence (Linus
Torvalds doesn't even use debuggers, for the same reason)
At the end of the day, you need competent developers for complex tasks -
no programming language, no framework, no SDLC will ever change that.

Viktor

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

viktor.engelm...@qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Roland Hughes]

On 10/17/2016 10:30 AM, Jason H wrote:

On 10/04/2016 06:31 PM, interest-requ...@qt-project.org wrote:
Similarly Healthcare.gov started off not Agile and ended Agile. 
Clearly, the problem isn't the methodology, it is your application of 
it. 


You know, I can forgive most of the dis-information of your posts as 
someone wanting to be the high priest of a false religion, but this one 
is inexcusable. Most major media outlets were paid by their advertisers 
to spew that lie about Healthcare.gov. People who do absolutely no 
research repeat it and the naive believe it. This _has_ to stop.


Those media outlets had not been following the project since its 
beginning like GCN was. GCN called them out on it. To date I have not 
heard of one having the ethical or journalistic integrity to print a 
retraction with the same fanfare and billing as the click-bait story.


https://gcn.com/blogs/reality-check/2013/11/healthcare-agile.aspx

Contrary to your opinion, Healthcare.gov is a shining example of the 
faster-cheaper-splat that is Agile.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

> On 10/04/2016 06:31 PM, interest-requ...@qt-project.org wrote:
> > I think the bigger issue, that many people have expressed here, but not 
> > said as such, is the Qt release cycle is not Agile.
> I would thank God it is not, but the rest of your post proves that it is.
> > As more teams adopt Agile development practices, the chasm between what 
> > user teams needs and what is being delivered grows.
> Well, only teams working on products with the life span of a fruit fly, 
> like a Web page. Most will be companies which go out of business. When 
> one is developing things which will inevitably have a 30+ year life span 
> or exist in a regulated environment Agile simply isn't an option. Think 
> payroll, accounts receivable, and most medical devices. Yes, most 
> medical devices in America are said to have a 7-10 year product life, 
> but the "end of life" units inevitably get reconditioned and sold to 
> poorer countries where they get used for another couple of decades.
> > As a result, it seems that Qt is drifting away from what it's users want or 
> > need. Sometimes though, it's not even so much that we need release, we just 
> > need a patch to hold us over to the next release. My Agile team does two 
> > week sprints so we can reorder priorities twice a month. The Qt community 
> > has no say (AFAIK) in determining the priority status, or what is worked on 
> > when. The worst issue I know of as an example of this is the Canvas bug on 
> > iOS (https://bugreports.qt.io/browse/QTBUG-37095  ). It's been in there for 
> > 2.5_yeara_, 17 votes and 36 watchers. Which in my experience is pretty damn 
> > high, though there are older and higher ones. Use the search string "votes 
> > >= 17 AND status != Closed and type = Bug" to get a list of that
> >and it's brethren. Which brings up the question, why isn't the Qt staff 
> > using a similar search to prioritize their backlog on a regular basis?
> This is inevitably what happens with Agile. Developers get to choose the 
> stories (in this case bugs) they work on and it is way cooler to put 
> your name on a new feature than to fix someone else's code, especially 
> if there is a management team in place measuring "performance" by how 
> many stories get completed each sprint instead of just how much better 
> the end product is.


Developers do not get to choose what stories to do. The priorities are not set 
by engineering. Business decides the priorities in sprint planning, and 
engineering does them. In proper Agile teams, the developers get to pick 
(assign to them) which stories they do in that sprint, not what goes into the 
sprint. 

In the Jeff Sutherland book "SCRUM: The art of doing twice the work in half the 
time" Sutherland citest he FBI's post 9/11 modernization effort called the 
Virtual Case File System, which was axed because it over past due and over 
budget. The replacement project Sentinel, a $450M project. It too started out 
not Agile, but based with another several years of being overdue and over 
budget (estimated $350M more to complete) that was moved to Agile and actually 
delivered.  Similarly Healthcare.gov started off not Agile and ended Agile. 
Clearly, the problem isn't the methodology, it is your application of it.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

You haven't highlighted any problem with Agile the methodology. You have only highlighted problems with the skills of your team, or at worst, how your team implements Agile. I don't disagree that having a thought-out event lifecycle approach isn't important, and I'd argue that it should have it's own story. Architecture is important, and sometimes the work these doesn't lend itself to someting traditionaly seen as a task. Architecture is more implicit in the code than explicit lines of code, but it still requires attention. 

The reason I'm so far behind on this list is that once again I've been called into an Agile shop to work on a project which is currently a train wreck and I'm spending 7 days per week trying to drag it out of the path of the impending plane crash before both roll down the hill into a pre-school. Agile is _completely_ to blame for the state of this project. You cannot hope to start a successful project which involves both a messaging system to external devices AND a database without first writing and vetting the following:

When you work off nothing but stories you are hacking on the fly and if your coders aren't system architect level people, not just one, but each and every one of them, you end in failure. You end up with a developer choosing to store data in JSON files for a device taking dozens, some times hundreds of readings per second, appending the new reading to the end of a JSON array and writing the entire file back to an SD card. Without the event->message->device  response->message->event life cycle completely mapped out in a solid document you end up with a dozen programmers working from a dozen different stories doing it a dozen different ways so eventually you end up with an embedded system slamming hundreds of requests onto a message bus for data it only needed to get once at startup.
 


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Bob Hood]

On 10/15/2016 6:59 PM, Roland Hughes wrote:

When you work off nothing but stories you are hacking on the fly...


Ok, since I've responded to this before (perhaps this should be a different 
thread?), I'll jump in there again and clarify where /I'm/ coming from...


First, let me say I embrace Agile, just as I embrace Waterfall, Spiral, and 
all other methodologies.  My issue with Agile is not with the methodology 
itself, but with the single-mindedness with which the industry has embraced it.


Agile is the spawn of Spiral--a.k.a., rapid prototyping--elevated to what can 
only be viewed as a religion now in the industry, so "hacking on the fly" is 
what Agile is all about: Short-term gains from short-term feedback.  In Spiral 
(which was /my/ methodology), you did the rapid prototyping and iterating with 
the customer to ensure that the program matched the formal requirements while 
you developed, instead of waiting until the end.  In Agile, you forego the 
formal requirements gathering step, so you only and always have the customer's 
fiat ("User Stories") driving the direction of the development.  It's hard to 
know when you're really done because you don't really have metrics to tell 
you--or the customer--when the project /is/ done.


In the 2005 book "The Art of Project Management", Scott Berkun observed:

   "For completeness, it is worth considering the simplest possible case:
   there is no project. All work is done on a piecemeal basis--requests come
   in, they are evaluated against other work, and then they are put into the
   next available slot on the schedule. Some development teams, web site
   developers, or IT programming departments work in much this way. Agile
   methods...are often recommended to these teams as the most natural system
   for organizing work because these methods stress flexibility, simplicity,
   and expectations of change."

This was just when Agile was gaining prominence, and before it had pretty much 
overtaken and eclipsed all other project management styles.  Agile fit the "IT 
programming project" style of development quite well ("flexibility, 
simplicity, and expectations of change"), but it did not scale well in all 
cases, and, as some of the anecdotal evidence shows, it can actually inflict 
damage on some project types.


There are people who believe Agile is the best method devised, and like bacon, 
should be employed lavishly and in all cases.  While I think it is 
single-minded, I understand where they are coming from.  I loved (and still do 
love) Spiral.  However, I am suspicious that those who beat their chests the 
most about how Agile is perfect for everything have only ever been in, or only 
seek out, those kind of "IT programming project" environments where it is a 
best fit.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Kyle Altendorf]

On 2016-10-15 20:59, Roland Hughes wrote:

> On 09/28/2016 12:25 PM, interest-requ...@qt-project.org wrote:
>
> Don't you have unit tests?
>
> Yes. But which is better, to be forced to use an inherently error-prone
> language (JavaScript) and rely on unit tests to clean up the mess, or to
> use a robust modern language (C++) and have less bugs to find and fix in
> the first place?

When you work off nothing but stories you are hacking on the fly and if 
your coders
aren't system architect level people, not just one, but each and every 
one of them,
you end in failure. You end up with a developer choosing to store data 
in JSON files
for a device taking dozens, some times hundreds of readings per second, 
appending
the new reading to the end of a JSON array and writing the entire file 
back to an
SD card. Without the event->message->device  response->message->event 
life cycle
completely mapped out in a solid document you end up with a dozen 
programmers
working from a dozen different stories doing it a dozen different ways 
so eventually
you end up with an embedded system slamming hundreds of requests onto a 
message bus

for data it only needed to get once at startup.


Documents won't avoid that...  at my last job we did 'v-model 
development' and created hundreds of pages of documentation and then 
went off and coded for months ignoring the documentation because it was 
bad and never kept up to date.  It had quadruplicated definitions of 
features that all disagreed.  Copied/pasted/modified definitions done 
pages at a time.  One feature definition stated, if you bothered to 
actually read it, that the entire system must not move (hint: its 
purpose was to move...).  That was one of the multiply copied items.  :]


Anyways, any development methodology will fail if implemented poorly.  
If the buzz-word is agile, it will likely fail because management won't 
be willing to handle it appropriately.  Same goes for v-model.


Cheers,
-kyle
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Roland Hughes]

This would be the second 2 fatal flaws with Agile.

Developer's choice

1 and done mentality/management. Actually that is better than some of 
the Agile groups at equipment manufacturers, some of them demand their 
developers commit 3 completed stories per day.


Big ugly Ogre on steroids type bugs don't get fixed, they simply rot 
until the product/company goes away. Moral is high but product quality 
is low.


On my current project, counting by the calendar, various team members, 
myself included, have put in over 1 month tracking down a memory leak 
problem. Each of us have found various parts of it, but there was 
nothing Agile about it. This was old school grind it out trouble 
shooting which is not allowed under Agile. Valgrind was near useless 
because it slowed the target down enough to require nearly a full 
overnight run but with Valgrind and the app running you ran out of 
memory within a few hours.


We may well have found the last piece of it on Friday, but, the bug 
would never have existed had the holy 4 SDLC documents been done prior 
to writing the first line of code.



On 10/04/2016 06:31 PM, interest-requ...@qt-project.org wrote:

There isn't, because developer selects the bugs they're going to fix. There's
common procedure.

My procedure is: I'll fix everything that is assigned to me, the moment it's
assigned, if I can. If I couldn't within one day, I won't be able to until
there's more information posted.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Roland Hughes]

On 10/04/2016 06:31 PM, interest-requ...@qt-project.org wrote:

I think the bigger issue, that many people have expressed here, but not said as 
such, is the Qt release cycle is not Agile.

I would thank God it is not, but the rest of your post proves that it is.

As more teams adopt Agile development practices, the chasm between what user 
teams needs and what is being delivered grows.
Well, only teams working on products with the life span of a fruit fly, 
like a Web page. Most will be companies which go out of business. When 
one is developing things which will inevitably have a 30+ year life span 
or exist in a regulated environment Agile simply isn't an option. Think 
payroll, accounts receivable, and most medical devices. Yes, most 
medical devices in America are said to have a 7-10 year product life, 
but the "end of life" units inevitably get reconditioned and sold to 
poorer countries where they get used for another couple of decades.

As a result, it seems that Qt is drifting away from what it's users want or need. Sometimes 
though, it's not even so much that we need release, we just need a patch to hold us over to 
the next release. My Agile team does two week sprints so we can reorder priorities twice a 
month. The Qt community has no say (AFAIK) in determining the priority status, or what is 
worked on when. The worst issue I know of as an example of this is the Canvas bug on iOS 
(https://bugreports.qt.io/browse/QTBUG-37095  ). It's been in there for 2.5_yeara_, 17 votes 
and 36 watchers. Which in my experience is pretty damn high, though there are older and 
higher ones. Use the search string "votes >= 17 AND status != Closed and type = 
Bug" to get a list of that
   and it's brethren. Which brings up the question, why isn't the Qt staff 
using a similar search to prioritize their backlog on a regular basis?
This is inevitably what happens with Agile. Developers get to choose the 
stories (in this case bugs) they work on and it is way cooler to put 
your name on a new feature than to fix someone else's code, especially 
if there is a management team in place measuring "performance" by how 
many stories get completed each sprint instead of just how much better 
the end product is.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Roland Hughes]

On 09/28/2016 12:25 PM, interest-requ...@qt-project.org wrote:

Don't you have unit tests?

Yes. But which is better, to be forced to use an inherently error-prone
language (JavaScript) and rely on unit tests to clean up the mess, or to
use a robust modern language (C++) and have less bugs to find and fix in
the first place?
This entire concept of TDD is the greatest failure of Agile. Relying on 
a developer who read the story wrong to write a test proving his/her 
incorrect interpretation of the story works perfectly via automated 
testing just so managers can tell people they run X-thousand tests on 
the code base each time a change is made...So what? Virtually all 
X-thousand are worthless.


The reason I'm so far behind on this list is that once again I've been 
called into an Agile shop to work on a project which is currently a 
train wreck and I'm spending 7 days per week trying to drag it out of 
the path of the impending plane crash before both roll down the hill 
into a pre-school. Agile is _completely_ to blame for the state of this 
project. You cannot hope to start a successful project which involves 
both a messaging system to external devices AND a database without first 
writing and vetting the following:


BRD, SRD, SAD & SSD

For those unfamiliar with the proper way to do things:
BRD = Business Requirements Document
SRD = System Requirements Document
SAD = System Architecture Document
SSD = System Specification Document

When you work off nothing but stories you are hacking on the fly and if 
your coders aren't system architect level people, not just one, but each 
and every one of them, you end in failure. You end up with a developer 
choosing to store data in JSON files for a device taking dozens, some 
times hundreds of readings per second, appending the new reading to the 
end of a JSON array and writing the entire file back to an SD card. 
Without the event->message->device response->message->event life cycle 
completely mapped out in a solid document you end up with a dozen 
programmers working from a dozen different stories doing it a dozen 
different ways so eventually you end up with an embedded system slamming 
hundreds of requests onto a message bus for data it only needed to get 
once at startup.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

Case and point:

https://bugreports.qt.io/browse/QTBUG-37095, which I mentioned recently, 17 votes, multiple platforms... a mere 14 line fix, had been open for 2.5 years.

 

 

 

 

Sent: Tuesday, October 04, 2016 at 8:59 PM
From: "Rob Allan" 
To: interest@qt-project.org
Subject: Re: [Interest] What don't you like about Qt?


From: Thiago Macieira <thiago.macie...@intel.com>

>> There isn't, because developer selects the bugs they're going to fix.
>> There's common procedure.

> Oops, this came out wrong after reediting. I meant that there is no common
> procedure, each developer chooses the bugs however they wish.

 

Doesn't this really cut to the heart of what John is complaining about - Agile or non-Agile aside? The issue seems to be that there is no well-defined or over-arching policy or procedure for choosing what bugs to fix - the developers just pull bugs off the heap that seem doable. That's a natural approach in some ways, and devs often have good instincts for which bugs matter and can be most readily fixed. But maybe there is a need for some sort of regular high-level review of bugs to identify those that are having the worst customer impact and need to be looked at by the devs.

 

Rob

 

___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Viktor Engelmann]

To come back to the original topic:
I dislike about Qt Creator that you cannot easily create and then use
custom widgets.

You have to read lots of documentation on how to make a Qt Creator
_Plugin_ (and I remember the useless error messages I got when the
plugin-interface changed between Qt 3 and 4).
Otherwise you have to put placeholders into your forms and then
"promote" them, for which there is a confusing remember-and-type
(instead of a clear read-and-select) user interface.

In Visual Studio, you run the wizard to create a custom widget and
within seconds, it is instantiatable in their GUI designer tool.

regards

Viktor
<>___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: keskiviikkona 5. lokakuuta 2016 12.34
> To: interest@qt-project.org
> Subject: Re: [Interest] What don't you like about Qt?
> 
> Em quarta-feira, 5 de outubro de 2016, às 19:48:00 CEST, John C. Turnbull
> escreveu:
> > You did mention though that The Qt Company has SLAs and will try to
> > reproduce problems etc., but what if I just want to say things like "I
> > want this feature" or "I don't think this feature is implemented in
> > the best way" or "I think the whole SDLC is being managed in a way
> > that is ineffective and is making using Qt in a production environment
> difficult"
> > or "mobile support is nowhere near good enough to implement serious
> > apps so I can't use Qt as a true cross platform toolkit" or "QML is a
> > great concept but without adequate C++ APIs, it's really only suitable for
> basic forms"?
> >
> > What SLAs or kinds of responses should I expect then?
> 
> I don't know. Your commercial contract with The Qt Company may include
> something about that. Or not. I don't know, I've never read one (not even
> during my time working for Trolltech). I guess that it's during negotiation 
> that
> you get more leverage to make some demands.
> 
> I do remember Trolltech sending yearly surveys to find out what customers
> wanted. I don't know if The Qt Company has kept that practice.
> 

Yes, latest one is actually just closing. In addition, we ask feedback from 
every support case.

> From the Qt Project's point of view, to get a feature in, you can do one of:
>  * do it yourself
>  * convince someone to do it for you
>   (with arguments or by freeing up their time by taking up part of their work)
>  * paying someone to do it
> 

The normal Qt bug priorization is quite efficient in my opinion - we fix first 
the bugs that have highest impact. Mostly these bugs are fixed already during 
the development cycle, but of course sometimes critical bugs may slip through, 
and will be addressed in patch releases.

Like Kai mentioned, in addition to the normal priorization the bugs reported by 
commercial customers get focus. If it is a corner case or bug with a good 
workaround, it may still not get priority over something that would block high 
number of users - but in general we think this works fairly well. So reporting 
bugs via Qt Support will give the issue a boost. 

In general, we are unfortunately not able to fix all issues. I think we do 
quite good work in finding the right priorities, but the fact remains that 
getting more bugs fixed overall would be beneficial. 

Yours,

Tuukka

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

Em quarta-feira, 5 de outubro de 2016, às 19:48:00 CEST, John C. Turnbull 
escreveu:
> You did mention though that The Qt Company has SLAs and will try to
> reproduce problems etc., but what if I just want to say things like "I want
> this feature" or "I don't think this feature is implemented in the best
> way" or "I think the whole SDLC is being managed in a way that is
> ineffective and is making using Qt in a production environment difficult"
> or "mobile support is nowhere near good enough to implement serious apps so
> I can't use Qt as a true cross platform toolkit" or "QML is a great concept
> but without adequate C++ APIs, it's really only suitable for basic forms"?
> 
> What SLAs or kinds of responses should I expect then?

I don't know. Your commercial contract with The Qt Company may include 
something about that. Or not. I don't know, I've never read one (not even 
during my time working for Trolltech). I guess that it's during negotiation 
that you get more leverage to make some demands.

I do remember Trolltech sending yearly surveys to find out what customers 
wanted. I don't know if The Qt Company has kept that practice.

>From the Qt Project's point of view, to get a feature in, you can do one of:
 * do it yourself
 * convince someone to do it for you
  (with arguments or by freeing up their time by taking up part of their work)
 * paying someone to do it

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[John C. Turnbull]

OK, thanks Thiago, it seems we do understand each other.

And it also seems that I am indeed venting my frustrations in an inappropriate 
forum (as you pointed out that this list is related to the open source 
project). Sorry about that.

You did mention though that The Qt Company has SLAs and will try to reproduce 
problems etc., but what if I just want to say things like "I want this feature" 
or "I don't think this feature is implemented in the best way" or "I think the 
whole SDLC is being managed in a way that is ineffective and is making using Qt 
in a production environment difficult" or "mobile support is nowhere near good 
enough to implement serious apps so I can't use Qt as a true cross platform 
toolkit" or "QML is a great concept but without adequate C++ APIs, it's really 
only suitable for basic forms"?

What SLAs or kinds of responses should I expect then?

> On 5 Oct. 2016, at 18:07, Thiago Macieira  wrote:
> 
> Em quarta-feira, 5 de outubro de 2016, às 10:33:37 CEST, John C. Turnbull 
> escreveu:
>> Thiago, it seems you have taken my comments as a personal attack on you and
>> you have responded (naturally) in a defensive way.
>> 
>> Well, I tried to make it very clear from my opening sentence that this was
>> *not* a personal attack on you (or anyone else for that matter). In fact, I
>> *thought* I made it obvious how much I am aware and appreciative of your
>> own massive and positive contributions to Qt in general.
> 
> Hello John,
> 
> That was not the intention. I did not understand it as a personal attack nor 
> did I mean to attack you for saying it either. I totally understand your 
> position and I hope you understand my frankness.
> 
>> But I think the key point here that perhaps you are missing is that for me
>> and I suspect for many "customers", Qt is a commercial product and a
>> support contract that we pay for. I see the entity that I am paying that
>> money to as "The Qt Company".  Whether or not the Qt *project* is "open
>> source" is neither here nor there in the context of one business paying
>> another for a product and support.
> 
> Indeed, you may feel that, but that discussion is between you and The Qt 
> Company, maybe between you and a consulting company you may have hired for a 
> project. I am not in that discussion and cannot comment about it.
> 
> But the bug reports in https://bugreports.qt.io are part of the Qt Project, 
> the open source side of it (just like this mailing list, actually). If you 
> report issues via the professional support contract, you get a different 
> person, dedicated to commercial customers, to look into your issue. They have 
> an SLA to respond to all your queries within a certain amount of time. They 
> also do try to reproduce your problem and come up with testcases.
> 
> As an open source developer, I only see the resulting testcase. That helps me 
> greatly, because the testcase is something I can almost immediately run, 
> confirm the issue, and fix, all within a couple of hours. Or I can confirm 
> it's 
> not a bug and close the issue. Now, I can't confirm the other Qt modules have 
> the same success story, I can only speak for myself and my modules.
> 
>> So, please, understand that I am not in any way even trying to be critical
>> of *you* and, on the contrary, I'm actually singing your praises!
> 
> No offence taken, don't worry.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

Em quarta-feira, 5 de outubro de 2016, às 07:27:38 CEST, Kai Koehne escreveu:
> > -Original Message-
> > From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org]
> > [...]
> > But maybe there is a need for some
> > sort of regular high-level review of bugs to identify those that are
> > having the worst customer impact and need to be looked at by the devs.
> 
> This is happening, although only internally in The Qt Company.

If we replace "customer" with "user", we can probably write an informational 
QUIP on prioritising bug reports.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Kai Koehne]

> -Original Message-
> From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org]
> [...]
> But maybe there is a need for some
> sort of regular high-level review of bugs to identify those that are having 
> the
> worst customer impact and need to be looked at by the devs.

This is happening, although only internally in The Qt Company.

Regards

Kai

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

Em quarta-feira, 5 de outubro de 2016, às 13:59:17 CEST, Rob Allan escreveu:
> Doesn't this really cut to the heart of what John is complaining about -
> Agile or non-Agile aside? The issue seems to be that there is no
> well-defined or over-arching policy or procedure for choosing what bugs to
> fix - the developers just pull bugs off the heap that seem doable. That's a
> natural approach in some ways, and devs often have good instincts for which
> bugs matter and can be most readily fixed. But maybe there is a need for
> some sort of regular high-level review of bugs to identify those that are
> having the worst customer impact and need to be looked at by the devs.

The priority should capture that effect.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

Em quarta-feira, 5 de outubro de 2016, às 10:33:37 CEST, John C. Turnbull 
escreveu:
> Thiago, it seems you have taken my comments as a personal attack on you and
> you have responded (naturally) in a defensive way.
> 
> Well, I tried to make it very clear from my opening sentence that this was
> *not* a personal attack on you (or anyone else for that matter). In fact, I
> *thought* I made it obvious how much I am aware and appreciative of your
> own massive and positive contributions to Qt in general.

Hello John,

That was not the intention. I did not understand it as a personal attack nor 
did I mean to attack you for saying it either. I totally understand your 
position and I hope you understand my frankness.

> But I think the key point here that perhaps you are missing is that for me
> and I suspect for many "customers", Qt is a commercial product and a
> support contract that we pay for. I see the entity that I am paying that
> money to as "The Qt Company".  Whether or not the Qt *project* is "open
> source" is neither here nor there in the context of one business paying
> another for a product and support.

Indeed, you may feel that, but that discussion is between you and The Qt 
Company, maybe between you and a consulting company you may have hired for a 
project. I am not in that discussion and cannot comment about it.

But the bug reports in https://bugreports.qt.io are part of the Qt Project, 
the open source side of it (just like this mailing list, actually). If you 
report issues via the professional support contract, you get a different 
person, dedicated to commercial customers, to look into your issue. They have 
an SLA to respond to all your queries within a certain amount of time. They 
also do try to reproduce your problem and come up with testcases.

As an open source developer, I only see the resulting testcase. That helps me 
greatly, because the testcase is something I can almost immediately run, 
confirm the issue, and fix, all within a couple of hours. Or I can confirm it's 
not a bug and close the issue. Now, I can't confirm the other Qt modules have 
the same success story, I can only speak for myself and my modules.

> So, please, understand that I am not in any way even trying to be critical
> of *you* and, on the contrary, I'm actually singing your praises!

No offence taken, don't worry.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Rob Allan]

From: Thiago Macieira 
>> There isn't, because developer selects the bugs they're going to fix.
>> There's common procedure.

> Oops, this came out wrong after reediting. I meant that there is no common
> procedure, each developer chooses the bugs however they wish.

Doesn't this really cut to the heart of what John is complaining about -
Agile or non-Agile aside? The issue seems to be that there is no
well-defined or over-arching policy or procedure for choosing what bugs to
fix - the developers just pull bugs off the heap that seem doable. That's a
natural approach in some ways, and devs often have good instincts for which
bugs matter and can be most readily fixed. But maybe there is a need for
some sort of regular high-level review of bugs to identify those that are
having the worst customer impact and need to be looked at by the devs.

Rob
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[John C. Turnbull]

Thiago, it seems you have taken my comments as a personal attack on you and you 
have responded (naturally) in a defensive way.

Well, I tried to make it very clear from my opening sentence that this was 
*not* a personal attack on you (or anyone else for that matter). In fact, I 
*thought* I made it obvious how much I am aware and appreciative of your own 
massive and positive contributions to Qt in general.

So, if I failed in my communication skills and caused you to feel "attacked" 
then I am sorry. But please know, that was most definitely not my intention.

The remainder of your comments are, as I also said before, most likely 
absolutely "spot on" in terms of their level of accuracy.

But I think the key point here that perhaps you are missing is that for me and 
I suspect for many "customers", Qt is a commercial product and a support 
contract that we pay for. I see the entity that I am paying that money to as 
"The Qt Company".  Whether or not the Qt *project* is "open source" is neither 
here nor there in the context of one business paying another for a product and 
support.

So, your extensive commentary on the ins and outs of maintaining an open source 
project are probably very relevant in that context and I am sure you know far 
more about those kind of matters than most (including me).

Further, your motivations for contributing your time and expertise to this 
project are indeed honourable and, I have never suggested anything else.

So, please, understand that I am not in any way even trying to be critical of 
*you* and, on the contrary, I'm actually singing your praises!

I think we at crossed paths here and perhaps this is not the appropriate forum 
for me to put forward the comments I am making.  If that's the case then, 
again, I am sorry and please direct me to a more appropriate forum.

To summarise, I am speaking from the perspective of a paying customer of a 
commercial entity.

And I suspect I am not the only one.

> On 5 Oct. 2016, at 10:09, Thiago Macieira  wrote:
> 
> Em quarta-feira, 5 de outubro de 2016, às 08:13:38 CEST, John C. Turnbull 
> escreveu:
>> Thiago, with all due respect, and I'm very aware of the significant
>> contribution you personally have made to both the Qt product and the
>> community, there is clearly a high degree of dissatisfaction with various
>> aspects of Qt and the management of the SDLC.
> 
> What's SDLC? Software Development Life Cycle?
> 
> The Qt Project actually has a very good cycle for an Open Source project. 
> It's 
> certainly of much higher quality and stricter standards than 95%+ of other 
> open source software out there. I can tell you that we run more unit tests a 
> day than the Linux kernel does in a month (or maybe a year).
> 
>> Your comments may be accurate but I'm not sure they have appeased many of
>> the disgruntled customers.
> 
> That may be, but facts and truth often don't serve to appease people. They're 
> more often than not a harsh reality.
> 
> I could have stayed silent, though, like I've done with the rest of this 
> thread.
> 
>> My advice (for what it's worth) would be to not ignore the swelling
>> negativity that is building amongst paying customers and to see that there
>> are some very genuine concerns out there that are making the task of
>> putting food on the table more difficult than it need be for some people.
> 
> I'm not ignoring the negativity and I doubt anyone is. But people who 
> complain 
> often have trouble putting their issues in the context of everything else 
> that 
> is going on.
> 
> Also, I don't have any customers. I don't receive a penny, directly or 
> indirectly, of licensing fees or support contracts. Other people and other 
> companies involved may have a financial incentive. I don't. All I care are 
> the 
> Open Source principles and the technical quality.
> 
>> It is troubling that you say that often developers simply don't *know* how
>> to fix bugs. That does not engender a high degree of confidence in
>> customers who have focused their entire business strategic plans on such a
>> product.
> 
> Again, that may be, but what would you rather I said? That developers are 
> magic geniuses that can fix anything, with little information, in no time at 
> all and twice on Sundays? C'mon, we're all limited, no one is perfect.
> 
> But note I wasn't saying either that the developers are stupid. Far from it. 
> The most likely cause of not knowing how to fix is that the bug report is 
> incomplete or the issue is not reproducible. I had one recently that attached 
> a very nice testcase, with even a shell script that ran everything and set up 
> properly. And yet, after running for several hours, I couldn't reproduce the 
> issue.
> 
> I also have two pending patches to QtDBus that fix some regressions 
> introduced 
> in 5.6.0 that I still haven't been able to get integrated because they 
> trigger 
> another regression somewhere that doesn't happen for me. How can I fix that?
> 
> Sometim

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

Em quarta-feira, 5 de outubro de 2016, às 08:13:38 CEST, John C. Turnbull 
escreveu:
> Thiago, with all due respect, and I'm very aware of the significant
> contribution you personally have made to both the Qt product and the
> community, there is clearly a high degree of dissatisfaction with various
> aspects of Qt and the management of the SDLC.

What's SDLC? Software Development Life Cycle?

The Qt Project actually has a very good cycle for an Open Source project. It's 
certainly of much higher quality and stricter standards than 95%+ of other 
open source software out there. I can tell you that we run more unit tests a 
day than the Linux kernel does in a month (or maybe a year).

> Your comments may be accurate but I'm not sure they have appeased many of
> the disgruntled customers.

That may be, but facts and truth often don't serve to appease people. They're 
more often than not a harsh reality.

I could have stayed silent, though, like I've done with the rest of this 
thread.

> My advice (for what it's worth) would be to not ignore the swelling
> negativity that is building amongst paying customers and to see that there
> are some very genuine concerns out there that are making the task of
> putting food on the table more difficult than it need be for some people.

I'm not ignoring the negativity and I doubt anyone is. But people who complain 
often have trouble putting their issues in the context of everything else that 
is going on.

Also, I don't have any customers. I don't receive a penny, directly or 
indirectly, of licensing fees or support contracts. Other people and other 
companies involved may have a financial incentive. I don't. All I care are the 
Open Source principles and the technical quality.

> It is troubling that you say that often developers simply don't *know* how
> to fix bugs. That does not engender a high degree of confidence in
> customers who have focused their entire business strategic plans on such a
> product.

Again, that may be, but what would you rather I said? That developers are 
magic geniuses that can fix anything, with little information, in no time at 
all and twice on Sundays? C'mon, we're all limited, no one is perfect.

But note I wasn't saying either that the developers are stupid. Far from it. 
The most likely cause of not knowing how to fix is that the bug report is 
incomplete or the issue is not reproducible. I had one recently that attached 
a very nice testcase, with even a shell script that ran everything and set up 
properly. And yet, after running for several hours, I couldn't reproduce the 
issue.

I also have two pending patches to QtDBus that fix some regressions introduced 
in 5.6.0 that I still haven't been able to get integrated because they trigger 
another regression somewhere that doesn't happen for me. How can I fix that?

Sometimes we can reproduce the issue, but then we end up with a situation that 
is so thorny that there is no good solution. Change something here and 
everything unravels over there. Or the bug fix introduces regressions.

And then there are people depending on the buggy behaviour. Example: I noticed 
that the QFile::created() function did not give you the file's creation time on 
BSDs (including Apple OSes), but the file's ctime. The fix was simple. But if I 
applied it the way I wanted, I would break people's applications that depended 
on created() returning the ctime.

> Further, appearing to be somewhat dismissive of the constructive criticism
> regarding the absence of Agile methodologies within the Qt processes and
> basically saying "that's the way it is", again, may not be seen as helpful
> by some customers.

You can ask for transparency. You can ask for more attention to bug reports 
with high priority. You can demand that all bug reports be triaged. I support 
you on all of those.

But you can't tell us how to do our jobs. Agile doesn't work for us and I 
don't know a single, large open source project with contributors from multiple 
companies and across multiple geographies that uses Agile. Trust me when I say 
that our methodology actually works: we fix hundreds of bugs per release, we 
catch almost all serious regressions and yet we still have time for 
innovation.

> You know the old saying "If it ain't broke, don't fix it".
> 
> Well, sadly, it *is* "broke".
> 
> And even though I personally don't know how, its way past time to "fix it".

Give me an example of a comparable open source project and we'll emulate.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

Em terça-feira, 4 de outubro de 2016, às 22:37:20 CEST, Thiago Macieira 
escreveu:
> There isn't, because developer selects the bugs they're going to fix.
> There's common procedure.

Oops, this came out wrong after reediting. I meant that there is no common 
procedure, each developer chooses the bugs however they wish.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[John C. Turnbull]

Thiago, with all due respect, and I'm very aware of the significant 
contribution you personally have made to both the Qt product and the community, 
there is clearly a high degree of dissatisfaction with various aspects of Qt 
and the management of the SDLC.

Your comments may be accurate but I'm not sure they have appeased many of the 
disgruntled customers.

My advice (for what it's worth) would be to not ignore the swelling negativity 
that is building amongst paying customers and to see that there are some very 
genuine concerns out there that are making the task of putting food on the 
table more difficult than it need be for some people.

It is troubling that you say that often developers simply don't *know* how to 
fix bugs. That does not engender a high degree of confidence in customers who 
have focused their entire business strategic plans on such a product.

Further, appearing to be somewhat dismissive of the constructive criticism 
regarding the absence of Agile methodologies within the Qt processes and 
basically saying "that's the way it is", again, may not be seen as helpful by 
some customers.

You know the old saying "If it ain't broke, don't fix it".

Well, sadly, it *is* "broke".

And even though I personally don't know how, its way past time to "fix it".

> On 5 Oct. 2016, at 07:37, Thiago Macieira  wrote:
> 
>> Em terça-feira, 4 de outubro de 2016, às 16:03:00 CEST, Jason H escreveu:
>> I think the bigger issue, that many people have expressed here, but not said
>> as such, is the Qt release cycle is not Agile. 
> 
> It's as fast as it can be. We can't release faster than it is because the 
> steps just take too long.
> 
>> what it's users want or need. Sometimes though, it's not even so much that
>> we need release, we just need a patch to hold us over to the next release.
> 
> All bug reports, when fixed, have a link to the actual change in 
> codereview.qt-
> project.org, which contain the patch and the SHA-1 of the Git commit. So you 
> *do* have the patch.
> 
>> My Agile team does two week sprints so we can reorder priorities twice a
>> month. 
> 
> It takes us three weeks to create source and binary packages, then test them 
> for sanity, before we release.
> 
>> The Qt community has no say (AFAIK) in determining the priority
>> status, or what is worked on when. 
> 
> Priority is determined on facts, not on popularity. If you have more facts, 
> provide them. If you can show that a lot of applications are affected by the 
> bug, it gains in priority.
> 
> That said, the most common issue for bugs not getting fixed is that the 
> developers couldn't figure out how. Voting won't change that fact.
> 
>> I think the incorporation of a regular search of that nature would immensely
>> improve the product. I don't think there is any transparency in the
>> selected for fix criteria?
> 
> There isn't, because developer selects the bugs they're going to fix. There's 
> common procedure.
> 
> My procedure is: I'll fix everything that is assigned to me, the moment it's 
> assigned, if I can. If I couldn't within one day, I won't be able to until 
> there's more information posted.
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

Em terça-feira, 4 de outubro de 2016, às 16:03:00 CEST, Jason H escreveu:
> I think the bigger issue, that many people have expressed here, but not said
> as such, is the Qt release cycle is not Agile. 

It's as fast as it can be. We can't release faster than it is because the 
steps just take too long.

> what it's users want or need. Sometimes though, it's not even so much that
> we need release, we just need a patch to hold us over to the next release.

All bug reports, when fixed, have a link to the actual change in codereview.qt-
project.org, which contain the patch and the SHA-1 of the Git commit. So you 
*do* have the patch.

> My Agile team does two week sprints so we can reorder priorities twice a
> month. 

It takes us three weeks to create source and binary packages, then test them 
for sanity, before we release.

> The Qt community has no say (AFAIK) in determining the priority
> status, or what is worked on when. 

Priority is determined on facts, not on popularity. If you have more facts, 
provide them. If you can show that a lot of applications are affected by the 
bug, it gains in priority.

That said, the most common issue for bugs not getting fixed is that the 
developers couldn't figure out how. Voting won't change that fact.

> I think the incorporation of a regular search of that nature would immensely
> improve the product. I don't think there is any transparency in the
> selected for fix criteria?

There isn't, because developer selects the bugs they're going to fix. There's 
common procedure.

My procedure is: I'll fix everything that is assigned to me, the moment it's 
assigned, if I can. If I couldn't within one day, I won't be able to until 
there's more information posted.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

Having worked on mutliple teams with different methodologies, I am fully aware of the benefits and drawbacks of each. If you read Sutherland's SCRUM book, which I regard has half terrible and half excellent, you'll be able to appreciate my point. The factual reality I am dealing with here is that every two weeks I am punting bugs in our tracker because I'm awaiting for a fix in Qt. In other development processes, this contant punting and lack of transparency in prioritization may go unnoticed. 

 

FWIW, I am as much for Agile as I am against it. As several of you have already stated it has its place but is not a cure-all. However I find that a lot of reluctance with the update is because older developers (including myself) do not like the feeling of micro-management (myself included), others fear the increase of transparency (taking 3 months to do something they could do in 1, or having to admit when development does not progress at an ideal pace). But the fact of the matter is output is increased. But then Agile falls over because it fails in that technically, you can't say when you'll be done a project and thereby how much it will cost, which is abhorrent to business who want to sign fixed-price contracts. What I now see is a lot of hybridization being attempted, which I personally feel is doomed to fail. 


 

Meanwhile Kaizen, the Japanese quality practice of contunious quality improvement seems to be missing from Qt. Given that list of 25+ issues with >= 17 votes, those would be a logical start to achiveing meaningful quality improvements. Those issues should be targeted first since they are affecting the most users. Repeat this every two weeks. Once the outliers are handled then the devs should be able to work on the fun stuff.

 

PS. If you're hating on Agile because you fear the transparency, or are concerned about your reputation, I think your days are limited. Also see https://www.youtube.com/watch?v=0SARbwvhupQ

 


Sent: Tuesday, October 04, 2016 at 11:40 AM
From: "Tim O'Neil" 
To: interest@qt-project.org
Subject: Re: [Interest] What don't you like about Qt?


I can tell you all from direct experience Agile is not a one-size-fits-all tool. Its a tool, best used in mid-sized to larger organizations trying to build software. Its not at all appropriate for smaller shops. Kanban works just fine in those.

 
On Tue, Oct 4, 2016 at 8:02 AM, Ronan Jouchet <ronan.jouc...@cadensimaging.com> wrote:

On 2016-10-04 10:28, Bob Hood wrote:
Like Spiral from whence it sprung, I think Agile works wonderfully
in certain project profiles.  However, not everybody drinks the
all-Agile-all-the-time Kool-Aid®.  Contrary to popular religion,
Agile is not the savior of the industry. It's another tool in the
toolbox, not a replacement for all the other tools, and savvy project
managers still apply the development methodology (Spiral, Agile,
Waterfall, etc.) or hybrid -- e.g., Waterfall mixed with Agile
elements -- that makes the most sense for the success of a project.

Just applying full Agile without considering the characteristics of
the project and its intended result is absolutely not a guarantee of
 success.

Absolutely. But you're fighting a strawman; Jason was in no way trying
to spread meaningless Agile verbiage / kool-aid, he also explained in
detail what he meant by it. Quoting him, emphasis mine:

On 2016-10-04 10:03, Jason H wrote:
My Agile team does two week sprints so we can reorder priorities
twice a month. **The Qt community has no say (AFAIK) in determining
the priority status, or what is worked on when**. The worst issue I
know of as an example of this is the Canvas bug on iOS (
https://bugreports.qt.io/browse/QTBUG-37095 ). It's been in there
for 2.5 _years_, 17 votes and 36 watchers. Which in my experience is
pretty damn high, though there are older and higher ones. Use the
search string "votes >= 17 AND status != Closed and type = Bug" to
get a list of that and it's brethren.

Which brings up the question, **why isn't the Qt staff using a
similar search to prioritize their backlog on a regular basis?**

I think the **incorporation of a regular search of that nature**
would immensely improve the product. I don't think there is any
**transparency in the selected for fix criteria** ?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest




--


“These last few days are among the happiest I’ve ever ignored.”
-Doug Kenney

MDExMDEwMDAgMDExMDAxMDEgMDExMDExMDAgMDExMDExMDAgMDExMDExMTE
gMDAxMDAwMDAgMDExMDExMTAgMDExMDAxMDEgMDExMTAxMTEgMDAxMDAwMD
AgMDExMDAxMTAgMDExMTAwMTAgMDExMDEwMDEgMDExMDAxMDEgMDExMDExMT
AgMDExMDAxMDAg


___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Tim O'Neil]

I can tell you all from direct experience Agile is not a one-size-fits-all
tool. Its a tool, best used in mid-sized to larger organizations trying to
build software. Its not at all appropriate for smaller shops. Kanban works
just fine in those.

On Tue, Oct 4, 2016 at 8:02 AM, Ronan Jouchet <
ronan.jouc...@cadensimaging.com> wrote:

> On 2016-10-04 10:28, Bob Hood wrote:
>
>> Like Spiral from whence it sprung, I think Agile works wonderfully
>> in certain project profiles.  However, not everybody drinks the
>> all-Agile-all-the-time Kool-Aid®.  Contrary to popular religion,
>> Agile is not the savior of the industry. It's another tool in the
>> toolbox, not a replacement for all the other tools, and savvy project
>> managers still apply the development methodology (Spiral, Agile,
>> Waterfall, etc.) or hybrid -- e.g., Waterfall mixed with Agile
>> elements -- that makes the most sense for the success of a project.
>>
>> Just applying full Agile without considering the characteristics of
>> the project and its intended result is absolutely not a guarantee of
>>  success.
>>
>
> Absolutely. But you're fighting a strawman; Jason was in no way trying
> to spread meaningless Agile verbiage / kool-aid, he also explained in
> detail what he meant by it. Quoting him, emphasis mine:
>
> On 2016-10-04 10:03, Jason H wrote:
>
>> My Agile team does two week sprints so we can reorder priorities
>> twice a month. **The Qt community has no say (AFAIK) in determining
>> the priority status, or what is worked on when**. The worst issue I
>> know of as an example of this is the Canvas bug on iOS (
>> https://bugreports.qt.io/browse/QTBUG-37095 ). It's been in there
>> for 2.5 _years_, 17 votes and 36 watchers. Which in my experience is
>> pretty damn high, though there are older and higher ones. Use the
>> search string "votes >= 17 AND status != Closed and type = Bug" to
>> get a list of that and it's brethren.
>>
>> Which brings up the question, **why isn't the Qt staff using a
>> similar search to prioritize their backlog on a regular basis?**
>>
>> I think the **incorporation of a regular search of that nature**
>> would immensely improve the product. I don't think there is any
>> **transparency in the selected for fix criteria** ?
>>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



-- 

*“These last few days are among the happiest I’ve ever ignored.”*


*-Doug Kenney*MDExMDEwMDAgMDExMDAxMDEgMDExMDExMDAgMDExMDExMDAgMDExMDExMTE
gMDAxMDAwMDAgMDExMDExMTAgMDExMDAxMDEgMDExMTAxMTEgMDAxMDAwMD
AgMDExMDAxMTAgMDExMTAwMTAgMDExMDEwMDEgMDExMDAxMDEgMDExMDExMT
AgMDExMDAxMDAg
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Ronan Jouchet]

On 2016-10-04 10:28, Bob Hood wrote:

Like Spiral from whence it sprung, I think Agile works wonderfully
in certain project profiles.  However, not everybody drinks the
all-Agile-all-the-time Kool-Aid®.  Contrary to popular religion,
Agile is not the savior of the industry. It's another tool in the
toolbox, not a replacement for all the other tools, and savvy project
managers still apply the development methodology (Spiral, Agile,
Waterfall, etc.) or hybrid -- e.g., Waterfall mixed with Agile
elements -- that makes the most sense for the success of a project.

Just applying full Agile without considering the characteristics of
the project and its intended result is absolutely not a guarantee of
 success.


Absolutely. But you're fighting a strawman; Jason was in no way trying
to spread meaningless Agile verbiage / kool-aid, he also explained in
detail what he meant by it. Quoting him, emphasis mine:

On 2016-10-04 10:03, Jason H wrote:

My Agile team does two week sprints so we can reorder priorities
twice a month. **The Qt community has no say (AFAIK) in determining
the priority status, or what is worked on when**. The worst issue I
know of as an example of this is the Canvas bug on iOS (
https://bugreports.qt.io/browse/QTBUG-37095 ). It's been in there
for 2.5 _years_, 17 votes and 36 watchers. Which in my experience is
pretty damn high, though there are older and higher ones. Use the
search string "votes >= 17 AND status != Closed and type = Bug" to
get a list of that and it's brethren.

Which brings up the question, **why isn't the Qt staff using a
similar search to prioritize their backlog on a regular basis?**

I think the **incorporation of a regular search of that nature**
would immensely improve the product. I don't think there is any
**transparency in the selected for fix criteria** ?

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Bob Hood]

On 10/4/2016 8:03 AM, Jason H wrote:

I think the bigger issue, that many people have expressed here, but not said as 
such, is the Qt release cycle is not Agile. As more teams adopt Agile 
development practices...


http://www.linkedin.com/pulse/agile-dead-matthew-kern

Like Spiral from whence it sprung, I think Agile works wonderfully in certain 
project profiles.  However, not everybody drinks the all-Agile-all-the-time 
Kool-Aid®.  Contrary to popular religion, Agile is not the savior of the 
industry. It's another tool in the toolbox, not a replacement for all the 
other tools, and savvy project managers still apply the development 
methodology (Spiral, Agile, Waterfall, etc.) or hybrid -- e.g., Waterfall 
mixed with Agile elements -- that makes the most sense for the success of a 
project.  Just applying full Agile without considering the characteristics of 
the project and its intended result is absolutely not a guarantee of success.


(No intention to hijack the thread.)
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

I think the bigger issue, that many people have expressed here, but not said as 
such, is the Qt release cycle is not Agile. As more teams adopt Agile 
development practices, the chasm between what user teams needs and what is 
being delivered grows. As a result, it seems that Qt is drifting away from what 
it's users want or need. Sometimes though, it's not even so much that we need 
release, we just need a patch to hold us over to the next release. My Agile 
team does two week sprints so we can reorder priorities twice a month. The Qt 
community has no say (AFAIK) in determining the priority status, or what is 
worked on when. The worst issue I know of as an example of this is the Canvas 
bug on iOS ( https://bugreports.qt.io/browse/QTBUG-37095 ). It's been in there 
for 2.5 _yeara_, 17 votes and 36 watchers. Which in my experience is pretty 
damn high, though there are older and higher ones. Use the search string "votes 
>= 17 AND status != Closed and type = Bug" to get a list of that
  and it's brethren. Which brings up the question, why isn't the Qt staff using 
a similar search to prioritize their backlog on a regular basis?


I think the incorporation of a regular search of that nature would immensely 
improve the product. I don't think there is any transparency in the selected 
for fix criteria?



> Sent: Monday, October 03, 2016 at 5:56 AM
> From: "John C. Turnbull" 
> To: "Bernhard Lindner" 
> Cc: interest@qt-project.org
> Subject: Re: [Interest] What don't you like about Qt?
>
> It's ironic in a way that every major graphical toolkit (and with many large 
> software projects in general) that I've worked with over decades now, the 
> attitude has commonly seemed to have been that "new" is better than "stable".
> 
> The end result is a product full of both older and newer unstable features.
> 
> Then credibility and reputation both take a major hit and for serious 
> production users, frustration overwhelms them as they wait for features they 
> have been using and investing years of effort/time/money into to simply work 
> without major defects.
> 
> More often than not though, if these features are not part of the "new shiny 
> strategy", they tend to just rot...
> 
> > On 3 Oct. 2016, at 18:14, Bernhard Lindner  
> > wrote:
> > 
> > 1. New features (quantity) are priorized over bug fixing (quality). 
> > Suggestions 
> > are almost sensless. I reduced writing bug reports and totally gave up 
> > writing 
> > suggestions due to this.
> > 
> > 2. Widgets have too low priority. In general new fancy features are 
> > priorized 
> > above bread-and-butter features from my point of view.
> > 
> > 3. Components have been declared outdated while the replacements did not 
> > provide the same feature set. This seriously damages Qt's reputation.
> > 
> >> It's not unusual for us developers and contributors to lose
> >> perspective of what's important.
> >> After many years spent on very particular implementation details, it
> >> becomes difficult to see outside of the box.
> >> 
> >> And because we already know the good aspects I'm asking only about the bad.
> >> No need to discuss or reach an agreement, just go ahead and enumerate
> >> what you don't like.
> > 
> > -- 
> > Regards, Bernhard
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[andy fillebrown]

I was hired on to my new job because of my Qt4 experience, and my
first QML related task was to convert a list view to a editable tree
view with drag and drop. It was not a good experience. The TreeView
control provided in Qt was full of bugs and I ended up pulling its
private C++ model adaptor into our project for bug fixes and writing a
bunch of javascript workarounds because there was no other way to get
it working satisfactorily. According to my co-workers, this is par for
the course for QML. Everything takes twice as long because things
don't work correctly out of the box. After having such a good
experience with QtGui widgets in Qt4 I was really sad to see how bad
QML is in comparison.

I like the idea of QML and I think the reasoning behind the shift away
from QtGui widgets is sound. There's just too many bugs, and design
view doesn't work for any .qml files in our project because the way
we're registering our custom controls is not supported in QtCreator
apparently.

Take a look at how Unity3D does their 2D UI elements sometime. It's
much easier to use than QML. It's not an apples to apples comparison
but it's something I feel like Qt should be shooting for when it comes
to ease of use. I learned both systems at the same time and Unity's
system took far less time and is much more stable.

Is the Qt team losing touch with the common developer? ...or is a lack
of resources maybe the root problem?  Both?  More?

I don't know. I'm just an average dev struggling with the new Qt. I do
know I wouldn't use Qt/QML for future projects in its current state
without giving Xamarin or some kind of HTML5 to app conversion a try,
first.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[John C. Turnbull]

It's ironic in a way that every major graphical toolkit (and with many large 
software projects in general) that I've worked with over decades now, the 
attitude has commonly seemed to have been that "new" is better than "stable".

The end result is a product full of both older and newer unstable features.

Then credibility and reputation both take a major hit and for serious 
production users, frustration overwhelms them as they wait for features they 
have been using and investing years of effort/time/money into to simply work 
without major defects.

More often than not though, if these features are not part of the "new shiny 
strategy", they tend to just rot...

> On 3 Oct. 2016, at 18:14, Bernhard Lindner  
> wrote:
> 
> 1. New features (quantity) are priorized over bug fixing (quality). 
> Suggestions 
> are almost sensless. I reduced writing bug reports and totally gave up 
> writing 
> suggestions due to this.
> 
> 2. Widgets have too low priority. In general new fancy features are priorized 
> above bread-and-butter features from my point of view.
> 
> 3. Components have been declared outdated while the replacements did not 
> provide the same feature set. This seriously damages Qt's reputation.
> 
>> It's not unusual for us developers and contributors to lose
>> perspective of what's important.
>> After many years spent on very particular implementation details, it
>> becomes difficult to see outside of the box.
>> 
>> And because we already know the good aspects I'm asking only about the bad.
>> No need to discuss or reach an agreement, just go ahead and enumerate
>> what you don't like.
> 
> -- 
> Regards, Bernhard
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Bernhard Lindner]

1. New features (quantity) are priorized over bug fixing (quality). Suggestions 
are almost sensless. I reduced writing bug reports and totally gave up writing 
suggestions due to this.

2. Widgets have too low priority. In general new fancy features are priorized 
above bread-and-butter features from my point of view.

3. Components have been declared outdated while the replacements did not 
provide the same feature set. This seriously damages Qt's reputation.

> It's not unusual for us developers and contributors to lose
> perspective of what's important.
> After many years spent on very particular implementation details, it
> becomes difficult to see outside of the box.
> 
> And because we already know the good aspects I'm asking only about the bad.
> No need to discuss or reach an agreement, just go ahead and enumerate
> what you don't like.

-- 
Regards, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Maxim]

Some things that i don't like:
-Qt uses own container classes (QList, QVector, etc.) instead STL
containers (or some kind of STL derived containers).
-Qt on Android: still big output APK size


On Sat, Sep 17, 2016 at 11:20 PM, Sérgio Martins 
wrote:

> Hi,
>
>
> It's not unusual for us developers and contributors to lose
> perspective of what's important.
> After many years spent on very particular implementation details, it
> becomes difficult to see outside of the box.
>
> And because we already know the good aspects I'm asking only about the bad.
> No need to discuss or reach an agreement, just go ahead and enumerate
> what you don't like.
>
>
> Personally, I don't know (too much time inside the box), but after
> googling these came up frequently:
>
>
> - C++ is difficult, Qt lacks quality bindings for mainstream languages
> - moc (on build systems that don't automate this step)
> - FUD around licensing
>
>
>
> Please state your top ones, even if it was already stated by someone
> else, so we have an idea about which ones matter more.
>
>
> Regards,
> Sérgio Martins
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[André Pönitz]

On Wed, Sep 28, 2016 at 12:43:37AM +0300, Konstantin Tokarev wrote:
> > I quite like QML as a declarative markup language, but am less enthused 
> > about
> > JavaScript. It seems like kind of a toy programming language. I'm a bit
> > shocked that you can write "code" where you can happily call functions or
> > access properties that don't even exist on the target object. 
> 
> Enter OOP. In classic OOP there are no function calls, you just send messages 
> to
> object, and object dispatches them "somehow"
> 
> Qt metaobject system has same properties, e.g. you can assign or read
> non-existing properties, connect to missing slots, etc.

And that's why one doesn't use the MO system *extensively* in non-trivial 
applications.

It's powerful and dangerous. It's extremely useful to bridge some gaps that the
core language left, like "soft" dependencies between plugins or introspection 
for
generated bindings. Beyond that? No, thanks. Definitely.

> >It is so easy to introduce a typo, or to remove a function or property that 
> >is
> >still needed somewhere else, and not realise it. You won't get a compile 
> >error,
> >or even a runtime crash, just strange behavior and maybe something in the
> >console log. And having functional code spread across C++ and JavaScript 
> >seems
> >less than ideal. I'm kind of getting used it, and trying to do only
> >layout-related stuff in the JavaScript, and anything that is more related to
> >application logic in C++. So you can certainly make it work - but I still 
> >feel
> >you could produce a more robust application if all of your coding could be 
> >done
> >in C++ and none in JavaScript.
> 
> Don't you have unit tests?

To catch mis-typed identifiers?

No. Why should I? I have a compiler.

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

Re: [Interest] What don't you like about Qt?

[Jason H]

Konrad:
> Also: Javascript is not an OO language: you are supposed to have classes, not 
> prototypes, for OO.

ES6 has proper classes. 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes

Rob:
> I quite like QML as a declarative markup language, but am less enthused about 
> JavaScript. It seems like kind of a toy programming language.

Love it or hate it, JavaScript is here to stay. I myself prefer Python and 
share your concerns. But JavScripts's concepts are simple enough, and it's easy 
extended. Things like SweetJS and transpilers are providing a way to address 
all the issues with JS. JS is becoming a runtime on top of the runtime. ASM.js 
runs at half native speed. So the process is you come up with you own language, 
like TypeScript, which gets translated to JS. On an ES5 platform? Use a 
transpiler to write ES6/7 code, but execute ES5.

I was disappointed when QML was not pythonic, but javascripty. But I think 
FWIW, it's fine and not a much would be changed.

One of the ways the lack of proper compiler-time checks is just to use 
microservices, so that impacts and contracts are limited. 
The other way is a test kit. You should always have a test kit.





___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Konrad Rosenbaum]

On Wednesday, September 28, 2016 10:57:01 Rob Allan wrote:
> But even
> then, in most OO languages, this is implemented through strongly-typed
> interfaces - so that if you tried to "publish" a message that wasn't
> defined, you would get a compile error. Most OO languages - Smalltalk, C++
> C#, etc - are strongly typed and have robust compile-time checking, so you
> can't just accidentally type the wrong name in a method call or property
> access, and get no error.

For the record: although Smalltalk has "strong" types (i.e. you cannot extend 
an object without changing its class), it is not statically checked! Variables 
can store any type and it determines whether an object does have a message 
during runtime. The better Smalltalk compilers do warn you (just warn, no 
error) about messages that do not exist anywhere, so you have some safety 
against typos.

OO does not require static checking - in fact polymorphy is much more powerful 
in dynamic languages, like Smalltalk or PHP.

Also: Javascript is not an OO language: you are supposed to have classes, not 
prototypes, for OO.

Konrad

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jean-Michaël Celerier]

On Tue, Sep 27, 2016 at 11:43 PM, Konstantin Tokarev 
wrote:

>
> Qt metaobject system has same properties, e.g. you can assign or read
> non-existing properties, connect to missing slots, etc.


And thanks god using it like this isn't necessary to make Qt apps.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Rob Allan]

> Enter OOP. In classic OOP there are no function calls, you just send
messages to object, and object dispatches
> them "somehow"

I don't think that sort of anonymous, decoupled messaging is the definition
of OOP. It is perhaps a description of the Observer Pattern, where the
"publisher" has no idea what "subscribers" might be out there. But even
then, in most OO languages, this is implemented through strongly-typed
interfaces - so that if you tried to "publish" a message that wasn't
defined, you would get a compile error. Most OO languages - Smalltalk, C++
C#, etc - are strongly typed and have robust compile-time checking, so you
can't just accidentally type the wrong name in a method call or property
access, and get no error. JavaScript is totally wild west in this regard -
you can pretty much type anything and it won't complain. This is not an
attribute of OO, it is an attribute of JavaScript.

> Don't you have unit tests?

Yes. But which is better, to be forced to use an inherently error-prone
language (JavaScript) and rely on unit tests to clean up the mess, or to
use a robust modern language (C++) and have less bugs to find and fix in
the first place?

Rob

On Wed, Sep 28, 2016 at 10:43 AM, Konstantin Tokarev 
wrote:

>
>
> 28.09.2016, 00:38, "Rob Allan" :
> > I tend to agree with André (not surprising as he largely agreed with
> me!). I'm not so sure about Bo's opinion that there would be lots of pain
> and complaint if the C++ classes provided a rich API to the Qt Quick object
> model. It seems like the object model is becoming more stable, and given
> that PIMPL hides most of the inner workings, it should be possible to
> continue to evolve the API with judicious use of "deprecated" pragmas, etc.
> Of course there will always be some "true" breaking changes that cause
> compile errors for Qt users, but would there really be such an outcry about
> that? Not sure.
> >
> > I quite like QML as a declarative markup language, but am less enthused
> about JavaScript. It seems like kind of a toy programming language. I'm a
> bit shocked that you can write "code" where you can happily call functions
> or access properties that don't even exist on the target object.
>
> Enter OOP. In classic OOP there are no function calls, you just send
> messages to object, and object dispatches them "somehow"
>
> Qt metaobject system has same properties, e.g. you can assign or read
> non-existing properties, connect to missing slots, etc.
>
> >It is so easy to introduce a typo, or to remove a function or property
> that is still needed somewhere else, and not realise it. You won't get a
> compile error, or even a runtime crash, just strange behavior and
> maybe something in the console log. And having functional code spread
> across C++ and JavaScript seems less than ideal. I'm kind of getting used
> it, and trying to do only layout-related stuff in the JavaScript, and
> anything that is more related to application logic in C++. So you can
> certainly make it work - but I still feel you could produce a more robust
> application if all of your coding could be done in C++ and none in
> JavaScript.
>
> Don't you have unit tests?
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Konstantin Tokarev]

28.09.2016, 00:38, "Rob Allan" :
> I tend to agree with André (not surprising as he largely agreed with me!). 
> I'm not so sure about Bo's opinion that there would be lots of pain and 
> complaint if the C++ classes provided a rich API to the Qt Quick object 
> model. It seems like the object model is becoming more stable, and given that 
> PIMPL hides most of the inner workings, it should be possible to continue to 
> evolve the API with judicious use of "deprecated" pragmas, etc. Of course 
> there will always be some "true" breaking changes that cause compile errors 
> for Qt users, but would there really be such an outcry about that? Not sure.
>
> I quite like QML as a declarative markup language, but am less enthused about 
> JavaScript. It seems like kind of a toy programming language. I'm a bit 
> shocked that you can write "code" where you can happily call functions or 
> access properties that don't even exist on the target object. 

Enter OOP. In classic OOP there are no function calls, you just send messages 
to object, and object dispatches them "somehow"

Qt metaobject system has same properties, e.g. you can assign or read 
non-existing properties, connect to missing slots, etc.

>It is so easy to introduce a typo, or to remove a function or property that is 
>still needed somewhere else, and not realise it. You won't get a compile 
>error, or even a runtime crash, just strange behavior and maybe something in 
>the console log. And having functional code spread across C++ and JavaScript 
>seems less than ideal. I'm kind of getting used it, and trying to do only 
>layout-related stuff in the JavaScript, and anything that is more related to 
>application logic in C++. So you can certainly make it work - but I still feel 
>you could produce a more robust application if all of your coding could be 
>done in C++ and none in JavaScript.

Don't you have unit tests?

>
> Rob
>
>> -- Forwarded message --
>> From: Bo Thorsen 
>> To: interest@qt-project.org
>> Cc:
>> Date: Thu, 22 Sep 2016 08:18:26 +0200
>> Subject: Re: [Interest] What don't you like about Qt?
>> Den 21-09-2016 kl. 23:53 skrev André Pönitz:
>>> On Wed, Sep 21, 2016 at 05:42:44AM +, Shawn Rutledge wrote:
>>>> On Sep 20, 2016, at 22:52, Rob Allan  wrote:
>>>>> My biggest gripe is that the Qt Quick object model seems to be much
>>>>> more poorly supported in C++ than it is in QML. For example, in C++
>>>>> you really only have access to QQuickItem - none of its derived
>>>>> classes are documented, and their interfaces are private - so the
>>>>> only way to manipulate items is using a generic "setProperty"
>>>>> syntax. This is in stark contrast to QML where all the QML types,
>>>>> methods and properties are available to you. When you have an app
>>>>> that builds most of its UI dynamically from C++ code (as ours
>>>>> does), this makes life pretty difficult. I guess this is one area
>>>>> where widgets would score better than Qt Quick (but we still prefer
>>>>> Qt Quick for a number of reasons).
>>>>
>>>> It’s intentional though: we don’t have to worry about binary
>>>> compatibility that way, or even source compatibility to an extent -
>>>> it’s only the QML API that we have to keep compatible.
>>>
>>> I believe quite a few of the people asking for C++ access to Qt Quick
>>> are perfectly aware of the state of the current implementation, at
>>> least to a degree to understand the desire to not set access to it in
>>> stone. But, after weighing pros and cons, they came to the conclusion
>>> that having *any* "official" access, even one that does not come with
>>> any binary or even source compatibility guarantees is more valuable
>>> than being restricted to QML.
>>>
>>> It is beyond me how one can hide behind the "we can't/do not want to
>>> guarantee compatibility" argument when people explicitly declared *for
>>> years* that they don't care about such for that particular scenario.
>>>
>>>> We don’t strictly even need PIMPLs (and I wonder if we could get any
>>>> speedup or memory savings if we didn’t have them), but most of the
>>>> classes have them anyway.  I guess maybe the original authors were
>>>> anticipating that the C++ API might become public some day, so they
>>>> have private objects just in case.  But making more of them public is
>>>>

Re: [Interest] What don't you like about Qt?

[Rob Allan]

I tend to agree with André (not surprising as he largely agreed with me!).
I'm not so sure about Bo's opinion that there would be lots of pain and
complaint if the C++ classes provided a rich API to the Qt Quick object
model. It seems like the object model is becoming more stable, and given
that PIMPL hides most of the inner workings, it should be possible to
continue to evolve the API with judicious use of "deprecated" pragmas, etc.
Of course there will always be some "true" breaking changes that cause
compile errors for Qt users, but would there really be such an outcry about
that? Not sure.

I quite like QML as a declarative markup language, but am less enthused
about JavaScript. It seems like kind of a toy programming language. I'm a
bit shocked that you can write "code" where you can happily call functions
or access properties that don't even exist on the target object. It is so
easy to introduce a typo, or to remove a function or property that is still
needed somewhere else, and not realise it. You won't get a compile error,
or even a runtime crash, just strange behavior and maybe something in the
console log. And having functional code spread across C++ and JavaScript
seems less than ideal. I'm kind of getting used it, and trying to do only
layout-related stuff in the JavaScript, and anything that is more related
to application logic in C++. So you can certainly make it work - but I
still feel you could produce a more robust application if all of your
coding could be done in C++ and none in JavaScript.

Rob


> -- Forwarded message --
> From: Bo Thorsen 
> To: interest@qt-project.org
> Cc:
> Date: Thu, 22 Sep 2016 08:18:26 +0200
> Subject: Re: [Interest] What don't you like about Qt?
> Den 21-09-2016 kl. 23:53 skrev André Pönitz:
>
>> On Wed, Sep 21, 2016 at 05:42:44AM +, Shawn Rutledge wrote:
>>
>>>
>>> On Sep 20, 2016, at 22:52, Rob Allan  wrote:
>>>
>>>> My biggest gripe is that the Qt Quick object model seems to be much
>>>> more poorly supported in C++ than it is in QML. For example, in C++
>>>> you really only have access to QQuickItem - none of its derived
>>>> classes are documented, and their interfaces are private - so the
>>>> only way to manipulate items is using a generic "setProperty"
>>>> syntax. This is in stark contrast to QML where all the QML types,
>>>> methods and properties are available to you. When you have an app
>>>> that builds most of its UI dynamically from C++ code (as ours
>>>> does), this makes life pretty difficult. I guess this is one area
>>>> where widgets would score better than Qt Quick (but we still prefer
>>>> Qt Quick for a number of reasons).
>>>>
>>>
>>> It’s intentional though: we don’t have to worry about binary
>>> compatibility that way, or even source compatibility to an extent -
>>> it’s only the QML API that we have to keep compatible.
>>>
>>
>> I believe quite a few of the people asking for C++ access to Qt Quick
>> are perfectly aware of the state of the current implementation, at
>> least to a degree to understand the desire to not set access to it in
>> stone. But, after weighing pros and cons, they came to the conclusion
>> that having *any* "official" access, even one that does not come with
>> any binary or even source compatibility guarantees is more valuable
>> than being restricted to QML.
>>
>> It is beyond me how one can hide behind the "we can't/do not want to
>> guarantee compatibility" argument when people explicitly declared *for
>> years* that they don't care about such for that particular scenario.
>>
>> We don’t strictly even need PIMPLs (and I wonder if we could get any
>>> speedup or memory savings if we didn’t have them), but most of the
>>> classes have them anyway.  I guess maybe the original authors were
>>> anticipating that the C++ API might become public some day, so they
>>> have private objects just in case.  But making more of them public is
>>> the same as locking the API and reducing flexibility.
>>>
>>> If there are any API warts, they become difficult to fix after that.
>>> (E.g. the restriction that we can neither add nor remove virtual
>>> functions is downright crippling sometimes.)
>>>
>>
>> There is no API lock if there is no compatibility promise. People ask
>> for the API, not the promise. Making it accessible with the usual _p.h
>> No guarantees/"We mean it." would not restrict any development,
>> and make a few peo

Re: [Interest] What don't you like about Qt?

[Jean-Michaël Celerier]

wrt FUD around licensing :

here is a recent reddit thread where someone wasn't able to see that
QtCreator was actually a free IDE :
https://www.reddit.com/r/cpp/comments/54foop/what_is_the_best_ide_for_game_development_on_mac/

> Oh, thank you! Their website was just confusing for me I couldn't figure
it out.


Best,
Jean-Michaël
<http://www.jcelerier.name>

On Fri, Sep 23, 2016 at 6:59 AM, Vlad Stelmahovsky <
vladstelmahov...@gmail.com> wrote:

> so the question: how to make it matter?
>
> On Thu, Sep 22, 2016 at 4:52 PM, Jason H  wrote:
>
>> I've never seen it claimed that voting matters 1 iota.
>>
>> I guess what we're asking for here is more prioritization transparency?
>>
>>
>> *Sent:* Thursday, September 22, 2016 at 2:27 AM
>> *From:* "Vlad Stelmahovsky" 
>> *To:* "Jason H" 
>> *Cc:* interest 
>>
>> *Subject:* Re: [Interest] What don't you like about Qt?
>> Actually you can vote for it and promote to other users to vote for it.
>> More votes - more chances issue to be solved
>>
>> On Wed, Sep 21, 2016 at 2:51 PM, Jason H  wrote:
>>>
>>> This gets at what I don't like about Qt the most: As a user I have no
>>> control of where it goes. I can (and do) file bugs and feature
>>> suggestions... How they get prioritized, I have no control over. Sometimes
>>> it's months, sometimes it's multiple years later, very often it's never (or
>>> more correctly, still not implemented yet). This is despite being a paying
>>> customer. Once the issue is entered, it might get tagged with the support
>>> contract level I am on, but it's effectively out of my hands.
>>>
>>>
>>>
>>> > Sent: Wednesday, September 21, 2016 at 8:35 AM
>>> > From: "Konstantin Tokarev" 
>>> > To: "Jean-Michaël Celerier" , "Jason
>>> H" 
>>> > Cc: interest , "Rob Allan" <
>>> rob_al...@trimble.com>
>>> > Subject: Re: [Interest] What don't you like about Qt?
>>> >
>>> >
>>> >
>>> > 21.09.2016, 15:28, "Jean-Michaël Celerier" <
>>> jeanmichael.celer...@gmail.com>:
>>> > > Hey, there is a lot of interesting points in all these answers; some
>>> similars, some not.
>>> > >
>>> > > Maybe a good way forward would be to try to pinpoint the problems
>>> more precisely with an online platform such
>>> > > as http://en.arguman.org/ ? Or even just some kind of google doc...
>>> >
>>> > I think wiki page would be a better alternative.
>>> >
>>> > >
>>> > > Starting from there would maybe make it easier for the Qt devs to
>>> weigh the "for" and "against" for the stuff that is often mentioned ?
>>> >
>>> > I doubt anyone here is going to weigh anything besides patches
>>> submitted to review.
>>> >
>>> > > Instead of having to find specific arguments in 45 mails...  And
>>> then open some paths for contributions to try to alleviate the problems.
>>> > >
>>> > > My 0.0005 cents
>>> > >
>>> > > Best
>>> > > Jean-Michaël
>>> > >
>>> > > On Wed, Sep 21, 2016 at 1:53 PM, Jason H  wrote:
>>> > >>> I also can't help making a comparison with two other popular layout
>>> > >>> frameworks: WPF/XAML, and Android/AXML. In both of these worlds,
>>> the markup
>>> > >>> language and the "code-behind" class hierarchy of UI elements are
>>> > >>> absolutely equivalent 1st class citizens. Anything you can do in
>>> XAML, you
>>> > >>> can also do in the C# code-behind, whether it be creating controls,
>>> > >>> changing their properties, altering layouts, etc. Likewise in
>>> Android/AXML,
>>> > >>> I can (if I choose) create FrameLayouts, RelativeLayouts,
>>> TextViews, etc in
>>> > >>> code, and arrange them and manipulate them any way I like, as an
>>> > >>> alternative to creating an AXML designer layout.
>>> > >>>
>>> > >>> It seems unfortunate that Qt Quick doesn't take this approach, and
>>> that the
>>> > >>> "code-behind" experience is so limited. One reason that I've heard
>>> why it
>>> > >

Re: [Interest] What don't you like about Qt?

[Vlad Stelmahovsky]

so the question: how to make it matter?

On Thu, Sep 22, 2016 at 4:52 PM, Jason H  wrote:

> I've never seen it claimed that voting matters 1 iota.
>
> I guess what we're asking for here is more prioritization transparency?
>
>
> *Sent:* Thursday, September 22, 2016 at 2:27 AM
> *From:* "Vlad Stelmahovsky" 
> *To:* "Jason H" 
> *Cc:* interest 
>
> *Subject:* Re: [Interest] What don't you like about Qt?
> Actually you can vote for it and promote to other users to vote for it.
> More votes - more chances issue to be solved
>
> On Wed, Sep 21, 2016 at 2:51 PM, Jason H  wrote:
>>
>> This gets at what I don't like about Qt the most: As a user I have no
>> control of where it goes. I can (and do) file bugs and feature
>> suggestions... How they get prioritized, I have no control over. Sometimes
>> it's months, sometimes it's multiple years later, very often it's never (or
>> more correctly, still not implemented yet). This is despite being a paying
>> customer. Once the issue is entered, it might get tagged with the support
>> contract level I am on, but it's effectively out of my hands.
>>
>>
>>
>> > Sent: Wednesday, September 21, 2016 at 8:35 AM
>> > From: "Konstantin Tokarev" 
>> > To: "Jean-Michaël Celerier" , "Jason
>> H" 
>> > Cc: interest , "Rob Allan" <
>> rob_al...@trimble.com>
>> > Subject: Re: [Interest] What don't you like about Qt?
>> >
>> >
>> >
>> > 21.09.2016, 15:28, "Jean-Michaël Celerier" > com>:
>> > > Hey, there is a lot of interesting points in all these answers; some
>> similars, some not.
>> > >
>> > > Maybe a good way forward would be to try to pinpoint the problems
>> more precisely with an online platform such
>> > > as http://en.arguman.org/ ? Or even just some kind of google doc...
>> >
>> > I think wiki page would be a better alternative.
>> >
>> > >
>> > > Starting from there would maybe make it easier for the Qt devs to
>> weigh the "for" and "against" for the stuff that is often mentioned ?
>> >
>> > I doubt anyone here is going to weigh anything besides patches
>> submitted to review.
>> >
>> > > Instead of having to find specific arguments in 45 mails...  And then
>> open some paths for contributions to try to alleviate the problems.
>> > >
>> > > My 0.0005 cents
>> > >
>> > > Best
>> > > Jean-Michaël
>> > >
>> > > On Wed, Sep 21, 2016 at 1:53 PM, Jason H  wrote:
>> > >>> I also can't help making a comparison with two other popular layout
>> > >>> frameworks: WPF/XAML, and Android/AXML. In both of these worlds,
>> the markup
>> > >>> language and the "code-behind" class hierarchy of UI elements are
>> > >>> absolutely equivalent 1st class citizens. Anything you can do in
>> XAML, you
>> > >>> can also do in the C# code-behind, whether it be creating controls,
>> > >>> changing their properties, altering layouts, etc. Likewise in
>> Android/AXML,
>> > >>> I can (if I choose) create FrameLayouts, RelativeLayouts,
>> TextViews, etc in
>> > >>> code, and arrange them and manipulate them any way I like, as an
>> > >>> alternative to creating an AXML designer layout.
>> > >>>
>> > >>> It seems unfortunate that Qt Quick doesn't take this approach, and
>> that the
>> > >>> "code-behind" experience is so limited. One reason that I've heard
>> why it
>> > >>> might have been done this way is that a rich and fully public C++
>> interface
>> > >>> may have hamstrung the developers too much, as there would be
>> constant
>> > >>> breaking changes from one release to the next. If that's true then
>> I guess
>> > >>> I understand that, but I would still rather put up with a rich C++
>> > >>> interface that had breaking changes at new releases, than the
>> relative
>> > >>> limited C++ interface we have now.
>> > >>
>> > >> I'm not sure I follow. Declarituce UI is in. QML, React (+JSX)  give
>> you decaritive layouts. It convergent evolution of stucture±properties+code
>> > >>
>> > >

Re: [Interest] What don't you like about Qt?

[Jason H]

I've never seen it claimed that voting matters 1 iota.

 

I guess what we're asking for here is more prioritization transparency?

 

 



Sent: Thursday, September 22, 2016 at 2:27 AM
From: "Vlad Stelmahovsky" 
To: "Jason H" 
Cc: interest 
Subject: Re: [Interest] What don't you like about Qt?


Actually you can vote for it and promote to other users to vote for it. More votes - more chances issue to be solved

 
On Wed, Sep 21, 2016 at 2:51 PM, Jason H <jh...@gmx.com> wrote:

This gets at what I don't like about Qt the most: As a user I have no control of where it goes. I can (and do) file bugs and feature suggestions... How they get prioritized, I have no control over. Sometimes it's months, sometimes it's multiple years later, very often it's never (or more correctly, still not implemented yet). This is despite being a paying customer. Once the issue is entered, it might get tagged with the support contract level I am on, but it's effectively out of my hands.



> Sent: Wednesday, September 21, 2016 at 8:35 AM
> From: "Konstantin Tokarev" <annu...@yandex.ru>
> To: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>, "Jason H" <jh...@gmx.com>
> Cc: interest <interest@qt-project.org>, "Rob Allan" <rob_al...@trimble.com>
> Subject: Re: [Interest] What don't you like about Qt?

>
>
>
> 21.09.2016, 15:28, "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>:
> > Hey, there is a lot of interesting points in all these answers; some similars, some not.
> >
> > Maybe a good way forward would be to try to pinpoint the problems more precisely with an online platform such
> > as http://en.arguman.org/ ? Or even just some kind of google doc...
>
> I think wiki page would be a better alternative.
>
> >
> > Starting from there would maybe make it easier for the Qt devs to weigh the "for" and "against" for the stuff that is often mentioned ?
>
> I doubt anyone here is going to weigh anything besides patches submitted to review.
>
> > Instead of having to find specific arguments in 45 mails...  And then open some paths for contributions to try to alleviate the problems.
> >
> > My 0.0005 cents
> >
> > Best
> > Jean-Michaël
> >
> > On Wed, Sep 21, 2016 at 1:53 PM, Jason H <jh...@gmx.com> wrote:
> >>> I also can't help making a comparison with two other popular layout
> >>> frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the markup
> >>> language and the "code-behind" class hierarchy of UI elements are
> >>> absolutely equivalent 1st class citizens. Anything you can do in XAML, you
> >>> can also do in the C# code-behind, whether it be creating controls,
> >>> changing their properties, altering layouts, etc. Likewise in Android/AXML,
> >>> I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews, etc in
> >>> code, and arrange them and manipulate them any way I like, as an
> >>> alternative to creating an AXML designer layout.
> >>>
> >>> It seems unfortunate that Qt Quick doesn't take this approach, and that the
> >>> "code-behind" experience is so limited. One reason that I've heard why it
> >>> might have been done this way is that a rich and fully public C++ interface
> >>> may have hamstrung the developers too much, as there would be constant
> >>> breaking changes from one release to the next. If that's true then I guess
> >>> I understand that, but I would still rather put up with a rich C++
> >>> interface that had breaking changes at new releases, than the relative
> >>> limited C++ interface we have now.
> >>
> >> I'm not sure I follow. Declarituce UI is in. QML, React (+JSX)  give you decaritive layouts. It convergent evolution of stucture±properties+code
> >>
> >> XAML, WPF, Qt Widgets all have structure and properties but no code.  You've got to create the objects then in another context, assign code to them.
> >>
> >> If you are taking about how QQuickItems wrap C++ my understanding is that's because of the scene graph. My perspective is that the C++ side is better before I'm always having to drop from QML to C++ to expose stuff for QML. So I really don't understand your issue?
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
> > ,
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
>
> --
> Regards,
> Konstantin
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



 

 
--


Best regards,
Vlad







___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Vlad Stelmahovsky]

Actually you can vote for it and promote to other users to vote for it.
More votes - more chances issue to be solved

On Wed, Sep 21, 2016 at 2:51 PM, Jason H  wrote:

> This gets at what I don't like about Qt the most: As a user I have no
> control of where it goes. I can (and do) file bugs and feature
> suggestions... How they get prioritized, I have no control over. Sometimes
> it's months, sometimes it's multiple years later, very often it's never (or
> more correctly, still not implemented yet). This is despite being a paying
> customer. Once the issue is entered, it might get tagged with the support
> contract level I am on, but it's effectively out of my hands.
>
>
>
> > Sent: Wednesday, September 21, 2016 at 8:35 AM
> > From: "Konstantin Tokarev" 
> > To: "Jean-Michaël Celerier" , "Jason H"
> 
> > Cc: interest , "Rob Allan" <
> rob_al...@trimble.com>
> > Subject: Re: [Interest] What don't you like about Qt?
> >
> >
> >
> > 21.09.2016, 15:28, "Jean-Michaël Celerier"  com>:
> > > Hey, there is a lot of interesting points in all these answers; some
> similars, some not.
> > >
> > > Maybe a good way forward would be to try to pinpoint the problems more
> precisely with an online platform such
> > > as http://en.arguman.org/ ? Or even just some kind of google doc...
> >
> > I think wiki page would be a better alternative.
> >
> > >
> > > Starting from there would maybe make it easier for the Qt devs to
> weigh the "for" and "against" for the stuff that is often mentioned ?
> >
> > I doubt anyone here is going to weigh anything besides patches submitted
> to review.
> >
> > > Instead of having to find specific arguments in 45 mails...  And then
> open some paths for contributions to try to alleviate the problems.
> > >
> > > My 0.0005 cents
> > >
> > > Best
> > > Jean-Michaël
> > >
> > > On Wed, Sep 21, 2016 at 1:53 PM, Jason H  wrote:
> > >>> I also can't help making a comparison with two other popular layout
> > >>> frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the
> markup
> > >>> language and the "code-behind" class hierarchy of UI elements are
> > >>> absolutely equivalent 1st class citizens. Anything you can do in
> XAML, you
> > >>> can also do in the C# code-behind, whether it be creating controls,
> > >>> changing their properties, altering layouts, etc. Likewise in
> Android/AXML,
> > >>> I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews,
> etc in
> > >>> code, and arrange them and manipulate them any way I like, as an
> > >>> alternative to creating an AXML designer layout.
> > >>>
> > >>> It seems unfortunate that Qt Quick doesn't take this approach, and
> that the
> > >>> "code-behind" experience is so limited. One reason that I've heard
> why it
> > >>> might have been done this way is that a rich and fully public C++
> interface
> > >>> may have hamstrung the developers too much, as there would be
> constant
> > >>> breaking changes from one release to the next. If that's true then I
> guess
> > >>> I understand that, but I would still rather put up with a rich C++
> > >>> interface that had breaking changes at new releases, than the
> relative
> > >>> limited C++ interface we have now.
> > >>
> > >> I'm not sure I follow. Declarituce UI is in. QML, React (+JSX)  give
> you decaritive layouts. It convergent evolution of stucture±properties+code
> > >>
> > >> XAML, WPF, Qt Widgets all have structure and properties but no code.
> You've got to create the objects then in another context, assign code to
> them.
> > >>
> > >> If you are taking about how QQuickItems wrap C++ my understanding is
> that's because of the scene graph. My perspective is that the C++ side is
> better before I'm always having to drop from QML to C++ to expose stuff for
> QML. So I really don't understand your issue?
> > >> ___
> > >> Interest mailing list
> > >> Interest@qt-project.org
> > >> http://lists.qt-project.org/mailman/listinfo/interest
> > > ,
> > >
> > > ___
> > > Interest mailing list
> > > Interest@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/interest
> >
> >
> > --
> > Regards,
> > Konstantin
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Bo Thorsen]

Den 21-09-2016 kl. 23:53 skrev André Pönitz:

On Wed, Sep 21, 2016 at 05:42:44AM +, Shawn Rutledge wrote:


On Sep 20, 2016, at 22:52, Rob Allan  wrote:

My biggest gripe is that the Qt Quick object model seems to be much
more poorly supported in C++ than it is in QML. For example, in C++
you really only have access to QQuickItem - none of its derived
classes are documented, and their interfaces are private - so the
only way to manipulate items is using a generic "setProperty"
syntax. This is in stark contrast to QML where all the QML types,
methods and properties are available to you. When you have an app
that builds most of its UI dynamically from C++ code (as ours
does), this makes life pretty difficult. I guess this is one area
where widgets would score better than Qt Quick (but we still prefer
Qt Quick for a number of reasons).


It’s intentional though: we don’t have to worry about binary
compatibility that way, or even source compatibility to an extent -
it’s only the QML API that we have to keep compatible.


I believe quite a few of the people asking for C++ access to Qt Quick
are perfectly aware of the state of the current implementation, at
least to a degree to understand the desire to not set access to it in
stone. But, after weighing pros and cons, they came to the conclusion
that having *any* "official" access, even one that does not come with
any binary or even source compatibility guarantees is more valuable
than being restricted to QML.

It is beyond me how one can hide behind the "we can't/do not want to
guarantee compatibility" argument when people explicitly declared *for
years* that they don't care about such for that particular scenario.


We don’t strictly even need PIMPLs (and I wonder if we could get any
speedup or memory savings if we didn’t have them), but most of the
classes have them anyway.  I guess maybe the original authors were
anticipating that the C++ API might become public some day, so they
have private objects just in case.  But making more of them public is
the same as locking the API and reducing flexibility.

If there are any API warts, they become difficult to fix after that.
(E.g. the restriction that we can neither add nor remove virtual
functions is downright crippling sometimes.)


There is no API lock if there is no compatibility promise. People ask
for the API, not the promise. Making it accessible with the usual _p.h
No guarantees/"We mean it." would not restrict any development,
and make a few people happier.


André, while I actually agree with pretty much everything you write, I 
also think you're a bit naïve in thinking it would work. I can already 
imagine all the angry emails about how difficult it is to upgrade to new 
versions because people have to rewrite the C++ code behind the QML 
stuff. This would lead to a lot of "Qt sucks" zealots in companies out 
there. Especially from those who have been forced by others to use a 
framework they weren't interested in in the first place. Introducing 
anything that will intentionally break source compatibility between 
releases is IMHO a complete no-go.


What I would like to see that mostly fixes this would be:

- a factory class so you actually can instantiate QML objects from C++ 
without eval'ing strings


- a way for the property setting and getting to fail, if the property 
isn't declared. Dynamic property setting always works at the moment


- a C++ and JS way to set up bindings

Yes, the code looks different than normal instantiate and call methods 
on C++ objects. But it's a way to do support C++ code behind QML without 
binary compatibility issues.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ experts for hire
http://www.vikingsoft.eu
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[André Pönitz]

On Wed, Sep 21, 2016 at 05:42:44AM +, Shawn Rutledge wrote:
> 
> On Sep 20, 2016, at 22:52, Rob Allan  wrote:
> > My biggest gripe is that the Qt Quick object model seems to be much
> > more poorly supported in C++ than it is in QML. For example, in C++
> > you really only have access to QQuickItem - none of its derived
> > classes are documented, and their interfaces are private - so the
> > only way to manipulate items is using a generic "setProperty"
> > syntax. This is in stark contrast to QML where all the QML types,
> > methods and properties are available to you. When you have an app
> > that builds most of its UI dynamically from C++ code (as ours
> > does), this makes life pretty difficult. I guess this is one area
> > where widgets would score better than Qt Quick (but we still prefer
> > Qt Quick for a number of reasons).
> 
> It’s intentional though: we don’t have to worry about binary
> compatibility that way, or even source compatibility to an extent -
> it’s only the QML API that we have to keep compatible.

I believe quite a few of the people asking for C++ access to Qt Quick
are perfectly aware of the state of the current implementation, at
least to a degree to understand the desire to not set access to it in
stone. But, after weighing pros and cons, they came to the conclusion
that having *any* "official" access, even one that does not come with
any binary or even source compatibility guarantees is more valuable
than being restricted to QML.

It is beyond me how one can hide behind the "we can't/do not want to
guarantee compatibility" argument when people explicitly declared *for
years* that they don't care about such for that particular scenario.

> We don’t strictly even need PIMPLs (and I wonder if we could get any
> speedup or memory savings if we didn’t have them), but most of the
> classes have them anyway.  I guess maybe the original authors were
> anticipating that the C++ API might become public some day, so they
> have private objects just in case.  But making more of them public is
> the same as locking the API and reducing flexibility.
>
> If there are any API warts, they become difficult to fix after that.
> (E.g. the restriction that we can neither add nor remove virtual
> functions is downright crippling sometimes.)

There is no API lock if there is no compatibility promise. People ask
for the API, not the promise. Making it accessible with the usual _p.h
No guarantees/"We mean it." would not restrict any development,
and make a few people happier.

> I think that there should be a more extensive C++ interface to the
> scene graph itself.  People complain that QtQuick is bloated: you
> have to create too many QObjects and too many bindings; so what’s the
> difference if you do it in C++ instead of QML?

Come on. Yes, it is bloated, and this particular problem won't go away
by making it accessible from C++. But that's absolutely not the only
point, not even the most important one. On my personal "more important"
list is at least access to a plethora of standard tools (code checkers,
profilers, debuggers, refactory tools) when using C++, the ease of
maintenance of a uniform code base where simple refactoring like
renaming "just works", compile time reality checks, and easier
integration in large projects where Qt is just one out of many building
blocks.

> But the scene graph nodes are fundamental and inescapable - hopefully
> not as bloated either.  (Why must they exist?  Because batching is
> fundamental to get good performance in OpenGL: you use a scene graph
> because you don’t want to make thousands of draw calls to draw the UI
> each time it changes.)

[I thought by now the prediction that OpenGL will be all that matters
in 2018 has been abandoned.  Not to mention that the sunny side of
OpenGL never extended to such mundane tasks like displaying text, and
that it probably would make sense to re-evaluate architectural decision
that were solely bases on that buried assumption.  But that's a
different topic to whine about]

> If you don’t like Javascript, there isn’t yet
> a good way to omit the whole engine from your build; but I think
> there should be, and then it might be practical to use the scene
> graph directly.  But that would be a static scene; to make it dynamic
> and interactive you'd have to re-invent some difficult things: event
> delivery, (most types of) animations, layouts, etc.  If you want to
> bind another language to the scene graph though, and use
> different/functional/more-elegant paradigms for the interactive
> stuff, it’s not a bad place for the boundary, right?

Probably not. A least this sounds like a reasonable starting point.
Also, without compatibility promises, not getting the boundary
right in the first attempt is not fatal.
 
Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 09:08:09 PDT André Somers wrote:
> Op 20/09/2016 om 22:09 schreef Alejandro Exojo:
> > On Monday 19 September 2016 18:35:43 Etienne Sandré-Chardonnal wrote:
> >> Yes, but for instance you can't move-pass an object between signals and
> >> slots across a queued connection, unless I'm wrong. You have to make your
> >> object implicitely shared. This causes lots of copies when passing a
> >> std::vector, for instance.
> > 
> > The Qt style on designing signals, is to use those for indicating that
> > something happened, but not passing the something in the signal. For
> > example, you get a signal that new data is available (e.g. a datagram),
> > but you don't get the datagram passed as signal argument.
> 
> You don't? Well, you can certainly get a pointer to it (which is cheap,
> of course)...
> See QNetworkAccessManager::finished(QNetworkReply *reply); [signal]

That's to indicate *which* reply finished. That's not passing actual data, 
since you probably already had a pointer to this QNetworkReply anyway.

Similarly to bytesWritten(qint64): it tells you how many bytes were written 
and we found that it's the most common action that happens in the slot. 
Compare to readyRead(): it could have told you how many bytes were read, but 
it would never give you the bytes that were read. That's up to you. And since 
you'd have to read yourself, giving you the count of how many bytes were read 
since the last time wasn't a very useful information.

> I would say that it is quite normal to signal the finishing of some
> operation _and_ directly pass along the results of that operation. If
> that is a std::vector, then indeed it would result in copying (so I'd go
> looking for a different design there, perhaps use a QVector instead).

Signals with non-trivial content are uncommon.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Xavier Bigand]

As some recommands to me to build my own version of Qt, I give it a try.
Sadly I am not able to build Qt 5.8 alpha nor the branch 5.8 from git. I
switched to the branch 5.7 that seems to compile correctly (still running).

That exactly why I think that it would be great if binaries of alpha and
beta were released in the Qt Maintenance Tool.

2016-09-21 14:51 GMT+02:00 Jason H :

> This gets at what I don't like about Qt the most: As a user I have no
> control of where it goes. I can (and do) file bugs and feature
> suggestions... How they get prioritized, I have no control over. Sometimes
> it's months, sometimes it's multiple years later, very often it's never (or
> more correctly, still not implemented yet). This is despite being a paying
> customer. Once the issue is entered, it might get tagged with the support
> contract level I am on, but it's effectively out of my hands.
>
>
>
> > Sent: Wednesday, September 21, 2016 at 8:35 AM
> > From: "Konstantin Tokarev" 
> > To: "Jean-Michaël Celerier" , "Jason H"
> 
> > Cc: interest , "Rob Allan" <
> rob_al...@trimble.com>
> > Subject: Re: [Interest] What don't you like about Qt?
> >
> >
> >
> > 21.09.2016, 15:28, "Jean-Michaël Celerier"  com>:
> > > Hey, there is a lot of interesting points in all these answers; some
> similars, some not.
> > >
> > > Maybe a good way forward would be to try to pinpoint the problems more
> precisely with an online platform such
> > > as http://en.arguman.org/ ? Or even just some kind of google doc...
> >
> > I think wiki page would be a better alternative.
> >
> > >
> > > Starting from there would maybe make it easier for the Qt devs to
> weigh the "for" and "against" for the stuff that is often mentioned ?
> >
> > I doubt anyone here is going to weigh anything besides patches submitted
> to review.
> >
> > > Instead of having to find specific arguments in 45 mails...  And then
> open some paths for contributions to try to alleviate the problems.
> > >
> > > My 0.0005 cents
> > >
> > > Best
> > > Jean-Michaël
> > >
> > > On Wed, Sep 21, 2016 at 1:53 PM, Jason H  wrote:
> > >>> I also can't help making a comparison with two other popular layout
> > >>> frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the
> markup
> > >>> language and the "code-behind" class hierarchy of UI elements are
> > >>> absolutely equivalent 1st class citizens. Anything you can do in
> XAML, you
> > >>> can also do in the C# code-behind, whether it be creating controls,
> > >>> changing their properties, altering layouts, etc. Likewise in
> Android/AXML,
> > >>> I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews,
> etc in
> > >>> code, and arrange them and manipulate them any way I like, as an
> > >>> alternative to creating an AXML designer layout.
> > >>>
> > >>> It seems unfortunate that Qt Quick doesn't take this approach, and
> that the
> > >>> "code-behind" experience is so limited. One reason that I've heard
> why it
> > >>> might have been done this way is that a rich and fully public C++
> interface
> > >>> may have hamstrung the developers too much, as there would be
> constant
> > >>> breaking changes from one release to the next. If that's true then I
> guess
> > >>> I understand that, but I would still rather put up with a rich C++
> > >>> interface that had breaking changes at new releases, than the
> relative
> > >>> limited C++ interface we have now.
> > >>
> > >> I'm not sure I follow. Declarituce UI is in. QML, React (+JSX)  give
> you decaritive layouts. It convergent evolution of stucture±properties+code
> > >>
> > >> XAML, WPF, Qt Widgets all have structure and properties but no code.
> You've got to create the objects then in another context, assign code to
> them.
> > >>
> > >> If you are taking about how QQuickItems wrap C++ my understanding is
> that's because of the scene graph. My perspective is that the C++ side is
> better before I'm always having to drop from QML to C++ to expose stuff for
> QML. So I really don't understand your issue?
> > >> ___
> > >> Interest mailing list
> > >> Interest@qt-project.org
> > >> http://lists.qt-project.org/mailman/listinfo/interest
> > > ,
> > >
> > > ___
> > > Interest mailing list
> > > Interest@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/interest
> >
> >
> > --
> > Regards,
> > Konstantin
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



-- 
Xavier
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

This gets at what I don't like about Qt the most: As a user I have no control 
of where it goes. I can (and do) file bugs and feature suggestions... How they 
get prioritized, I have no control over. Sometimes it's months, sometimes it's 
multiple years later, very often it's never (or more correctly, still not 
implemented yet). This is despite being a paying customer. Once the issue is 
entered, it might get tagged with the support contract level I am on, but it's 
effectively out of my hands.



> Sent: Wednesday, September 21, 2016 at 8:35 AM
> From: "Konstantin Tokarev" 
> To: "Jean-Michaël Celerier" , "Jason H" 
> 
> Cc: interest , "Rob Allan" 
> Subject: Re: [Interest] What don't you like about Qt?
>
> 
> 
> 21.09.2016, 15:28, "Jean-Michaël Celerier" :
> > Hey, there is a lot of interesting points in all these answers; some 
> > similars, some not.
> >
> > Maybe a good way forward would be to try to pinpoint the problems more 
> > precisely with an online platform such
> > as http://en.arguman.org/ ? Or even just some kind of google doc...
> 
> I think wiki page would be a better alternative.
> 
> >
> > Starting from there would maybe make it easier for the Qt devs to weigh the 
> > "for" and "against" for the stuff that is often mentioned ?
> 
> I doubt anyone here is going to weigh anything besides patches submitted to 
> review.
> 
> > Instead of having to find specific arguments in 45 mails...  And then open 
> > some paths for contributions to try to alleviate the problems.
> >
> > My 0.0005 cents
> >
> > Best
> > Jean-Michaël
> >
> > On Wed, Sep 21, 2016 at 1:53 PM, Jason H  wrote:
> >>> I also can't help making a comparison with two other popular layout
> >>> frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the 
> >>> markup
> >>> language and the "code-behind" class hierarchy of UI elements are
> >>> absolutely equivalent 1st class citizens. Anything you can do in XAML, you
> >>> can also do in the C# code-behind, whether it be creating controls,
> >>> changing their properties, altering layouts, etc. Likewise in 
> >>> Android/AXML,
> >>> I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews, etc 
> >>> in
> >>> code, and arrange them and manipulate them any way I like, as an
> >>> alternative to creating an AXML designer layout.
> >>>
> >>> It seems unfortunate that Qt Quick doesn't take this approach, and that 
> >>> the
> >>> "code-behind" experience is so limited. One reason that I've heard why it
> >>> might have been done this way is that a rich and fully public C++ 
> >>> interface
> >>> may have hamstrung the developers too much, as there would be constant
> >>> breaking changes from one release to the next. If that's true then I guess
> >>> I understand that, but I would still rather put up with a rich C++
> >>> interface that had breaking changes at new releases, than the relative
> >>> limited C++ interface we have now.
> >>
> >> I'm not sure I follow. Declarituce UI is in. QML, React (+JSX)  give you 
> >> decaritive layouts. It convergent evolution of stucture±properties+code
> >>
> >> XAML, WPF, Qt Widgets all have structure and properties but no code.  
> >> You've got to create the objects then in another context, assign code to 
> >> them.
> >>
> >> If you are taking about how QQuickItems wrap C++ my understanding is 
> >> that's because of the scene graph. My perspective is that the C++ side is 
> >> better before I'm always having to drop from QML to C++ to expose stuff 
> >> for QML. So I really don't understand your issue?
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
> > ,
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> 
> 
> -- 
> Regards,
> Konstantin
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Konstantin Tokarev]

21.09.2016, 15:28, "Jean-Michaël Celerier" :
> Hey, there is a lot of interesting points in all these answers; some 
> similars, some not.
>
> Maybe a good way forward would be to try to pinpoint the problems more 
> precisely with an online platform such
> as http://en.arguman.org/ ? Or even just some kind of google doc...

I think wiki page would be a better alternative.

>
> Starting from there would maybe make it easier for the Qt devs to weigh the 
> "for" and "against" for the stuff that is often mentioned ?

I doubt anyone here is going to weigh anything besides patches submitted to 
review.

> Instead of having to find specific arguments in 45 mails...  And then open 
> some paths for contributions to try to alleviate the problems.
>
> My 0.0005 cents
>
> Best
> Jean-Michaël
>
> On Wed, Sep 21, 2016 at 1:53 PM, Jason H  wrote:
>>> I also can't help making a comparison with two other popular layout
>>> frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the markup
>>> language and the "code-behind" class hierarchy of UI elements are
>>> absolutely equivalent 1st class citizens. Anything you can do in XAML, you
>>> can also do in the C# code-behind, whether it be creating controls,
>>> changing their properties, altering layouts, etc. Likewise in Android/AXML,
>>> I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews, etc in
>>> code, and arrange them and manipulate them any way I like, as an
>>> alternative to creating an AXML designer layout.
>>>
>>> It seems unfortunate that Qt Quick doesn't take this approach, and that the
>>> "code-behind" experience is so limited. One reason that I've heard why it
>>> might have been done this way is that a rich and fully public C++ interface
>>> may have hamstrung the developers too much, as there would be constant
>>> breaking changes from one release to the next. If that's true then I guess
>>> I understand that, but I would still rather put up with a rich C++
>>> interface that had breaking changes at new releases, than the relative
>>> limited C++ interface we have now.
>>
>> I'm not sure I follow. Declarituce UI is in. QML, React (+JSX)  give you 
>> decaritive layouts. It convergent evolution of stucture±properties+code
>>
>> XAML, WPF, Qt Widgets all have structure and properties but no code.  You've 
>> got to create the objects then in another context, assign code to them.
>>
>> If you are taking about how QQuickItems wrap C++ my understanding is that's 
>> because of the scene graph. My perspective is that the C++ side is better 
>> before I'm always having to drop from QML to C++ to expose stuff for QML. So 
>> I really don't understand your issue?
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


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

Re: [Interest] What don't you like about Qt?

[Jean-Michaël Celerier]

Hey, there is a lot of interesting points in all these answers; some
similars, some not.

Maybe a good way forward would be to try to pinpoint the problems more
precisely with an online platform such
as http://en.arguman.org/ ? Or even just some kind of google doc...

Starting from there would maybe make it easier for the Qt devs to weigh the
"for" and "against" for the stuff that is often mentioned ?
Instead of having to find specific arguments in 45 mails...
 And then open some paths for contributions to try to alleviate the
problems.

My 0.0005 cents

Best
Jean-Michaël

On Wed, Sep 21, 2016 at 1:53 PM, Jason H  wrote:

> > I also can't help making a comparison with two other popular layout
> > frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the
> markup
> > language and the "code-behind" class hierarchy of UI elements are
> > absolutely equivalent 1st class citizens. Anything you can do in XAML,
> you
> > can also do in the C# code-behind, whether it be creating controls,
> > changing their properties, altering layouts, etc. Likewise in
> Android/AXML,
> > I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews, etc
> in
> > code, and arrange them and manipulate them any way I like, as an
> > alternative to creating an AXML designer layout.
> >
> > It seems unfortunate that Qt Quick doesn't take this approach, and that
> the
> > "code-behind" experience is so limited. One reason that I've heard why it
> > might have been done this way is that a rich and fully public C++
> interface
> > may have hamstrung the developers too much, as there would be constant
> > breaking changes from one release to the next. If that's true then I
> guess
> > I understand that, but I would still rather put up with a rich C++
> > interface that had breaking changes at new releases, than the relative
> > limited C++ interface we have now.
>
> I'm not sure I follow. Declarituce UI is in. QML, React (+JSX)  give you
> decaritive layouts. It convergent evolution of stucture±properties+code
>
> XAML, WPF, Qt Widgets all have structure and properties but no code.
> You've got to create the objects then in another context, assign code to
> them.
>
> If you are taking about how QQuickItems wrap C++ my understanding is
> that's because of the scene graph. My perspective is that the C++ side is
> better before I'm always having to drop from QML to C++ to expose stuff for
> QML. So I really don't understand your issue?
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

> I also can't help making a comparison with two other popular layout
> frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the markup
> language and the "code-behind" class hierarchy of UI elements are
> absolutely equivalent 1st class citizens. Anything you can do in XAML, you
> can also do in the C# code-behind, whether it be creating controls,
> changing their properties, altering layouts, etc. Likewise in Android/AXML,
> I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews, etc in
> code, and arrange them and manipulate them any way I like, as an
> alternative to creating an AXML designer layout.
> 
> It seems unfortunate that Qt Quick doesn't take this approach, and that the
> "code-behind" experience is so limited. One reason that I've heard why it
> might have been done this way is that a rich and fully public C++ interface
> may have hamstrung the developers too much, as there would be constant
> breaking changes from one release to the next. If that's true then I guess
> I understand that, but I would still rather put up with a rich C++
> interface that had breaking changes at new releases, than the relative
> limited C++ interface we have now.

I'm not sure I follow. Declarituce UI is in. QML, React (+JSX)  give you 
decaritive layouts. It convergent evolution of stucture±properties+code

XAML, WPF, Qt Widgets all have structure and properties but no code.  You've 
got to create the objects then in another context, assign code to them. 

If you are taking about how QQuickItems wrap C++ my understanding is that's 
because of the scene graph. My perspective is that the C++ side is better 
before I'm always having to drop from QML to C++ to expose stuff for QML. So I 
really don't understand your issue?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Björn Piltz]

I switched from qmake to cmake some five+ years ago and while I don't
regret it, it takes the 'I' out of all the IDEs I use. No class wizard or
real refactoring. Creating a new class or worse library or project takes a
lot of blind text editing. This could only be fixed by a full fledged QBS I
guess.

2016-09-21 9:08 GMT+02:00 André Somers :

>
>
> Op 20/09/2016 om 22:09 schreef Alejandro Exojo:
>
>> On Monday 19 September 2016 18:35:43 Etienne Sandré-Chardonnal wrote:
>>
>>> Yes, but for instance you can't move-pass an object between signals and
>>> slots across a queued connection, unless I'm wrong. You have to make your
>>> object implicitely shared. This causes lots of copies when passing a
>>> std::vector, for instance.
>>>
>> The Qt style on designing signals, is to use those for indicating that
>> something happened, but not passing the something in the signal. For
>> example,
>> you get a signal that new data is available (e.g. a datagram), but you
>> don't
>> get the datagram passed as signal argument.
>>
> You don't? Well, you can certainly get a pointer to it (which is cheap, of
> course)...
> See QNetworkAccessManager::finished(QNetworkReply *reply); [signal]
>
> I would say that it is quite normal to signal the finishing of some
> operation _and_ directly pass along the results of that operation. If that
> is a std::vector, then indeed it would result in copying (so I'd go looking
> for a different design there, perhaps use a QVector instead).
>
> André
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[André Somers]

Op 20/09/2016 om 22:09 schreef Alejandro Exojo:

On Monday 19 September 2016 18:35:43 Etienne Sandré-Chardonnal wrote:

Yes, but for instance you can't move-pass an object between signals and
slots across a queued connection, unless I'm wrong. You have to make your
object implicitely shared. This causes lots of copies when passing a
std::vector, for instance.

The Qt style on designing signals, is to use those for indicating that
something happened, but not passing the something in the signal. For example,
you get a signal that new data is available (e.g. a datagram), but you don't
get the datagram passed as signal argument.
You don't? Well, you can certainly get a pointer to it (which is cheap, 
of course)...

See QNetworkAccessManager::finished(QNetworkReply *reply); [signal]

I would say that it is quite normal to signal the finishing of some 
operation _and_ directly pass along the results of that operation. If 
that is a std::vector, then indeed it would result in copying (so I'd go 
looking for a different design there, perhaps use a QVector instead).


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Shawn Rutledge]

On Sep 20, 2016, at 22:52, Rob Allan  wrote:
> My biggest gripe is that the Qt Quick object model seems to be much more 
> poorly supported in C++ than it is in QML. For example, in C++ you really 
> only have access to QQuickItem - none of its derived classes are documented, 
> and their interfaces are private - so the only way to manipulate items is 
> using a generic "setProperty" syntax. This is in stark contrast to QML where 
> all the QML types, methods and properties are available to you. When you have 
> an app that builds most of its UI dynamically from C++ code (as ours does), 
> this makes life pretty difficult. I guess this is one area where widgets 
> would score better than Qt Quick (but we still prefer Qt Quick for a number 
> of reasons).

It’s intentional though: we don’t have to worry about binary compatibility that 
way, or even source compatibility to an extent - it’s only the QML API that we 
have to keep compatible.  We don’t strictly even need PIMPLs (and I wonder if 
we could get any speedup or memory savings if we didn’t have them), but most of 
the classes have them anyway.  I guess maybe the original authors were 
anticipating that the C++ API might become public some day, so they have 
private objects just in case.  But making more of them public is the same as 
locking the API and reducing flexibility.  If there are any API warts, they 
become difficult to fix after that.  (E.g. the restriction that we can neither 
add nor remove virtual functions is downright crippling sometimes.)

I think that there should be a more extensive C++ interface to the scene graph 
itself.  People complain that QtQuick is bloated: you have to create too many 
QObjects and too many bindings; so what’s the difference if you do it in C++ 
instead of QML?  But the scene graph nodes are fundamental and inescapable - 
hopefully not as bloated either.  (Why must they exist?  Because batching is 
fundamental to get good performance in OpenGL: you use a scene graph because 
you don’t want to make thousands of draw calls to draw the UI each time it 
changes.)  If you don’t like Javascript, there isn’t yet a good way to omit the 
whole engine from your build; but I think there should be, and then it might be 
practical to use the scene graph directly.  But that would be a static scene; 
to make it dynamic and interactive you'd have to re-invent some difficult 
things: event delivery, (most types of) animations, layouts, etc.  If you want 
to bind another language to the scene graph though, and use 
different/functional/more-elegant paradigms for the interactive stuff, it’s not 
a bad place for the boundary, right?

Some people think that making more scene graph stuff public is also not worth 
the trouble, and would tie down existing internal APIs too much.  Especially 
when it comes to text rendering.  But in the meantime you can use private APIs 
when public ones are missing.

If you just want to write custom items which populate scene graph nodes, and 
still use QML in general, it’s already not so bad (as long as your custom items 
don’t include text).  If you want to mix OpenGL and QtQuick in layers, no 
problem.  (Qt3D made sure of that.)  

> I would still rather put up with a rich C++ interface that had breaking 
> changes at new releases, than the relative limited C++ interface we have now.

If you are really OK with that, then use private APIs.  Probably better to 
start with 5.8 since there were big changes from 5.7 to 5.8.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Rob Allan]

I'm fairly new to Qt (a few months), but am already very impressed by its
power and overall quality. I'm also super impressed that the user-base is
being asked about what they don't like - so many providers of tools or
services just don't want to hear this stuff! So much kudos to the
developers for even asking this question.

My biggest gripe is that the Qt Quick object model seems to be much more
poorly supported in C++ than it is in QML. For example, in C++ you really
only have access to QQuickItem - none of its derived classes are
documented, and their interfaces are private - so the only way to
manipulate items is using a generic "setProperty" syntax. This is in stark
contrast to QML where all the QML types, methods and properties are
available to you. When you have an app that builds most of its UI
dynamically from C++ code (as ours does), this makes life pretty difficult.
I guess this is one area where widgets would score better than Qt Quick
(but we still prefer Qt Quick for a number of reasons).

I also can't help making a comparison with two other popular layout
frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the markup
language and the "code-behind" class hierarchy of UI elements are
absolutely equivalent 1st class citizens. Anything you can do in XAML, you
can also do in the C# code-behind, whether it be creating controls,
changing their properties, altering layouts, etc. Likewise in Android/AXML,
I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews, etc in
code, and arrange them and manipulate them any way I like, as an
alternative to creating an AXML designer layout.

It seems unfortunate that Qt Quick doesn't take this approach, and that the
"code-behind" experience is so limited. One reason that I've heard why it
might have been done this way is that a rich and fully public C++ interface
may have hamstrung the developers too much, as there would be constant
breaking changes from one release to the next. If that's true then I guess
I understand that, but I would still rather put up with a rich C++
interface that had breaking changes at new releases, than the relative
limited C++ interface we have now.

Rob
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jérôme Godbout]

I could also add the enum exposition to Qml, would be nice to have them
inside their own name and a way to auto map int to string value. we always
have to it manually to convert back and forth for available string/int
value. an object that would wrap the enum and have the following properties:

C++ enum

enum TestEnum
{
  toto = 0,
  titi = 2
};

Qml exposition

TestEnum.toto -> return int
TestEnum.allKeys -> list of int
TestEnum.allNames -> list of string
TestEnum.keyNameMap -> QVariantMap()

That would save us many manual exposition and we could iterate on C++ enum
value easily


On Mon, Sep 19, 2016 at 4:03 PM, Jérôme Godbout  wrote:

> For myself I would love to see those changes (mostly to Qml, the C++ part
> is fairly striaght forward and we mostly no more used QWidgets):
>
>
>1. Ability to extend or declare basic type into Qml (not only
>QObject), QQuaternion QMatrix4x4 functions are too limited and it's painful
>to have a singleton to have those methods, would have been friendlier to
>extend method on those objects. We would love to declare a vector4d plane
>interface and the like.
>2. Fix bugs (we have reported some bugs since 5.0 that are still
>open), we are currently stuck into 5.5 because of a bug that appeared. We
>had to create patch that are still needed for mouse scroll wheel behavior
>since 5.3
>3. QQmlListProperty and the like be more Javascript compatible (length
>property as alias to count), so we can do typical Javascript Array method
>on them. Also, using long item list is a pain when they do a clear and push
>back every element back but 1 when removing an item from it!
>4. Multiple Engine into a single application work as long as you don't
>use any singleton into your qmldir, C++ you can create a singleton per
>engine living into their own thread, since you get the ptr into argument
>when the request arrive, but you have no control for the one into qmldir
>and it seem like a lazy ignored the QQmlEngine* ptr that request it or the
>thread into which it did happen.
>5. qsTr() that can revaluate when the resource language is modified
>and not having to make qsTr("myStr") + I18n.revaluate (singleton that we
>trigger a change on the revaluate value when changing the languages so GUI
>string get updated).
>6. Clean up of base Application (QApplication, QGuiApplication...)
>it's so confusing and still have to check what I need from time to time and
>may end up with the wrong one that will only crash at run time when loading
>the style of either one (when you mix Qml and QWidgets project you have to
>change this after adding a single widget of a different type). We still
>have a QWidget around for Tree View (because let's be thruthful, the Qml
>TreeView s*** big time) and for Dock Window.
>
>
> On a positive note:
>
>- I strongly welcome the new QtQuick Controls style, it was painful
>and hard to skin everything into QtQuick.Controls 1 (I didn't had the
>chance to play too much with it yet, stuck in 5.5 but this is great news)
>- DPI independent and scaling. We start using it, cannot wait to
>upgrade to benefit from it even more, we are .svg all the way already so
>this will be great for high dpi screen.
>
> Great jobs from Qt team, they had a fast release to make sure they were
> present in the past few years with the mobile boom. But now, for one, I
> would welcome a little less features and more rock solid stuff.
>
> P.S: It could be nice to have a centralized source for 3rd party Qt/Qml
> module (maybe that's already exist I haven't check but it seem like we
> often reinvent the wheel for Qml Component).
>
> Good job,
> regards,
> Jerome
>
>
> On Mon, Sep 19, 2016 at 2:59 PM, Konstantin Tokarev 
> wrote:
>
>>
>>
>> 19.09.2016, 21:54, "André Pönitz" :
>> > On Sat, Sep 17, 2016 at 09:20:43PM +0100, Sérgio Martins wrote:
>> >>  Hi,
>> >>
>> >>  It's not unusual for us developers and contributors to lose
>> >>  perspective of what's important.
>> >>  After many years spent on very particular implementation details, it
>> >>  becomes difficult to see outside of the box.
>> >>
>> >>  And because we already know the good aspects I'm asking only about
>> the bad.
>> >>  No need to discuss or reach an agreement, just go ahead and enumerate
>> >>  what you don't like.
>> >>
>> >>  Personally, I don't know (too much time inside the box), but after
>> >>  googling these came up frequently:
>> >>
>> >>  - C++ is difficult, Qt lacks quality bindings for mainstream languages
>> >>  - moc (on build systems that don't automate this step)
>> >>  - FUD around licensing
>> >>
>> >>  Please state your top ones, even if it was already stated by someone
>> >>  else, so we have an idea about which ones matter more.
>> >
>> > On the technical side:
>> >
>> > #1: The very existence of *two* largely incompatible technology stacks.
>> >
>> > #2: Lack of full C++ access to 

Re: [Interest] What don't you like about Qt?

[Alejandro Exojo]

On Monday 19 September 2016 18:35:43 Etienne Sandré-Chardonnal wrote:
> Yes, but for instance you can't move-pass an object between signals and
> slots across a queued connection, unless I'm wrong. You have to make your
> object implicitely shared. This causes lots of copies when passing a
> std::vector, for instance.

The Qt style on designing signals, is to use those for indicating that 
something happened, but not passing the something in the signal. For example, 
you get a signal that new data is available (e.g. a datagram), but you don't 
get the datagram passed as signal argument.

Can you give an example of which signal requires passing a large std::vector 
as argument, and ends up being a problem?

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[André Somers]

Op 19/09/2016 om 22:49 schreef Thiago Macieira:

On segunda-feira, 19 de setembro de 2016 18:35:43 PDT Etienne Sandré-
Chardonnal wrote:

Yes, but for instance you can't move-pass an object between signals and
slots across a queued connection, unless I'm wrong. You have to make your
object implicitely shared. This causes lots of copies when passing a
std::vector, for instance.

Correct. You may have more than one slot connected to the same signal, so move
semantics don't make sense to signal-slot connections: if we moved to the first
destination, then the second would receive a moved-from object.

In theory, one could perhaps make a second connect to a signal with move 
semantics fail, or you could just allow a user to cut himself there, 
just like C++ itself does. At least, I am not aware of any mechanism in 
C++ itself that would protect against doing a move on the same object 
twice. So why should Qt?


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

On segunda-feira, 19 de setembro de 2016 18:35:43 PDT Etienne Sandré-
Chardonnal wrote:
> Yes, but for instance you can't move-pass an object between signals and
> slots across a queued connection, unless I'm wrong. You have to make your
> object implicitely shared. This causes lots of copies when passing a
> std::vector, for instance.

Correct. You may have more than one slot connected to the same signal, so move 
semantics don't make sense to signal-slot connections: if we moved to the first 
destination, then the second would receive a moved-from object.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

2. There are still bugs from 5.2 that need fixing.

3. QmlListProperty has a LOT of requests against it. https://bugreports.qt.io/browse/QTBUG-34015?jql=text%20~%20%22QQmlListProperty%22

PS> Like https://qpm.io?


Sent: Monday, September 19, 2016 at 4:03 PM
From: "Jérôme Godbout" 
To: "interest@qt-project.org" 
Subject: Re: [Interest] What don't you like about Qt?

For myself I would love to see those changes (mostly to Qml, the C++ part is fairly striaght forward and we mostly no more used QWidgets):
 



	Ability to extend or declare basic type into Qml (not only QObject), QQuaternion QMatrix4x4 functions are too limited and it's painful to have a singleton to have those methods, would have been friendlier to extend method on those objects. We would love to declare a vector4d plane interface and the like.
	Fix bugs (we have reported some bugs since 5.0 that are still open), we are currently stuck into 5.5 because of a bug that appeared. We had to create patch that are still needed for mouse scroll wheel behavior since 5.3
	QQmlListProperty and the like be more _javascript_ compatible (length property as alias to count), so we can do typical _javascript_ Array method on them. Also, using long item list is a pain when they do a clear and push back every element back but 1 when removing an item from it!
	Multiple Engine into a single application work as long as you don't use any singleton into your qmldir, C++ you can create a singleton per engine living into their own thread, since you get the ptr into argument when the request arrive, but you have no control for the one into qmldir and it seem like a lazy ignored the QQmlEngine* ptr that request it or the thread into which it did happen.
	qsTr() that can revaluate when the resource language is modified and not having to make qsTr("myStr") + I18n.revaluate (singleton that we trigger a change on the revaluate value when changing the languages so GUI string get updated).
	Clean up of base Application (QApplication, QGuiApplication...) it's so confusing and still have to check what I need from time to time and may end up with the wrong one that will only crash at run time when loading the style of either one (when you mix Qml and QWidgets project you have to change this after adding a single widget of a different type). We still have a QWidget around for Tree View (because let's be thruthful, the Qml TreeView s*** big time) and for Dock Window.



On a positive note:



	I strongly welcome the new QtQuick Controls style, it was painful and hard to skin everything into QtQuick.Controls 1 (I didn't had the chance to play too much with it yet, stuck in 5.5 but this is great news)
	DPI independent and scaling. We start using it, cannot wait to upgrade to benefit from it even more, we are .svg all the way already so this will be great for high dpi screen.

Great jobs from Qt team, they had a fast release to make sure they were present in the past few years with the mobile boom. But now, for one, I would welcome a little less features and more rock solid stuff.

 

P.S: It could be nice to have a centralized source for 3rd party Qt/Qml module (maybe that's already exist I haven't check but it seem like we often reinvent the wheel for Qml Component).

 



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Sean Harmer]

On 19/09/2016 17:35, Etienne Sandré-Chardonnal wrote:

Yes, but for instance you can't move-pass an object between signals and
slots across a queued connection, unless I'm wrong. You have to make
your object implicitely shared. This causes lots of copies when passing
a std::vector, for instance.


And what happens if you have two slots connected and move?

Sean



2016-09-19 18:10 GMT+02:00 Konstantin Tokarev mailto:annu...@yandex.ru>>:



19.09.2016, 19:09, "Thiago Macieira" mailto:thiago.macie...@intel.com>>:
> On segunda-feira, 19 de setembro de 2016 10:40:08 PDT Etienne Sandré-
> Chardonnal wrote:
>> - C++ style is a little bit outdated (no move semantics fir instance)
>
> Move semantics support have been in Qt since 5.0 or so.

4.8



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jérôme Godbout]

For myself I would love to see those changes (mostly to Qml, the C++ part
is fairly striaght forward and we mostly no more used QWidgets):


   1. Ability to extend or declare basic type into Qml (not only QObject),
   QQuaternion QMatrix4x4 functions are too limited and it's painful to have a
   singleton to have those methods, would have been friendlier to extend
   method on those objects. We would love to declare a vector4d plane
   interface and the like.
   2. Fix bugs (we have reported some bugs since 5.0 that are still open),
   we are currently stuck into 5.5 because of a bug that appeared. We had to
   create patch that are still needed for mouse scroll wheel behavior since 5.3
   3. QQmlListProperty and the like be more Javascript compatible (length
   property as alias to count), so we can do typical Javascript Array method
   on them. Also, using long item list is a pain when they do a clear and push
   back every element back but 1 when removing an item from it!
   4. Multiple Engine into a single application work as long as you don't
   use any singleton into your qmldir, C++ you can create a singleton per
   engine living into their own thread, since you get the ptr into argument
   when the request arrive, but you have no control for the one into qmldir
   and it seem like a lazy ignored the QQmlEngine* ptr that request it or the
   thread into which it did happen.
   5. qsTr() that can revaluate when the resource language is modified and
   not having to make qsTr("myStr") + I18n.revaluate (singleton that we
   trigger a change on the revaluate value when changing the languages so GUI
   string get updated).
   6. Clean up of base Application (QApplication, QGuiApplication...) it's
   so confusing and still have to check what I need from time to time and may
   end up with the wrong one that will only crash at run time when loading the
   style of either one (when you mix Qml and QWidgets project you have to
   change this after adding a single widget of a different type). We still
   have a QWidget around for Tree View (because let's be thruthful, the Qml
   TreeView s*** big time) and for Dock Window.


On a positive note:

   - I strongly welcome the new QtQuick Controls style, it was painful and
   hard to skin everything into QtQuick.Controls 1 (I didn't had the chance to
   play too much with it yet, stuck in 5.5 but this is great news)
   - DPI independent and scaling. We start using it, cannot wait to upgrade
   to benefit from it even more, we are .svg all the way already so this will
   be great for high dpi screen.

Great jobs from Qt team, they had a fast release to make sure they were
present in the past few years with the mobile boom. But now, for one, I
would welcome a little less features and more rock solid stuff.

P.S: It could be nice to have a centralized source for 3rd party Qt/Qml
module (maybe that's already exist I haven't check but it seem like we
often reinvent the wheel for Qml Component).

Good job,
regards,
Jerome


On Mon, Sep 19, 2016 at 2:59 PM, Konstantin Tokarev 
wrote:

>
>
> 19.09.2016, 21:54, "André Pönitz" :
> > On Sat, Sep 17, 2016 at 09:20:43PM +0100, Sérgio Martins wrote:
> >>  Hi,
> >>
> >>  It's not unusual for us developers and contributors to lose
> >>  perspective of what's important.
> >>  After many years spent on very particular implementation details, it
> >>  becomes difficult to see outside of the box.
> >>
> >>  And because we already know the good aspects I'm asking only about the
> bad.
> >>  No need to discuss or reach an agreement, just go ahead and enumerate
> >>  what you don't like.
> >>
> >>  Personally, I don't know (too much time inside the box), but after
> >>  googling these came up frequently:
> >>
> >>  - C++ is difficult, Qt lacks quality bindings for mainstream languages
> >>  - moc (on build systems that don't automate this step)
> >>  - FUD around licensing
> >>
> >>  Please state your top ones, even if it was already stated by someone
> >>  else, so we have an idea about which ones matter more.
> >
> > On the technical side:
> >
> > #1: The very existence of *two* largely incompatible technology stacks.
> >
> > #2: Lack of full C++ access to the stack that currently receives most
> > development attention.
> >
> > [repeat]
> >
> > #6: Mandatory(!) use of JavaScript in said stack, embedded(!) in a DSL,
> > thwarting any claims of being "declarative" and any originally hoped-for
> > benefits for tooling.
>
> 6a. Mandatory use of particular implementation of JavaScript in said stack
>
> >
> > [#7: Incompatitible feature development for both stacks, would be a
> > non-issue if #1 didn't exist]
> >
> > Andre'
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
> --
> Regards,
> Konstantin
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-pr

Re: [Interest] What don't you like about Qt?

[Konstantin Tokarev]

19.09.2016, 21:54, "André Pönitz" :
> On Sat, Sep 17, 2016 at 09:20:43PM +0100, Sérgio Martins wrote:
>>  Hi,
>>
>>  It's not unusual for us developers and contributors to lose
>>  perspective of what's important.
>>  After many years spent on very particular implementation details, it
>>  becomes difficult to see outside of the box.
>>
>>  And because we already know the good aspects I'm asking only about the bad.
>>  No need to discuss or reach an agreement, just go ahead and enumerate
>>  what you don't like.
>>
>>  Personally, I don't know (too much time inside the box), but after
>>  googling these came up frequently:
>>
>>  - C++ is difficult, Qt lacks quality bindings for mainstream languages
>>  - moc (on build systems that don't automate this step)
>>  - FUD around licensing
>>
>>  Please state your top ones, even if it was already stated by someone
>>  else, so we have an idea about which ones matter more.
>
> On the technical side:
>
> #1: The very existence of *two* largely incompatible technology stacks.
>
> #2: Lack of full C++ access to the stack that currently receives most
> development attention.
>
> [repeat]
>
> #6: Mandatory(!) use of JavaScript in said stack, embedded(!) in a DSL,
> thwarting any claims of being "declarative" and any originally hoped-for
> benefits for tooling.

6a. Mandatory use of particular implementation of JavaScript in said stack

>
> [#7: Incompatitible feature development for both stacks, would be a
> non-issue if #1 didn't exist]
>
> Andre'
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] What don't you like about Qt?

[André Pönitz]

On Sat, Sep 17, 2016 at 09:20:43PM +0100, Sérgio Martins wrote:
> Hi,
> 
> 
> It's not unusual for us developers and contributors to lose
> perspective of what's important.
> After many years spent on very particular implementation details, it
> becomes difficult to see outside of the box.
> 
> And because we already know the good aspects I'm asking only about the bad.
> No need to discuss or reach an agreement, just go ahead and enumerate
> what you don't like.
> 
> 
> Personally, I don't know (too much time inside the box), but after
> googling these came up frequently:
> 
> - C++ is difficult, Qt lacks quality bindings for mainstream languages
> - moc (on build systems that don't automate this step)
> - FUD around licensing
> 
> Please state your top ones, even if it was already stated by someone
> else, so we have an idea about which ones matter more.

On the technical side:

#1: The very existence of *two* largely incompatible technology stacks.

#2: Lack of full C++ access to the stack that currently receives most
development attention.

[repeat]

#6: Mandatory(!) use of JavaScript in said stack, embedded(!) in a DSL,
thwarting any claims of being "declarative" and any originally hoped-for
benefits for tooling.

[#7: Incompatitible feature development for both stacks, would be a 
non-issue if #1 didn't exist]

Andre'

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Etienne Sandré-Chardonnal]

Yes, but for instance you can't move-pass an object between signals and
slots across a queued connection, unless I'm wrong. You have to make your
object implicitely shared. This causes lots of copies when passing a
std::vector, for instance.

2016-09-19 18:10 GMT+02:00 Konstantin Tokarev :

>
>
> 19.09.2016, 19:09, "Thiago Macieira" :
> > On segunda-feira, 19 de setembro de 2016 10:40:08 PDT Etienne Sandré-
> > Chardonnal wrote:
> >> - C++ style is a little bit outdated (no move semantics fir
> instance)
> >
> > Move semantics support have been in Qt since 5.0 or so.
>
> 4.8
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Konstantin Tokarev]

19.09.2016, 19:09, "Thiago Macieira" :
> On segunda-feira, 19 de setembro de 2016 10:40:08 PDT Etienne Sandré-
> Chardonnal wrote:
>> - C++ style is a little bit outdated (no move semantics fir instance)
>
> Move semantics support have been in Qt since 5.0 or so.

4.8

http://doc.qt.io/qt-4.8/qt4-8-intro.html

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] What don't you like about Qt?

[Thiago Macieira]

On segunda-feira, 19 de setembro de 2016 10:40:08 PDT Etienne Sandré-
Chardonnal wrote:
>- C++ style is a little bit outdated (no move semantics fir instance)

Move semantics support have been in Qt since 5.0 or so.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Jason H]

1. Qt progresses at a glacial pace, and often neglects the more urgent/parity 
issues.
- a. As more organizations adopt agile, this becomes all that more apparent. 
I've got to wait for a year for a code change to hit a release? Sorry, that's 
just too long.
- b. Basic stuff like controlling the LED flash on mobile will land for C++ but 
won't be in QML for another year. 
- c. There is no backlog grooming. Stuff like the blurry canvas bug goes on for 
_YEARS_ (we're still waiting)

2. Qt Development don't seem in-tune with what Qt users need/want.
- a. Development is often focused on new, sexy features, when they haven't 
finished the previous release (platform parity, QML/C++ parity)
- b. The mobile stack is no longer being developed (maintained yes, developed, 
no). There is no support for Wake-locks, push notifications, and other missing 
platform integrations. So the community is left to repeatedly re-develop these 
essential mobile functions.

3. Qt has too many versions/code-lines
- a. 5.6 (LTS), 5.7, 5.8, and now 5.9 are all actively being maintained. 
- b. The rampant versioning pace has to be creating waste, taking devs away 
from development and instead spending it on maintenance. 

That being said, Qt is still really great and really does deliver on "Code 
less, create more". I compare my solutions to my friends' who have a lot of 
cruft code to satisfy their platform. Qt/QML is the most concise code out 
there. Look at React+JSX. It's basically QML but with <> ( 
text). So QML I think is the golden 
standard for declarative languages. Kudos to it's inventors!

What Qt can do better:
1. Switch to Agile, deliver monthly releases
2. Reduce versions being maintained. (You're stuck with 5.6 LTS, but that plus 
a monthly 5.X release, whatever is current).
- a. Version the Qt modules independently with the X.Y being a snapshot of 
modules at release.*
3. Work harder on feature parity before release. 

* I realize as a toolkit, Qt historically requires binary compatibility between 
X.Y versions, and that any app depending on X.Y.z should be able to run on any 
X.Y, but I think that it is time for that to end. I've seen enough regressions 
to know that a .Z release can introduce application-breaking change. Also, from 
a security standpoint, I don't want an attacker being able to run against a 
previous release with a known vulnerability. Being able to say .Z= (.Z exactly) 
.Z+ " .X or later" is really the only realistic constraint. The idea that you 
can run against a previous version than you were built with just invites 
trouble. Furthermore, these constraints should be up to the app developer.




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Duane]

On 19/09/2016 9:11 AM, Konstantin Tokarev wrote:



19.09.2016, 16:08, "Henry Skoglund" :

Ok here's my number #1 complaint:

the MaintenanceTool app, when you start it, why is the default selected
choice to remove Qt??? It should be to update Qt of course.

(Such a design could get you fired if you worked for say, Microsoft. :=)


I'd rather removed this option from default MaintenanceTool GUI, and added 
separate uninstaller executable (which would in fact run MaintenanceTool with 
respective command line argument)



I think just making it NOT the default would be ok.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Konstantin Tokarev]

19.09.2016, 16:08, "Henry Skoglund" :
> Ok here's my number #1 complaint:
>
> the MaintenanceTool app, when you start it, why is the default selected
> choice to remove Qt??? It should be to update Qt of course.
>
> (Such a design could get you fired if you worked for say, Microsoft. :=)

I'd rather removed this option from default MaintenanceTool GUI, and added 
separate uninstaller executable (which would in fact run MaintenanceTool with 
respective command line argument)

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

Re: [Interest] What don't you like about Qt?

[Henry Skoglund]

Ok here's my number #1 complaint:

the MaintenanceTool app, when you start it, why is the default selected 
choice to remove Qt??? It should be to update Qt of course.


(Such a design could get you fired if you worked for say, Microsoft. :=)

Rgrds Henry


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Kyle Altendorf]

On 2016-09-19 05:20, Bo Thorsen wrote:

* Designer plugin development/deployment sucks (should be in a
scripting language or json, and should be possible to do per project)


I don't know if you count Python as a scripting language or not, but 
just in case, you can do this with PyQt.


http://pyqt.sourceforge.net/Docs/PyQt5/designer.html#writing-qt-designer-plugins

And my code that uses it.

https://github.com/altendky/st/tree/6a52806ca72d5f8c9392ea3ab74b1f91cefa46b5/epyq/widgets

Cheers,
-kyle
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Uwe Rathmann]

On Sat, 17 Sep 2016 21:20:43 +0100, Sérgio Martins wrote:

> Please state your top ones, even if it was already stated by someone
> else, so we have an idea about which ones matter more.

a) C++ ( far beyond everything else )

The 2 language approach is a pain. In our application we have thousands 
of totally pointless lines of code only for bridging between C++ libs and 
QML. Having a compact syntax - for code, that would be trivial in C++ as 
well - IMO simply doesn't justify this extra work.

Beside that QML has bad instantiation times for large projects and its 
concept of item composition makes applications heavy. More than 30 
QObjects for a button ( Quick Control 1 ) says it all.

My experience with working on C++ controls with an optional QML API shows 
how surprisingly easy it would have been to have both APIs. Too sad, that 
with Qt Quick Control 2 this chance has been missed.

b) Vector graphics

Qt has no strategy for handling vector graphics - neither Widgets nor Qt 
Quick. Not having full featured layout classes ( dynamic constraints etc 
) are another problem, when trying to implement user interfaces, that 
need to work on different devices.

c) Compatibility policies

The compatibility policy of Qt makes it impossible to fix design problems 
of X.0 versions. This leads to adding balconies instead of getting the 
foundations stable.

F.e. have a look at the font/locale propagation. It obviously has been 
identified as being forgotten and has been added to QQuickControl ( Quick 
controls 2 ) - instead of QQuickItem.

In consequence Qt Quick Control 2 does not play together with controls of 
other libs ( and v.v ).

e) X11 paint engine

Being the maintainer of the Qwt project I'm missing a hardware 
accelerated paint engine, that just works.

-- 

In general I would like to see Qt being more focused on what it is good 
at - for me this is cross platform desktop development ( Qt/Widgets ) and 
Qt Embedded projects - not Android/iOS.

A a long term goal I would also like to see desktop and embedded 
technologies being reunited. Even if user interfaces on desktop and for 
embedded are ( and probably will stay ) different I don't see why writing 
them needs to be totally different.

My 2 cents,
Uwe 

 

 

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Sze Howe Koh]

On 19 September 2016 at 17:20, Michael Sué  wrote:
> Hi,
>
> - nothing new for widgets.
> - not yet full support for VS 2015, missing "Addin" that is, for more than a
> year now.
> - missing C++ support for mobile platforms.
> - unusable Docs for Qt3D.
>
> Best, Michael.

Hi Michael,

Regarding VS 2015, keep an eye on the Qt VS Tools:
https://blog.qt.io/blog/2016/08/11/from-visual-studio-add-in-to-qt-vs-tools-beta/
Add-Ins can no longer be used because Microsoft removed support for
them.


Regards,
Sze-Howe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Sze Howe Koh]

On 19 September 2016 at 01:14, Nate Rogers via Interest
 wrote:
>
> I'm a Linux user but a guy at work was trying out Qt on windows for a project 
> he was working on. He tried the new installer and it didn't come 
> preconfigured with a compiler like it used to. I didn't have time to trouble 
> shoot it so I just had him download 5.5 because that one works without any 
> messing around. Sorry I don't have more info
>
> Nate

Hi Nate,

For future reference: If you want an included compiler on Windows, be
sure to download the _MinGW_ based Qt. Regarding the availability of
"preconfigured"/bundled compilers, Qt 5.7 is actually the same as Qt
5.5.

Microsoft does not allow their compiler to be distributed by 3rd
parties, thus the Visual Studio (MSVC) based Qt cannot come bundled
with a compiler.


Regards,
Sze-Howe


> On Sun, Sep 18, 2016 at 1:05 PM, Freddy Martinez Garcia
>  wrote:
> Hi Nate, I’m a macOS user and I hate Windows, but right now I’m involve in a 
> big project developed with QML, Qt Widgets and C++ (because we have various 
> apps for desktop and mobile).
>
> In Windows I only had problem with the compiler from Visual Studio, which has 
> a lot of problem with the compatibilities with C++11/14 and we must use it 
> because MinGW (how in my opinion is much more better) has not support for Qt 
> Web Engine.
>
> What is your problem wit Qt 5.7 in Windows ? Just to know if I have the same 
> problem  my friend?
>
> regards
>
>
> =
> "El tamaño de tus logros depende del tamaño de tus metas."
> B.S. Computer Science
> Buenos Aires, Argentina
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Michael Sué]

Hi,

- nothing new for widgets.
- not yet full support for VS 2015, missing "Addin" that is, for more than a
year now.
- missing C++ support for mobile platforms.
- unusable Docs for Qt3D.

Best, Michael.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Bo Thorsen]

Okay, I'll bite:

* Poor standard of some modules - Qt Multimedia and Qt Components especially
* Too much focus on features instead of fixing bugs
* Designer plugin development/deployment sucks (should be in a scripting 
language or json, and should be possible to do per project)

* Current gerrit workflow make Qt contributions a pain to get started with
* Javascript chosen as the scripting language for Qt (see this for 
giggles: https://www.destroyallsoftware.com/talks/wat)

* Commercial pricing is impossible to figure out for my customers
* Not using exceptions (I know, won't happen, and most appreciate this)

Compared to the awesome quality and completeness of Qt, those are minor 
points. I've been a happy Qt coder for almost 20 years now and hope for 
20 more :)


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Marco Piccolino]

1) I don't like the distribution being so monolithic.

I'd rather see the packages being shipped individually and having explicit
version dependencies, like QML modules do and like qpm.io is doing.
Maybe this kind of approach will be easier/possible with the new config
system?

2) I don't like qml being considered only as a UI language or confounded
with QtQuick, which sometimes happens even in the docs and a few namings.

I do mostly mobile and I can't say I have tried all languages and
frameworks out there, but the combined declarative/imperative approach of
qml+js is a damn great one even for crafting different kinds of non-ui
components. I wonder if anyone else had the same positive experience.

Of course treating it not just as a UI language would mean improving it in
some respects (APIs, threading beyond workers etc). Not saying it can be
used everywhere as it is implemented now, but it's a very concise way of
expressing concepts and makes lots of sense to me.

I'd like to see qml+js rightfully marketed and developed as a
general-purpose language for crafting whole application architectures,
always with the option to kick-in c++ modules when needed.

3) I don't like the lack of extensive examples and documentation about good
full-blown application architectures implemented with Qt.

Granted, architecture is something that transcends the framework and varies
a lot, but seeing a few complex examples of architecture best practices
thoroughly documented and explained would possibly avoid many pitfalls
while designing a Qt app.

I can of course go out there and grab an opensource project like Telegram
and dissection it, but a) I am not sure Qt is used there as it was inteded
b) it requires so much more work from my part.

4) Accessing mobile-specific functionality (contacts, notifications, file
browsing, opening documents, inter-app operability etc.)  is still in most
cases platform-specific, and while AndroidExtras and JNI ways are by now
fairly well documented (thanks BogDan and Eskil!), iOS is a whole different
story and mostly requires you to find out stuff by yourself or asking the
few experts that exist. Plus implementing those parts by yourself limits a
lot the value of using a native cross-platform framework, beyond UI and
algorithms.

An extensive, up-to-date, maintained abstraction layer over such
functionality for Android, iOS and WinRT (and desktop OSes, since those are
also increasingly incorporating traditionally-mobile functionality) is
simply not there yet.

Over at http://slackin.qtmob.org there are some people who have implemented
their own stuff quick&dirty, but being everybody a full-time app developer,
it seems that unfortunately nobody has the time to start new Qt modules, to
comply fully with contribution guidelines, and to contribute massively to
something that for the most part requires fiddling with QPA, native APIs,
and continuous maintenance.

This said, I really love Qt and I wish it lives and prospers for years to
come!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Simon Schäfer]

Hi,

I have a some missing things for nearly all topics Qt covers:

1. moc is lacking some sort of plugin mechanism. If there where, developers 
could extend the autocreation of QObjects, with their own ideas.

2. The build system, qmake. It feels very unusable and you have to use a lot 
of hidden secrets if you need more then the common building. Like when you 
have your own source code generation toolset or a more complex dependency 
trees.

3. The documentation of QBS is missing the red line within its documentation 
similar to the one for Qt itself, if i click on a classname in the QtDocs the 
Breadcrumbs change to somthing like: "Qt 5.7 > Qt Core > C++ Classes > 
QAbstractAnimation" that way I can jump back to what i was coming from or at 
least a list where I see other possibilities. in Qbs its always: "Qbs Manual > 
Rule Item" What i would expect something like "Qbs Manual > Qbs Items > Rule 
Item"
3.1 Personaly I think Qbs is going the right way, not being another Makefile 
generator.

4. The mobile APIs are not extended to keep up with current stuff provided by 
iOS and Android, like fingerprint sensors.
4.1 supporting libraries for reading barcodes might be handy as well

5. No way on deploying to web, "code once deploy everywhere" was once the 
slogan, well everywhere except the web. 

6. Regarding all the IoT talk what i miss the most is some sort of RPC 
Framework, either with direct communication and/or through some sort of broker 
technology.
6.1 Writing this by ourself would be easier if the moc had a plugin mechanism, 
so at least the header parsing part would have been already done.

Cheers
Simon
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Etienne Sandré-Chardonnal]

Qt Commercial user here.

I do not like:

   - Long time to get bugs fixed
   - QtQuick requires switching to QML and is not usable directly in C++
   - Widgets development got less attention due to QtQuick development.
   HiDPI support was a good idea but it introduced many bugs
   - C++ style is a little bit outdated (no move semantics fir instance)
   - No OS display color profile information support

Cheers,


Etienne

2016-09-19 8:08 GMT+02:00 Shawn Rutledge :

>
> > On 18 Sep 2016, at 02:37, Xavier Bigand 
> wrote:
> >
> > I am using Qt for my day job,
> >
> > Our first difficulty with Qt is the release cycle that is really long
> and the difficulty to test the futur versions.
> > As we often need the latest features or bug fixes, waiting 3-4 month
> isn't possible, and some times we just implement our self features or use
> workaround for bugs.
> > Alpha and Beta versions aren't accessible on the Qt maintenance tool
> that we use, and compiling Qt from the source is to much work for every
> platforms we use,...
> >
> > We'll certainly don't use an Alpha or Beta version of Qt for production,
> but it is interesting to be able to report bug on upcoming version as soon
> as possible (especially for new features as Qt3D,...).
>
> Then you should use git.  Yes it’s bleeding edge, but CI helps to make it
> more stable than it otherwise would be.
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Shawn Rutledge]

> On 18 Sep 2016, at 02:37, Xavier Bigand  wrote:
> 
> I am using Qt for my day job,
> 
> Our first difficulty with Qt is the release cycle that is really long and the 
> difficulty to test the futur versions.
> As we often need the latest features or bug fixes, waiting 3-4 month isn't 
> possible, and some times we just implement our self features or use 
> workaround for bugs.
> Alpha and Beta versions aren't accessible on the Qt maintenance tool that we 
> use, and compiling Qt from the source is to much work for every platforms we 
> use,...
> 
> We'll certainly don't use an Alpha or Beta version of Qt for production, but 
> it is interesting to be able to report bug on upcoming version as soon as 
> possible (especially for new features as Qt3D,...).

Then you should use git.  Yes it’s bleeding edge, but CI helps to make it more 
stable than it otherwise would be.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Freddy Martinez Garcia]

Qt 5.7 has a lot of improves and I think that you should use this version…

I have no problem installing Qt on Windows… I install VS Community Edition
with the compilers for C++ and then, I use the online installer for Windows
given by Qt website… Also, you need to know that you should install Windows
SDK (I guess that this is the name… I don’t remember well because I’m not
Windows guru), because if you want to debug your code, here is the
debugger… But no issues in the installation process. At least, that’s what
I do to use Qt on Windows...


=



*"El tamaño de tus logros depende del tamaño de tus metas." C++ and Qt
Senior DeveloperB.S. Computer ScienceBuenos Aires, Argentina*

On September 18, 2016 at 2:14:37 PM, Nate Rogers via Interest (
interest@qt-project.org) wrote:

I'm a Linux user but a guy at work was trying out Qt on windows for a
project he was working on. He tried the new installer and it didn't come
preconfigured with a compiler like it used to. I didn't have time to
trouble shoot it so I just had him download 5.5 because that one works
without any messing around. Sorry I don't have more info

Nate

Sent from Yahoo Mail on Android


On Sun, Sep 18, 2016 at 1:05 PM, Freddy Martinez Garcia
 wrote:
Hi Nate, I’m a macOS user and I hate Windows, but right now I’m involve in
a big project developed with QML, Qt Widgets and C++ (because we have
various apps for desktop and mobile).

In Windows I only had problem with the compiler from Visual Studio, which
has a lot of problem with the compatibilities with C++11/14 and we must use
it because MinGW (how in my opinion is much more better) has not support
for Qt Web Engine.

What is your problem wit Qt 5.7 in Windows ? Just to know if I have the
same problem  my friend?

regards


=


*"El tamaño de tus logros depende del tamaño de tus metas."  B.S. Computer
Science Buenos Aires, Argentina*

On September 18, 2016 at 1:48:54 PM, Ben Lau (xben...@gmail.com
) wrote:

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Nate Rogers via Interest]

I'm a Linux user but a guy at work was trying out Qt on windows for a project 
he was working on. He tried the new installer and it didn't come preconfigured 
with a compiler like it used to. I didn't have time to trouble shoot it so I 
just had him download 5.5 because that one works without any messing around. 
Sorry I don't have more info
Nate

Sent from Yahoo Mail on Android 
 
  On Sun, Sep 18, 2016 at 1:05 PM, Freddy Martinez 
Garcia wrote:   Hi Nate, I’m a macOS user and I hate 
Windows, but right now I’m involve in a big project developed with QML, Qt 
Widgets and C++ (because we have various apps for desktop and mobile).
In Windows I only had problem with the compiler from Visual Studio, which has a 
lot of problem with the compatibilities with C++11/14 and we must use it 
because MinGW (how in my opinion is much more better) has not support for Qt 
Web Engine.
What is your problem wit Qt 5.7 in Windows ? Just to know if I have the same 
problem  my friend?
regards 
 
=
"El tamaño de tus logros depende del tamaño de tus metas." 
B.S. Computer Science
Buenos Aires, Argentina 

On September 18, 2016 at 1:48:54 PM, Ben Lau (xben...@gmail.com) wrote:
 

  
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Freddy Martinez Garcia]

Hi Nate, I’m a macOS user and I hate Windows, but right now I’m involve in
a big project developed with QML, Qt Widgets and C++ (because we have
various apps for desktop and mobile).

In Windows I only had problem with the compiler from Visual Studio, which
has a lot of problem with the compatibilities with C++11/14 and we must use
it because MinGW (how in my opinion is much more better) has not support
for Qt Web Engine.

What is your problem wit Qt 5.7 in Windows ? Just to know if I have the
same problem  my friend?

regards


=


*"El tamaño de tus logros depende del tamaño de tus metas." B.S. Computer
ScienceBuenos Aires, Argentina*

On September 18, 2016 at 1:48:54 PM, Ben Lau (xben...@gmail.com) wrote:



On 18 September 2016 at 21:56, Bob Hood  wrote:

> On 9/18/2016 2:43 AM, Jean-Michaël Celerier wrote:
>
>> Some things that bother me :
>>
>> * Features being QML-only instead of being usable from C++. I like coding
>> in C++ (but I agree it's hard).
>>
>
> This is certainly arguable.  For some, I guess coding in C++ is hard.  For
> others, it's as natural as breathing.
>
> In fact, it leads to my particular issue: QML.  I waited a long time for
> Qt to reach a point where it was usable for mobile development, and I
> personally was disappointed with the declarative approach taken with QML.
> Aside from being somewhat out of character for the framework, it seems to
> have been a divisive approach, creating a separation not only between
> interface and code, but between languages!  Jean-Michaël's point
> abovehighlights that.
>
> I want to code mobile in a language I use on a daily basis for things
> other than just mobile.  I realize it is a great fit for some people, but
> unfortunately for me, QML isn't.  I've therefore had to turn my attention
> to Xamarin (especially now that it is integrated into Visual Studio).  I've
> never been much of a fan of C#, but it is certainly closer to C++ than QML.
>
> (No QML flame wars, please.  I'm just expressing my personal situation,
> not saying that QML isn't useful for some people.)
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>


Personally I don't mind to code in two languages. I would treat QML as an
interface builder language. (e.g the old .ui file or those xml files in
Android) But the hard problem is on the data sharing model between C++ and
QML/JS. QAbstractItemModel is an overkill solution. Many people may instead
chose QObjectListModel for sharing data. But I have too many bad experience
with it. It is too easy to crash and difficult to trace the problem.











___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Nate Rogers via Interest]

I like C++ & QML. I don't like that the new version of Qt for windows is so 
hard to get working! Qt 5.5 worked right out of the box, no need to monkey 
around with compilers and everything else. I really don't like that
Nate

Sent from Yahoo Mail on Android 
 
  On Sun, Sep 18, 2016 at 12:48 PM, Ben Lau wrote:   

On 18 September 2016 at 21:56, Bob Hood  wrote:

On 9/18/2016 2:43 AM, Jean-Michaël Celerier wrote:

Some things that bother me :

* Features being QML-only instead of being usable from C++. I like coding in 
C++ (but I agree it's hard).


This is certainly arguable.  For some, I guess coding in C++ is hard.  For 
others, it's as natural as breathing.

In fact, it leads to my particular issue: QML.  I waited a long time for Qt to 
reach a point where it was usable for mobile development, and I personally was 
disappointed with the declarative approach taken with QML.  Aside from being 
somewhat out of character for the framework, it seems to have been a divisive 
approach, creating a separation not only between interface and code, but 
between languages!  Jean-Michaël's point abovehighlights that.

I want to code mobile in a language I use on a daily basis for things other 
than just mobile.  I realize it is a great fit for some people, but 
unfortunately for me, QML isn't.  I've therefore had to turn my attention to 
Xamarin (especially now that it is integrated into Visual Studio).  I've never 
been much of a fan of C#, but it is certainly closer to C++ than QML.

(No QML flame wars, please.  I'm just expressing my personal situation, not 
saying that QML isn't useful for some people.)
__ _
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/ma ilman/listinfo/interest



Personally I don't mind to code in two languages. I would treat QML as an 
interface builder language. (e.g the old .ui file or those xml files in 
Android) But the hard problem is on the data sharing model between C++ and 
QML/JS. QAbstractItemModel is an overkill solution. Many people may instead 
chose QObjectListModel for sharing data. But I have too many bad experience 
with it. It is too easy to crash and difficult to trace the problem. 




 




  
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Ben Lau]

On 18 September 2016 at 21:56, Bob Hood  wrote:

> On 9/18/2016 2:43 AM, Jean-Michaël Celerier wrote:
>
>> Some things that bother me :
>>
>> * Features being QML-only instead of being usable from C++. I like coding
>> in C++ (but I agree it's hard).
>>
>
> This is certainly arguable.  For some, I guess coding in C++ is hard.  For
> others, it's as natural as breathing.
>
> In fact, it leads to my particular issue: QML.  I waited a long time for
> Qt to reach a point where it was usable for mobile development, and I
> personally was disappointed with the declarative approach taken with QML.
> Aside from being somewhat out of character for the framework, it seems to
> have been a divisive approach, creating a separation not only between
> interface and code, but between languages!  Jean-Michaël's point
> abovehighlights that.
>
> I want to code mobile in a language I use on a daily basis for things
> other than just mobile.  I realize it is a great fit for some people, but
> unfortunately for me, QML isn't.  I've therefore had to turn my attention
> to Xamarin (especially now that it is integrated into Visual Studio).  I've
> never been much of a fan of C#, but it is certainly closer to C++ than QML.
>
> (No QML flame wars, please.  I'm just expressing my personal situation,
> not saying that QML isn't useful for some people.)
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>


Personally I don't mind to code in two languages. I would treat QML as an
interface builder language. (e.g the old .ui file or those xml files in
Android) But the hard problem is on the data sharing model between C++ and
QML/JS. QAbstractItemModel is an overkill solution. Many people may instead
chose QObjectListModel for sharing data. But I have too many bad experience
with it. It is too easy to crash and difficult to trace the problem.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Xavier Bigand]

It would be more confortable to have more artifacts for 2 reasons :
 1. As we constantly update our product based on Qt (our release cycle is
between 3 and 6 months), reducing the delay to migrate to the latest
version of Qt (to improve the stability, performances, compatibility,...)
when come close to our release window can be great advantage for our final
users. A lot of previous versions of Qt breaks our application
initialization (essentially because of our homebrew 3D engine), or we got
small regressions on High DPI management. I think that having beta could be
also a chance for you to have better release if you got feedback sooner.

 2. Some times we are interested by new features that should help us for a
mid-long term view, as Qt3D, webview,... For Qt3D for example I start the
migration from our 3D engine to it, I have reported few bugs on Qt 5.7 that
are blockers to continue this work, but there are already fixed on Qt 5.8
branch, sadly as it's a long term development it is hard for me to take
time build a custom version of Qt.


In the past I already build custom versions of Qt (5.0), but I got a issues
:
 - Hard to configure correctly (especially with OpenGL)
 - Not enough RAM on my computer
 - Really long to compile (> 30 min per build), a big issue when you
develop on the same computer because you can't do anything during this
time. I had to build for Android, mingw and VS.
 - I got issues with Qt creator and kits to stay compatible with Qt
Maintenance Tool
 - How to share with my coworkers? creating a new repo server for Qt
Maintenance Tool?


One of the main C++ problem is the building aspect, because of
compatibility issues (between compilers, platforms,...) building process
are to much complex. After you have to add the configuration of the build
that for the case is something natural.
Automate the build of softwares is something really hard to do.


PS: I really love Qt, it is something amazing and really good for the C++.
And I could not consider developing in C++ without it.



Else I just miss property bindings in C++ lol.



2016-09-18 15:17 GMT+02:00 André Pönitz :

> On Sun, Sep 18, 2016 at 02:37:01AM +0200, Xavier Bigand wrote:
> > I am using Qt for my day job,
> >
> > Our first difficulty with Qt is the release cycle that is really long
> and the
> > difficulty to test the futur versions.  As we often need the latest
> features or
> > bug fixes, waiting 3-4 month isn't possible, and some times we just
> implement
> > our self features or use workaround for bugs.  Alpha and Beta versions
> aren't
> > accessible on the Qt maintenance tool that we use, and compiling Qt from
> the
> > source is to much work for every platforms we use,...
>
> I cannot follow this line of reasoning.
>
> Binary downloads only help in setups without custom patches or without
> enough
> expertise to run a git clone / configure / make. But you do have custom
> patches
> and you do know how to build Qt.
>
> Asking for more artifacts to be produced e.g. for Alpha releases increases
> the pressure on the already difficult release process, i.e. has a high
> chance
> of delaying final releases even more.
>
> On the other hand you consider waiting periods of 3-4 months for a Qt
> release
> already as problematic for your way of working. How does that fit?
>
> Andre'
>



-- 
Xavier
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Bob Hood]

On 9/18/2016 2:43 AM, Jean-Michaël Celerier wrote:

Some things that bother me :

* Features being QML-only instead of being usable from C++. I like coding in 
C++ (but I agree it's hard).


This is certainly arguable.  For some, I guess coding in C++ is hard.  For 
others, it's as natural as breathing.


In fact, it leads to my particular issue: QML.  I waited a long time for Qt to 
reach a point where it was usable for mobile development, and I personally was 
disappointed with the declarative approach taken with QML.  Aside from being 
somewhat out of character for the framework, it seems to have been a divisive 
approach, creating a separation not only between interface and code, but 
between languages!  Jean-Michaël's point abovehighlights that.


I want to code mobile in a language I use on a daily basis for things other 
than just mobile.  I realize it is a great fit for some people, but 
unfortunately for me, QML isn't.  I've therefore had to turn my attention to 
Xamarin (especially now that it is integrated into Visual Studio).  I've never 
been much of a fan of C#, but it is certainly closer to C++ than QML.


(No QML flame wars, please.  I'm just expressing my personal situation, not 
saying that QML isn't useful for some people.)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[André Pönitz]

On Sun, Sep 18, 2016 at 02:37:01AM +0200, Xavier Bigand wrote:
> I am using Qt for my day job,
> 
> Our first difficulty with Qt is the release cycle that is really long and the
> difficulty to test the futur versions.  As we often need the latest features 
> or
> bug fixes, waiting 3-4 month isn't possible, and some times we just implement
> our self features or use workaround for bugs.  Alpha and Beta versions aren't
> accessible on the Qt maintenance tool that we use, and compiling Qt from the
> source is to much work for every platforms we use,...

I cannot follow this line of reasoning.

Binary downloads only help in setups without custom patches or without enough
expertise to run a git clone / configure / make. But you do have custom patches
and you do know how to build Qt.

Asking for more artifacts to be produced e.g. for Alpha releases increases
the pressure on the already difficult release process, i.e. has a high chance
of delaying final releases even more.

On the other hand you consider waiting periods of 3-4 months for a Qt release
already as problematic for your way of working. How does that fit?

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

Re: [Interest] What don't you like about Qt?

[Jean-Michaël Celerier]

Some things that bother me :

* The (perceived) lack of stability with QtQuick / QML : first there was
QtQuick with 4.8, then QtQuick 2.0, maybe QtQuick 3.0 with Qt 6 ? Then
Controls 1.0, then Controls 2.0 ... everytime with a somewhat short
life-span, which makes it a pain when looking for documentation or help,
e.g. on stackoverflow.
* Features being QML-only instead of being usable from C++. I like coding
in C++ (but I agree it's hard).
* Some features not really cross-platform (e.g. in QtMultimedia,
QAudioDecoder does not work everywhere, same for the 3D audio classes when
there is no OpenAL).
* The goddamn 4.8 documentation still popping up prior to any other in
google search.
* It's goddamn impossible to do any meaningful work with the QML designer,
every time in the change logs they state that it's becoming better, I drag
two random widgets and the thing crashes.
* I agree for the FUD against licenses. But overall there is a lot of FUD
against the LGPL, not only Qt (e.g. "you can't statically link against LGPL
libs", yes you can). However, while I understand the need for the Qt
company to make licensing revenue, I don't think that alienating developers
(hiding the "OpenSource" part more and more in the website since the
qt-project merger) is the right way to do it.
* I don't care a lot about moc, as Olivier Goffart has shown with Verdigris
it's either ugly macros or moc. And in CMake it's trivial to use anyway.
However, I think that the Qt guys should *really* try to lobby the C++
standard body's reflection working group so that when (if :'( ) there is
reflection in C++ 2α, Qt's meta object model can be implemented in terms of
it easily. This would make for something *very* powerful.
* QString being UTF-16 :'(

Some things that don't bother me at all but seems to bother a lot of people
on forums :
* They expect Qt to be only a GUI toolkit, not a full-blown application
framework.

But overall Qt rocks :p
Best regards,


---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, Sep 17, 2016 at 10:20 PM, Sérgio Martins 
wrote:

> Hi,
>
>
> It's not unusual for us developers and contributors to lose
> perspective of what's important.
> After many years spent on very particular implementation details, it
> becomes difficult to see outside of the box.
>
> And because we already know the good aspects I'm asking only about the bad.
> No need to discuss or reach an agreement, just go ahead and enumerate
> what you don't like.
>
>
> Personally, I don't know (too much time inside the box), but after
> googling these came up frequently:
>
>
> - C++ is difficult, Qt lacks quality bindings for mainstream languages
> - moc (on build systems that don't automate this step)
> - FUD around licensing
>
>
>
> Please state your top ones, even if it was already stated by someone
> else, so we have an idea about which ones matter more.
>
>
> Regards,
> Sérgio Martins
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Xavier Bigand]

I am using Qt for my day job,

Our first difficulty with Qt is the release cycle that is really long and
the difficulty to test the futur versions.
As we often need the latest features or bug fixes, waiting 3-4 month isn't
possible, and some times we just implement our self features or use
workaround for bugs.
Alpha and Beta versions aren't accessible on the Qt maintenance tool that
we use, and compiling Qt from the source is to much work for every
platforms we use,...

We'll certainly don't use an Alpha or Beta version of Qt for production,
but it is interesting to be able to report bug on upcoming version as soon
as possible (especially for new features as Qt3D,...).

A great Thanks for all developers of Qt 😉

2016-09-18 0:48 GMT+02:00 Artem Sidyakin :

> > From what I see, IPTV industry is massively switching away from Qt
> because LGPL3 is incompatible with clients’ requirements
>
> I’m just from IBC (http://www.ibc.org) and I didn’t see much “switching
> away from Qt” there. What I saw was switching from LGPL v2.1 to commercial
> license.
>
> ---
> Artem Sidyakin
>
> > On 17 сент. 2016 г., at 22:59, Konstantin Tokarev 
> wrote:
> >
> >
> >
> > 17.09.2016, 23:21, "Sérgio Martins" :
> >> Hi,
> >>
> >> It's not unusual for us developers and contributors to lose
> >> perspective of what's important.
> >> After many years spent on very particular implementation details, it
> >> becomes difficult to see outside of the box.
> >>
> >> And because we already know the good aspects I'm asking only about the
> bad.
> >> No need to discuss or reach an agreement, just go ahead and enumerate
> >> what you don't like.
> >>
> >> Personally, I don't know (too much time inside the box), but after
> >> googling these came up frequently:
> >>
> >> - C++ is difficult, Qt lacks quality bindings for mainstream languages
> >> - moc (on build systems that don't automate this step)
> >> - FUD around licensing
> >
> > FUD you say? From what I see, IPTV industry is massively switching away
> from Qt because LGPL3 is incompatible with clients' requirements.
> >
> >>
> >> Please state your top ones, even if it was already stated by someone
> >> else, so we have an idea about which ones matter more.
> >>
> >> Regards,
> >> Sérgio Martins
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
> >
> > --
> > Regards,
> > Konstantin
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



-- 
Xavier
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[Artem Sidyakin]

> From what I see, IPTV industry is massively switching away from Qt because 
> LGPL3 is incompatible with clients’ requirements

I’m just from IBC (http://www.ibc.org) and I didn’t see much “switching away 
from Qt” there. What I saw was switching from LGPL v2.1 to commercial license.

---
Artem Sidyakin

> On 17 сент. 2016 г., at 22:59, Konstantin Tokarev  wrote:
> 
> 
> 
> 17.09.2016, 23:21, "Sérgio Martins" :
>> Hi,
>> 
>> It's not unusual for us developers and contributors to lose
>> perspective of what's important.
>> After many years spent on very particular implementation details, it
>> becomes difficult to see outside of the box.
>> 
>> And because we already know the good aspects I'm asking only about the bad.
>> No need to discuss or reach an agreement, just go ahead and enumerate
>> what you don't like.
>> 
>> Personally, I don't know (too much time inside the box), but after
>> googling these came up frequently:
>> 
>> - C++ is difficult, Qt lacks quality bindings for mainstream languages
>> - moc (on build systems that don't automate this step)
>> - FUD around licensing
> 
> FUD you say? From what I see, IPTV industry is massively switching away from 
> Qt because LGPL3 is incompatible with clients' requirements.
> 
>> 
>> Please state your top ones, even if it was already stated by someone
>> else, so we have an idea about which ones matter more.
>> 
>> Regards,
>> Sérgio Martins
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
> 
> -- 
> Regards,
> Konstantin
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest