On 19/05/2011, at 4:20 AM, BRM wrote:
QtService is presently only supported via an add-on to Qt. I would be very
helpful to have it be part of the official Qt instead of an add-on - e.g.
it's
distributed with Qt just like QtGui.
It could also use some TLC, for example:
- QtService is
On 19/05/2011, at 4:42 AM, Thiago Macieira wrote:
On Wednesday, 18 de May de 2011 11:20:25 BRM wrote:
It could also use some TLC, for example:
Who's going to give it that TLC?
Well, if Nokia shows interest in adding the QtService functionality to Qt and
you ask nicely..
That's one of
On 25/05/2011, at 2:13 AM, Jason H wrote:
I think if we could lock the lib and exe to specific versions (like Windows SxS)
we'd be better off. We just need a way to link to specific versions of the Qt
libraries. (Though SxS is still problematic, I think it is an improvement)
You technically
At the risk of making myself a target. ;)
Rather than looking for a build system where an IDE can manipulate the project
file directly (eg .pro, CMakeLists.txt, etc.), is there any merit to defining
an API or command line interface which an IDE can hook into and then it is up
to the
On 14/06/2011, at 10:19 PM, Stefan Majewsky wrote:
I was thinking about using QML to define internal datastructures (e.g.
as a more powerful alternative to QSettings). While doing so, I came
to wonder whether some of QtDeclarative's custom additions to the
metaobject framework should be
Sorry to reply to my own post. My fingers are working faster than my brain this
morning. ;)
The notion of the default property is already covered by the USER keyword in
Q_PROPERTY. Is there any reason why QML doesn't simply use that instead of
requiring a separate DefaultProperty entry in the
Actually, how about something like this:
class QThread
{
// ...
public:
enum TimeUnit
{
Seconds,
Milliseconds,
Microseconds
};
void sleep(unsigned long time, TimeUnit units);
};
One could also envisage TimeUnit being in the Qt namespace rather than
On 24/08/2011, at 4:33 PM, Andre Somers wrote:
Personally, I think that adding this to QThread is not really needed
though. I don't see what is wrong with setting the sleep period in
milliseconds; sleep() should not be used all that much anyway.
In the same way that no-one will ever
On 18/09/2011, at 9:48 AM, Thiago Macieira wrote:
The big difference there is whether those executables are
architecture-specific in multiarch configurations (e.g.,
/usr/lib64/NAME/libexec). Usually they aren't.
How could an executable not be architecture-specific? I must be missing
something.
Sorry, slight typo in my original email. Creating an observer would be done
like this:
addObserver(sender, SomeSignalEvent::eventID(), receiver,
ReceivingClass::handleSomeSignalEvent);
Also, the SomeSignalEvent class should have had an accessor function to allow
the receiver to get the
On 27/09/2011, at 6:34 PM, Thiago Macieira wrote:
On Tuesday, 27 de September de 2011 10:03:17 craig.sc...@csiro.au wrote:
This discussion about what to make a reference platform vs documented
platform seems to be specific to Linux (okay, maybe embedded too, but
discussion seems to be mostly
On 28/09/2011, at 10:20 PM, henry.haveri...@nokia.com
henry.haveri...@nokia.com wrote:
Rohan wrote:
I have some comments on the target platforms.
On all platforms, Open GL (ES) 2.0 is required.
linux-x86-32-gcc-x11 Ubuntu Linux 10.04 ×86 32 bit, X11
linux-x86-64-gcc-x11
On 04/10/2011, at 6:05 PM, morten.sor...@nokia.com wrote:
On Sep 29, 2011, at 6:02 AM, ext Rohan McGovern wrote:
It would be good if we could somehow get some more data/feedback on who
might be interested to deploy a Qt 5.0 app on OSX 10.6. Right now I
have argued against it mostly for
Feels good to vent it out sometimes, huh? ;) I have some sympathy with some of
your points, but I'll restrict myself to a couple of specifics.
On 07/10/2011, at 11:27 PM, Till Oliver Knoll wrote:
But with the current requirement that even the QWidget based apps now
need OpenGL support
On 08/10/2011, at 6:07 AM, Harri Porten wrote:
On Fri, 7 Oct 2011, craig.sc...@csiro.au wrote:
Desktop apps won't be going away any time soon, and there are some
rather big commercial companies who would likely make some noise if Qt
on desktop was being neglected.
Were and how will
On 22/10/2011, at 5:18 AM, Thiago Macieira wrote:
On Friday, 21 de October de 2011 16:29:36 Stefan Majewsky wrote:
Moin moin,
it would be nice to have a command line parser in QtCore, i.e. some
class that parses stuff like
./program -vh --long-option --value=5 foo.dat
given some
Number of parameters for flag is controlled by the last parameter to
addSupportedFlag(), which is of type QStringList. If this string list is empty,
the flag accepts no parameters. If it is non-empty, then the flag accepts the
same number of parameters as there are items in the string list. The
On 22/10/2011, at 10:44 PM, Thiago Macieira wrote:
On Saturday, 22 de October de 2011 11:29:38 craig.sc...@csiro.au wrote:
With that out of the way, I've put the class definition up on pastebin for
comment. I've withheld the implementation until I've had a chance to clear
it with our legal
On 24/10/2011, at 7:15 AM, Stephen Bryant wrote:
Hey guys,
Apologies for being late to the party!
If Craig doesn't like QCommandLine, and the other implementation mentioned
has
legal restrictions, I have an implementation I wrote - with no legal
restrictions other than normal Qt
19 matches
Mail list logo
