Re: [Development] QML engine C++ class renaming

[d3fault]

I understand that QML/Quick is young, which justifies breaking backwards
compatibility as it matures... but thinking longer-term, wouldn't it be
better to call the newest QtQuick (2.0) just QtQuick and the 1.0 version
Qt4Quick... to retain backwards compatibility? Does this promise of
backwards compatibility only last for one major version number change?
Isn't Qt 3 support being dropped with the release of Qt 5? Wouldn't that
imply that support for Qt Quick 1.0 is going to be dropped for the Qt 6
release? I see no point in making a promise, going through all the extra
effort of maintaining it... and then just dropping it later. We might as
well drop support for Qt Quick 1.0 now and force the (albeit painful)
upgrade process NOW rather than later (when they have EVEN MORE code
written dependent on Quick 1.0).

As an aside, what's the difference between qml and quick? I thought they
were the same thing. Why is QT += qml quick necessary? Seems like it should
be one or the other. Sorry if this is noob'ish.

Developers wishing to compile their Quick 1.0 code on Qt 5 should be forced
to do QT += qt4quick or something, explicitly asking for backwards
compatibility (assuming my paragraph above is ignored... which I'm guessing
it will be...). New code should just be QT += quick... and hopefully Quick
matures enough so that backwards compatibility isn't broken again.

As for QQml vs Qml, Qml definitely reads better.. but QQml follows the
rules. Rules can be broken and/or changed, however. With Qml becoming such
a large part of the Qt experience (it seems to get way more attention than
the C++ part lately), I'd say it's worth the exception.

d3fault

On Wed, Feb 15, 2012 at 4:41 AM, Artur Souza (MoRpHeUz) 
artur.so...@openbossa.org wrote:

 On Wed, Feb 15, 2012 at 8:31 AM, Olivier Goffart oliv...@woboq.com
 wrote:
 
  Anyway, this is a compatibility library. It's sole role is to be there
 to help
  transition (just like qt3support was)

 I had the impression that most people agreed that qt3support was a
 mistake. Are we going to take the same strategy for Qt5? :)

 Cheers!

 --
 ---
 Artur Duque de Souza
 openBossa
 INdT - Instituto Nokia de Tecnologia
 ---
 Blog: http://blog.morpheuz.cc
 PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
 ---
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] The place of QML

[d3fault]

*cough*

http://qt-project.org/forums/viewthread/16465/

Does Qt need a modern C++ GUI API?
 -No, I am perfectly happy with QML, JavaScript, interpreters, virtual
 machines, glue code, glue abstract and proxy object
 -Yes, I’d like the option of 100% native development without being left
 behind with a last century GUI API



Can someone put that poll, or at least a link to it, on the front page of
qt-project.org?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The place of QML

[d3fault]

Yes, it is strongly biased due to the wording. Fix the wording and post it
anyways. The numbers will not change.

I got bored and drew a pretty picture to summarize my feelings for QML:
http://bayimg.com/jaooAAaDC
Hope you laugh.

But back to being serious. How can anybody in the QML camp argue against
this: Modern, Hardware Accelerated GUI Defining/Declaring/Creation does not
require QML/JS Interpreter/Virtual Machine.

It's like these genius' (QML/QtQuick is still brilliant) got so caught up
with what they were working on that they forgot the big picture: Hardware
Accelerated C++ GUI. Forcing the use of a declarative language, a JS
Interpreter, and a virtual machine just makes most of us want to stab
ourselves in the eye out of principle (our principles differ from yours).

To quote Lars,

 We want to make the usage of Javascript supported as well as C++ is
 supported. We are not making it the *superior* way or even the only way.

...except that the javascript way currently is the superior way. If you
want a hardware accelerated UI (without hacking together your own...
defeating the purpose of using a UI toolkit), you are forced to use
javascript (QML).

d3fault

On Fri, Apr 20, 2012 at 3:59 PM, marius.storm-ol...@nokia.com wrote:

 That's a strongly biased poll due to the wording. And it's missing the
 points the Lars has been trying convey, but some seem to ignore.

 --
 Sent from my Nokia N9On 4/20/12 17:31 ext d3fault wrote:
 *cough*

 http://qt-project.org/forums/viewthread/16465/


 Does Qt need a modern C++ GUI API?
 -No, I am perfectly happy with QML, JavaScript, interpreters, virtual
 machines, glue code, glue abstract and proxy object
 -Yes, I’d like the option of 100% native development without being left
 behind with a last century GUI API



 Can someone put that poll, or at least a link to it, on the front page of
 qt-project.org?

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

Re: [Development] The place of QML

[d3fault]

 C++ Front-End to QtQuick (like Ivan described)
OR
Pre-Compile QML and only ship bytecode in binary for QtQuick use
plox

d3fault


On Mon, Apr 23, 2012 at 1:59 AM, Alan Alpert alan.alp...@nokia.com wrote:

 On Mon, 23 Apr 2012 17:35:02 ext lars.kn...@nokia.com wrote:
  On 4/22/12 9:14 AM, ext d3fault d3faultdot...@gmail.com wrote:
 
  ...
  ...
  To quote Lars,
  
  We want to make the usage of Javascript supported as well as C++ is
  supported. We are not making it the superior way or even the only way.
  
  
  ...except that the javascript way currently is the superior way. If you
  want a hardware accelerated UI (without hacking together your own...
  defeating the purpose of using a UI toolkit), you are forced to use
  javascript (QML).
 
  No, you should be using QML. That doesn't imply that you have to write
 any
  application logic in Javascript. As I said, use it as a better .ui
  language. You can still do all your app logic in C++ if you so want.

 I don't think Lars emphasized this enough, but QML is *not* JS. In fact,
 the JS engine is only used when you have non-trivial
 bindings. The rule of thumb is that you have to really write code that
 looks like JS in order to have it interpreted by V8. So if
 you use it the same way as a .ui file, the performance characteristics are
 almost the same too. For example:

 Rectangle {
x: 10
y: 10
width: 10
height: 10
 }

 This is the level of functionality that UI files provided, and it didn't
 need JS. Well, it still doesn't. That QML code isn't
 going to run anything through V8. The QML engine is smart enough to just
 assign the values and not bother using a JS interpreter.
 You end up with a C++ object instantiated, and with some properties set,
 which is exactly what .ui files did. So if you compare
 this to a .ui file, the only difference is that it is being compiled when
 you load the component instead of during the compile
 phase. Oh, and it's easy enough to write by hand as well as with the
 visual designer.

 I understand that run-time compilation is a concrete performance cost for
 a static UI, and we're looking into ways of storing the
 compiled output so that you can just load bytecode to initialize objects
 (for the same performance characteristics as a .ui file).
 But so far our performance metrics show that the compile time is minuscule
 for QML applications and so it's not high enough on our
 priority list for what to optimize. Patches are welcome though :) .

  When you ask for simply exposing all a C++ API to all QML items, you're
  missing a point. QML is a language that include statestransitions and a
  binding engine. The binding engine works on arbitrary expressions and
  needs some backend to evaluate these. That backend happens to be V8.
 
  I don't see a problem with that. You're also not complaining that we have
  PCRE as a backend to implement regular expressions.
 
  We are already exposing most of the the C++ APIs that make sense for
  application developers to use. Simply exposing the C++ interface of all
  QML elements won't buy you anything, as the most important feature of Qt
  Quick (bindings) still can't be handled that way.
 
  There's zero value in exposing the C++ class that implements the QML
  Rectangle element. There's nothing you can really do with it anyway. If
  you need to create your own QML elements in C++ we have QQuickItem and
  QQuickPaintedItem, which form a very good and solid basis.
 
  And as others already pointed out, we need to be careful as to what we
  expose in C++. Any API we add comes at a large cost (that you probably do
  not see) in terms of maintenance and limitations to what we can change
  because of binary compatibility.

 I can see the non-zero value in exposing the Rectangle element. It's
 pretty much equivalent to QGraphicsRectItem then. I don't
 know about you, but I didn't find QGraphicsRectItem very useful at all. In
 a C++ graphics scene, it wasn't worth the bother to
 compose images out of multiple QGraphicsRectItems. That approach was
 cumbersome and inflexible compared to implementing your own
 QGraphicsItem and just painting a rectangle in paint(). Note that with
 QQuickPaintedItem, you can do the exact same thing with
 scenegraph today (well, on the day Qt5 is released ;) ) just take your
 QPainter* and go to town. Or use QQuickItem and paint it
 using scenegraph or GL directly, to truly get the sort of hardware
 acceleration and speed that requires custom C++ code. (NB:
 after writing your super-fast C++ native object you can then use QML to
 instantiate it and set initial properties, if that appeals
 to you.)

 This is one of the main reasons we aren't exposing the elements to C++.
 The value for providing these elements in C++, compared to
 you doing your own painting in C++, is very ill defined. It's not zero,
 but there is a large cost in the limitations we have when
 we make an API public. Remember that if we change it to expose the C

Re: [Development] The place of QML

[d3fault]

... but multiple polls
have shown otherwise (including one recently shut down by a Nokian).

Nokia's investment in Qt is big (check
 http://www.macieira.org/blog/qt-stats/ ) therefore I'm not really sure
 the best approach is to put more pressure or requests in that direction.

Big
so Money + Manpower = Great Software??
wow I wish I knew that earlier... I could be a million dollars by now

 Why not asking others?

Nokia owns Qt outright and are the only ones capable of preventing a
fork. I don't want a fork. I don't want segregation because it is
expensive and hurts real development.


tl;dr:
You + 3rd Parties --(Contribute Revenue Generating
Modules/Code/Fixes/Enhancements)-- Qt Project/Nokia/Digia --(revenue
generated goes to Nokia's bottom line [mobile] (or Digia's bottom
line, but that's irrelevant))-- Qt Project is Funded by Nokia who is
targeting Nokia's bottom line (mobile)

All in all, I acknowledge I'm wasting my breathe. Nokia doesn't give a
shit about me, only their bottom line. Why bitch, then? Why not just
go out and start a Qt Charity and offer support for Qt-deriv/fork
released under LGPL? It could even be classified as a for profit
business. The reason is simple: I'm just one guy. A fork, a
charity/business, and support are a fuck ton of work. I'd rather let
the ideas float on this mailing list before just charging out my front
door with a sword drawn.
Lastly, a fork would hurt the Qt Project/Nokia/Digia the most. The
fork could still PULL all of Qt Project/Nokia/Digia's work to
itself... and accept patches and further contributions directly under
the LGPL (not requiring the Qt Contributor's Agreement, which let's
Nokia do anything they want with your code). Nokia would be unable to
pull said LGPL-only enhancements without convincing the author's to
sign a Qt Project Contributor's Agreement (and why would they?).

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

Re: [Development] The place of QML

[d3fault]

 and
then use QWidgets. I mean you can... but then you're wasting the Pi. I
don't know what GUI language I'm going to write Pi apps in tbh:
Obsolete/stable/slow QWidgets or New/untested/fast QML/QtQuick. The
slow/fast difference will probably be visibly notable for certain GUI
events on certain programs -- most notably on the Pi.


On 5/16/12, Giuseppe D'Angelo dange...@gmail.com wrote:
 The OP:
 - doesn't like the fact that QML has not a comprehensive C++ API;
 - does want instead that API;
 - doesn't like the CLA and the fact that he would be giving to Nokia
 more what Nokia gives him back under a free license;
 - knows that such an API won't come from Nokia soon;

 The natural consequence is: OP: go ahead and create this technology.

 Make a startup, hire 20+ world-top-class developers, work hard for 1-2
 years, and release your product as a 3rd-party add on for Qt.

 You won't have to sign any CLA, and you'll be free to release it under
 any licensing model you want.

 And any bank will be happy to back your company, since, as you say,
 - it's ok for you / you're willing to run in the red for some time
 - the huge number of people wanting your product will make it
 completely repay for the initial investment.

 Does it sound good?

Sounds Great. Can you provide funding ;-)? I've already said that all
that's needed is a Charity/Business. But in saying this you are pretty
much admitting that Nokia themselves do not have a vested interest.
The mere fact that it should be contributed as a 3rd party module
should signal a problem with the Qt Project infrastructure. Do we want
Qt to have amazing 1st party/supported/maintained/tested modules or do
we want to have to rely on the community to contribute BASIC
FUNCTIONALITY (modern C++ gui -_-) through 3rd party modules?
A huge disadvantage (though also an advantage) would be that said
charity/business couldn't use the Qt Trademark. Their 3rd party module
would probably be specific to Qt. They could refer to Qt... but they
couldn't not call themselves Qt. Profits would suffer (this is also an
advantage because of the current work required to
support/maintain/fork Qt).


On 5/18/12, Uwe Rathmann uwe.rathm...@tigertal.de wrote:
 What I want to say with this is: speedup numbers heavily depend on the
 use case and often doesn't mean much for your application.

Well obviously. The difference is that hardware acceleration almost
always brings the additional advantage of freeing up the CPU.
Let's not even get started on how much better a GPU scales under heavier load.
Hardware acceleration can speed up your processes (not referring to
CPU processes... but the overall task) by an order of magnitude
compared to cpu-based rendering. 2.5x sounds like a safe low estimate
to me...

Hardware Acceleration is something the C++ and QML camp both
definitely agree on.
Uwe, if you don't think the performance difference between CPU/GPU is
that much... you should be perfectly happy sticking to the 'Done'
(which almost actually kind of means perfected... so long as you're ok
with obsolete) QWidgets.


