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
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-pro
S 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
__
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
_
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 javascri
*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
> behin
rted. 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).
d
ory consumption. The 'concrete performance cost' of
run-time compilation is unnecessary in principle (regardless of how
insignificant it is)... which is why we don't want it.
Yes yes, tons of work... tons of maintenance... I get that. But it's better
I bi
evelopment). Forking Qt will also
permanently lower the barrier to entry for contributing to the
derivative of Qt (which would have to be renamed obviously) to only
requiring you to release your code under the LGPL... not having to
sign the Qt Contributor's Agreement.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
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
Farting Apps don't die
off soon (they won't)
On 5/12/12, Thiago Macieira wrote:
> On sábado, 12 de maio de 2012 21.57.17, Holger Hans Peter Freyther wrote:
>> On 05/12/2012 08:28 PM, d3fault wrote:
>> > whereas the point I'm trying to make is that the Qt Project gen
a way to say it (Nokia or
not, this project isn't dying! Long live Qt [or whatever it is called
in the future]!!!). Better wording: Qt is not as healthy as it could
be. I want to see it thrive. I want to want to contribute... because I
know that if I want to contribute, others will too.
Atlant: thank you for the story/history lesson
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
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 accele
ith 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
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 a
nsensus 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
___
ed 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
__
people want to fork. Sure, I'm too lazy... but what
about the next guy? I want Qt to be all it can be (lol Army). This means
that the issue needs to be dealt with if we want Qt to thrive. You do want
Qt to thrive, don't you? We need to keep the community together in order
for that to ha
he 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
&
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
ble 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
(whoo
ill. Removing the
CLA (never gonna happen) or forking would work too.
On Wed, Jul 4, 2012 at 2:15 AM, wrote:
> d3fault, after seeing all your posts in this list it is clear that your
> aim might be well aimed but is more obstructive than constructive.
>
Yea I hope so. My aim is to be
cation 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 (plat
nitoring.
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
ame
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
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
>
r 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
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
ector = new MyOptimizedDetector();
QFileSystemWatcher *fsw = new QFileSystemWatcher(myOptimizedDetector);
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
o 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
e
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
h 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 p
n 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
On Wed, Sep 26, 2012 at 12:40 AM, André Somers 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?
>
t;on.
But you shouldn't have to outside of the branch you're working on (dev
imo). Not only does someone working on stable directly have to watch
dev/testing, but someone working on dev now has to watch
testing/stable for changes too?? Doesn't sound worth it.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
m
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
_
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).
x27;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.
___
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
gt;
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 yo
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
lated classes from the project
(QSslSocket namely). Leaving them in is misleading.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
t 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.
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 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 wrote:
> tl;dr:
> Open Project
> Closed Security
>
> The
usted"
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
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
d3
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 requir
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).
d3
On Fri, Oct 19, 2012 at 3:37 PM, Knoll Lars 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
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,
d3faul
r 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
__
ich 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
On Oct 19, 2012 8:12 AM, "Roseline Thompson"
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
hanks
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
___
..
...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
On 10/23/12, d3fault 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 analog
On 10/23/12, Donald Carr 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 repor
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
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. Peo
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 l
ent], don't say nothin'
at all". -Thumper
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
//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
best for the
community? Or will he be fired for insubordination? If so, Turunen
Tuukka is really the Chief Maintainer. He bought his way into the
position when Digia acquired Qt.
I really hope we choose Full Disclosure as our security model, as it
gives the _users_ the best opportunity to protect
atever 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
ments. 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
/police withholding information that
there's a serial killer rapist walking around your neighborhood?
The news and police practice full disclosure. It is a privilege of a
technologically advanced society.
d3fault
___
Development mailing list
Develop
valid, however.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
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
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 a
guments.
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.
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: W
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@
x27; that 5 will
set in stone.
<*insert holy war argument here*>
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
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
nough megabytes to clone/compile Qt 5. Fracking POS
netbook. Christmas is just around the corner and I've been a good boy
this year. I'm 12 and what is this.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
ent" 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
The words "stable" and "release" are somewhat ambiguous (enough to
warrant change).
A release is implicitly stable, so the converse usually also holds
true: stable is released.
d3fault
___
Development mailing list
Development
"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.
rivial fix... but not worth ignoring. Changing
later will be much more expensive.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
g" or even "green"
(dev=red,middle=green,release=blue), so long as it isn't ambiguous.
The current setup is equivalent to dev=white, stable=brown-orange,
release=brown-red.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
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
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 ma
##Bringing this to development mailing list
>> - Original Message -
>> From: d3fault
>> To: bog_dan...@yahoo.com
>> Cc:
>> Sent: Wednesday, January 16, 2013 7:53 AM
>> Subject: Full Ministro in Ministro-Redirection stub
>>
>> Hi, sorry
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 ta
nment, 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
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 so
ded.
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
eady 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
___
Deve
Have you looked at the Qt Service Framework? It's new to 5.0. Doc:
http://doc.qt.nokia.com/5.0-snapshot/service-frameworks.html . Here is an
example app demonstrating it's usage:
http://doc.qt.nokia.com/5.0-snapshot/servicebrowser.html .
> *Hi,*
>
> *Qt nicely supports extending applications and
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...@openboss
91 matches
Mail list logo
