Re: [Qt5-feedback] Add QtService to Qt proper
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 presently a set of template classes, making use of Signal/slots hard. It could probably be better done using Abstract classes to define the interface. - It would be useful to schedule shutdown as opposed to having the '-t' option simply terminate it; probably '-t' should be --force-shutdown instead. - The Interactive Service functionality could probably be removed given that (i) adding GUIs to services is not adviced, and (ii) Windows no longer supports it (as of Vista). Other platforms may but we probably should follow best practices and encourage developers to split the service from the GUI. I very much agree with this, and given that the move to Qt5 is going to have binary compatibility breaks, it would seem to be an opportune time to really consider bringing an improved/restructured QtService class into Qt proper. I agree with Ben's view that the current templated approach is both unnecessary and a hinderance. Dispensing with the GUI support should make for a much cleaner class, and as Ben pointed out, a GUI should really be split from the service itself anyway. QtService is one of those things that I find myself asking Why isn't this part of the main Qt libraries already?. It makes sense and fits nicely with the other set of classes provided by Qt. I put it at a similar level as QDesktopServices, QProcess and QSharedMemory. One of the trickier bits of using QtService at the moment is if you want to support additional command-line options beyond those defined by QtService. This is hard enough to do robustly that we basically don't want to do it and instead work around it. Maybe the command-line handling should be done separately from the QtService class and have QtService provide member functions to do the equivalent instead? FWIW, we ended up implementing our own generic (and extensible) command line argument processing class for some other work, so we have the other half of this picture. I could understand if others would be less keen to forego the bundled command-line capabilities within QtService as it is currently implemented. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Add QtService to Qt proper
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 the things this list is for, right? ;) -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
[Qt5-feedback] Qt major versions (was: C++ api to use for UI in addition to QML)
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 already have what you need with the current releases. The major part of the version is also part of the library name that applications link to (or should link to!). Under Mac and linux, binaries link to llibQtCore.4.dylib and ibQtCore.so.4 respectively. Under Windows, the major version is made part of the library name itself rather than as part of the extension (ie QtCore4.dll) so you have no choice but to link against a specifc major version. Thus, there is already the mechanism required for an application to link to specific binary compatible levels of Qt. Perhaps part of the problem is that the major part of the Qt version changes very slowly. This in turn means that backwards compatibility has to be maintained for long periods. It's somewhat unfortunate that the Qt business/marketing is linked to the technical aspect of version numbering. From a technical point of view, a version number has some fairly well established conventions that many (most?) mature libraries follow. The major part of the version number is what libraries and executables link against (or should link against!). If you build against the earliest release of a particular major version, it should work with all later releases for the same major version. For example, if I built against Qt 4.0.0, it should work with any 4.x.y version. The problem with Qt is that the major part changes slowly and new features people want are introduced with minor point releases. This leads developers to situations where they have to say their software requires Qt 4.x or later i nstead of simply requires Qt 4. This makes the problem of what to link against much harder, because if you make your application link against, say, version 4.4 instead of just 4, then it won't work with 4.5 or later! This is particularly evident as of around Qt 4.6, which had a number of new things added (the pattern of adding more new things continued with 4.7). So the mechanism is there to link against specific versions, it's just that the way Qt increments its version numbers sometimes works against the developer. Now, from a marketing aspect, Qt has a pattern of keeping its major version the same for long periods. People like to be able to say Uses Qt4, but in reality, Qt4 isn't enough any more. Too often, I have to ask Which version of Qt4?, meaning which minor release, since new features appear only in certain minor releases. This is where marketing Qt4 becomes at odds with what developers need Qt4 to mean from a technical point of view. There are different ways to address this. One is to decouple the public marketing release version from the underlying technical version. Examples of this are where you see things like Autodesk Maya 2010, which makes no mention of the major version number used by the underlying libraries you would link against (it uses Qt 4.5.3, incidentally). They have the freedom to change or keep the major version as they need to from release to release. This sort of decoupling may appeal to some but may also be unattractive to others. Another option is to simply have more frequent major releases. Anything longer than a year is probably too long for the Qt community (many would argue even that is too long), but anything shorter and you risk making Qt too much of a moving target. I suspect that the compliance costs for things like LSB also get higher the more often you change the major version. So that's a couple of ideas for improvement. I'd be particularly interested in hearing if Nokia is willing to consider changing how it handles major version increments to help address this issue, but let's see what other ideas and opinions people have too. ;) -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Build system requirements for Qt5
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 underlying build tool to support that interface? For example, an IDE would query the interface to get details about what's in the project. If the IDE then wanted to add a file, modify a flag, make some particular compilation feature conditional on a platform, etc., it would call a function/run a command and the build tool would then be responsible for carrying out the request. When the IDE wants to build a target, clean a project, etc, it would do that through the interface too rather than try to do it directly. The IDE would not have to be burdened with understanding the intricacies of the build tool's project files - that responsibility would then rest with the build tool itself - nor would the IDE even have to really be aware of whethe r something like make, nmake, msbuild, etc. is even being used under the covers. There are a few of advantages to this approach: (1) Qt Creator and other IDE's can focus on their IDE, not the various build tools that they might want to support. (2) Developers would be free to use whatever build tool they liked as long as it offered a library/command line tool that fulfilled the interface. (3) Owners of a build tool would be free to continue using their existing project file formats or change them as they needed, without fear of breaking any IDE's that use the API/tool interface. They would just need to ensure that they provide an API/tool to fulfil the interface requirements. (4) The build tool owners should have the best knowledge for how to best take advantage of that build tool's features and strengths. They should be able to implement the interface in an optimal way rather than every IDE developer having to do that. (4) If anyone feels the need to write yet another new build tool, they could write the required library/tool for the IDE interface and then the IDE can use it with little or no modification. Using this approach, the whole argument of declarative versus imperative versus frankenstein-hybrid becomes a moot point. Instead, the discussion would shift to what should be in the interface, and it's worth noting that the discussion here on this list is finally getting down to that anyway (at least qualitatively). I'm sure there are also disadvantages to this approach too, but I don't want to spoil the fun of those who would like to pick apart the idea. ;) Okay, warm up those flamethrowers.. it's cold enough here in Melbourne at the moment that we could use the heat. :-P On 09/06/2011, at 6:29 AM, Oswald Buddenhagen wrote: On 06/08/11 20:39, ext Alexander Neundorf wrote: So what do you actually want from the buildsystem what cmake does not provide right now ? hmm ... - it needs to be *fast* - a null build should not take noticeably more time than stat()ing all files - as thiago noted, it needs to handle distributed building efficiently these two boil down to not being a meta build tool, but a native build tool. this is theoretically easily solvable, and the elusive cbuild is being talked about since half a decade, but was still not delivered. as far as i'm concerned, IDE integration should happen only via native support plugins for The build tool. not sure how realistic this is for the two relevant proprietary IDEs (VS and XCode). - changing a build rule somewhere deep down the tree absolutely must not trigger a re-configuration of the entire build tree. - caching of build configuration should come naturally, not as an afterthought (which many developers forget). these are inherent to the project structure and language. - it needs a language which is not a royal pain in the arse to use for both humans and machines (IDEs) - it needs to be clean and well-specified - it needs to be declarative from the ground up: - the skeleton should be declarative. imperative constructs should be clearly encapsulated - not the other way round - it should be declaration order independent - it should be centered around build properties, not command lines. no CFLAGS, except as a total fallback. cmake is half way there. these are all prerequisites for a clean IDE integration, and for comprehensibility of complex build systems. - it should cleanly support modularization. using another subproject's artifact should be the same as using a known framework or something configured. subprojects should be cleanly detachable from the superproject. - it needs to feed an IDE with a useful understanding of the project structure (not some random foo.o targets whose existence the IDE must divine
Re: [Qt5-feedback] Merging QDeclarative specifics into core QMetaObject
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 merged into the main macros. For example: Q_PROPERTY(QObject* foo READ foo WRITE setFoo NOTIFY fooChanged) Q_CLASSINFO(DefaultProperty, foo) could become: Q_PROPERTY(QObject* foo READ foo WRITE setFoo NOTIFY fooChanged DEFAULT) +1 for this suggestion. In fact, this was how I expected the default property to be defined the first time I was using this aspect of properties of QObject's. Note also that the Qt documentation still says that Qt itself does not use anything defined via Q_CLASSINFO except for the ActiveQt extension, but it appears that this is no longer true with QML/QtDeclarative (sorry, can't remember the details of where/how, but I'm sure the relevant people will know the details). If the DEFAULT keyword/classinfo is absorbed into the Q_PROPERTY macro, then at least the Q_CLASSINFO reverts to going back to being just for extensions to Qt or client code. Making this change in the break to Qt5 would seem the right time to do this. If there's going to be a Qt4 -- Qt5 porting tool like there was from 3 -- 4, then it could convert/absorb the Q_CLASSINFO(DefaultProperty,...) stuff into the corresponding Q_PROPERTY macro. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] [ExternalEmail] Re: Merging QDeclarative specifics into core QMetaObject
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 classinfo? The relevant page on QML (Extending QML Functionalities using C++) describes the use of the DefaultProperty entry. Reading over this again, it really does seem like an oversight that this was added instead of re-using the USER property already available in the metaobject system. I suspect that this classinfo feature could be phased out by supporting the DefaultProperty in the classinfo if it is present, but fall back to the USER property if DefaultProperty is not present. In Qt5, I'd then suggest dropping the support for DefaultProperty. On 15/06/2011, at 10:08 AM, craig.sc...@csiro.au wrote: 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 merged into the main macros. For example: Q_PROPERTY(QObject* foo READ foo WRITE setFoo NOTIFY fooChanged) Q_CLASSINFO(DefaultProperty, foo) could become: Q_PROPERTY(QObject* foo READ foo WRITE setFoo NOTIFY fooChanged DEFAULT) +1 for this suggestion. In fact, this was how I expected the default property to be defined the first time I was using this aspect of properties of QObject's. Note also that the Qt documentation still says that Qt itself does not use anything defined via Q_CLASSINFO except for the ActiveQt extension, but it appears that this is no longer true with QML/QtDeclarative (sorry, can't remember the details of where/how, but I'm sure the relevant people will know the details). If the DEFAULT keyword/classinfo is absorbed into the Q_PROPERTY macro, then at least the Q_CLASSINFO reverts to going back to being just for extensions to Qt or client code. Making this change in the break to Qt5 would seem the right time to do this. If there's going to be a Qt4 -- Qt5 porting tool like there was from 3 -- 4, then it could convert/absorb the Q_CLASSINFO(DefaultProperty,...) stuff into the corresponding Q_PROPERTY macro. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Protected functions of QThread
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 within
QThread if other classes might find it useful.
On 24/08/2011, at 12:03 PM, craig.sc...@csiro.au wrote:
I figure this might be the right time to scratch an itch with QThread. :-P
It has often annoyed me how the sleep(), msleep() and usleep() functions of
QThread are protected and not public. A number of times I've found myself in
the situation where I want to call these from outside of a QThread subclass
and have had to resort to defining a dummy subclass just so I could call
them. The only rationale I can think of for why these were made protected is
to try to ensure that they are only called from threads that were indeed
created by QThread (not sure if that is even necessary for these functions to
work).
I propose that for Qt5, one of three things be done:
(1) Make sleep(), msleep() and usleep() public static functions. This would
be source compatible but would also allow them to be called from any thread,
not just those that were created with a QThread.
(2) Make sleep(), msleep() and usleep() public member functions. This would
not be source compatible but it would force the current thread to be obtained
by calling QThread::currentThread() and then calling the sleep-related
functions through that. The only source incompatibility would be a static
function in a QThread subclass calling one of the sleep-related functions.
(3) Deprecate the sleep(), msleep() and usleep() functions for Qt5 and
provide public member functions with different names, such as sleepSec(),
sleepMsec() and sleepUsec(). I'm not at all attached to these suggested
names, by the way. ;)
Of these options, I think (3) is probably the most promising.
--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia
___
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia
___
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Protected functions of QThread
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 need more than 640k RAM ;) But as Robin Burchell already pointed out, a merge request from David Faure has already been accepted a few weeks ago which makes these three sleep-related functions public statics of QThread (ie option (1) of my original post). -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] libexec?
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. I meant if a 64-bit library (/usr/lib64/libfoo) can use a 32-bit helper application (/usr/lib/foo/libexec/bar). Or to put it simply: where should the 64-bit helper be installed: /usr/lib or /usr/lib64? Since this appears to be a linux-specific question, the lsb-disc...@lists.linux-foundation.orgmailto:lsb-disc...@lists.linux-foundation.org mailing list might be the right place to ask that question. I think there was some discussion on there earlier this year about what should be done around multi-arch in the LSB, so it would seem wise for Qt to be on the same page with the LSB spec and development of upcoming versions. Perhaps iyou could post your question there with some more context - they should be able to recommend the right approach. PS: The LSB guys recently took on discussion of the FHS too with a view to updating it, so now is a good time to be talking to them about issues like this. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] [ExternalEmail] Re: QObject: new signals-slots syntax
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 someString_ value. I'm sure you'd all figured that out
on your own though. ;)
On 22/09/2011, at 9:48 AM, craig.sc...@csiro.au craig.sc...@csiro.au wrote:
On 22/09/2011, at 3:20 AM, Thiago Macieira wrote:
On Wednesday, 21 de September de 2011 18:49:04 Stephen Kelly wrote:
Another solution (also by way of adding an indirection) is to add a
function that emits, which is protected.
template typename Klass, typename... Args
void QObject::emitSignal(void (Klass:: *signal)(Args...), Args... args);
Then you'd write:
emitSignal(Me::textChanged, newText);
instead of:
emit textChanged(newText);
The template magic to make that happen is already present.
However, it would be completely source-incompatible with the existing
code, which is a big no-no. It would require making the signal functions
themselves not do anything -- only serve as identifiers.
For source compatibility they could be implemented by moc to work as
currently, no?
Oh, they need to keep the current implementation so that SIGNAL and SLOT
based connections still work. Never mind me.
The old connection mechanism is almost guaranteed to work.
The problem is to update emit lines, which are calls to functions that
cause
the signal to be emitted.
Also note that the solution above doesn't fix the following case:
otherObject-emitSignal(Them::textChanged, newText);
Just as it doesn't protect today:
emit otherObject-textChanged(newText);
The big difference is that emitSignal would be protected in QObject, so
any
class deriving from QObject would have access to it.
We've been looking at this for a year. If anyone has more interesting ideas,
they are more than welcome. But please try to write the proof of concept
first.
Our conclusion is that if you want compile-time checking of the arguments,
you
need to give up the protectedness of the emission.
I'll mention one approach not because I think it is the right one to use
here, but rather just to potentially fuel further discussion. For reasons I
won't go into, we have our own observer-based code which has similarities to
what Qt's signal-slot mechanism offers. Instead of relying on string-based
signatures, it uses addresses of instances of a specific event class, which
we call EventID. We also have an event base class which we call
ObservableEvent. Our equivalent of defining a signal is to define a subclass
of ObservableEvent. We provide the EventID singleton that corresponds to an
ObservableEvent subclass using a static function. A short code extract to
give you an idea of how this works would be:
class SomeSignalEvent : public ObservableEvent
{
QString someString_;
public:
SomeSignalEvent(const QString s) : someString_(s) {}
static const EventID eventID() { ... }// Implementation hidden to
keep it simple
};
class SendingClass : public CanNotifyEvents// I won't explain this, but
it's similar to inheriting from QObject
{
// ...
};
class ReceivingClass
{
public:
void handleSomeSignalEvent(const SomeSignalEvent e);
};
In our code, you would create an observer for an event on a specific object
something like this:
addObserver(sender, SomeSignalEvent::eventID(), receiver
ReceivingClass::handleSomeSignalEvent);
Now, let's say that, as per this discussion thread, you wanted to limit who
can emit/raise the SomeSignalEvent. Specifically, let's say you only wanted
SendingClass to be able to do that. In that case, you could make the
constructor for SomeSignalEvent private and add SendingClass as a friend. You
leave the eventID() static function public. This means only SendingClass can
create/emit the event, but anyone can connect to / listen for that
signal/event.
Now, it may look like more work and yes, there are some things that the above
approach makes a bit harder than the current signal-slot mechanism, but it
does allow you to have full compile time checking and it does allow you to
have non-public emit access while still allowing public connect/listen
access. I've simplified things a bit in the examples above. In our code, we
have macros and templates handle all the gory details and it is actually very
simple to use. We've also very much appreciated that receivers don't have to
derive from a common base class, so it's easy to add connections where we
want the receiver to be a private class defined within a .cpp file, for
instance.
I reiterate that I'm not advocating this as a replacement for the current
signal-slot mechanism. It isn't source compatible with it, obviously, and it
is a bit different in how the
Re: [Qt5-feedback] Documenting the scope of Qt 5.0
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 about linux at this stage). I put it to the list that this is precisely what the LSB is meant to address. Most of the work has already been done to make Qt build against LSB 4.0 (by Harald Fernengel and myself). Why not make LSB 4.0 the reference *and* documented platform for linux? Then the only question is whether or not a particular flavour of linux supports the LSB spec, and this is something that all the major linux distros generally try to do. Yes, there will be the odd need for a specific hack/fix to work around the occasional distribution-specific deficiency or bug, but I'm only aware of one such case in order to make Qt build against LSB 4.0. Qt5 would seem to be the perfect time to make LSB 4.0 a tier 1 config/platform for Qt. Currently, I maintain a smallish patch set for each Qt release to make it buildable with LSB (almost all the patches now are confined to webkit). I'd be more than happy to work with others if there was interest in making LSB 4.0 a tier 1 config/platform for Qt. Currently, I can only work on this as my current role allows, so some help would be welcome. Granted, there are some issues around OpenGL versions, but those are easily resolved by adding an additional constraint that sits on top of LSB 4.0 (and which looks to be getting addressed by upcoming LSB versions anyway). The only module I have not yet built against LSB 4.0 is DBus, since it isn't part of the LSB, but Thiago has already indicated in a previous response that providing the DBus headers to Qt should be enough since it will try to load the QtDBus module dynamically at run-time and still work fine if it can't be loaded. Hello I think Qt should build with the LSB, yes. But making it our reference platform will not exactly work, as the LSB 4.0 is now several years out of date. I can't get the details as the website seems to still be down related to Linux Foundation's infrastructure downtime. Agreed, it does lag. The LSB guys are aware of this and there have been discussions about changing that so that they are much closer to the current / leading distros. The LSB isn't meant to innovate in the area of support. It's meant to standardise best practice across the industry. For that reason, it's always behind in terms of support and will usually lag one year behind the state of the art or more. When developing for the future, we need to look at what the state of the art of everything else will be, not what Red Hat Enterprise Linux and SUSE LInux Enterprise Server shipped in 2008. (And by look at I don't mean always use) Take for example Wayland: when will it be available in the LSB for us to build against? Anyway, what we can do is provide documentation on what we require by using the LSB as the baseline: it's LSB 4.0 plus these libraries upgraded and these other libraries present. I'd very much support this approach. Making LSB 4.0 the base with a (hopefully small) list of libraries you need to update to something more recent would be a welcome change for people working on or supporting a wider range of linux distributions than simply Ubuntu. In many cases, LSB 4.0 + a few libs would probably be satisfied out of the box on recent distros, so for those who like to be more current, things should just work for them. For those who need to stay on older systems, at least the libs that need to be updated or provided as part of the application's packages would be clearly defined. Another benefit of taking the LSB 4.0 + some libs approach is that it sends very clear messages to the LSB guys as to what things they should consider adding to the next version of the LSB spec itself. Currently, I get the feeling that there's not a whole lot of communication going between the Qt and LSB communities, which is funny considering Qt itself is part of the LSB! -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Documenting the scope of Qt 5.0
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 Ubuntu Linux 10.04 ×86 64 bit, X11 linux-x86-32-gcc-wayland Linux Ubuntu 10.04 ×86 32-bit, Wayland I think that Ubuntu 10.04 maybe too old already. The Mesa version shipped on that Ubuntu can't do GLES2.0 AFAIK. Also I think there is no wayland compositor available out-of-the-box. In other words, to actually test Qt5 with wayland and GLES2.0 on Ubuntu 10.04, you probably have to change the environment to the point where it's no longer accurate to call it Ubuntu 10.04. We already plan to test with Ubuntu 11.10 in CI, so the question is whether or not 10.04 should be kept as well. Probably not. I updated the table for now along these lines. I would strongly recommend you include Ubuntu LTS releases in your CI. These are specifically meant to be long-lived and so, by definition, won't go away quickly. Yes, plenty of people move to the latest and greatest versions, but I think talk of removing 10.04 from the CI is premature at this stage. Granted, it's been out for 2 years now, but my understanding is that it is still the most recent LTS release available. 10.04 is apparently supported on desktops until April 2013 (longer on servers - April 2015, but that's probably not feasible to support in the CI). Thiago, Craig: if we later agree to use something LSB based, let's then update this. I changed the headings of the table to indicate that we're specifying the CI system configuration, rather than the reference platform, that might indeed be a bit more abstract and general.. linux-arm7-gcc-wayland Linux, ARM7, Waylandgcc 4.5 ? The platform must be specified more completely. Right now it specifies that the kernel is Linux, CPU is ARMv7, wayland is used somehow and gcc 4.5 may be used. There's a lot of gaps to be filled in :) We should find some existing platform which fits these specs, and specify that as the target instead. If such a thing doesn't exist then I guess we shouldn't target it. It'd be good to find a configuration in the CI for this. I documented that we need to specify this in more detail. osx-10.7-64Apple Mac OS X 10.7 “Lion” Cocoa 64 bit osx-10.6-64Apple Mac OS X 10.6 “Snow Leopard” Cocoa 64 bit osx-10.6-32Apple Mac OS X 10.6 “Snow Leopard” Cocoa 32 bit Out of the listed platforms, Macs are the most expensive and least reliable for CI purposes, so it would be really great if we could cut these down a bit. At least testing 32-bit OSX 10.6 in CI is probably a waste (?) I would like to go even further and do Qt 5.0 CI with OSX = 10.7 only. Older OSX could still have some release testing if it's perceived as valuable. It would indeed be good to keep the list of reference configurations shorter. I moved 10.6 to the second table (platforms we would like to support). (Well, I believe Tier 1 has been so far defined to be included in the CI, but anyways.) Again, I think suggesting that OSX 10.6 be dropped from the CI for Qt5 is premature. Heck, 10.7 has only been out a few months and there's still plenty of reasons why people would be cautious about updating to it, especially in the Enterprise world. The Qt 4.7 branch does not formally support 10.7 (you get warnings to that effect when you compile with it). The Qt 4.8 branch does support OSX 10.7, but Qt 4.8 hasn't even been released yet. It would seem prudent to keep OSX 10.6 in the CI for a while, at least in the initial stages of Qt5 to ensure that there are no compatibility surprises. I'm well aware of the cost of having to support OSX builds (we have to do likewise for our own software), since you can't legally virtualise it like you can the other platforms. Maybe someone with friends at Apple can convince them to sponsor a build server or two for you? :-P -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Documenting the scope of Qt 5.0
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 selfish reasons and I honestly have no idea who cares about it :) I would like to require 10.7 for developing (with) Qt 5. My impression is that most developers are running that version anyway and I would rather not have to maintain 10.6 support during the Qt 5.0 development. 10.6 support can be implemented later on if someone is interested in doing the work, but I'm hoping this won't be a big issue by the time we get to the Qt 5.0 release. While clearly this would make life easier for some developers, it's just too premature to move on yet. Lion has only just been out a few months. As I understand it, Qt5 is supposed to be aiming for a date sometime next year. That would mean that you'd be dropping support for a Mac OS version that was the latest up to only about a year before you drop it! I don't know that there would be too many cases in Qt's history where it dropped a mainstream desktop version so quickly.. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
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 that means I cannot even run my apps in a virtual machine such as VirtualBox on a Mac in a decent way (and yes, I AM cross-developing a lot in VirtualBox, for both Windows and Linux)! You are not alone with that combination! Actually, VirtualBox is just about there for OpenGL. It claims to support OpenGL 2.1 now, which theoretically should be sufficient for what Qt5 is aiming for. There's a small number of omissions which have been reported in their bug tracker, so if someone wants to push to have that bug addressed, you will probably have a viable VirtualBox option for OpenGL by the time Qt5 comes out. The bug ticket can be found here: https://www.virtualbox.org/ticket/8275 I know at this point it's already too late I guess, the QML-ification of Qt is already progressed to far. At least that had been my expectation half a year ago... and who knows, maybe I AM one of the very few people left trying to stick to the good old working technology, and desktop apps as we know them are dying out. Every application will bring along its own look and feel and usability concepts and that's what people want (or the developers at least)... then so be it! 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. Consider Autodesk - they rewrote their Maya package to use Qt for their 2011 release. I can't see them switching to QML any time soon just after expending all that effort, the cost in terms of time and additional development would be hard to justify. Maya is also very heavily dependent on OpenGL and being what it is, interactivity and overall performance are both crucial to its success. Now consider that Maya is THE package for film special effects in the movie industry (read: big $$$) and hopefully that will give you some reassurance that you have some relatively heavy hitters who should be sharing some of your concerns. ;) -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
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 they make that noise? Remember that Nokia has freed themselves of the commercial Qt sales and support business. That freedom is now being used for experiments with new approaches. There are service providers for classic QWidget-based programming but when it comes to new developments the market still has to be established. Hi Harri, I understand why you might also have some interest in this area (we are one of your customers!). Since I have no affiliation with Autodesk, I don't want to speculate on any specifics here. My point is more that Autodesk obviously made a business decision to rewrite Maya to be based on Qt, specifically its QWidgets. They surveyed their community of plugin developers more than once to gauge interest before they did this and since they went ahead with it, one can assume they deemed it worth the effort. Should they encounter problems with Qt's QWidgets where those problems have a strong negative impact on their product, they will simply have to find a way to address them. Being a big company (hence more $$$ and manpower), they should have more options open to them than a smaller business might. Whether they would find working through Digia to be the most effective or whether they engage with the wider Qt development community more actively, my main point is that their n eed to keep their customers happy will drive them to find a solution. And they should have the means to do so. Currently, they rely on the LGPL version of Qt and they make available all their customisations on their website. Their community of plugin developers also rely on the LGPL version as a consequence. One would hope that the rest of the Qt community would benefit from any steps Autodesk found they had to take. I'm just using Autodesk as one example here, purely because I'm more familiar with them (we are part of the community of plugin developers for Maya). I don't want to distract from the main discussions on this list. I was more hoping to simply point out that there are plenty of companies that rely on Qt's current QWidget functionality. For those who can't or don't want to change from QWidget in the medium term, there will be a collective need to see the QWidget-based capabilities maintained at least at some modest level. Those with the deeper pockets are probably more likely to have more options. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Command line parser in QtCore?
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 format definition. KCmdLineArgs and KCmdLineOptions from kdecore do exactly that for KDE programs. I don't have time right now, but perhaps someone wants to pick up this task? Hello Stefan Speaking as QtCore's maintainer, I'll reserve the decision until I see your proposal. A while back, we also found ourselves in need of decent command line parsing. It kinda surprised me that Qt didn't offer anything already in this area, since it seemed like the sort of thing that Qt would normally provide. So we considered our options. Our apps are not KDE apps, so we were not able to look there for a solution. We also do not use boost (let's not debate that, it's not the point of this post), so we were not able to use their solution either. In the end, we decided we needed to write our own, which we did. At the time, I had the thought that if we do it right, maybe one day we could consider contributing it back to become part of Qt. Funny how things come around.. Let me state a couple of things before going further. The code in question is 100% our own, so no issues with copyright and contributors, etc. I'd just have to get formal approval from our legal people to release it (that would take time, but since this code isn't particularly novel, I think I can get that approval). Our solution currently supports the main needs for a command line parser, but it won't have every bell and whistle people might want. That said, I don't think it would be particularly difficult to add support for the main omissions. 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 people. In the meantime, I think the interface of the class is probably enough to get some feedback on whether people think this has the potential to be a viable candidate for a command line parser for Qt: http://pastebin.com/45PiHzLA Note that the code currently does not adhere to the Qt coding guidelines (it follows ours instead), but if we do end up contributing it to Qt, then it should not be too difficult to bring it into line. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Command line parser in QtCore?
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 string
list merely specifies the names to give the parameters in the usage/help
message.
Type checking could be added easily by the client where it is needed. If your
subclass wants to operate on specific types, then the neat way to do it would
be to add a member function to your subclass to encapsulate that conversion.
Your validate() function would normally handle checking whether parameters that
need to be convertible to a specific type can indeed be converted. For example,
if there was a flag that was expected to have one parameter that was
convertible to int, it could fairly trivially be implemented something like
this:
int getSomeFlagParam1() const
{
// Would normally check that the parameter is convertible to int
// from within validate()
return QVariant(flagParameter(someFlag, 0)).toInt();
}
On 22/10/2011, at 5:18 PM, Иван Комиссаров wrote:
Oops, sorry, it can check flags:) didn't saw addSupportedFlag method:(
So only issue is type-checking (and number of parameters for flag)
22.10.2011, в 10:15, Иван Комиссаров написал(а):
Hi, your implementation can't automatically check if flags exists (you should
ask it manually instead, which is painful - adding new flags will require tons
of if-spagetti) and automatically print usage/help if something is wrong, also
it doesn't have type-checking of input parameters. Too simple, as for me.
22.10.2011, в 4:29, craig.sc...@csiro.aumailto:craig.sc...@csiro.au
craig.sc...@csiro.aumailto:craig.sc...@csiro.au написал(а):
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 format definition. KCmdLineArgs and KCmdLineOptions from
kdecore do exactly that for KDE programs. I don't have time right now,
but perhaps someone wants to pick up this task?
Hello Stefan
Speaking as QtCore's maintainer, I'll reserve the decision until I see your
proposal.
A while back, we also found ourselves in need of decent command line parsing.
It kinda surprised me that Qt didn't offer anything already in this area, since
it seemed like the sort of thing that Qt would normally provide. So we
considered our options. Our apps are not KDE apps, so we were not able to look
there for a solution. We also do not use boost (let's not debate that, it's not
the point of this post), so we were not able to use their solution either. In
the end, we decided we needed to write our own, which we did. At the time, I
had the thought that if we do it right, maybe one day we could consider
contributing it back to become part of Qt. Funny how things come around..
Let me state a couple of things before going further. The code in question is
100% our own, so no issues with copyright and contributors, etc. I'd just have
to get formal approval from our legal people to release it (that would take
time, but since this code isn't particularly novel, I think I can get that
approval). Our solution currently supports the main needs for a command line
parser, but it won't have every bell and whistle people might want. That said,
I don't think it would be particularly difficult to add support for the main
omissions.
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 people. In the meantime, I think the interface of the class is
probably enough to get some feedback on whether people think this has the
potential to be a viable candidate for a command line parser for Qt:
http://pastebin.com/45PiHzLA
Note that the code currently does not adhere to the Qt coding guidelines (it
follows ours instead), but if we do end up contributing it to Qt, then it
should not be too difficult to bring it into line.
--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia
___
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.commailto:Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
___
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.commailto:Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia
___
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
Re: [Qt5-feedback] [Development] Command line parser in QtCore?
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 people. In the meantime, I think the interface of the class is probably enough to get some feedback on whether people think this has the potential to be a viable candidate for a command line parser for Qt: http://pastebin.com/45PiHzLA Note that the code currently does not adhere to the Qt coding guidelines (it follows ours instead), but if we do end up contributing it to Qt, then it should not be too difficult to bring it into line. Hi Craig It's not just the coding guideline, it's the architecture. I'm not a fan of tool classes with virtuals... The usage() function should not have been virtual in the first place and could be easily made non-virtual without lose of functionality, so that just leaves validate(). One could potentially leave validate() as non-pure virtual if you want to allow subclasses to not bother validating, but I think that's sending the wrong message to developers. Seems like a poor compromise just to allow people to use the class without having to subclass it. If you want to validate your flags/arguments, you are either going to have to create a new class for it at some point (in which case why not use a virtual validate since you are creating a new class anyway), or you are going to have to inline your validation in the code where you make use of the flags. I guess that latter case seems justifiable, but I'd personally prefer to see all the argument handling code within the one (sub)class - one class, one responsibility and all that. But I do think there's value in making the class encourage dev s towards thinking about validation. I've already seen that in our code, it has had the effect that devs think about and implement validation as they go rather than getting around to it later. That said, if you have suggestions for how to achieve the same goals without using a virtual function, I'm open to it. The cases I've seen so far though just seen unnecessarily complex compared to the simplicity of the approach we've gone with. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Command line parser in QtCore?
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 license compatibility. My opinion here is just one among many. ;) It supports most of the usual suspects: long and short options, aliases (ie: you can treat 'h', '?' and 'help' as the same thing), parameters (even multiple), and optionally stopping at '--'. There's no type conversion - everything stays as a QString, but you can ask it what it found, in what order, what it didn't recognise and what was left over at the end! Sounds more complete than the code I put up for comment. It appears you'd still have to do validation outside of the class, but if I'm the only one who cares about that, it should be trivial for us to wrap your class with something that handled validation as well. Oh - it doesn't need subclassing, or use signals or slots. I'm afraid it's just old-fashioned calls to methods on an object! :-) That should keep more people happy. ;) It's 2 classes, 755 lines - including Doxygen comments. Who should I send a copy to? (I didn't want to spam the whole list!) For easy reference, you could just copy the header to pastebin.com and send the link to this list. That would at least allow us to review the API, which is probably more important at this first stage than the implementation. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