to end,
Qt would never have appealed to me (maybe I would have landed on GTK+
instead idk) if the use of QWidgets required me to define my UI in
XML. This is essentially what QML is requiring.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The place of QML

[d3fault]

 thread would look 
significantly different.

Incorrect. If the people involved in the debate were capable of
proposing a Qt-style C++ API for the QML functionality (meaning, a C++
front-end to the QtQuick back-end similar to the QML front-end), then
we'd already have a C++ Front-End to the QtQuick Back-End and there
would be no need for debate. The problem is that QtQuick is an
undocumented and complex beast. It's 'state of the art'. Without
QtQuick, QML is [essentially] worthless. The genius' behind
QML/QtQuick (yes, QtQuick was created with QML in mind :-/) are
[essentially] the only ones who know how it works... so they'd need to
be the ones to either a) create said C++ front-end, or b) properly
document the QtQuick internals (as well as overall design - what
happens when) so someone else can create said C++ front-end. Hopefully
this will be done after Qt 5.0 ships and we can begin playing catch up
with all the QML-specific functionality that has been created (lol,
talk about wasted effort. Qt is/will-be split in half).

QtQuick was developed with QML in mind, and also depends on it (for now).
QML was developed with JavaScript in mind, and also depends on it (for now).

We just want to hurry up and get both of those for nows out of the
way. Being fellow developers, we understand that decoupling a design's
dependencies is a lot harder than designing it to be decoupled in the
first place (say, for example, if QtQuick was designed with both a
QML/C++ front-end in mind). At this rate (and especially considering
the lack of interest from practically all of Nokia (hello Nokian who
agrees with us. I don't blame you for keeping your mouth shut. Jobs
are a hard thing to come by these days ;-))), it's going to take a
very long time before we have a C++ front-end to the QtQuick back-end.

Allegedly (according to Caspicse... although he suggests using it
directly like a troll), we just want a front-end to QtQuick that uses
QQuickView, QQuickItem, QSGNode and provides the QML functionality...
but in C++. Sounds easy... except looking at those 3 public classes, I
wouldn't have the slightest clue where to start. What's the difference
between an Item and a Node? They are both used interchangeably in
various contexts. Don't respond to this. Instead, put the
documentation where it belongs ;-).
I actually just spent a few minutes looking at the source code and
already found a problem with this approach: QQuickItem.h #includes
QtQml/qqml.h and QtQml/qqmlcomponent.h ... LOL WUT? QtQuick
depends on QML internally too? Great. That's as far as I read because
I already knew the design was fucked. lol @ 'decoupling' statement a
few sentences back.


Domino
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72628
The decision regarding the C++ API seems to be based on the lack of resources 
and on time constraints.

Lack of resources and time constraints would also make an excellent
cover while still being true. It doesn't account for the fact that the
finite resources/time are already being used on something the majority
don't want.

What happens to QML/QtQuick if/when Nokia goes out of business this
year ( 
http://articles.businessinsider.com/2012-04-19/tech/31365445_1_nokia-ceo-stephen-elop-oil-platform
)? Ok probably bought out by Microsoft, but sameshit. We'll have an
unfinished/undocumented/incomplete QML/QtQuick implementation and
QML/QtQuick will be practically worthless. Microsoft will own the Qt
trademark at that point and will just sit on it (could be wrong, but
at the very least they're just going to ruin it more (could be wrong
again.. maybe Microsoft will see it for what it is and embrace/develop
it further, now that they own the trademark (pigs fly))).
QtQuick will still be too complicated to just up and create a C++
front-end for and we'd have to decide whether it's worth the effort of
reverse engineering the design of QtQuick or if we should create a
replacement from scratch using similar a design


Marius Storm-Olsen
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72629
However, if you feel strongly for it, feel free to work on a code suggestion, 
submit it for peer-review and discussion at https://codereview.qt-project.org/

Oh, it's that easy eh I just come up with a 'code suggestion' for some
complex undocumented back-end and then just commit it and then it just
works just like that? What am I waiting for!?!?!?!? *codes randomly*
Thanks for closing the comments btw. More discussion is exactly what
we don't need. As you've pointed out, we just need 'code suggestions'
to be submitted from random independent developers.


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

[Development] Proposal: Change Qt Slogan

[d3fault]

I think we need a slogan change so as not to lie to our users.

Old Slogan: Code Once. Create More. Deploy Everywhere.
New Slogan: Code Once. Create More. Deploy Everywhere that supports OpenGL + v8.

The reasons are self-explanatory.
The v8 part might only be true for the 5.0.0 release... but it appears
the OpenGL requirement is here for good.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Code of conduct.

[d3fault]

On Thu, Jun 21, 2012 at 12:30 PM, André Pönitz 
andre.poen...@mathematik.tu-chemnitz.de wrote:

 I don't think the current level of what might be considered offensive
 wording in parts of the world is unbearable, and I don't really think
 spending time on finding consensus on such issues is spend well.


+1

Besides, there is already a policy in place for this.

http://qt-project.org/wiki/The_Qt_Governance_Model

Chief Maintainer
... to intercede if other community members aren’t acting appropriately.

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

Re: [Development] Code of conduct.

[d3fault]

On Fri, Jun 22, 2012 at 3:29 AM, Alexis Menard
alexis.men...@openbossa.orgwrote:

 On Fri, Jun 22, 2012 at 4:53 AM,  marius.storm-ol...@nokia.com wrote:
  Right. I must admit i can't see which specific incident which triggered
 this thread now, i believe the community has behaved good lately. But i
 agree that a general code of conduct for all our forums (mails, IRC,
 reviews, bugreports, etc)

 I hate to point fingers but reading this made me sad :

 http://labs.qt.nokia.com/2012/06/18/qt-5-accessibility-apis/#comments




This whole thread makes me sad.

Microsoft/Nokia have carefully crafted a state of FUD...

...and all you want to talk about is the Code of Conduct policy??



The Qt Project is, in this very moment, in the worst state it could
possibly be in.



No amount of disrespectful comments (made by yours truly) could make it any
worse.


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

[Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

[d3fault]

QML is not interoperable with Qt/C++.

It claims to be interoperable, but it's really not.

QML can access everything from Qt/C++ (usually requires glue code), but Qt
cannot access everything from QML.

Examples:
a) Qt Graphical Effects
b) QML Desktop Components
c) [more to come, no doubt]

^every time a new piece of QML-exclusive functionality is announced and
touted as Qt functionality, the divide in the community grows.

QML is ruining Qt's good name by introducing a toy programming language
mode and splitting the community in half by making new framework features
exclusive to that TPL mode.

QML is a _user_ application of Qt. It is a powerful product, potentially
profitable, and the users of it can even use Qt/C++ behind the scenes.
However, it does not belong in the Qt code base (perhaps as an Add-On?).

The IEEE defines 'interoperability' as:
the ability of two or more systems or components to exchange information
and to use the information that has been exchanged.
The definition of 'exchange':
An act of giving one thing and receiving another in return -- just
wanted to point out that the exchange in interoperability is two ways
QML only uses functionality that Qt/C++ provides. QML specific
functionality is inaccessible from Qt/C++.
Therefore, QML is not interoperable with Qt/C++ and should not be in Qt's
code base.

Another way of thinking about this: Imagine Nokia was pouring resources and
functionality directly into the python bindings (instead of upstream) and
then claiming the python bindings were Qt. Oh, you like C++? You like
native? Too bad, now you have to use python if you want any of the new
functionality.

Now let's get out our conspiracy theory watches (so we can see how much
time we waste speculating): It's plausible that Microsoft directed Nokia
into purchasing Trolltech with the sole intentions of segregating the
community (divide and conquer) in the way described above. It makes me
giggle when people respond saying The Nokia employees are devoted to Qt!.
I don't question their devotion for a second (the code monkeys working at
Nokia are on my team as far as I'm concerned)... but at the end of the day,
they do what they're told to do by the guy who writes their paycheck. Qt
in-house developer's boss: Nokia. Nokia's boss: Microsoft. The only
question that remains: does Microsoft play that dirty? (hint: yes). I hate
repeating myself (I do it often), but for anyone who can't figure out why
Microsoft would dislike Qt: Microsoft's primary revenue source is operating
system sales. They do so well with operating system sales because of their
use of vendor lock-in tactics. Applications made for Windows tend to not
work on other operating systems. Qt is changing that. Qt is platform
independent, as powerful as (if not more powerful than) Microsoft's .Net
lineup, with the added advantage of being 100% native. Qt is the biggest
threat to Microsoft's long-term survival.


So with all the noise that I'm making, QML is making more. Not only that,
it's siphoning resources and splitting the community in half.

d3fault

p.s. re: me not having any merit
From http://qt-project.org/wiki/The_Qt_Governance_Model
Decisions about the future of the Project are made through mailing list
discussion with the members of the community, from the newest User to the
Chief Maintainer.
That being said, I expect to be ignored because the vast majority of
contributors/deciders work within Nokia (and can't speak freely because of
it (they can still speak against the motion though. anyone else see the
problem with that? LOL 'Open Governance')). We'd need a lazy consensus
among 3rd party contributors beating out Nokia employees voting against...
and then we'd have to hope the Maintainers/Chief Maintainer doesn't
override the decision. Never going to happen. Fork sounds easier... but
that splits the community as well.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

[d3fault]

On Jul 3, 2012 10:04 PM, lorn.pot...@nokia.com wrote:

 QML was started long before Nokia bought Trolltech.

 To answer your question, my opinion is No, QML should not be removed.


Lorn, so you think it should be allowed that Qt Modules are not
interoperable?

Also, did QML in the Trolltech days have javascript hacked on and
forced-JIT in the design? There's a 3rd option that I intentionally didn't
mention that is actually a sensible home for QML: .ui file replacement.
Currently QML depends too much on itself to be a .ui file replacement.
There is no C++ equivalent of much of the functionality in QML, whereas
everything you can do in a .ui file, you can do in C++.

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

Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

[d3fault]

On Jul 4, 2012 1:18 AM, Attila Csipa q...@csipa.in.rs wrote:

replacement. There is no C++ equivalent of much of the functionality
  in QML, whereas everything you can do in a .ui file, you can do in C++.
 

 This is a bit of a red herring. You can do everything in the .ui you can
 do in C++ exactly because there is not that much you can do with it. You
 can have a fully static QML (without any JS) for the same purpose, but
 that would make no sense - that would be just syntax switching from XML
 to JSON without any functional benefit.

It is not a red herring because everything QML brings to the table can
theoretically (read: definitely) be done in C++.

Interoperability is of course
 very important, but it's really not about we will intentionally make it
 suck, but rather that some things are easier to expose to the C++ side
 than others. Long before declarative we had QtScript and QtWebkit which
 were - in those days - even less interoperable, but perhaps they were
 not as cool, so the sour grapes syndrome didn't kick in :) Yes, one
 might have personal preferences regarding the language choice and how it
 interfaces with the rest of Qt, but that doesn't invalidate the concept.

QtScript is app specific and serves a special need. You don't need to use
it for every regular GUI app. Webkit is C/C++, so I'd imagine whatever
interoperability you desire could have been added trivially. I wasn't
around back then.

 You're not forced to use QML, it's just that for some tasks it's the
 easiest (and thus recommended) way to go.


This is where you're wrong. It's use qml or be stuck with last generation
raster painted qwidgets. (or make your own)

On Jul 4, 2012 1:26 AM, Shawn Rutledge shawn.t.rutle...@gmail.com wrote:
 QML is itself quite a simple language, if we leave out the possibility
 of using JS handlers; maybe it wouldn't even be too hard to write a
 qmlc which generates C++ code as long as one doesn't rely on any JS
 language features (or by bundling the JS snippets somehow).  I haven't
 tried though; has anyone else?

qmlc would differ greatly from uic in that qmlc would generate a lot more
code than a programmer would ever want to type. UI files are
interchangeable with C++ to the point where .ui files are essentially just
the C++ code in xml form (xml is easier for the designer to parse +
re-generate).

If QML was implemented as a thin JSON layer with an underlying C++ API
(front-end to QtQuick), then qmlc would be more similar to .ui files
(whoop-de-do) and would be interoperable through said C++ API (the biggy).

I do agree that a qmlc is a step in the right direction... or is at the
very least not a step in the wrong direction.

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

If Windows and Linux provide the capabilities, we shouldn't let
specific functionality absent in Mac (or any platform for that matter)
define Qt. I think modifying the addPath methods to include an
optional bool watchRecursively = false as the second parameter is the
correct solution. Any platforms that don't have a suitable solution
can/should use an #ifdef'd out Qt-internal solution (or a QPA default
implementation? something along those lines idk). So as you said you
attempted and failed, the Mac OSX implementation should internally
keep a copy of the dir structure and the public API should remain
cross-platform. The only thing needed is a this class consumes more
memory/cpu on Mac than on the other platforms. That warning
definitely beats a oh by the way this public API performs differently
on the Mac message, creating a nightmare for application developers
wanting to target multiple platforms.

I would compare this to Windows Metro (a specific platform) not
including/allowing OpenGL (analogous to efficient recursive directory
monitoring), and Qt solving this by using ANGLE (platform-specific
workaround).

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

I don't like your single signal design. It's cross platform only in that it
will compile/function on every platform. The application will behave
differently in the slot connected to said signal on mac than on
windows/linux. We should not expect every _user_ app to have separate
codepaths for different platforms. A.k.a exactly what Qt isn't about.

