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

, 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

Re: [Development] The place of QML

*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

Re: [Development] The place of QML

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

Re: [Development] The place of QML

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

Re: [Development] The place of QML

(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

Re: [Development] The place of QML

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

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

[Development] Proposal: Change Qt Slogan

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

Re: [Development] Code of conduct.

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

Re: [Development] Code of conduct.

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] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

. 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

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

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

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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

Re: [Development] QFileSystemWatcher and Recursive Monitoring

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?

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

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

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?

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

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

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

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

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

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

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

Re: [Development] RFC: Qt Security Policy

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

Re: [Development] RFC: Qt Security Policy

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

Re: [Development] RFC: Qt Security Policy

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

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

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] Proposal: Change Qt's Security Policy to Full Disclosure

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

Re: [Development] RFC: Qt Security Policy

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

Re: [Development] RFC: Qt Security Policy

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

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

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

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

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

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

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

Re: [Development] Proposal: Change Qt's Security Policy to Full 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

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

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

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

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

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

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

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

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

] 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

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

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

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

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

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

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

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

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

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

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

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

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

.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 ___ 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)

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)

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)

. 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

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

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

, 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

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

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

/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

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

(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

/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

Re: [Development] Branching 5.0

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

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

. 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

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

. 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

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

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

Re: [Development] Evolving Qt's multithreading API

. 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

, 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

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

Re: [Development] Why waste energy supporting Python?

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

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

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 lis

[Development] Why waste energy supporting Python?

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

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

Re: [Development] Property bindings in Qt 6

th 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. d3fau

Re: [Development] Metatype system in Qt6

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

Re: [Development] Changes to Qt offering

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