a special occassion (but eh, terrible time for a joke. I'm being
cereal in this post)). He once tried to convince me that Microsoft actually
likes Qt. Uhhh.. WHAT???
This is going to be an interesting next few months,
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
On Fri, Jun 15, 2012 at 12:02 PM, Thiago Macieira wrote:
> On sexta-feira, 15 de junho de 2012 11.42.07, d3fault wrote:
> > The Qt Trademark and the Nokia Corporation might die (except Qt won't
> ever
> > 'officially' die. It's in Nokia/Microsoft's
they still get a cut though?
Digia: do you outright own Qt Commercial?)... but Microsoft will pressure
Nokia into keeping it non-BSD regardless. Should Microsoft buy Nokia, they
wouldn't want it to be BSD'd either, for obvious reasons (more permissive
license = attracts more develop
ars to be the case), awesome. Burn,
Nokia, burn. I'm sorry a lot of you might be losing your jobs soon, that
really sucks. Nothing good comes from it (unless you had your creative
control stripped from you and were being forced to work on certain features
that you didn't think belonged in
the agreement and
found the answer wooo. The answer is: any code that moves out of Qt is
still considered a part of Qt. I bet a lot of the modules that were never
in QtBase aren't included in the BSD Clause either.
On Fri, Jun 15, 2012 at 3:43 PM, Thiago Macieira
wrote:
> On sexta-feira, 1
modules requring an active maintainer to be
included in a release... right? And QTheDeclarative as a whole might be
too large in general for the community to even finish before it even gets
to a maintainable status. I'll be sad if we lose QTheQuick along with it
:-/.
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
doing.
That being said, I still want Nokia to burn. Because it already is. Anybody
could tell you that Nokia's about to go out of business. I just wish
someone would put a bullet in the back of it's head and end it swiftly and
quickly. All this politics crap means we get to watch
On Sat, Jun 16, 2012 at 7:44 AM, Thiago Macieira
wrote:
> On sábado, 16 de junho de 2012 03.45.16, d3fault wrote:
> > Lars, since you're here; I don't want to put you on the spot but am going
> > to anyways. I predict a Microsoft buyout before the complete closure of
>
re able to share it?
I also don't agree with the recent subject change to "OT". This is very
much on topic if you are intested in Qt's future.
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Bricks = shat. Seriously, this is better than christmas.
I love you Digia.
Qt will quadruple in size once it's targetting Android/iOS (paying extra is
the norm for Apple fans, so needing a commercial license to release on the
iOS app store will be shrugged off as just another expense).
d3
acquire-Qt-from-Nokia/
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
The "DiagramScene" example included with Qt should help. It has nodes and
arrows that are re-drawn when the nodes are moved. Check out
DiagramItem::itemChange in diagramitem.cpp and the Arrow class itself.
d3fault
___
Interest mailing list
I
t an attempt to KISS? Any suggestions on re-using buffers in those
situations (am I missing something)?
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
state() == ConnectedState both before
and after the write... but that just seems like an ugly hack imo.
What would you guys recommend?
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
would
explain why my write 2 messages / read 1 message test above triggered
bytesWritten for BOTH of the messages, if that was the case.
I tried looking through the Qt source for an answer, but really
couldn't even find any related code (Ima newb to Qt internals).
qtcpsocket.cpp,
thing along the lines
of QNetworkRequest::Acknowledged() [signal] though not necessarily
anything to do with QNAM (especially since the QNetworkReply makes a
better acknowledgement in that case lol (and now I'm just confusing
myself)).
[0] -
http://en.wikipedia.org/wiki/Transmission_Con
layer for
the [Qt] applications to use (you said lots of people end up having to do
it).
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Transport layer is good enough if you are ok with relying on
"statistical faith" that the application layer will read it -- and this of
course ignores the many ways you mentioned the message could get stuck in
between.
I don't think anyone's proposing doing that... as it would
my own specific use case takes
priority sorry :-P.
To end, are there any plans to make QSslSocket work with QUdpSocket?
The overheads of TCP are redundant.
d3fault
inb4 a handful of people miss the point and try to explain to me why
tcp ack's are not redundant. "you're guaranteed orde
as
the same problem... we don't know that the ACK's ACK made it to the
application layer fml). A proper solution requires more thought. It
probably wouldn't be too complicated. Famous last words?
Such a class could greatly simplify application protocol creation.
Weee http://xkc
nd I
can't figure it out from the context. You mean message re-ordering?
Reminder to Konrad: Don't use any of my protocols, ever.
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
ent.
And when did I say HTTP wasn't on the application layer?
A [poor] analog to what I'm describing is QDataStream itself: It wraps
a QIODevice and inserts encoding data on the sender side and strips it
for you on the receiver side... but it's still in the application
layer.
The Generic ACK'er would become part of the application protocol...
and (just like QDataStream) would be intended for Qt <--> Qt
communication.
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
s opposed
to knowing it's sitting in the receiver's transport layer... worthless
information to the sender's application layer). Can now stop the
re-transmit timeout or whatever.
You're right about one thing: this argument is futile.
d3fault
__
enes.
Have a look at:
http://qt-project.org/doc/qt-4.8/qtextstream.html#RealNumberNotation-enum
http://qt-project.org/doc/qt-4.8/qstring.html#number-2
http://qt-project.org/doc/qt-4.8/qstring.html#argument-formats
d3fault
>
> Alex
>
> On Fri, Oct 5, 2012 at 3:59 PM, Rui Maciel wrot
would have unintended results unless I changed them to
pointers (I remember this subject being discussed a while ago on the
mailing list. delete ends up being called on non-new'd variables or
something).
d3fault
___
Interest mailing list
Interest@qt
guh sorry wrong list
mfw 2012 and we still have to change that
On Oct 21, 2012 10:20 PM, "d3fault" wrote:
> 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/registe
ng itself) unless you're doing a somewhat large
unit of work in every slot invocation/iteration. Example: read an image,
convert it, write it to disk, schedule another. You'd be IO bound so the
threading overhead would be cheap by comparison.
d3fault
___
void handleObjectReadyForConnections(MyObjectType *obj)
{
connect(btn, SIGNAL(clicked()), obj,
SLOT(doSomethingPleaseAndThankYou()));
connect(obj, SIGNAL(somethingHappenedDde()), this,
SLOT(handleSomeoneStoleMyCarDude()));
//etc
}
New Qt class or what?
d3fault
Quick fix:
On 10/23/12, d3fault wrote:
> emit readyForConnections(&obj); //Would be dangerous to call methods
> etc on this object. Should only connect to it's signals/slots
What I meant to say is that listeners to that signal should not call
methods on the object. Calling
#x27;m trying to perfect, is the
long-standing single (or I guess double lol) backend thread.
If I'm wrong and setting QThreadPool's max thread count to be >= your
backend object count on a per-project basis isn't a dirty hack
(separation of concerns!)... and if QtConcurrent
exec();
}
...etc so I can have N amount of objects on the thread. Already pretty
sure I can do it with just 1 template type (haven't tested lol).
I'd also want to stay C++ 98 compliant.
MOC can definitely do this :). At least hackily (signals/slot
ample is to create a reference for doing it cleanly.
Glad I made this thread else I never would have gotten the
stack-object-within-run idea (thanks to all those who contributed to
that, directly or indirectly).
I think I'm just going to stick with QThread. "Choose the right tool
for
le customArg2) : QThread(parent)
{
//save the args
m_ArgHolder1 = customArg1;
m_ArgHolder2 = customArg2;
}
void YourObjectThread::run()
{
//pass them in
YourObject *obj = new YourObject(m_ArgHolder1, m_ArgHolder2);
x27;re
a commercial customer.
Sauce:
http://lists.qt-project.org/pipermail/releasing/2012-September/000634.html
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
GenericArgument what I want? Or should I steal the code from
however signals/slots does it?
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
religion.
Science is independently verifiable.
Religion requires you to blindly have faith.
ANALogy Provided By,
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
y, look in videographicsitem.pro and videoplayer.cpp
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
bs would
be drag-n-drop enabled breadcrumbs, where hovering over the breadcrumb
while holding down the mouse during a drag-n-drop changes to the
folder for dropping into. Xfce's file manager does this, though it
does copy/paste instead of cut/paste.
d3fault
__
see what comes from this.
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
I hope they port QtWebkit next, that way I can write my GUI in
html/javascript to then have it rendered by Webkit, which will
incidentally be running as html/javascript. The html/javascript
html/javascript renderer. mind = blown (is dat sum bootstrap?)
Ok I'll shutup now,
d3
at all
the "expose X to QML" threads created in the past few months).
inb4 raeg,
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
nctionality of QUrl. Just call QUrl::queryItems()
[3] to get your list. There could be negative implications in doing it
this way, so using QString yourself/manually might be safer.
d3fault
[0] -
http://stackoverflow.com/questions/8582138/how-can-i-split-a-string-according-to-delimiters-in
pieces together yourself to iterate over your 60 HTML files, rendering
and calling QPdfWriter::newPage() where appropriate.
d3fault
[0] - http://qt-project.org/doc/qt-5.0/qtgui/qpdfwriter.html
[1] -
http://qt-project.org/doc/qt-5.0/qtwebkitexamples/webkitwidgets-framecapture.html
__
using PAL ( http://www.adrianboeing.com/pal/index.html )
but I prefer the "Qt way" of doing C++.
Thanks,
d3fault
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
d since it generates itself, it “generates output
from this application in it’s original […] form”.
Am I incorrect in my interpretation? Does that file need to fulfill
the requirements of the GPLv3? I hope I’m wrong.
Please feel free to surround your response with IANAL
ts interfaces, so the above is usually what a solution
looks like
d3fault
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
ll this is
> of no consequence, the vtable is respected (if I remember correctly that's
> specified in the standard). So the following should also be working without
> any problem:
>
> QObject::connect(a, Interface::someSignal,
ly a bad
idea, in this case the goal is to make a "signals & slots interface", so
it's guaranteed that all derived classes will ultimately inherit QObject.
Lastly, I'll mention that I didn't come up with any of these techniques. I
picked them up over the years from r
On 5/13/19, Bernhard Lindner wrote:
>> QFile::rename should rename always or fail! It should never do
>> completely different operation - copy!
>
> I agree.
>
Adding a non-copying rename method to QFile/etc seems justified. Maybe
call it: fastRename, tryRename, or a
3/Commercial modules are useless
to me.
d3fault
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
ffer, etc.).
>
If "something in memory" is your requirement, you could give QSettings
a filePath on a tmpfs. Then after the QSettings object has gone out of
scope, open that filePath with QFile.
d3fault
___
Interest mailing list
Interes
)
: QWidget(parent)
{
QHBoxLayout *myLayout = new QHBoxLayout();
myLayout->addWidget(new QLabel(tag), 0 /*you might want to use
1 here for stretch*/, Qt::AlignLeft);
myLayout->addWidget(new QPushButton("x"), 0, Qt::AlignRight);
setLayout(myLayout);
PI in the name of
performance" -- but I can't find the exact quote.
d3fault
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
tioned in that thread.
Alternatively... how about a more noob friendly Qt-Interest list? Some
people get off on helping noobs (helps them sleep better at night I
guess)... but I think most of us just get annoyed by his(her?) noise.
d3fault
>
> Alex
>
> Le 15/02/2012 14:34, Sujan Dasm
54 matches
Mail list logo