Just because you attempted the perfect solution once and failed, doesn't
mean it can't be done. At the end of the day we just need some #ifdef
Q_MAC_OSX (or maybe this can/should be in QPA) with boring file property
(filename,filesize,maybe-crc32?,etc) comparison stuff before determing the
proper signal to emit.

I also think we should remove the 256 limit even for non-recursive
monitoring on the Mac (always use FSEvents). 256 is a ridiculously small
limit for any app wanting to do any slightly serious fs event monitoring.

Aside: perhaps QObject::connectNotify can be cleverly used to skip the
string comparison stage for an event if there is no slot connected to that
particular signal. So if they only connect to dirChanged, the internal code
never uses the 'expensive' #ifdef'd out file change detected code.

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

On Jul 23, 2012 8:07 AM, logic.cpp logic@gmail.com wrote:
What else do you suggest then, should we make 3 separate classes one for
each
 OS?


definitely not. qt is a cross platform toolkit after all. separate
back-ends... on the other hand: yes.

 By all means, please do try to generate this in-memory snapshot of a
sizable
 directory tree (say 20,000 folders 150,000 files) with all the necessary
info
 you listed (filename,filesize etc.) and tell me how it goes.
 Last I tried it on my own hard drive full of stuff (40k folders 300k
files) it
 1) consumed too huge an amount of memory, and 2) took too long to
complete.


That's fine, so long as a warning is present in the class description for
affected platforms. The argument i'm making is that EVERY _user_ app will
be responsible for creating the in-memory snapshot and additional
codepaths at least if they plan on targetting Mac OS. The overhead in
terms of memory/performance is the exact same... but you're giving app
developers the extra burden of doing it every time they use qfsw. It's
better behind the scenes and hidden from the _user_. At the very least just
so it only has to be coded/maintained once (instead of once per _user_ app).

 What I'm trying to achieve here is to have some kind of common cross
platform
 interface for file-system monitoring (in contrast to, for example, making
3
 separate classes QWinWatcher QNixWatcher QMacWatcher which will force
users to
 have platform specific code) that works as similarly as possible on all
OSs and
 gracefully degrades as necessary. Users will be made aware of this
degradation

Behind the scenes compile time progressive enhancement is better than
userland runtime graceful degradation -- at least in this use case.

 In fact - as was noted in a previous post - even on Mac OS itself there
can be
 different features available depending on which version (Snow Leopard(-)
vs.
 Lion(+)) and not just any trivial feature difference, it's a huge 
important
 one; getting actual file-level details on what exactly changed,
eliminating the
 need for an existing snapshot to compare against! Will Qt not take
advantage of
 these features where available?

Simple, the #ifdef Q_MAC_OSX now becomes #if (Q_MAC_OSX_VERSION = 69 /*or
whatever the Leopard version is*/)

So Lion+ uses it's native functionality, and Leopard and any other platform
missing the functionality uses an expensive in-house snapshot comparison
method.

 The questions remain as follows;
 - Should it all be in one class?

Yes, making it two classes isn't necessary. It's still the same
functionality, just with a recursive element.

 If yes, how to go about differences in features/functionality.
 Should we emit many different kinds of signals, or just 1 general
signal.

This doesn't matter so much, as long as the Qt code ensures that the same
signal(s) are emitted for every platform. Using a single signal +
capabilities() shifts the burden onto the _user_ developer... and one could
even argue that qfsw isn't even cross platform at that point.

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

On Jul 23, 2012 7:51 PM, logic.cpp logic@gmail.com wrote:

 So - are you suggesting that Qt file-system monitoring facilities
 should actually generate an in-memory snapshot of the necessary
 directory tree(s) for platforms that need it (in this case Mac OSX =
 Snow Leopard) ?

 Hey I'm not against, it would be really easy to implement. But you
 should really try testing something like this yourself on your
 computer first. It's /really/ memory consuming as well as /really/
 time consuming for large trees of stuff, fairly common nowadays in
 anyone's photo/music/video/doc etc. collection. Sure we can alleviate
 the time-consuming part with a worker thread, but I'm telling you this
 is quite a hunk of resources you're signing off Qt to consume for a
 possibly large percentage of use cases (many many people out there
 have = Snow Leopard).

The amount of resources consumed is irrelevant if the _user_ consumes the
same amount with their custom implementation. The only value gained in
doing the work up front in Qt / behind the scenes is that now every _user_
developer doesn't have to implement it manually. It will save a ton of man
hours from having to reinvent the wheel.

You mentioned giving the user a choice on whether Qt maintains the state
comparison tree or not. This is definitely the optimal choice, but:
a) adds design complexity
b) would maybe be confusing on platforms where it's n/a
both of those problems are solvable (obscure the (b) choice somewhat... i
think i recall a Mac-specific QMainWindow function regarding the toolbar
and OS integration. do something like that)


 BTW d3fault are you on IRC? What's your handle  timezone, maybe we
 can chat about this more.


I'm not on IRC lately but you can email me if you want. Irregular/shifting
sleeping patterns so timezone won't help.

 P.S. Just on a personal note, the reason I got caught up in all this
 to begin with was some application I wanted to develop. My particular
 project involves a snapshot of the file system anyway, so in my
 particular case on MacOSX=Snow Leopard I would definitely just obtain
 directory-level information from FSEvents and proceed to compare the
 directory's contents with that of my existing snapshot.
 In fact if Qt is gonna do a whole in-memory snapshot as d3fault
 suggests for this situation, I'm considering dropping this whole QFSW
 campaign and just roll out my own solution :)

Might as well contribute your own solution then. This way you don't have to
maintain the code... everyone else (myself included) benefits... and you
don't even have to write that much more code. You just organize it
differently (and comply with Qt coding standards etc).

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

On Jul 23, 2012 11:49 PM, Sylvain Pointeau sylvain.point...@gmail.com
wrote:
 I really like the idea of 1 signal and use the best as possible of each
OS. I am against Qt to make a snapshot of the directory because it will not
be done efficiently, means that this code, to be efficient, depends on the
task to achieve, and there is probably a ton of optimisations that we can
apply in a particular context.


It will only be inefficient for the few platforms that don't support the
functionality. The cost for platforms that already do provide the
functionality is zero.

Filesystem notifications are a pretty basic piece of functionality, and
having them be 100% cross platform would be a huge win for Qt.


 Maybe create a separate to provide a helper of creating a snapshot? In
this case I would suggest using a sqlite database and not the memory.
Memory is definitly a showstopper.


Theoretically it could be either (user chooses memory or sqlite) or both
(fixed size memory cache with sqlite storing the rest) or neither (when the
user wants to maintain the snapshot themselves (but remember, this is only
applicable to the platforms that DON'T support fine grained fs event
notifications. All these options are n/a to the platforms that do) because
they can perform context sensitive optimizations as you mentioned)... but
uhh I'm willing to bet sqlite would be a lot slower since now there's a hdd
read/write. Would save memory though if that's your concern. It's just
added design complexity which I'm guessing regedit doesn't want to deal
with. It's already getting complex enough.

Can any Qt devs comment on whether QFsw would even be allowed in Qt in a
non cross-platform state (ignoring the fact that pretty much any solution
is better than the current Qt release's solution lol)? regedit, you might
find it doesn't pass code review... but maybe the capabilities() hack is
enough, idk (i still wouldn't recommend it)...

d3fault

p.s. just thought of this: you could specify what properties in the
snapshot you want to be compared as an optimization (enum flags
filter). but then there's the cross platform breaking use case where
you use the optimization just described to purposefully get less
notifications (say... ignore filename changes but tell me about file size
changes (all using some enum flag filter mechanism))... but when you run
that code on a platform that doesn't need the snapshot logic, you'll still
receive filename changed events (unless your setting of said enum flag
filters activates snapshot comparison mode... which isn't there because
it's #ifdef'd out on this platform (and so shouldn't be)). Bah, this
optimization sucks but it's still better than forcing every _user_ app
to do it manually every time.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

On Jul 24, 2012 3:09 AM, Sylvain Pointeau sylvain.point...@gmail.com
wrote:
 having them inefficient is worst than not having them.

Arguably. We have to choose from the following:
1) Make Qt only target Lion+, drop Leopard support as well as any platform
without fine grained fs notifications
2) Not have a cross platform public API (breaks Qt rules?)
3) Be inefficient for the few platforms that don't support fine grained fs
notifications

All 3 options suck (as does the current state of Qfsw), but I'm pretty sure
the last option sucks the least.

 make a separate lib or class and let the user decide if he can use it.
 don't force everybody to be penalized.

Similarly, don't force everyone to reinvent the wheel.


 As I said, a generic implementation cannot beat specialized code for the
specific domain/case.


Yes, but as mentioned before, we could additionally (runtime switch? ex:
if(Qfsw::currentPlatformDoesntSupportFineGrainedFsNotifications()) {
m_Qfsw.setDontSimulateFineGrainedSupportBecauseWeWillDoItManually(true); /*
already true(ish) for platforms with fine grain notifications */ }) disable
the behind-the-scenes-state-comparison code so the user can optimize their
heart out. They'd have to again use that static fine grained detection
method in their slot connected to dirChanged to decide whether or not to
even use their own manual implementation, because most relevant platforms
already provide fine grained notifications and the user's manual code
should then be skipped. A bit complicated, but definitely doable.

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

On Thu, Jul 26, 2012 at 9:55 AM, logic.cpp logic@gmail.com wrote:
 So how about something like this (others have suggested something along these 
 lines):

 In order to work recursively,

Recursive isn't the same problem. Recursive is easy. The only problem
with doing recursive before was that 256 fd limit on Mac... which I
think we should get around by using FSEvents.


The rest of your  post was kind of confusing, but I came up with a
design where everyone wins. It's just a high level public API design,
but you should be able to easily figure out the internals from it (let
me know if you can't).

It's:
1) Cross platform without requiring the user to write custom code
2) Customizable/optimizable for the apps that need/want it
3) Efficient on platforms that support fine grained notifications,
inefficient (unless you do (2) above) on platforms without


Here you go, I used overly verbose wording to make it as clear as
possible. Also, I'm not sure how interfaces are supposed to be named
within Qt so I just guessed. And note the pure virtual public slot in
the interface... it should help explain.



class QFileSystemWatcher : public QObject
{
Q_OBJECT
public:
QFileSystemWatcher(QObject *parent = 0);

QFileSystemWatcher(IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter
*userCustomSnapshotComparisonCode, QObject *parent = 0);

void addPath(const QString path, bool recursive = false);
void addPaths(const QStringList paths, bool recursive = false);
QStringList directories() const;
QStringList files() const;
void removePath(const QString path, bool recursivelyRemove = false);
void removePaths(const QStringList paths, bool recursivelyRemove = 
false);
signals:
void directoryChanged(const QString dir);
void fileChanged(const QString file);
};

class IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter
: public QObject
{
Q_OBJECT
public slots:
virtual void dirChangedSoFigureOutFileChangesAndEmitThem(const QString 
dir)=0;
signals:
void manuallyDetectedFileChanged(const QString file);
};

class 
QFileSystemWatcherDefaultSpecialCoarseToFineGrainedNotificationsFigureOuter
: public IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter
{
Q_OBJECT
public slots:
void dirChangedSoFigureOutFileChangesAndEmitThem(const QString dir)
{
//here is the default implementation using the most common 
method
(snapshot comparison of file properties) for detecting fine grained
notifications

//after we detect a file in the dir has changed, we simply do:
emit manuallyDetectedFileChanged(filename);
}
};


using it:
//if you want cross-platform support and don't care that some
platforms will be very slow
QFileSystemWatcher *fsw = new QFileSystemWatcher();

//if you have a special app and want to do some optimized detection
(but this is only applicable to platforms that don't already provide
fine-grained. in those cases the interface is simply ignored)
IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter
*myOptimizedDetector = new MyOptimizedDetector();
QFileSystemWatcher *fsw = new QFileSystemWatcher(myOptimizedDetector);


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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

On Jul 27, 2012 6:02 AM, logic.cpp logic@gmail.com wrote:

 BH

 I think this is very much like what I was trying to describe.


I think so too, it was immediately after reading your post that the design
jumped out at me. The confusing part was your stating that the interface
should be required to be implemented, then saying there's a default impl as
a bonus (contradiction). Oh well, doesn't matter now :).

Are you working on getting it implemented?

It's really annoying that Mac=Snow Leopard is forcing us into such
corners, but if it works and it pleases all Qt evangelists :) then maybe
this'll do.

It is annoying, but it's even worse to allow a platform to stall Qt like
that. I'm glad to see Qfsw will hopefully finally progress... I'm pretty
sure recursive has been in the plans for a while now (it just always leads
to this same discussion about platforms not supporting fine grained
notifications).

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

[d3fault]

I've been thinking about it some more, and I think it would be a good idea
to add another optional bool to the opt-in custom interface constructor.

So it now would be:
QFileSystemWatcher(IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter
*userCustomSnapshotComparisonCode, bool
alwaysUseCustomFigureOuterEvenIfPlatformDoesntNeedIt = false, QObject
*parent = 0);

The reason for the additional bool is that we cannot predict what criteria
a _user_ will use to determine a file changed. They may ignore certain
changes that the native platform would emit, which will lead to
inconsistencies in their application on platforms with native support vs.
those without. The bool allows them to opt to take control of every
platform so there aren't any inconsistencies. It defaults to false because
most of the time the user will want to use the much more efficient native
platform notifications when available.

We need a pretty beefy class description explaining all this.

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

[Development] bool QProcess::waitForFinished() Race Condition?

[d3fault]

Unable to confirm the race condition, which is why I'm posting here
instead of filing the bug report. Isn't there a race condition between
calling QProcess::start() and QProcess::waitForFinished()?

Can't the OS switch contexts at ANY TIME (in this case, between the
start() and waitForFinished() calls)?

Scenario:

QProcess proc;
proc.start(aVerySmallBinary);
//OS switches contexts by sheer chance right here to the newly started
process. If the process is short enough it could finish and exit
cleanly before executing the following line
bool finished = proc.waitForFinished();
//finished should be true, but in the race condition case it will be
false because waitForFinished returns false ... if this QProcess is
already finished (doc).

One way to safely start/finish a process without the race condition is
to use the static method QProcess::execute(). but then you can't
capture stdout/stderr or listen for the QProcess::error() etc etc etc.
All you get with QProcess::execute() is the exit code as an integer
returned to you (output is simply forwarded to your process).

I tried testing/proving the race condition by doing a
QWaitCondition::wait() in between start() and waitForFinished() with a
3000 ms timeout (as way of sleeping)... but couldn't get it to
trigger. QProcess::waitForFinished() always returned true (my process
was /bin/echo test). I did however get waitForFinished to return
false when I called start() in one slot (attached to QPushButton I
press) and waitForFinished in another slot (from a different
QPushButton I press). I would be very much questioning my sanity if
waitForFinished() didn't return false in the second case... so it
doesn't really tell me anything. Maybe the code driving QProcess
already accounts for this race condition (something along the lines of
calling waitForFinished() within the same... errr... slot (event?) as
start() catches the rare case where the process finishes before you
call waitForFinished? Maybe I am simply testing it wrong and the race
condition exists? I do not know) and the documentation should be
updated accordingly so future users don't get confused as I am now?

Proposed Fix (if there is even a problem (if there isn't, the fix is
to update the docs)): Add a non-static method similar to execute()
that starts and waits for finish in one call. Perhaps called int
QProcess::startAndWaitForFinished(). This way we get the safety of
QProcess::execute() but without losing all the non-static
functionality that QProcess provides.

d3fault

p.s. maybe my fundamental understanding of how QProcess works is
wrong. Isn't the process run asynchronously? Or is that only with
startDetached()?? I am under the impression that startDetached() is
the same as start() in that they are both asynchronous... with the
difference being that a process started with startDetached continues
to run after the calling process (us) exits. Does start() run the
program synchronously? The more I think about it the more I doubt
that. How would I even be able to call waitForFinished() while it's
running if that was the case?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] bool QProcess::waitForFinished() Race Condition?

[d3fault]

Ahh that makes sense. Thank you!

Here is my proposed change for the documentation regarding the return
value from waitForFinished() :

Returns true if the process finished; otherwise returns false (if the
operation timed out, if an error occurred, or if this QProcess is
already finished. Note that the QProcess being finished is different
from the underlying process being finished. If you call start() and
your underlying process finishes before you can call
waitForFinished(), the QProcess object itself will not be considered
finished until execution returns to the event loop and QProcess can
then account for the fact that the underlying process has finished).



I don't have a git clone and gerrit set up atm otherwise I'd submit
it. Can someone else do it for me?

And another semi-OT question relating to documentation: how are we
synchronizing wiki edits of the documentation with the git copies?
Seeing as the documentation lives in the .cpp files, automatic
synchronization sounds... uhhh... difficult.

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

Re: [Development] bool QProcess::waitForFinished() Race Condition?

[d3fault]

On Wed, Sep 26, 2012 at 12:40 AM, André Somers an...@familiesomers.nl wrote:
 Op 26-9-2012 9:32, d3fault schreef:
 I don't have a git clone and gerrit set up atm otherwise I'd submit
 it. Can someone else do it for me?
 Well, this sounds like a fine time to get such a setup then?
 And another semi-OT question relating to documentation: how are we
 synchronizing wiki edits of the documentation with the git copies?
 Seeing as the documentation lives in the .cpp files, automatic
 synchronization sounds... uhhh... difficult.
 Simple: it is not. That is unfortunate, since there is valuable content
 in the docnotes (I assume that's what you mean with 'wiki edits of the
 documentation').


I need to lay off the crack. I must have hallucinated edit buttons
on the docs on qt-project.org/docs/ sometime in the past (or maybe it
was the nokia.com days). I thought qdoc (with a flag or similar tool)
was populating a wiki database with every release or something. But
yes, the docnotes are important too!

re: Below. tl;dr: clarifications in docs between QProcess and
underlying process, especially with respect to being finished.
And now I'm wondering if there are still scenarios where users might
get confused when using waitForFinished(). When using QProcess without
an event loop, wouldn't wait for finished always return true even if
the expected result is false (that it already finished)?

Scenario:

...programming without an event loop (lol)...

QProcess proc;
proc.start(aSmallAndFastBinaryAgain); // /bin/echo test , for example
//lots of other lines here, taking lots of time. maybe modal dialogs etc etc
bool finished = proc.waitForFinished();
//they would expect it to be false after reading the documentation and
getting confused between QProcess and the underlying process
//since we aren't using an event loop, QProcess never has the chance
to mark itself as finished. A user might think that since so much
stuff has happened (modal dialogs especially) in between that it would
be improbable that the process had NOT finished. They would be wrong
because QProcess never had the chance to update itself as being
finished (no event loop).

Proposed solutions: bool isFinished() which checks the underlying
process without needing an event loop
Or: A start/waitForFinished stack of sorts (haven't thought this
design through, see below) so that for every start(), a subsequent
call to waitForFinished() will always return true (but only once --
and obviously I'm ignoring the error cases where it should return
false)... regardless of if it is called with an event loop or not.
Would probably break existing code however :-/ (if using an event loop
and you give control back to the event loop so QProcess can mark
itself finished, a later call to waitForFinished returns false. After
this fix it would return true and thus break existing code).

I don't care too much about this because I am not programming without
an event loop... but I thought it was at least worth mentioning. This
is probably a waste of an email but maybe someone will read and
benefit from it years from now.

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

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

[d3fault]

On Sun, Oct 7, 2012 at 4:53 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 On domingo, 7 de outubro de 2012 21.23.53, mikko.saa...@nokia.com wrote:
 xhr.setRequestHeader(Origin,http://www.google.fi\nReferer:http://www.goog
 le.fi/whateverhttp://www.google.fi/nReferer:%20http:/www.google.fi/whatever
 );

 and this results on the HTTP ===

 ORIGIN: http://www.google.fi
 Referer: http://www.google.fi/whatever


Definitely looks like a security risk, thank you for reporting it.


 If you find that it's a security issue, contact us at secur...@qt-project.org
 so we can deal with it.


Can we get a Security mailing list that uses the email address
provided above so as to keep the process more transparent? Qt's
response time to the CRIME vulnerability is/was pathetic (I am
partially to blame for that -- didn't report it thinking it would be
fixed upstream in SSL itself).

Or perhaps two security related lists: Security-discussion (for a
thread like this) and Security-announce (for confirmed vulns, perhaps
read-only to the public)?

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

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

[d3fault]

On Sun, Oct 7, 2012 at 10:00 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 For obvious reasons, the security list is not public and is not open for
 subscription from other people. If you feel you have a reason to be in the
 security mailing list, please mail us there and ask to be subscribed. We're
 looking for people who with the following skills:


What are those obvious reasons that trump transparency? Full
disclosure security is the best form of security.

You're talking about an official/internal 'team', whereas I'm talking
about a mailing list. The 'team' would be the only ones with write
access to Security-announce... but everyone should be encouraged to
contribute to Security-discussion. Everything should be done
transparently... else what is Open Governance but a marketing
buzz-word?

Note: discussions between the security team members should take place
entirely on Security-discussion (allowing anybody to join in)... up
until they confirm the vuln and post it on Security-announce.


 1) can provide advice in security-related matters, such as fixes to issues
 2) can get around Qt's source code (knows where to find things)
 3) can write code and unit tests, submit to the Qt repository


Can you add me then? I mostly just want to read it, but I might be
able to help somewhere.

^^See the problem here? Privileged information. Who knows what major
security holes are sitting in secur...@qt-project.org while the rest
of us sit around with our finger's crossed.


 As for the CRIME vulnerability, we had it fixed before the details were made
 public (by way of guessing what the issue was). The problem happened after the
 fix, in getting it published.

Yea some vague IRC discussions were happening between a few
developers, but it took a week+ before an announcement and patch
release was made. A post to Security-announce should have been made
immediately after it was confirmed (some would argue that the
announcement should wait until there's a fix, but I don't).

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

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

[d3fault]

On Mon, Oct 8, 2012 at 12:39 AM, Thiago Macieira
thiago.macie...@intel.com wrote:
 Full disclosure *after* we've analysed the bug and delivered a fix, if
 necessary.


Well I think we should change the policy then. Informing application
developers that their software might be (or definitely is) at risk is
CRUCIAL in applied security. Sometimes the best option is to shut down
operations until a fix is provided. By keeping the sploitz behind the
scenes, you're empowering those with access to the information and
giving the cold shoulder to the application developer.

It's not like CRIME was any big secret though. It's not so much of a
matter of disclosing the vulnerability so much as it is about
informing developers that their software is at risk.


Disclosing the details about an exploit before it's fixed is bad
 practice. That includes similar fixes delivered by others in other products,
 not just Qt.


Other products don't concern me, so I don't care if they keep their
users in the dark. Secure products (OpenBSD, OpenSSL, etc) do full
disclosure security, so should we.


 You trust the people who are there, you trust their credentials. We've got
 someone who does security analyses for a living.


Trust and Security are contradicting terms.
Also, my dog does security for a living. Think about it, that sentence
means nothing.


 We recognise we dropped the ball. So we're working to improve.


Me: Can I halp? Can we have a place to discuss security?
You: Nope dis is top secret yo

improve

d3fault

p.s. if I need to suck your d!c| for access to incoming security
vulns, this Open Governance project isn't really open at all.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: Qt Security Policy

[d3fault]

Oh right this is where I'm supposed to disagree or object or
something... See:
http://lists.qt-project.org/pipermail/development/2012-October/006892.html

tl;dr: I object on the grounds that behind closed doors security is
not only a waste of time, it also hurts Qt _users_.



Do This:
-CVE/CERT aka private/exclusive notifications go to some email address
that only core security team has access to:
security-priv...@qt-project.org or something
-secur...@qt-project.org becomes 'Security' mailing list, public
Read/Write. Only people interested in security read from or post to
this list. Questions, suggestions, etc
-security-annou...@qt-project.org/Security-announce mailing list
announces immediately on (a) vuln existence confirmation, (b) vuln fix
(a and b can be grouped together, but a should not wait for b).
Distributors and Qt _users_ alike subscribe to this list, but with
Read-Only access. Core security team has write access
-The regular Qt Announce list does just that: announces major, minor,
and patch (aka security) releases


That way, everybody can both help with and practice security. Security
benefits from more eyes.

With the behind closed doors method, only the special 10 elite full
time security analysis dogs (core security team) get to 'make
important decisions for you' (aka compromise your security) AND those
10 people now have the special ability to sell or exploit that
privileged information before a fix becomes available (a full week of
basically limitless server access, in the case of CRIME). I almost
became a special elite trusted dog analyst myself if only I would have
'kept up the good work' (read: done nothing) for a few more months.
That shows how incredibly easy it is for an adversary to gain access.
They don't even have to be a nice person.

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

Re: [Development] RFC: Qt Security Policy

[d3fault]

On Wed, Oct 10, 2012 at 2:34 AM, Ziller Eike eike.zil...@digia.com wrote:
 -CVE/CERT aka private/exclusive notifications go to some email address
 that only core security team has access to:
 security-priv...@qt-project.org or something

 in the proposal that is secur...@qt-project.org


Yes, but it is a private email address that only the core security
team has read access to. I am proposing we change that, and the
creation of the security-priv...@qt-project.org is to accommodate for
CVE/Cert requiring non-disclosure. I guess other people could send to
it too but I don't really care what goes on in there to be honest.

 -secur...@qt-project.org becomes 'Security' mailing list, public
 Read/Write. Only people interested in security read from or post to
 this list. Questions, suggestions, etc

 in the proposal that is development@ and/or interest@


Exactly, it isn't there. Security issues should be handled, or at the
very least categorized, differently from regular development/interest
discussion.

 -security-annou...@qt-project.org/Security-announce mailing list
 announces immediately on (a) vuln existence confirmation, (b) vuln fix
 (a and b can be grouped together, but a should not wait for b).
 Distributors and Qt _users_ alike subscribe to this list, but with
 Read-Only access. Core security team has write access

 in the proposal that is announce@


Eh not really nothing was mentioned about dispatching an email
immediately after a vuln is confirmed. And if you want to flood the
main Announce with boring (to most) security posts then go for it...
but I wouldn't.


Also what's with your post you basically just re-stated everything in
the original proposal with nothing new added. Are you trolling me or
...?

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

Re: [Development] RFC: Qt Security Policy

[d3fault]

Bump.

What's going on with this important issue?

-Am I being ignored (in which case, I should have used a pseudonym to
present my argument)?
-Has discussion halted because of a lack of consensus (in which case,
I present to you the following image: http://bayimg.com/eAEhDAaEE )?
-Am I being listened to (this is the optimal case for every situation
ever (ever))?

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

Re: [Development] RFC: Qt Security Policy

[d3fault]

Whoops that third one was a typo, should have read I am instead of Am I.
I am clearly not being listened to :-P (and I should have used a
pseudonym to trick your inferior brain(s)). You should not associate
an argument with the person presenting it (even though most do). It is
fallacious.

So can we please discuss security openly? Why is Qt using Open
Governance for some aspects and a closed old fashioned fail model for
another?

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

Re: [Development] RFC: Qt Security Policy

[d3fault]

On Fri, Oct 19, 2012 at 1:08 AM, André Somers an...@familiesomers.nl wrote:
You may not agree with the decision
 taken, but the grown-up thing to do is to accept that and move on.

Tell that to the Jews who were forced to go to the holocaust.

Please focus your energy on more productive ventures.

...so you're saying discussing/modifying/improving Qt's security
policies isn't productive? Interesting.


I find it hilarious that, despite me being the immature baby at times
(admittedly), everybody else (the 'mature grown-ups') attack my
persons instead of my arguments. I'm consistently surprised at how
illogical programmers can be (considering programming is logic...).


Welcome to Qt: The community where if you suggest something FIRST,
your opinions are written in stone and irreversible. If I would have
started this thread instead and offered up the suggestions, due to a
lack of disagreement I would have gotten consensus. Sounds pretty
stupid to me.

Anybody want to respond telling me why they think full disclosure is
worse than behind closed doors security? You know, instead of telling
me something I already know (that I'm a baby/immature/etc ).

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

[Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

I proposed it, therefore if nobody disagrees, I get consensus and the
decision goes into effect. I'll quote myself in an earlier post to
actually give this thread some substance:

On Thu, Oct 18, 2012 at 3:40 PM, d3fault d3faultdot...@gmail.com wrote:
 tl;dr:
 Open Project
 Closed Security

 The officially endorsed method for reporting security issues for Qt is
 to send them to secur...@qt-project.org , which is a private mailing
 list. I have a problem with that.

 Experience has shown that 'security through obscurity' does not work.
 Public disclosure allows for more rapid and better solutions to
 security problems ( http://www.debian.org/security/ ).

 Security information moves very fast in cracker circles. On the other
 hand, our experience is that coding and releasing of proper security
 fixes typically requires about an hour of work -- very fast fix
 turnaround is possible. Thus we think that full disclosure helps the
 people who really care about security (
 http://openbsd.org/security.html ).

 If the Qt Project does not intend on taking security issues seriously,
 then we should remove security related classes from the project
 (QSslSocket namely). Leaving them in is misleading.

 d3fault

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

Re: [Development] RFC: Qt Security Policy

[d3fault]

On Fri, Oct 19, 2012 at 8:27 AM, Oswald Buddenhagen
oswald.buddenha...@digia.com wrote:
 google responsible disclosure


No need, and that's hardly an argument. What if I said: google full
disclosure as my counter-argument?

So anyways I'll bite, even though we've already been over this.
Responsible disclosure is very similar to Full disclosure except that
there's a window of time where a variable size group of individuals
are sitting on the vulnerability information until a fix is delivered.
As I've said before, holding onto that information only extends the
window in which an exploit can be utilized. It has a vital flaw: it
requires you to trust other human beings. A group of them no less.

Security information moves very fast in cracker circles. (
http://openbsd.org/security.html )

You only need ONE weak/corrupt link in your group of trusted
analysts for the practice of Responsible Disclosure to now ACTIVELY
CAUSE HARM TO USERS who you are trying to protect.

Full disclosure allows everyone to analyze their own situation and
decide whether or not to bring their systems down (sometimes this
can't be helped) until a fix is available.

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

Re: [Development] RFC: Qt Security Policy

[d3fault]

Are you willing to put the security of your operations in the hands of
all the wives and children who might have access to their dad's
computer (he being a member of that trusted network of analysts)?
Humans can be bought/persuaded/compromised/etc with ease.

l2security

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

On Fri, Oct 19, 2012 at 9:48 AM, Alexis Menard ale...@webkit.org wrote:
 First you should let more than a day for people to answer.


Waited 11 days in the other thread...

 Secondly I disagree with your statement and using the same link
 (Debian) you sent let me quote something else :

 A: Once the security team receives a notification of an incident, one
 or more members review it and consider its impact on the stable
 release of Debian (i.e. if it's vulnerable or not). If our system is
 vulnerable, we work on a fix for the problem. The package maintainer
 is contacted as well, if they didn't contact the security team
 already. Finally, the fix is tested and new packages are prepared,
 which are then compiled on all stable architectures and uploaded
 afterwards. After all of that is done, an advisory is published. [1]


Weird that Debian contradicts themselves, but hardly relevant. Plenty
of projects use responsible disclosure... but that is NOT an argument
in favor of it. Lots of projects are also insecure, get it?

 Now let's say someone found a security flaw in Qt, report the attack
 vector and we blindly publish it with the fix not yet in work. What
 happen if somebody in the meantime make a proper with bad intention
 and spread it over? Millions of products run Qt. Then we don't have
 anything to provide to help our user it's too late. When we put the
 exploit public, there should already be a patch committed and
 announcement made so people can update their Qt before it gets too
 late.


Fix'd:

 Now let's say someone found a security flaw in Qt, report the attack
 vector and we sit on it for a week or two. What
 happen if somebody in the meantime leaks that vulnerability with bad intention
 and spread it over? Millions of products run Qt. Then we don't even
 give our users the option of shutting down their vulnerable systems
 until a fix can be delivered. They are sitting in the dark waiting for
 a fix to an exploit they don't even know exists (but the crackers certainly 
 do!)


 When we put the
 exploit public, there should already be a patch committed and
 announcement made so people can update their Qt before it gets too
 late.

That is an impossible requirement without extending the window in
which an vulnerability can be exploited.

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

Mathematical Truth:

It is better:
To be vulnerable and know it (so you can shut down your machine or
unplug dat ethernet cable).

Than:
To be vulnerable and not know it (especially when there's a growing
number of others that do).

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

On Fri, Oct 19, 2012 at 3:37 PM, Knoll Lars lars.kn...@digia.com wrote:
 This is just wrong, and I'm getting tired of your ramblings on this mailing 
 list. Just because you send something to the ML and people get tired of 
 answering you doesn't mean your proposal is accepted.


I was writing that tongue in cheek and mocking Thiago. Sarcasm  You.

 We have a fully worked out proposal by Rich on the table that many people 
 agreed with, and we'll stick with it for now.


His proposal is alright, with the exception of handling incoming
vulnerabilities. He didn't even discuss the subject, so what do you
even mean sticking with it?

 Lars

I'd expect more from you, being the Chief Maintainer of the project
and all. What a worthless post. You didn't even attempt to tackle my
argument.

Speaking of which, if ANYBODY can defeat it, I'll shut up here and now.



Ok noobs, you leave me no choice. Just like when someone doesn't
believe a specific vulnerability is legit, I guess I have to prove it
with an actual exploit. So I'll be ditching this alias and creating a
new one. Unlike the provingapoint12345 puppet, it will appear entirely
real (hurr I can use tor etc you morons (TAILs means any 5 year old
can)). I will stop being mean to people, and I'll even contribute
random bug fixes or other small contributions just to earn merit.
Thiago has already indicated that it's pretty easy for someone to join
Qt's security team. So after I get in, I'll be secretly publishing all
the reports to cracker circles around the globe.

Guess your only counter is to never let anybody else join the security
team. Good security policy you got there. Sholy Hit I'm surrounded by
retards.

Anonymous

...rejoice that I am leaving, but know that I am here in the shadows
watching you [mas7urba7e] from a distance...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

 http://users.ece.cmu.edu/~tdumitra/public_documents/bilge12_zero_day.pdf


Interesting article, but it tells us nothing. They merely talk about
Full vs. Responsible Disclosure, and they admit that it's an ongoing
debate. The overall conclusion after 12 pages in the article: the
disclosure of zero-day vulnerabilities causes a significant risk for
end-users, as the volume of attacks increases by up to 5 orders of
magnitude. Common sense lol, and zero day comes no matter what.

Responsible Disclosure is Security-Through-Obscurity, and
Security-Through-Obscurity DOES NOT WORK. You are pushing back zero
day and claiming it's a good thing. Not only do crackers who already
have the vulnerability get to use it for that much longer, but now
you're also widening the exposure (ever so slightly) of the
vulnerability. Now you not only have those 1 or 2 crackers to worry
about, but also every analyst in the closed security group, their
wives, their children, ALL the software they run on the machine in
which they analyze (all it takes is one bug), etc etc etc. There are
infinite ways for the information to be leaked unintentionally.

Scenario:
A vulnerability exists.
One cracker finds it and keeps it all to himself.
30 days later, one analyst finds it and reports it to this private
network of security analyst friends (a few thousand people perhaps?).
2 weeks later, the vulnerability is publicly disclosed and the fix is released.

The 2 weeks in which the thousands of trusted individuals have
access to the information is much more dangerous than the 30 days in
which one cracker has it all to himself. The solo cracker can only do
so much by himself (I'm certainly not claiming we shouldn't be afraid
of him, but that's a different discussion than Full vs. Responsible
Disclosure).

Rationale: During those two weeks, the likelihood that the information
escapes into the wild (into the underground cracker circles worldwide
where information flows like water) increases tremendously.

Check and mate,
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

On Oct 21, 2012 8:24 PM, Joseph Crowell joseph.w.crow...@gmail.com
wrote:
 You propose that since zero day happens no matter what, we conveniently
make a zero day site ourselves so that the script kiddies don't have to do
it themselves.


did you mean to respond only to me?

Which do you fear more?
-A script kiddie with access to the same information as you.
-A cracker with access to information that you don't have.

I fear the latter much more, and the current Qt Security Policy is actively
increasing the amount of individuals in that group.

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

Re: [Development] [Interest] Heavily Commented Example: Simple Single Frontend with Two Backends

[d3fault]

volatile bools work, but just know that every time you check it you are
doing a non-cached memory read (relatively slow). It can't read from the
cache/registers (much faster) because other threads/processes are allowed
to modify it at any time (and when they do, they don't/can't modify the
cached/in-register copy). I used to use volatile bools in a similar fashion
before I discovered Qt... but Qt provides much better ways for managing
threads.

If you only need to read from the serial port periodically, you can set
your backend up like I did for backend2 in the exampe... which also uses a
timer.

but if it ain't broke, don't fix it...

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

Re: [Development] Donation From Mrs Roseline Thompson

[d3fault]

On Oct 19, 2012 8:12 AM, Roseline Thompson roselinethom...@hotmail.com
wrote:
 I am not afraid of death hence I know where I am going.

After thoroughly analyzing your email, I have concluded that your argument
is not logical. Bish.

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

May I have a list of the core security team members who I am forced to
entrust the security of my operations unto, so that I may hire private
detectives to do background checks on them (and also sneak into their homes
while they're away to perform a security analysis on their machines)? Thanks

Also please tell me why I can't join the Qt Security Team without
contradicting yourselves. (You don't trust me?
Hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahah that's
exactly the point. Why should I trust you?)

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

 You haven't earned the trust of the people in charge.

 The current security team members have earned the trust of the people in
 charge.

 No contradictions there.

Why do they need to trust me?
Because the information is dangerous.

By admitting that the information is dangerous, they are admitting
that having + holding the information is dangerous (even for them!!!).

By holding onto the information, they are putting us all in danger.

Thus, contradiction.

Full Disclosure levels the playing field.
It gives a slight advantage to script kiddies, yes...
...but it gives us a [different] much larger advantage: Knowledge.

Knowledge is useful for shutting down to thwart ongoing zero day
attacks... and also the mere availability of the knowledge prevents
entirely the analyst leakage (or anal. leakage for short :-P) scenario
I've described countless times.

d3fault

Other:

The public disclosure increases the incentive for a fix to be
researched/discovered/published/audited(more eyes = less bugs), but
this argument is weak so I probably shouldn't even have mentioned it.

not to mention: the people in the security team are the people in
charge -_-. flawed logic is flawed.

You're like the priests in the early days hiding information (the
ability to read and write) and trying to convince us it's for our own
good. Time will tell who is right. su time; echo d3fault is right;
exit;
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

On 10/23/12, d3fault d3faultdot...@gmail.com wrote:
 You're like the priests in the early days hiding information (the
 ability to read and write) and trying to convince us it's for our own
 good. Time will tell who is right. su time; echo d3fault is right;
 exit;


That analogy fits better than I first realized.

Since the ability to read [books] allows malicious individuals to
make bombs, nobody should have the ability to read [books]. -Knars
Loll, Thiago Macieira, et al


Posts are forever, not just Christmas
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

On 10/23/12, Donald Carr sirsp...@gmail.com wrote:
 life is clearly not a popularity contest for d3fault.

rofl thank you for that compliment. better than Charley telling me I'm
smart repeatedly -_-



I agree completely!!! It's just that the
recommended/officially-endorsed way of reporting security
vulnerabilities is to the private mailing list.
secur...@qt-project.org should be official/public,
security-priv...@qt-project.org should be OFFERED, but not the
'official' way. The analyst who discovers the vuln can choose whatever
he wants. He can even sell it to crackers... lol.

qt-project.org/security/index.html should read something like this:


If you discover a vulnerability, please report it to
secur...@qt-project.org and we'll take care of the rest. You can of
course join in on the discussion and suggest fixes etc, as Qt is a
COLLABORATIVE PROJECT.

If you think the vulnerability would cause harm being publicly
disclosed, you can instead send it to security-priv...@qt-project.org
--- but remember... just who are those people with access to that
list, and can you trust them to not un/intentionally leak your
vulnerability?



Emphasis added.

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

On 10/23/12, Lincoln Ramsay a1291...@gmail.com wrote:
 We're not renaming things or creating new lists just to match the
 names you think we should have.


*sigh*, I had a feeling someone would say something like that.

The changes are trivial at a glance, yes
...but what the Qt Project officially endorses/recommends is the real
change here.

Right now, the Qt Project instructs analysts use
security-through-obscurity when reporting vulnerabilities.

If you find [...] a security issue, contact us at security at qt-project.org
so we can deal with it (
http://lists.qt-project.org/pipermail/development/2012-October/006893.html
).

You could change that /security/index.html suggestion to recommend the
development list for public and keep security@ for the private list,
that makes no difference. Semantics. As an aside, I think it would be
better for security to go in it's own list... but that's just an
organizational decision.

List names are not very important at all, whereas the policy on where
to report vulns is extremely important.

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

/noise is higher with public (v. closed):  As
an administrator/user, announcement of a security issue without a fix
is likely not-actionable, or the shut-my-stuff-down action is a
costly over-response.  I must await a second announcement, and the
first announcement is noise to which I cannot respond, but against
which I am now liable (e.g., you've added to my noise, and to my
liability, without a benefit).


A Benefit: Knowledge of the vulnerability's existence, giving you the
ability to protect yourself by shutting down. You think protecting
your + your users' data is an over response? Fine, but I'm glad we
don't work together. Konrad said something similar to me a while ago:
remind me to never use your software :-P.

If you only want to be notified when there's a fix available
(ignorance = bliss), then subscribe to the main ANNOUNCE list only...
simple. Don't force the rest of us to be in the dark with you.

 ...
(a3) and (a4) are basically the same, and actually make me think
you're a [expert] troll in disguise (at least I don't hide it). But
there's a simple counter to it anyways: more eyes on the code/vuln
means that a fix will be found faster than a small group of
individuals, in addition to possibly finding a bug in a fix that a
small group of individuals might miss. This is your strongest
argument, but it's still very weak. Ignoring noise is easy. Just look
at how well others do in ignoring me.


However, I concede that the issue is whether-or-not my four points are
pragmatically compelling in contrast with your-four-points (i.e.,
your discrete lists of benefits for open v. closed).


Hey, we agree on something yayyy. Copy - Paste [for my own arguments]...







ALSO, I want to correct what I said in previously. I do think the
naming is rather important (though still nowhere near as important as
the policy itself). Having public = development@  private =
security@ will end up being misleading. People will think the
only/official way is through security@ ... which is the private one if
we don't change the names -_-


Definitely not giving up as easily as QML. QML is aesthetics and a
problem I can solve myself. Security policy is much more important and
there's nothing I can do but try to convince those in charge to change
it.

Getting tired of repeating myself, but also getting tired of hearing
the same non-argument,
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

tl;dr:

 d3fault if you keep up the good work you can join the security team

 the security team is for trustworthy individuals

 d3fault, we don't trust you


How is my keeping up the good work earning trust? Do you guys really
not see the gaping hole in that logic?

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

Please disregard Zeno's personal attacks towards me and his request that
the subject die and we all move on. His type of email is exactly what I
describe two emails back. Waste (so is this one, except to keep the subject
alive).

If you can't say something relevant [to the argument], don't say nothin'
at all. -Thumper

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

On 10/24/12, Samuel Rødal samuel.ro...@digia.com wrote:

 As far as I see it all the options have vulnerabilities, so it shouldn't
 be hard to prove that they exist within either approach.


Yep. Close one giant security-through-obscurity vulnerability, open
the door for script kiddies. It's a trade off, but at least we won't
have the ILLUSION OF SECURITY (worse than being insecure) anymore.


 If I get you correctly, you're saying that you want two security mailing
 lists, one open and one closed. Others have countered this by saying
 that the existing development mailing list will in practice act as the
 open one. In what way do you perceive these two options as being
 radically different?


Knowledge availability, which I value and I guess others do not?

m_ListOfUsersCommentingWithoutFirstReading  Samuel;

See: http://lists.qt-project.org/pipermail/development/2012-October/007478.html

Duuude, you responded directly to that email too. How the what the I don't even

Are you trolling me?

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

Re: [Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)

[d3fault]

 be generous and say that 3% of the community is able to act on the
fully-disclosed security information before a fix or workaround is published.
That means 97% is still vulnerable, and we've just enabled low-resource
attackers to attack.


You're being too generous. Most people don't take security seriously.
It's probably more like 1%. Those 1% that do take security seriously
should not suffer [greatly] because the other 99% are not practicing
security.

I think all 100% of them know how to shut down. Just because they
choose not to doesn't mean we should hide the vulnerability so the 99%
can stay online (still vulnerable). Let them suffer. Don't make those
of us who care about security suffer.

By hiding the information, you aren't giving us (1%) the opportunity
to shutdown.



 - a high signal/noise ratio on the disclosures, which should cause people to
   pay more attention


I would rather it be noisy during the period where a fix is unknown.
Let the collaborative nature of the internet take hold and ideas for a
fix can surface a lot faster and travel through a lot more brains,
which also decreases the chances of accidentally introducing another
vulnerability in the fix.

It's also an argument in favor of moving security discussion to it's
own list. Things can get pretty hairy at times.

Let the _user_ choose what signal/noise ratio they want to receive by
what lists they subscribe to. Only want the fixes? Subscribe to the
main ANNOUNCE only. Ignorance is bliss (no it isn't).

This is why I think we need Security (discussion) and
Security-ANNOUNCE (vuln discovery, fix release (fix release is also on
main ANNOUNCE)). The Security-ANNOUNCE will have that high
signal/noise ratio you speak of, so it is the list that those who
can't comprehend a vulnerability should subscribe to. Oh, I'm
vulnerable. Time to shut down. variable amount of time passes. Yay a
fix, I can bring my systems back online. 100% signal, no noise.





What is wrong with my qt-project.org/security/index.html proposal that
accommodates for both Full and Responsible Disclosure? It gives the
analyst that discovers the vulnerability the choice of what to do with
it. I think the default should be Full Disclosure, and the analyst
should have to opt-in to Responsible Disclosure. We almost already
have that (this list is for public discussion), but Full Disclosure is
not the default/endorsed/recommended way to report vulnerabilities.
Not even the script kiddies argument stands up against that. If the
analyst decides the information will do more harm than good (script
kiddies), he can choose to disclose it privately (Note: he can also
sell it to crackers :-P. The point I'm making here is that the analyst
can do whatever he wants with it... ***but most of them are just going
to do whatever the project suggests***. This project currently
suggests private disclosure :-(. Do you remember what sparked this
discussion weeks ago? That one guy asked what to do with security
vulnerabilities and you told him to send them to
secur...@qt-project.org. He would have done whatever you said).


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

Re: [Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)

[d3fault]

this group WILL be hacked

Nah. WILL is too strong a statement. More like: very very very very likely ;-)

Besides, this argument does not counter mine. I am asserting that the number
of attackers who get access to the exploits before they become public is much,
much smaller than the number of attackers who would be aware of the
information if we disclosed immediately.

The number isn't very relevant because they are crackers instead of
script kiddies. The number of crackers is also a question mark. You
simply cannot know how many crackers have gained access to the
information. It's better to know that everyone knows than to think*
you and your peers are the only ones who know (and to keep the rest of
us in the dark). You do not have to fear the script kiddies a single
bit if you are armed with the same information as them (because you
shut down).

* = erroneously


It's about deciding which of two evils is the lesser one.

EXACTLY.
-A few crackers armed with knowledge you don't have
-A ton of script kiddies with knowledge you also have

The lesser of two evils is the latter.

BECAUSE *copies from above*:
You do not have to fear the script kiddies a single bit if you are
armed with the same information as them (because you shut down).


you know already where the highest deciders in the Qt Project stand.

If I can convince you then you might be able to convince him. Since,
you know, he actually respects you and all (brought that upon myself
xD).


I'm talking about disclosing details like possible buffer overflow in 
filename
line number. That is, the input discussion of is there a security problem
in the first place?

We should handle it like OpenBSD, erring on the side of caution. If
it's definitely a buffer overflow, it should be fixed. The QML people
don't have to pay attention to the Security discussions and can
continue being oblivious (note: if you are oblivious, you are not
secure).

During our ongoing auditing process we find many bugs, and endeavor
to fix them even though exploitability is not proven. We fix the bug,
and we move on to find other bugs to fix. We have fixed many simple
and obvious careless programming errors in code and only months later
discovered that the problems were in fact exploitable. (Or, more
likely someone on BUGTRAQ would report that other operating systems
were vulnerable to a `newly discovered problem', and then it would be
discovered that OpenBSD had been fixed in a previous release) (
http://openbsd.org/security.html ).

I would like Qt to be ahead of the game like OpenBSD is. I'd even like
to see a minimal/hardened version of Qt where code must first pass
extensive auditing. I would happily contribute to that process as it
serves me directly.


No, it's completely unrealistic to assume most people will be able to handle
those details. They will be able to handle here's a patch, please apply it
and recompile Qt or if you're using this feature, please add this line to
your source code.

Similarly, they could handle You are vulnerable. You should shut down
to protect yourself and Here's a fix, apply it like this and you
should be ok to bring yourself back online.


Therefore, we need to cope with people who are not competent in everything.

Yes, but we should not simultaneously force those who are competent to suffer.


We can only accept people there once we're reasonably sure that the person 
isn't
trying to do exactly what you indicated: hack our systems to get access to
information that isn't public.

They wouldn't have to hack their way in if you gave them access.
You've already shown that it's relatively easy for someone to join the
security team.


If this is your world view, here's a suggestion for you, which should
immensely increase the security of your systems:
Turn them all off. Now. Do not turn them back on.

lol. We cannot attain perfection, but we should still strive for it.
Yes having your systems online is a risk... and so is going outside.
But if you ***KNOW*** there's a man with a gun standing outside your
door, you aren't going to go outside. The same is true for knowing of
a vulnerability's existence: don't go online until you know it's been
dealt with.


Moreover, we're adding new code every day and some of it could
contain issues.

See above about a hardened Qt. Moving to Full Disclosure would be a
first step towards that.


And a decision has been made, reached by consensus.

Leftover corporate policy and a bunch of opinions and other
non-arguments. Honestly, this discussion we're having right now has
been the only productive one.


But you have not convinced anyone to change their minds.

Yet!


We're all a smarter today because we've learned something.

Woot, progress. Now I know I shouldn't give up!


...especially since my livelihood depends on it.


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

Re: [Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)

[d3fault]

Meh, sorry for the noise. That analogy sucks actually. Knowledge of
the serial killer rapist on a limited basis (a la private disclosure)
does not empower others (script kiddies)... so the analogy fails. The
point about not going outside when a killer is *KNOWN* to be right out
your door is still valid, however.

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

Re: [Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)

[d3fault]

On 10/26/12, Oswald Buddenhagen oswald.buddenha...@digia.com wrote:
 this is exactly where you are simply wrong.
 for the vast majority of users, downtime is a way more costly problem
 than an information leak.


True. Those people fall into the 99% category of people not practicing
security. For the 1% of us that do, an information leak is worse than
downtime.



 also, we are talking about qt here. no sane person would use qt in the
 trusted parts of a (seriously) security-sensitive system.


So are you suggesting we remove the QSsl namespace from Qt then? You
can't have it both ways.


 so, can we now *please* put the matter to rest?

No.


I am anticipating Thiago's well formed/thought-out response [to my
email 3 posts back] :-).


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

Re: [Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)

[d3fault]

On 10/26/12, Konstantin Tokarev annu...@yandex.ru wrote:

 Use of QSsl just allows your application to use SSL, but by no means makes
 it
 secure or trusted.


*blinks*

SSL = SECURE Socket Layer

You soft tossed me that one (or perhaps a expert troll agen).

...but you're half right: using QSsl does not mean the rest of your
application is secure.



On 10/26/12, Thiago Macieira thiago.macie...@intel.com wrote:
 You're wrong here.

 The new security policy was reached by consensus by posting the new details
 to
 this mailing list and opening up for discussion. Aside from you, no one
 objected strongly to the choice of Responsible Disclosure.

 That's consensus.


Link? You're not referring to my previous proposal are you? Also: we
can still change it.




Is that it? This was just getting interesting. How anti-climactic.


What about:

EXACTLY.
-A few crackers armed with knowledge you don't have
-A ton of script kiddies with knowledge you also have

The lesser of two evils is the latter.

BECAUSE *copies from above*:
You do not have to fear the script kiddies a single bit if you are
armed with the same information as them (because you shut down).

That's a strong argument.


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

Re: [Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)

[d3fault]

 indicators do not feel grief
tank. Back to Top indicators but feel good, stop, my various. Learn More
bow, not comprehensive, they set up at the course of the Business.
Business investment, but now
start time, and now here's a bow, and more hate Information
no deductible. We want a cat. In and of itself: * Password: mourning, but
free. Cheap arc pain, various arrows emissions but that orange
consumer. Learn More Visit. Twice in as Admin
courses and in the control tank. Our customers, and the temperature development
Next, is the only company online, who's always planning tour
cat. We bow before, or investment element to decorate the porch is
not available.

Arrows platform soft heart disease and the official website. More and more ugly
more complicated story. Tomorrow, and my bed. Comments Policy
employee for that afternoon on the free products. Copyright
More More More More members. Phone and
evenpages, a ridiculous mouse will be born. But the story is.
But but the main pain. Back to Top urn and the lake, and of life nor
the bottom of the column.
This page is required to post a comment. in
sauce, a platform that afternoon, she wants to lump it,
Life's a temperature or temperature. Each life cat food
mass time content is summarized here. Learn More at the bow.
Integer feasible pure but it's an EU company undertakes.
See for yourself here, here and on the fringe, just needs tank.

.this paragraph came out of google translate the exact same
(untranslated).

.ditto.

Our vehicles are always online. That system, the alarm goes
Pregnant, please pot More pain, requiring the author's bow and
now. We IPhone a versatile layer that but, quotes
free. We now orci, and it has been said in the porch, the element does not
great. Now and not feasible. For today's Bureau,
automated gate cat sometimes porch. Product life base
Change takes time. News Contact Us or
Options. Learn more about protein bed hotel. For more
To become a great hotel, but an emotional level.

Product development, provide any Event, please pain sometimes
survey, but the consumer's job, and a lion. Welcome to itself, and
They cried out, but it was said
now. Each pump adapter and cats who follow some skirmish
development. No drilling and pumping at work. Welcome Back,
China bow life immigration, consumer convenience base adapter, but the tank
impact mass base jaws. Even more, a large ferry visitors
on Monday, unless before immigration fears, but I know the pain of the
skies the pain.
Some annoyance's hit real estate development. We want
Our job and price. Until they start region this post.

* Denotes required field and evenpages, shall be born
Perl. For More Information About My Defaults. Add comment
pure, is China's largest and Information, to raise up, nor to hate. Read
Rights nor comprehensive, but it does not ensure great mourning. To the great
that they may adorn or feasible, of the crime nor to compare. No
deductible, hatred
More and more, the price of freedom in my tank, or immigration is OK
But lion. But OK hotel but more pollutants or more requirements
divers. That's impact here. Please grab an impact
More drinking. Search no more. Recent clinical nor
drilling. As planning and construction. Our clinical indicators,
shovel the versatile,
designers need to comment. But it is not the torturer has been said
nibh not be published viverra.








And here's some gems... most likely the result of Google Translate
butchering everything:


Welcome to a new experience of life here.

Well thank you kind sir 3... but what was the old experience?

a ridiculous mouse will be born

We certainly wouldn't want that now would we

Add to prefix meaning half, for, in the course of the time, to, Information 
that is.

Couldn't agree more!

But your life from time to catch pregnancy

See this is where your argument falls apart. I'm male

Free time, no Section at the fringe, ugly or just annoying, but it was set up 
job free life.

I *think* this is you calling me a spoiled American? uJelly?

Each soft pump nearby

Sounds hot.

We want a cat

k

But the story is.

An irrefutable fact.

Search no more

I actually spent a great many years (relative to the length of my
life) searching for that perfect  programming environment... and Qt is
(almost ;-P) it. So I will search no more...

I think the above pretty much invalidates all your arguments.

You may very well be right. I'll probably never know...

Now, to put it politely, frack off.

lol 3. I have thicker skin than the project's leaders
How did you get around the filter zomgh4x?



Or, put more delicately, Catullus, carmen 16, verse 1.
ROFL: http://en.wikipedia.org/wiki/Catullus_16#Prose_translation


Catullus incarnate,
d3fault

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

Re: [Development] Common base class for all socket types

[d3fault]

+1

It's now or never (well... 6... so like 2020 lol?)

A 'server' that can listen to clients that are both:
a) other processes on the same machine
b) other machines on the network
at the same time by working with a common abstract base type would be
very handy.



Unifying the connectTo* methods is the biggest concern. QLocalSocket
does not have a port. Unifying the localSocketName + hostName is easy
though.


Here's the design that keeps being mentioned:

class QAbstractSocket;
class QLocalSocket : QAbstractSocket;
class QAbstractNetworkSocket : QAbstractSocket;
class QTcpSocket : QAbstractNetworkSocket
class QUdpSocket : QAbstractNetworkSocket

^^^EDIT: renamed most of these below

A question mark in my brain is whether or not QLocalSocket should
derive from a QAbstractLocalSocket. Surely there are multiple ways to
do a local socket (hypothetically: an ugly wrapper around
QSharedMemory :-P (or you could also just specify which to use as a
constructor parameter in QLocalSocket too but OH WAIT THAT'S
EXACTLY WHY the current QAbstractSocket design fails. I say it's
better to have and to not need [...])).

So screw it, +1 on QAbstractLocalSocket (derives from QAbstractSocket
ofc) type too. We can't predict the future, as is evident by the
discussion we are having.


...perhaps we should take the word 'socket' out of the impl of
QLocalSocket, since a named pipe isn't one.

how about:
class QLocalFifo : QAbstractLocalSocket : QAbstractSocket;

idk what the perfect name for that would be. QLocalPipe (but the unix
variants really are sockets!)? QLocalDataChannel as mentioned in the
page OP links to (this would now imply QAbstractDataChannel as the
common base)?


re-design + rename:
class QAbstractDataChannel;
class QAbstractLocalDataChannel : QAbstractDataChannel;
class QAbstractNetworkDataChannel : QAbstractDataChannel;
class QNamedPipeOrLocalSocket : QAbstractLocalDataChannel; //this name sucks.
class QTcpSocket : QAbstractNetworkDataChannel;
class QUdpSocket : QAbstractNetworkDataChannel;

and just to demonstrate the 'hypothetical' purpose of
QAbstractLocalDataChannel---
class QSharedMemoryDataChannel : QAbstractLocalDataChannel;
^^I'm not saying we actually implement that (but we could), just that
we cannot predict what the future will hold.


As an aside, while I'm on the subject: Which is faster? QSharedMemory
or QLocalSocket?


d3fault
unprecedented precedence preceding price
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Common base class for all socket types

[d3fault]

a common base class is an interesting idea. But it’s a moot point
since we have to maintain binary compatibility until Qt 5. So
QAbstractSocket cannot change. We’ll revisit the issue when Qt 5
development starts, but that’s a long way in the future. (
http://blog.qt.digia.com/blog/2008/02/22/qlocalserver-qlocalsocket/#comment-1820
)

It won't happen for Qt 5. It's way too late for that. (
http://lists.qt-project.org/pipermail/development/2012-November/007746.html
)

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

Re: [Development] Common base class for all socket types

[d3fault]

On 11/6/12, Corentin Jabot corentin.ja...@gmail.com wrote:

 I dont see how the connectTo* methods could be shared, and I don't
 think it would be a good idea to try to do so.


I disagree. Having a QListQAbsrtactSocket* and then being able to
iterate over them and connectTo* and disconnectFrom* without knowing
their type is helpful. You (_developer_) can't know the duration of
each connection (_user_) either so we could move the traditional
connectTo parameters into a new constructor and expose them as
properties as well. Then QAbstractSocket::connectToHost() would have
no arguments, and we can provide a helper/source-compatible overload
QTcpSocket::connectToHost(host, port) while we're at it. The base type
constructor has no arguments and calling the empty connectToHost
before setting up the properties will just return false.

(I'm conveniently ignoring QObject *parent and Read/ReadWrite args as
they aren't relevant)


Iterating over a list of connections like this is already possible,
but as stated requires glue code and ugly hacky design. This thread is
just about a cleanup. Since no new code is introduced, there's a very
low chance of introducing bugs and it's worth breaking the randomly
declared (in May!) feature freeze.



Additionally, hostName() is shared in the obvious way and we
can/should introduce a url() or some such that would, for example,
append the port after a colon (in relevant subclasses). I guess this
would also imply being able to pass in that url (to yet another
constructor in each subclass) as an alternative to specifying the
host/port as separate args.


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

Re: [Development] Common base class for all socket types

[d3fault]

On 11/8/12, Corentin Jabot corentin.ja...@gmail.com wrote:
 so one could do
 QLocalSocket socket(foo_pipe);  // or QTcpSocket(localhost, 42)
 socket.open();
 ...
 socket.close();


I agree that the actual connectToHost() impl should live in open() so
we can control it additionally using a QListQIODevice*, but I think
we should keep connectToHost() around to keep the API intuitive. It
will seem confusing from a _user_ perspective to call open() and then
waitForConnected(). Same with
disconnectFromHost/close/waitForDisconnected.


Extra reading:
QIODevice vs. QAbstractSocket
A QIODevice is generally only alive/active in between the calls to
open/close (there are exceptions)... and typically only allows one
'client' to IO to the device or else you'll [possibly/probably] face
syncrhonization issues. Constrast this with QAbstractSocket, where the
'service' is alive before and after calls to open/close
(connect/disconnect)... and it can/does handle multiple 'clients'
regularly. Again, to restate: you CAN communicate with a 'server'
(usually referred to as a daemon when used like this) through a
process/file (iodevices), but this is generally not the case.

Making QLocalSocket inherit from QAbstractSocket gives the _user_ a
simple and intuitive way to have a server that can communicate with
local peers (different thread (different process on same machine) and
remote peers (LAN, WAN) using the same client/server implementation.
The clients and servers don't need to care where their peers live. The
current design (making you utilize QIODevice as the base class) means
the client implementation has to know what kind of socket it is
communicating over (glue code, see:
http://lists.qt-project.org/pipermail/development/2012-November/007769.html
), you cannot simply call open() (or connectToHost()) and not worry
about it. Separation of concerns.

Current QIODevice base: client impl can't cleanly/easily
connect/disconnect at will (it has to know the sub type)
Revised QAbstractDevice base: client impl can't cleanly/easily
INSTANTIATE (done once) at will, but CAN connect/disconnect (as many
times as he wants) at will without knowing the socket type


Pretty sure my subconscious came up with all this while I was sleeping,
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branching 5.0

[d3fault]

always close to releasable = testing

-dev
-testing
-release or stable

eradicates any chance of confusion, regardless of who is right


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

Re: [Development] Android port - Why do we need Ministro?

[d3fault]

Random idea: can't we use Android's Services API to do a
QtLibrariesFolderPathRequest, and only the first Android-Qt
application (with the 'Ministro-built-in', building on OP's idea) that
gets an empty/null string from the service request goes on to download
the libraries to it's local folder and then from then on that
application sets up a service to provide the
QtLibrariesFolderPathRequest to all future Android-Qt applications
that are installed?

Downside: uninstalling your *first* Android-Qt application will result
in deletion of the Qt libs, so running of the 2nd through N downloaded
Android-Qt applications will re-download them and will do the service
responding from then on.
^^^this con does suck (waste of bandwidth), but the con of install
ministro + re-launch app sucks more (for end users (retards) at
least)



Elaboration:

1) Download Qt-Android App
2) Launch it
3) Ministro/Java-stub (the same piece that currently redirects to
Ministro in Google Play) does a QtLibrariesFolderPathRequest
3a) If it gets an empty/null string, it downloads the libraries to
it's local/writeable directory
3b) Sets up a service provider for QtLibrariesFolderPathRequest
pointing to it's local dir
4) It and all future Qt-Android applications can now find the
libraries through the service call




Lastly, we use random folder names (or at least make sure they aren't
in use) and probably even Qt version API specifications as arguments
in the Android API Service call.


d3fault



Slightly OT but not worth another email: Re: Proposal: Adding a
repository in Qt Project for the Ministro tool, needed by Qt for
Android .. I think if Ministro is NOT seen by the users (as
described by OP and myself here), then it can remain named Ministro
because who cares. BUT if it is seen by the users (they are redirected
to it in Google Play), we should definitely rename it to something
more 'utilitarian' such as Qt Library Downloader/Qt Library
Installer (etc). Also, it's much easier to change the name now
(especially since it barely matters (in-after bike shedding)) than to
change it later.

Lazlo said:
Perhaps simply just to the point: Dependency Installer/Store?
^^The problem with dependency installer is that it now implies
dependencies for Qt [installer] to anyone trying to build Qt from
source etc. Not a HUGE problem, but definitely worth thinking about.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Android port - Why do we need Ministro?

[d3fault]

Sorry for double post, but I thought up a solution to the wasted
bandwidth con (by using the SD card as a download cache). Bleh.

Basically on null/empty folder path we then proceed to check some SD
card download cache to copy the libs to the local dir and set up the
service provider. If they aren't on the SD card in some agreed upon
location, they are downloaded as usual (and then copied to the SD card
in case that specific app is uninstalled).


Now the only con is the wasted space on the SD card (who cares).


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

[Development] Full Ministro in Ministro-Redirection stub; WAS: Android port - Why do we need Ministro?

[d3fault]

##Bringing this to development mailing list

 - Original Message -
 From: d3fault d3faultdot...@gmail.com
 To: bog_dan...@yahoo.com
 Cc:
 Sent: Wednesday, January 16, 2013 7:53 AM
 Subject: Full Ministro in Ministro-Redirection stub

 Hi, sorry to bother you as I'm sure you're busy working on Android Qt,
 but I'm wondering if maybe you didn't see my post here:
 http://lists.qt-project.org/pipermail/development/2013-January/009249.html
 on the topic of [Development] Android port - Why do we need
 Ministro?. I understand the technical problem of no common shared
 folder that Ministro solves and I'm wondering if there's a problem
 with the design in my link (solves the same problem) that I'm just
 failing to see? I like what Ministro does but I think making the
 experience as seamless as possible (aka, they don't ever see or
 explicitly install Ministro) would be the best solution for the end
 users.

 Also be sure to click to the next email in the thread for the DUH
 solution to the bandwidth problem.

 I am aware of the 2 new cons introduced by my design: each/every Qt
 Android application now requires access to the SD-Card and the Network
 (security risks), but I think they're worth it in the end because
 Android is not a secure OS to begin with, as it includes proprietary
 and closed source binaries (I'm willing to bet our views on security
 differ).


 Thank you for all of your contributions to Necessitas/Ministro/Qt,
 d3fault


On Wed, Jan 16, 2013 at 10:52 AM, BogDan bog_dan...@yahoo.com wrote:
 Hi,

 Your solution sound similar with this
 https://groups.google.com/group/android-qt/browse_thread/thread/708d0be52dd4af92
  one.

 Please check that thread for my answer.

 Cheers,
 BogDan.


Hmm, you're right, the design is flawed.

I've been letting the problem soak in my subconscious for the past
week or so and came up with a solution that I'm not sure you'll like.


Basically it's a compromise between:
a) Not trusting other applications to supply and/or not change the
libraries (because as you pointed out, md5 summing for integrity and
loading of libraries is not an atomic process)
b) Not caring about security because Android is already insecure
(proprietary binaries): as long as it is *FUNCTIONAL*, security can be
assumed to already be compromised so who really cares as long as it
works

Here's a solution that implements the compromise:
tl;dr: 2 Activities in the manifest. One for
'idgaf'/insecure/FUNCTIONAL usage, and one for
forced-loading-of-local/verified-and-non-outside-writeable-libraries/safer
usage


In Launcher:

1-ActivityRegular: Checks local dir for libs, broadcasts for libs
path (uses them if found), downloads libs if necessary, caches them on
SD card, md5sums local copy that is actually loaded

2-ActivityForcedSafer: Checks local dir for libs, DOES NOT BROADCAST
FOR LIBS PATH, downloads libs if necessary (or pulls from SD card
cache), caches them on SD card if relevant, md5sums local copy that is
actually loaded



Pros: Completely transparent/seamless to end users (the biggest pro of
them all), still provides 'moderate' security for those who actually
trust proprietary binaries (ROFLMFAO)

Cons: A pretty hefty amount of wasted disk space for every app that is
run even once in 'safer' mode (it would be possible/easy to run out of
space by running them all in Safer mode), cluttering of Launcher menu
(two entries for every one activity), all Qt-Android apps would need
Internet and SD Card Permissions


Even though the first con is a pretty big one, I think it's worth it
in order to provide a seamless Qt-Android user experience. I myself
will launch every app in 1-ActivityRegular mode, so the first con will
be invisible to me. I think most users will too because Android is not
a secure OS to begin with. Be that as it may, we should still provide
an as secure as Ministro [currently] mode of operation for those who
want it.

Additionally, knowledge of the underlying system/design allows you to
choose which Qt-Android application will be the one in charge
('trusted', just as Ministro needs to be trusted) of supplying the
libs: whichever one you install first.


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

Re: [Development] Evolving Qt's multithreading API

[d3fault]

On Sun, Mar 3, 2013 at 10:15 AM, Sze Howe Koh szehowe@gmail.com wrote:
 On 27 February 2013 15:38, Laszlo Papp lp...@kde.org wrote:

 On Wed, Feb 27, 2013 at 1:13 AM, Joseph Crowell joseph.w.crow...@gmail.com 
 wrote:

 I have threads that live for the full life of my application but telling
 them to stop on application shut down is painful.


 What a coincidence. I have just had the same scenario. :-)

 How did you guys solve this issue? Do you need different cleanup code
 for the cancelled halfway case and the finished naturally case?


That depends too much on your specific design to be able to be
answered. If your slots can schedule more slots (for example), then
they might receive a quit message in between two slots that depend on
each other and the thread could be brought down halfway because the
second slot is never entered... and maybe some relevant data corrupted
(in that case, you would have to use flagging to cleanly shutdown,
which isn't too difficult but turns your code into a spaghetti of
paths).

I wrote a clean threading example for my own reference a while ago.
Took quite a bit of reading the documentation, but once you know what
you're doing (a lot of which depends on proper design of your backend
thread/object), it's not too hard to tell them to stop at application
shutdown. Here's that example demonstrating clean shutdown:
http://lists.qt-project.org/pipermail/interest/attachments/20121026/60482ba0/attachment.zip

In that project I was also working on my own evolution of the
threading API but eventually gave up after I deemed fighting qmake/moc
to be a waste of time. Was pretty close to getting QThread to be able
to target a Functor with some args etc like has been mentioned in this
thread. That's what Qt's threading solution is really missing.


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

Re: [Development] Urgent gerrit change for 5.1: closing the Qt Quick feature gap on the desktop

[d3fault]

This completely justifies forcing the _user_ to depend on and deploy v8
(barf) and a QML interpreter/compiler (twitch).

I was thinking about doing my own April fools by ANNOUNCE'ing the removal
of Qt Widgets and the change of Qt's overall direction to a JavaScript
programming environment, the latter of which isn't even a joke.


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

Re: [Development] Qt5 combined source package - Perl dependency

[d3fault]

Paddles!

On Mon, Apr 29, 2013 at 11:25 AM, Thiago Macieira
thiago.macie...@intel.com wrote:
 A determined hacker could infiltrate Digia's network and tamper with their
 email server. When an email is received for secur...@qt-project.org, it could
 then forward the vuln to the hacker's own email address. This way, the
 privately disclosed vulns are now publically disclosed only amongst hacker
 circles, which means all of the _users_ of Qt binaries are left in the dark,
 as well as for people building from sources (including Linux distributions).


 Is this far-fetched? Maybe, but that's not the point. The point is: why do we
 want to leave an attack vector open, if we can close it?

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


+1 that's some sound logic right there. Why leave an attack vector open?


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

Re: [Development] Why waste energy supporting Python?

[d3fault]

On 4/25/18, Konstantin Tokarev  wrote:
> 1. C++ is not modern, not safe, and by far not simple language
> (despite having a lot of strengths in different areas)
>

https://www.youtube.com/watch?v=hEx5DNLWGgA
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Are there plans to decouple QML from JavaScript?

[d3fault]

Now that QML can be precompiled and has a software renderer, I see it
as *almost* usable. One final piece missing to get me on board:
decouple qml from js.

to re-state old arguments:
-I already have all of C/C++ at my disposal, JS buys me nothing
-If I don't use it, I shouldn't have to pay for it

>From a C++ perspective, Bindings are really the only interesting
feature that JS brings, but those don't require JS! JS was just a
lazy/quick/hacky/EXPENSIVE way to get Bindings in QML. A much better
approach would be to parse the Bindings using libclang [0] and
generate regular Qt/C++ code to support the bindings [1]. That being
said, I don't even need bindings and am perfectly content using
signals/slots to update the GUI.

What if there was a per-project config, say "QML_NoJS", that when
enabled, causes compilation to error out if there is any JS detected?
Qt Lite project would additionally need to support compiling QML
without JS, but that's obvious.


d3fault

[0] - https://llvm.org/docs/tutorial/OCamlLangImpl1.html
[1] - https://forum.qt.io/topic/16009/does-qt-need-a-modern-c-gui-api/132?page=4
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Why waste energy supporting Python?

[d3fault]

Supporting Python first class dilutes Qt, please don't. What's next,
Qt for Java? It's one thing to collect community-developed bindings
for various other languages into a single place... but something else
entirely to pay an entire "team" of developers to work on what is
essentially duplicated effort. That money could instead be spent on
new Qt features and/or fixing the ever growing list of bugs
(supporting Python first class will only add to that list of bugs).
Also, will Python/Qt libs be easily usable from Qt/C++? I doubt it, at
least not without deploying a python interpreter (and we already have
to deploy a JavaScript interpreter if we want to use QtQuick).

Modern C++ has come leaps and bounds over recent years in improving
code simplicity and safety (clang-tidy QtCreator integration FTW)...
whereas afaik Python still crashes if you don't have your WHITESPACE
perfectly organized bleh. Simply put, encouraging the use of
Python is the same thing as discouraging the use of Modern, Simple,
and Safe C++.

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[d3fault]

On 5/29/19, Mutz, Marc via Development  wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>
> These are basically Qt-internals, and should never have been public in
> the first place.
>

I disagree (unless there's some replacement you forgot to mention?).
Being able to create implicitly shared classes is extremely useful. I
consider implicit sharing and signals/slots, together, to to be one of
Qt's greatest strengths. They allow you to thread safely access/read a
"single" object across multiple threads without even thinking about
threading primitives such as mutex/waitcondition. You can also thread
safely modify/write to that object, by copying/detach()'ing just
before write (CoW).

I think the reason QSharedDataPointer hasn't seen very much use in
user code is because it's so darn tedious and time consuming to setup.
There's a lot of boilerplate/repetitive code in the EmployeeData
example of QSharedDataPointer's doc. At least that's why I
rarely/never use it in my own code. But there's a solution to that,
outlined here: https://bugreports.qt.io/browse/QTBUG-68589 (the
"Sample.isd"/json design in the comments of that bug report would be
very easy to implement).


> == QLinkedList -> std::list
> == QQueue / QStack -> std::queue, std::stack ==
> == QSet / QHash -> std::unordered_set/map ==
> == QMap -> std::map ==
>

Disagree. The software design process differs too greatly when dealing
with CoW vs. non-CoW containers. Assuming you could do s/QMap/std::map
(etc for all the containers) and have it compile without changing
anything else, there are just fundamental differences in the way
you're expected to use the containers. With Qt's CoW containers you
refer to a container by value, even from multiple threads
*simultaneously*, and it never performs a deep copy unless you try to
modify the container. ex:

Thread #0:
emit fooSignal(someQMap);

Thread #1:
void someFooSlot(someQMap)
{
m_MyCopy = someQMap; //with a CoW container the atomic reference
count is just incremented by 1. with a non-CoW container a deep copy
is performed here
}

Tons of user code was designed relying on there being CoW containers,
so removing it would make memory consumption skyrocket (OOM likely). I
don't see this as a feasible change. Hypothetically, how would one
thread safely share a std container with another thread (via
signals/slots) without performing a deep copy? Pass a
reference/pointer to the container and pass mutex along with it? That
would require lots of code changes (mutex.lock everywhere) and would
be prone to use-after-free errors (Qt's CoW semantics do lifetime
management seamlessly).

I recommend doing what someone else suggested in this thread: keep the
Qt'ish API (enqueue/dequeue vs. push/pop etc) and use the std
containers for the underlying implementation (just wrapped in CoW).


d3fault
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Property bindings in Qt 6

[d3fault]

On 9/26/19, Julien Cugnière  wrote:
> As a user, I find this project very interesting, as after learning
> QML, I often found myself wanting to use some kind of binding system
> when coding in C++.
>
> One question that comes to mind when you mention lazy evaluation: how
> does this interact with the "onPropertyChanged" signal? In QML, one
> sometimes sees code like :
>
> onFullnameChanged: {
> console.log("the fullname changed!");
> foo.bar();
> }
>
> At first glance, this doesn't seem compatible with lazy evaluation.
>

I had a similar question: how do we use this lazy evaluation with e.g.
QLabel::setText? I skimmed the sourced but didn't see any "dirtied"
signal to connect to.

Otherwise though this looks promising and a much cleaner approach than
depending on javascript.

d3fault
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Metatype system in Qt6

[d3fault]

On 12/5/19, Olivier Goffart  wrote:
> That will not be working anymore if the MyType is only worward declared.
> The user will have to do one of these:
>   1. #include "MyType.h"  in the header
>   2. Q_DECLARE_OPAQUE_POINTER(MyType *)
>   3. Q_MOC_INCLUDE("MyType.h") : that's not yet implemented but would make
> moc
> include the file in the generated file.
>

>
> Now another question is what exactly do we want to automatically register.
> Of course, we will register the way to construct, copy, and destruct the
> types.
> Now, should we also register automatically the other things that we can do:
>
>   - operator==
>   - QDataStream operators
>   - QDebug operator
>
> Ideally we also want this to be automatic, but i've run into an issue.
> I naively tought it would be simple enough to just use SFINAE to detect if
> the
> type has the operator==, with something like that.
>


If qt6-moc depends on libclang [0], we could intelligently determine
that MyType* is only forward declared and then transparently generate
the required calls to Q_DECLARE_OPAQUE_POINTER(MyType*) where needed.
Same goes for detecting ==operator/QDataStream/QDebug. I've heard
Thiago say that depending on libclang is a no go [1]. Is this no
longer the case for Qt6? Having libclang available during the
precompile stages would open up a world of possibilities for Qt.

d3fault

[0] - https://wiki.qt.io/Qt_Contributors_Summit_2019_-_moc_and_QMetaObject
[1] - 
https://bugreports.qt.io/browse/QTBUG-68589?focusedCommentId=406466=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-406466
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[d3fault]

Both the "removal of LTS" and "removal of offline installers" serve as
evidence that Tuukka Turunen doesn't care about the Free
Software/Culture movement. In both cases he is actively hurting the
open source side of Qt in order to promote the business side. The work
is already being done to create the LTS and Offline Installers; openly
publishing that work requires very little (negligible) additional
effort.

It's not the end of Qt by any means, but it's a step in the wrong direction.


d3fault
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development