[Development] CppCon 2014 Registration Open
Apologies for the cross-post (interest@ and development@), but registration just opened this morning for CppCon 2014, September 7-12, 2014 in Bellevue, Washington, USA. http://cppcon.org/ There is a Super-Early-Bird registration price of $695 for the week for the first 100 people. It would be great to see all of those claimed by the Qt-developers and Qt-users. ;-)) (I'm going, but don't let that dissuade you. ;-)) This is the first year this conference is being offered, backed by the Standard C++ Foundation with strong commercial support (such as by Microsoft, Google, etc.) --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
John Layt sayeth: snip, Qt printing API changes As noted on the Releasing list, I didn't get the OSX 10.7 blocker bug fixed in time, and using just the layout code without the plugin proved too much work to be stable in time, so *none* of this change set has made it for 5.3. snip, Thoughts? Knoll Lars respondeth: I¹ve been discussing a bit with Friedemann and Andy on IRC, and I¹m willing to give this change set an exception to the feature freeze. The reason is that I believe that this significantly improves our level of support in this area, and that the patch set is almost there. The API is pretty much ok now, so there won¹t be a lot more changes coming anymore. The main thing that¹s missing is bug fixing certain areas, and that¹s what the stabilisation period is there for. So please go ahead with your changes so that we can get them in within the next few days. +1 --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
John Layt sayeth: Hi, I've spent the last few weeks going over the current print support and trying to map out a plan to improve things. snip, Given my limited time, I've decided to take a different approach to try build the new code over the next few releases as a new set of QPA classes that are then used by the current public api in place of the old plugin code, before later being used for the new public api.snip, snip, aims for 5.3, 5.4, beyond snip, One major sub-task in there will be to try upgrade our PDF support to full PDF/A standard which may affect the timing. I have a work branch at [1] which implements the new QPlatformPrintDevice api for the 3 platforms and integrates it so far into QPrinterInfo and the Linux QPrintEngine. It also has some new classes QPageSize, QPageMargin and QPageLayout to remove lots of duplicated and error-prone page and margin handling code. Once the Windows and Mac print engine integration is completed I'll start pushing these for review. *ping*, this email has been sitting in my inbox, I just wanted to applaud this effort by John for Qt/PDF enhancements. Don't let silence make you think these changes are not greatly appreciated and desired! Thanks for your efforts here. P.S. If anyone wants this completed sooner, I'd be happy to discuss sponsorship to allow me to work on it full-time for the next 6 months :-) That was the delay ... they said not at the present time. ;-( Since they have Executive-Style-Hair, I'm sure there was a good reason from which I am mercifully spared. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt.vector3d() and friends
Sean Harmer sayeth: Hi, during the development of the new version of Qt3D's QML API we have come across an interesting (well if you like that kind of thing) problem. The issue is that at present the QML value type helpers for types such as QVector3D are provided by QtQuick meaning that we have to do import QtQuick x.y to be able to use them. There may well be cases where people wish to use Qt3D without QtQuick but we still need to be able to use these value types from within QML. So should we: 1) Just tell users to import QtQuick everywhere 2) Replicate the value type helpers to Qt3D 3) Have some common way of providing these e.g. from QtQml 3) seems the most sane to me but of course is a change from the existing approach. 1) means we force a dependency of QtQuick on Qt3D for any given scene and means that users will get all of the 2D scenegraph stuff contained therein even if they don't want/need it. 2) Is bad as it's copy/paste coding and we would need to use a different object name that Qt (as in Qt.vector3d(0,0,0)) to prevent collisions if someone decides to use both QtQuick and Qt3D. Thoughts? Agree with Sean: I strongly support the (3) approach. I suppose (1) could be a temporary work-around until the (3) change is fully implemented, but I think we should be headed-towards (3). --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: [Interest] [ANN] C++Now 2014: 5 Days to Submissions Deadline
snip, C++ Now 2014 Conference Thiago Macieira wrote: Anyone else wants to submit this time? This year, as representatives of the Qt Project, we had Charley Bay, Tony van Eerd and me. I'd like a few more Qt devs showing up and presenting our more... ahem, pragmatic / conservative... solutions to other C++ library devs. This was my first time at the C++Now! conference in 2013 -- previously named BoostCon. Here's a heads-up! for the this email list (my impressions) regarding C++Now!: (1) This is a really tough crowd. Very strong C++ language lawyers and practitioners, including many voting members of the C++ Standards Committee. Very high-powered/intensive discussions on current and future C++. By tough crowd, I mean you can't impress them with run-of-the-mill understanding or assertion. However, be aware that they are very clearly welcoming to attendees at any level of understanding, they work hard to have small-get-togethers and discussions with people at all levels of practice and understanding, and you will absolutely walk away a better software professional no matter your current experience. (2) Thiago had *THREE* talks accepted last year. Really super-human effort was required out of him, and all three were very well-received as strong technical talks regarding topics well-understood in the Qt community, but which were fresh and new to that group (including C++ practitioners, but also many Boost contributors/maintainers and C++ Standards voting members). So, if any Qt-developer/maintainer were interested in submitting, those experiences and challenges are uniquely fresh to this group, IMHO. The word, PRACTICAL! comes to mind regarding all things Qt, whereas Boost and the C++ language advancement IMHO would be closer to the words, CLEVER! or NOVEL! (3) Registrations will fill up quickly if you plan on attending (they cap at 250 attendees). If you're looking for a C++ conference, I don't know that there is a better one. (4) I'm intending on submitting a talk, Extreme OO In the Era of C++11. Not specifically a Qt-talk, but I'm thinking about a talk related to Qt/QML Plugins. (I spoke on them at DevDays-SanFran.) That might be a better talk for C++14, that is considering adding Modules as a new feature of the C++ language. I think it would be great to have more Qt devs/maintainers there... --charley -- Forwarded message -- Subject: [Interest] [ANN] C++Now 2014: 5 Days to Submissions Deadline Date: terça-feira, 3 de dezembro de 2013, 16:00:20 From: Boris Kolpackov bo...@codesynthesis.com Para: inter...@qt-project.org Hi, Only 5 days left before the submissions deadline for C++Now 2014! C++Now is a general C++ conference for C++ experts and enthusiasts. It is not specific to any library/framework or compiler vendor and has three tracks with presentations ranging from hands-on, practical tutorials to advanced C++ design and development techniques. For more information about C++Now, see the conference's website: http://cppnow.org/about/ Have you learned something interesting about C++ (e.g., a new technique possible in C++11)? Or maybe you have implemented something cool related to C++ (e.g., a C++ library)? If so, consider sharing it with other C++ enthusiasts by giving a talk at C++Now 2014. For more information on possible topics, formats, etc., see the call for submissions: http://cppnow.org/2013/10/21/2014-call-for-submissions/ Boris ___ Interest mailing list inter...@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest - -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Higher-Level Docs, possibly Qt-related (was: Re: Qt 4.8.6 Release Plans)
On Wed, Oct 30, 2013 at 1:59 AM, Konrad Rosenbaum kon...@silmor.de wrote: ** Hi, On Wednesday 30 October 2013 00:58:05 Calogero Mauceri wrote: The Qt documentation states that QDir::currentPath() returns The application working directory. Shouldn't the workind directory be initialized with the path the application was launched from? If that's not the case, which is the right way to obtain the working directory? (not the executable path as the QApplication::applicationDirPath() is returning) The current working directory is the directory the application is currently working in (I know, it sounds like a tautology). Or in other words: if you open a file with a relative path name, the current working dir is the one in which your program looks for the file: QFile file(myfile); file.open(QIODevice::ReadOnly); is equivalent to: QFile file(QDir::current()+/myfile); file.open(QIODevice::ReadOnly); You can change it with QDir::setCurrent or the underlying OS function chdir. At application startup the current working directory is the exact same directory that the parent was in when it spawned your process (this is somewhat simplified). This is the same behavior over all desktop OSes. The parent application is free to chose: it can simply refuse to care (result: your CWD is more or less random from your programs perspective; this is why an app started from a KDE desktop is almost always in $HOME, but sometimes somewhere else); it can assume you are a command line tool and want to work in the same place the shell is in (that's what happens if you start anything from a shell); it can try to be helpful and switch to the directory the binary is in (apparently what Mac used to do); or it can try to make things consistent by switching to the root directory (apparently what 10.9 does). In short: relying on the CWD at startup is misguided for most GUI apps. If you need to be in a specific directory: use some other mechanism to find it and then switch there, do not rely on being placed there by magic. Places you may want to be: * somewhere relative to your binary: use QApplication::applicationDirPath() - I do this in apps that have complex trees of files with data needed at runtime, apps that work in their own little universe * in the users home directory: QDir::setCurrent(QDir::homePath()) - desktop apps that interact with user files * in the exact same place you were started from: don't move - this is true for most command line tools (like qmake, moc, ...) * in the root directory - true for most server processes (daemons, middleware, ...) * in the temp dir: use QDir::setCurrent(QDir::tempPath()) - e.g. simulations that create some throw-away data only * in some dir that was configured by the user: read the config then switch - true for other server-like processes (e.g. automation software, ...) The tricky question we're trying to coax out of you: does QDir.current() really return an empty string or the root directory /? The former may indicate a bug on Apple's part, the latter is a perfectly valid place to be in. Konrad This is an outstanding (and thorough/exhaustive/detailed) post on this topic. Where can we put this in the Qt Docs or Guidance-Help for future users, and future Qt-internals-implementors? (I'd really like this saved-for-posterity so as to refer back to it in the future, and it seems like these are guiding principles to which the Qt internals should be able to refer in future discussions to justify design/behavior.) We do *lots* of Qt-based multi-threaded command-line apps, including server-and-monitor-processes, and it seems in today's distributed-and-multi-core-world there will be more of this by more users. Since Qt is the *only* real cross-platform solution at present (I'm not very excited about Javascript/HTML5), and Qt's libraries and APIs nicely bridge the issues on different platforms, it seems like Konrad's higher-level-understanding of this topic is *exactly* the value-proposition that the Qt Community is able to provide to the industry -- which is useful even if the reader is previously unaware of Qt. I understand this example topic (current-working-dir) is not specifically a Qt-library (or API) issue, but a cross-platform-and-cross-historical-understanding-of-the-problem issue. Do we have documentation that is a good home for these higher-level design/programming discussions, especially as it relates to cross-platform or cross-historical understanding, which often touches-on the issues Qt's APIs are intended to solve? Another example of this is Thiago's excellent discussions regarding binary compatibility. It's not a Qt-topic directly, but is an issue in which Qt leads-the-industry for understanding to establish convention. As Qt has impressively handled compatibility over a long historical period on many platforms, it is uniquely able to discuss at a higher-level these
Re: [Development] Disabling exception support in QtCore?
On Wed, Oct 2, 2013 at 12:39 PM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Wed, Oct 02, 2013 at 06:57:01AM +0200, Thomas Sondergaard wrote: On 2013-10-01 21:20, Thiago Macieira wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? As an outside voice, I'd like to point out that the rest of the world is using exceptions and removing whatever exception support there is in QtCore seems like a step in the wrong direction. Depends on what you define as rest of the world. If you mean by rest of the world other languages, like Java or Python, then yes, that world is using exceptions, and they are reasonable _there_. But if you check out what other C++ projects with Real World exposure do you'll find that they tend to be very cautious with exceptions - unless they simply outlaw them. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions is for instance pretty concise: We don't use C++ exceptions. They later give detailed reasoning and a conclusion including Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. [Side note: That's _exactly_ Qt's proposition: Being practically useful, not dogmatic.] http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions says In an effort to reduce code and executable size, LLVM does not use RTTI (e.g. dynamic_cast;) or exceptions. These two language features violate the general C++ principle of 'you only pay for what you use', causing executable bloat even if exceptions are never used in the code base, or if RTTI is never used for a class. Because of this, we turn them off globally in the code. Boost, which is not exactly notorious for old fashioned code, says at least on the topic of exception specifications some compilers turn off inlining if there is an exception-specification. Some compilers add try/catch blocks. Such pessimizations can be a performance disaster which makes the code unusable in practical applications (see http://www.boost.org/development/requirements.html#Exception-specification ) Note that even the C++ Standard rolls back a part of the previous support for exceptions in C++11 by deprecating dynamic exception specifiers which turned out to be (surprise...) impractical, see 15.4.17/Annex D or e.g. http://www.gotw.ca/publications/mill22.htm for historic reasoning. Lesson learned here: Being allowed does not necessarily make it usable. Size overhead for just enabling exceptions is (of course depending on actual model/implementation) typically cited as 5-10%, which incidentally matches Thiago's findings for Qt Core rather well. That's a pretty high price for a single feature in general, and especially so if it does not add adequate value. In my book removing the need to pay for features one doesn't use is a Good Thing more often than not. Andre' +1 to Andre' I didn't trim his post because there's a lot there, and IMHO it's worth re-reading. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
Thiago wrote: Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? No, and yes. ;-)) I vote not worth it, I would disable exceptions in QtCore. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New reference platforms in the CI for Qt5.2
Tony sayeth: snip, We'd like to change the reference platforms a bit. We have new platforms coming in and old ones are just that.old. snip, These changes would be targeted for Qt 5.2 and the current proposition can be seen here: http://qt-project.org/wiki/CI_Configurations (That web page has been badly out of date, but I'm automating the update process of it currently. I will also keep the Qt argument list up to date so that you can see what the differences are between the configurations.) snip, charley: This is a helpful page -- thanks! QUESTION: I see MSVC2012 start to show up for Win8 (only), and Win7 mostly stays with MSVC2010. Because Microsoft is pushing updates for their MSVC2012 (they are no longer updating MSVC2010, and it misses much C++11), our impression is that MSVC2010 is like Vista, where it's just easier to move-along to the next version. However, we will be Win7 for the foreseeable future (we have no current efforts investigating Win8). Thus, our (Windows) reference platforms are MSVC2008 and MSVC2012 (we have no interest in 2010). Are other people doing this too? Is there interest in moving to MSVC2012 at the expense of MSVC2010? Laszlo: A few months ago, we moved from 2008 to 2010 because we were using Qt4 for that project, and there were no official 2012 packages. I do not work anymore in that project, but the plan was to move to 2012 once the Qt 4 to 5 migration would take place. My impression is, and experience for that matter, a 2010 to 2012 change is a common ongoing practice for Qt 5 customers. I have not seen many people using 2008 with Qt 5. Agreed -- we looked at building Qt5 with MSVC2008, and I've seen reports on the web that people have done it, but I don't know that it buys you much. I should have been more clear for our (Windows) reference platforms: *- Qt4 + MSVC2008 (sustaining development only) *- Qt5 + MSVC2012 (existing and new development) ...where we have no interest in MSVC2010 (Microsoft seems to call it done with no more updates). Further, we will probably move quickly from 2012=2013, as it looks like a pretty good (stable) compiler with the current active love and attention by Microsoft. qtnext wrote: for X64, msvc2012 is fine, but it seems that for XP 32, msvc 2012 is not possible If I have correctly understand. Yes, we've been following the drama there as we have XP-embedded (32-bit) with Qt4. (Funny stories all-around there.) For the casual reader, the original MS solution was to use the 2010 compiler for XP, which you could launch from within the 2012 IDE. However, after community uproar, there have been several patches/updates by Microsoft to reverse the decision, and it now looks like 2012 officially targets XP: http://stackoverflow.com/questions/13130713/how-to-compile-for-win-xp-with-visual-studio-2012 http://stackoverflow.com/questions/14349793/c-program-written-in-vs2012-works-w-win7-8-2008r2-2012-but-not-2003-xp-32bit (In other news, porting from 2010 to 2012 is a little more work for legacy MFC users, as there was some shuffling in the AfxWin.h and Windows.h headers; however, the 2012=2013 port seems to be rather trivial, and the C++ improvements appear to be significant, which is partly why we want it as soon as we are able.) For the Qt community, though, my suggestion for reference platforms would be something like: FOR TODAY: *- Qt4 + MSVC2008 (sustaining development only) ...I see no real advantage for Qt4+MSVC2010, nobody is sustaining fielded releases with this combination, I'm not sure they should bother... *- Qt5 + MSVC2012 (existing and new development) ...I see no real advantage for Qt5+MSVC2010, nobody is sustaining fielded releases with this combination, I'm not sure they should bother... FOR SOON (AFTER STABLE MSVC2013): *- Qt5 + MSVC2013 (existing and new development) ...Could also provide Qt5+MSVC2012 for the transition, should be easy/cheap because the headers are similar (identical?), but I'd expect most people would move over to 2013 for new development, perhaps keeping 2012 for sustaining... --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New reference platforms in the CI for Qt5.2
Tony sayeth: snip, We'd like to change the reference platforms a bit. We have new platforms coming in and old ones are just that.old. snip, These changes would be targeted for Qt 5.2 and the current proposition can be seen here: http://qt-project.org/wiki/CI_Configurations (That web page has been badly out of date, but I'm automating the update process of it currently. I will also keep the Qt argument list up to date so that you can see what the differences are between the configurations.) snip, This is a helpful page -- thanks! QUESTION: I see MSVC2012 start to show up for Win8 (only), and Win7 mostly stays with MSVC2010. Because Microsoft is pushing updates for their MSVC2012 (they are no longer updating MSVC2010, and it misses much C++11), our impression is that MSVC2010 is like Vista, where it's just easier to move-along to the next version. However, we will be Win7 for the foreseeable future (we have no current efforts investigating Win8). Thus, our (Windows) reference platforms are MSVC2008 and MSVC2012 (we have no interest in 2010). Are other people doing this too? Is there interest in moving to MSVC2012 at the expense of MSVC2010? --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML engine changes
Simon sayeth: snip, proposed integration of new QML Engine replacing V8 Chris replied: This is really exciting news! Good stuff! +1 I wonder how much performance delta there is between JIT and pure interpretted, with a tight enough interpreter loop, if you make some simplifying assumptions (eg, types can't change at runtime / enforce no property deletion or dynamic property addition to objects or prototypes / disallow eval()). snip, +1, I'm very interested in this QML-engine integration beyond what was possible with V8: *- Strong type safety *- Optimizations (e.g., object-paths) *- more/better JIT options *- more/better bytecode/packaging/deployment options *- more/better future QML tooling (e.g., runtime debugging/inspection around the QML-engine) Chris: snip,, but I personally think that weak typing is the major negative of JavaScript :-/ +1 Simon: I'm also not sure yet about the exact difference between JIT and interpreter, but type propagation is something that Erik has been working on, based on the assumption that while JS is untyped, QML is in fact strongly typed. That is one of those areas with a huge potential. +1 Simon: Roberto and Aaron). We've progressed rather well and in our wip/v4 branch in qtdeclarative we're now passing all auto tests (as well as the ECMAScript 262 test suite). So that's why we'd like to propose merging this work into qtdeclarative mainline (dev branch), in the coming days/week(s) in time for Qt 5.2 though. Chris: This confuses me a bit. Why isn't the implementation tuned specifically for QML, instead of being a fully-compliant ecmascript implementation? Simon: Because we want to continue to support the use-case of import Foo.js as Bar; I've personally used that for a little spare time app I wrote, when I was super happy to discover that a piece of functionality I needed was available as third-party JS library that I could just exclude. But spec compliance does not imply tuning, and indeed I think generally any optimization we do will most likely be geared towards QML, as long as it doesn't pessimize the regular JS execution. Ok, that makes sense, so I won't argue against it. However, I agree with Chris that ecmascript compliance isn't a big wish/need/goal for me. I'd prefer to give (design) priorities to: *- strong typing *- (tight) QML-engine integration with running system (e.g., internal QML runtime system with bindings is quite different than the mechanisms intended by an ECMA-script engine) *- performance (e.g, byte-code, JIT, optimized object-paths) *- deployment/packaging options (e.g., binary byte-code) And, of course, I totally applaud the removal of eval() and other runtime code issues that block iOS deployment (I'm not targeting that platform, I just agree with Apple's complaint about embedding V8, and don't want opportunities for malicious injection in my systems). Chris: And I think some extremely impressive performance improvements could be gained by integrating more tightly with the QML engine. Simon: Absolutely, that remains a goal (tight integration). +1, I support this direction. Chris: Something Aaron mentioned to me a little while ago, is the possibility of doing a two-stage binding generation (it's not too clean, but it's extremely impressive): build pre-optimized binaries; run the application on device; application emits the IR for the bindings during first time evaluation, back to QtCreator; collect the IR and do a reverse transform into C++ code; generate optimized binaries. All of the type information is generated/known at the time the IR is generated, so there shouldn't be any problems compiling the resultant reverse transform; you end up with super-fast bindings implementation, and no JIT required in the final binaries. If any bindings change at runtime, just use an interpreter to evaluate the expression. Simon: That's an interesting idea! Whoa... THAT'S COOL. I'm very interested in more on this. Please feel free to share thoughts on this topic or other experimentation along these lines. (This could be *extremely* useful; I could see tooling be put in-place to simplify/automate this process.) So this is a heads-up and of course a last call for objections :) No objection -- :/me strong supporter! Chris: Anyway, I'm really excited about this change. Congrats and thanks to Erik, Lars and yourself for your impressive work! +1 -charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] kdelibs coding style
Samuel sayeth:
A good reason for using the
Foo()
: x(0)
, y(0)
{
}
syntax for initializer lists after all is to make diffs easier to read
when adding or removing a member variable. The same argument could be
made for permitting braces for one-line if-statements.
+1, that's a really helpful style for the base/member initializer list.
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
Axel sayeth: snip, whitespace-only changes for consistency to coding standard +1 YAY, Axel! This is a personal wish by me -- consistency. Including for whitespace. I find it astounding the legacy-code-bases that essentially decide that they cannot be improved -- no such patches are welcome -- because it would require work, add merge conflicts, etc. While those are real issues, the result suggests the project *must* go stale, and become increasingly annoying/inconsistent. I work in such systems. And, that makes me sad. Oswald respondeth: snip, patch welcome, should be consistent, probably should be done periodically, and for incremental parts of the code base as they can be addressed Seems like a sensible response. Axel: snip, To summarize my suggestion: * accept partly style fixes (in either type or file space) * accept them on an a timely manner to make it feasible at all with regards to merge conflicts * intentionally ignore stuff in src/3rdparty I might even be interested in looking into the automatic style check issue, but can't promise anything. Sounds good. Long-term, the automatic-style-check thing (e.g., scripts to reformat upon check-in) would be ideal, but I realize that can be tricky. It makes sense that we would eventually get the whitespace-formatting into the tool-chain workflow, though. I like where the CI-system and review-process is going, and it seems like this is merely an extension of that. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
snip, no Qt3D for mid-March Qt5.1 feature freeze Sean sayeth: snip, summary of Qt3D API and internals push for Qt5.2 I also was disappointed that Qt3D would not make it into Qt5.1, but IMHO the details Sean (and James Turner) provided are quite excellent -- there's a lot there, and it makes sense to provide this think-it-through for the APIs. Nobody wants to rewrite their 3D to a new API shortly after the first release, and I'd assume some users needing the real benefit of OpenGL/3D would need those new APIs (see Sean's API/feature description). So, I support the Qt3D defer-decision, and I'll watch API development through the Summer (and probably play with early releases as it becomes available). BTW, I really like the new Qt release-schedules. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] issue tracker rights
Mitch sayeth: I think a lot of people are hesitant to contribute fixes because of all of the setup required to contribute, also (yeah, it's easy once you are familiar with it). snip, +1 It would be nice to make this, turn-key. For example, on platforms like Windows, it would-be-nice to have an installer that you could download, which installs a QtContributor.exe, which is a simple GUI to pull Qt modules or otherwise make easy the local-codebase management and compiling/linking/install of a module configuration. I don't want to make more-work for anyone, but I think a contributor-IDE with contributor-utility-help would be useful (enter/search-for/reproduce bugs, pull module updates so bugs could be reproduced/fixed/verified, etc.) If we want casual-users to find/reproduce/look-at bugs, a one-click-setup would be great, IMHO. Yes, once it's in-place, it's easy. But it's not easy getting it in-place. Also, many of us must maintain clean-reference development environments where we maintain last-released development in addition to (wanting-to) closely follow new Qt module development. An easy module-configurator tool would be nice for this. I'm thinking of something like a simple GUI on top of Thiago's Qt-module-selector/configurator-scripts. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Design review: Adapter layer, C++ to QML
I've implemented a C++ adapter-layer (mostly template-based) to expose
C++ objects to QML.
We are in the early-stages for its use, and (of course) the final-API
will significantly impact how we expose our (domain-specific) C++ classes
to QML.
My manager suggested I ask others what they are doing to solve similar
problems (C++/QML adapter layer). IMHO, this could reasonably be a
standardized adapter-API for generalized use in applications with rich
C++ classes that must be exposed to QML (that's us).
--
Design goals:
(a)- Expose individual C++ objects with minimal code
(b)- Individual QML-instances can contain a C++ back-end-instance
that is not shared with other QML instances.
(c)- Multiple QML-instances can share access to the same C++ back-end
instance, with coordinated updates (e.g., as one QML-instance triggers a
C++ object property-value-change, all QML instances are notified of
that change)
(d)- Enable nested QML-wrapped-object-access to nested C++ instances that
are natively stored (e.g., no refactoring of C++ code to incrementally
expose nested C++ objects to QML)
(e)- Expose sets of C++ instances to QML (e.g., through
QAbstractListModel) with add/remove notifications to QML
--
Conceptual design:
Each C++ instance is wrapped by a singleton-QmlBoxBack instance with
application-specific properties exposed. Many QmlBox instances will
reference that single QmlBoxBack instance for ultimate-state, and the
QmlBoxBack will maintain the registered-set of QmlBox instances, so
that when one QmlBox changes a property-value, all QmlBox instances are
notified of the change. Similarly, the QmlBoxBack instance is
charged-with explicit notification of all QmlBox instances when the
back-end C++ model changes asynchronously. (We are using this for
monitoring back-end instrumentation.)
For logistical reasons, a QmlBoxBacksManager is needed to manage the
(registered) QmlBoxBack instances, to preserve the singleton nature of
the QmlBoxBack for a give C++ instance.
--
High level design is:
(1) The following C++ key abstractions are implemented:
- QmlBox (derives from QObject)
- QmlBoxBack (derives from nothing)
- QmlBoxBacksManager (template base class)
(2) Application-specific type definition:
- Implement your C++ class (e.g., MyDog)
- Derive MyQmlDogBox from QmlBox to expose type-specific properties
- Derive MyQmlDogBoxBack from QmlBoxBack to propagate type-specific
properties
- Use macro to define MyQmlBoxBacksManagerDog (which parameterizes
QmlBoxBacksManager)
(3) Application-specific use:
- QML can instantiate instances, or reference instances on the C++ side
- QML is notified when items are added/removed from the C++ side,
which triggers instantiation of QML instances (e.g., through
QAbstractListModel semantics)
(4) Internal details:
- Each C++ instance is wrapped-by a SINGLE QmlBoxBack instance,
which owns or references that C++ instance (e.g., like a
smart-pointer)
- Many QmlBox instances are registered within a given QmlBoxBack;
when property values change, all QmlBox instances are notified of
that property-change
- All QmlBoxBack instances for a given type are registered with
the QmlBoxBacksManager for that type, which deletes the QmlBoxBack
instances when the C++ object is destroyed, and un-registeres QmlBox
instances as-needed.
SUMMARY:
- One QmlBoxBack for each C++ instance
- Many QmlBox instances reference a given QmlBoxBack
(5) Practical use:
- ...where myInstrument, laser, and wavelength are implemented
through application-specific C++ types:
Item {
color: myInstrument.laser.wavelength.color
}
- ...where a list-model exists to expose many instances of the
application-specific type detector, which has properties channel and
filter:
ListView {
model: myInstrument.detectors
delegate: Text { text: ( + channel + ) + filter.text }
}
--
QUESTIONS:
(1) Are you doing heavy-duty-wrapping of rich C++ models, without
refactoring the C++ code? What was the design, and did it work for you?
(2) Have you a critique for the design listed above (how to improve it, if
it seems a reasonable approach)?
(3) Have I missed similar approaches that already exist, which we could
otherwise use directly?
(4) Is there interest in formalizing this for wider conventional use by
the Qt community? (We are currently intending on using this for our code
base, but the adapter-layer itself is not specific to our domain.)
Thanks!
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Design review: Adapter layer, C++ to QML
Hi, Alan-- charley: I've implemented a C++ adapter-layer (mostly template-based) to expose C++ objects to QML. snip, Sounds like this is for developers using Qt, not working on Qt. qt-interest is the correct ML for that (although given the youthful state of QML, this could also suggest improvements to QML later. But we can worry about that later). Agreed -- although I'm tentatively suggesting the Qt-proper libraries offer this API layer natively (in the Qt distribution), as I'd assume most users with heavy C++ libs would need it. Still, your point is valid, so I can move lists with this discussion (if there's insufficient interest here). -- Design goals: (a)- Expose individual C++ objects with minimal code There are other related goals that could be involved in the C++/QML adaption layer. The last generator script I wrote for this ( http://alan.imagin-itis.net/?p=166 ) was about non-Qt C++ code (with a GUI focus), but I assume you're talking about exposing QObject subclasses in a Qt project from the start. Your generator script didn't focus on the instance-hierarchy exposed to QML, and that's what I'm focused on. (I like your generator idea, but much of our code likely requires manual consideration of what properties and instances are exposed.) Further, no, I'm talking specifically about exposing a massive amount of C++ classes to QML, within instance-hierarchies, when none of those C++ classes derive from QObject. (b)- Individual QML-instances can contain a C++ back-end-instance that is not shared with other QML instances. Is this just creating a subclass with Q_PROPERTY macros? The C++ instance has the reference-state, and the QML instance merely wraps it. The QML/GUI cannot instantiate the reference instance (the C++ back-end model manages all that). Further, with this design, no QML instances are temporarily-created to access a property. Rather, they always exist as a wrapper to the C++ instance, or they don't (it's the same QML instance each time properties are extracted from that C++ object). (c)- Multiple QML-instances can share access to the same C++ back-end instance, with coordinated updates (e.g., as one QML-instance triggers a C++ object property-value-change, all QML instances are notified of that change) Perhaps you should just be using the new QML Singleton type, used like so: MyType.myProp = foo; //Engine creates an instance of the C++ type first time MyType is used, all references use that instance. The QML model cannot instantiate the back-end C++ instances (they correlate to hardware managed by a back-end-model). Rather, we only want QML to reflect whatever the model is doing. (d)- Enable nested QML-wrapped-object-access to nested C++ instances that are natively stored (e.g., no refactoring of C++ code to incrementally expose nested C++ objects to QML) I don't understand what you're saying here. Do you mean that adding a QML adaption layer requires no changes to the backing C++ class? Yes: The QML adaptation layer requires no changes to the backing C++ classes. Further, we require a deep-object-instance-hierarchy of wrappers for the deep-hierarchy-of-C++-instances. snip, I'm not sure why you needed the multiple QML instances - single C++ instance thing in the first place. Even in Qt 4, you can have a single C++ instance that's exposed but as an uncreatable type. Just put that in your root context as myInstrument and you're good to go. We will have a (C++) Detector object with many properties, and there will be many GUI/QML views into that detector (it appears in the list-of-all-detectors, on a graphical drawing of the instrument configuration, in the list of saved/collected parameters, in the list of all-filters used, etc.) In all these cases, there is a GUI-representation of something, and the Detector-properties are what we want exposed: Voltage, filter, QC-status, fluorochrome, laser, etc. So, logically, a single Detector instance is implicitly displayed in many different ways in many parts of our GUI. Each display can be different. All of them must reflect the state of the *specific* back-end-C++-instance. With this current implementation, the properties exist in a single place -- the back-end C++ object. The idea of conveniently exposing sets of objects with QAbstractListModel like behaviour is interesting, but I don't think it should be mixed up with the exposing single instances question. We already had a thread on improving QAbstractListModel's utility in QML, which I think is a more promising approach. I'm very interested progress on, improving QAbstractListModel's utility in QML. I don't have specific needs. However, my specific implementation is a utility (template) base class derived from QAbstractListModel that *demands* the derived type implement an enum for the roles for extracting properties. So, my list-model implementation is merely a utility
[Development] [semi-solved] Qt5 moc error in combination with boost
There's a Qt5 moc error when using Boost, with a work-around. See: http://qt-project.org/forums/viewthread/22993 It describes Boost 1.49, but this work-around also works for Boost 1.52: ...leads to compile error (Win7/MSVS2010): C:/Some/Path/3rd/Boost/boost_1_52_0/boost/mpl/if.hpp(131): Error: Macro argument mismatch. Project : error PRJ0019: A tool returned an error code from MOC ..\..\Some\Path\MyClass.hpp Work-around, in ALL files that moc: //...USING BOOST, MUST GUARD INCLUSION... #ifndef Q_MOC_RUN # include boost/function.hpp # include MyClass.hpp #endif // Q_MOC_RUN We're not using much of Boost 1.52, but we *do* use some of the type/traits stuff (which triggers this error). There are a few Boost/moc errors/bugs reported in https://bugreports.qt-project.org/, but I couldn't find this one. Did I miss it, or should I create a new one? I'm specifically curious about when this might be fixed, as the work-around is annoying (I haven't looked into what the fix might be). Thanks! --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and QAbstractListModel
Alberto sayeth: Hi all! I'd like to make C++ models more usable from QML; in the net there are several blog posts illustrating how to achieve that, but IMHO it would be better if at least some of these handy features were in QAbstractListModel itself: - count property - get(index) invocable method, returning a QVariantMap mapping all the roles to their data for the specified index Alan respondeth: +1 from me, those would clearly make it more QML-friendly. Also, though not very often requested, we could add: - remove(index) which just calls QAbstractItemModel::removeRow() - QListQVariant items(const QString role), which returns the data for the role role for all items. I'm on the fence about adding those. Since they wouldn't be commonly used, maybe it would be better to wait until there's time for a more holistic 'models in QML' update (which likely means waiting a long while, but eventually QML and QtQuick will need to deal with the issue of full tree model support). The implementation for the above is fairly trivial, so I wonder if there's some other reasons why it hasn't been done or if it's just that no one did and a patch is welcome. To my knowledge it's the latter. There's a lot of Qt API which could be made more QML friendly, especially in this way (just adding properties and convenience functions, for when a user subclass is exposed to QML). Funny this should be posted -- I'm coding a wrapper for a bunch of app-specific QML/QAIM right now. I assume we are all referencing Chris' blog post from two years ago: http://cdumez.blogspot.com/2010/11/how-to-use-c-list-model-in-qml.html ...and Benoît's referencing blog from a year ago with some extensions: http://bsauts-en.blogspot.com/2011/09/listmodel-in-c-exposed-to-qml.html ...and stuff like QML read/write (role) updates: http://qt-project.org/forums/viewthread/21787/ ...and making a model a property of an item within another model: http://qt-project.org/forums/viewthread/6906 There's not tons of C++QAIM/QML blog posts out there, so please jump in if you know of others. Generally, I'm trying to understand accepted-convention regarding these, and implement my template-wrappers which look like: QAbstractItemModel = (derive) MyItemModel (abstract with signals/slots/properties) = (derived) MyItemModelBase (template with app-specific hooks possible) = (derived) MyAppSpecificModel (many of these) This is a pattern I've used quite a lot with Qt (others have also), and it works: - MyItemModel implements stuff I always want extended, has signals/slots/properties, and runs through moc - MyItemModelBase does NOT run through moc (it's a template, you can't), but has common implementation that may be overridden in application-specific-type-derived-cases. (Derived classes merely override the MyItemModelBase::SomeFunc()) - MyAppSpecificModel - may run through moc, but usually I don't need additional signals/slots/properties (anything needed was commonly provided in MyItemModel). What's interesting about the QAIM/QML thing (to me) is abstracting the concept of the Item-within-the-Model with properties/roles exposed to QML. Chris' example illustrated this with his ListItem (derived from QObject). But, I think it would more generically be handled with that common pattern I tend to use: QObject = MyModelItem (with signals/slots/properties) = MyModelItemBase (template, no moc) = MyAppSpecificItem (many of these) QUESTION: Alan seems to suggest the (C++) QAIM/QML might be changed/updated in the near-future (and that was the purpose for the question in this thread). Is that to handle the model or the item, or both? QUESTION #2: I *assumed* (perhaps wrongly) that QAbstractItemModel DID NOT have Q_PROPERTY() things because the Q_PROPERTY() is purported to expose attributes to QML. I see Q_PROPERTY() as an adapter-to-QML. So, it seemed obvious (to me) that all Q_PROPERTY() things would go into MyItemModel, and not the QAbstractItemModel itself. Any common-properties (like count() and get(int)) could similarly be in a derived QAbstractItemModelWrappedForQml. Is the intent to make it open-season on adding Q_PROPERTY things to other C++ classes, for those attributes to be exposed to QML? I'm not sure that's a good idea, because it seems like the act-of-wrapping/exporting to QML is a very different level API than the act of C++ interfacing with the primitive C++ class. (This isn't a strongly held view, it's just my current impression.) An additional design need I have is for generic-sets-of-things to be referenced by MyAppSpecificModel instances, so that adding/changing the set is reflected in the QML. I'm pretty sure this can be implemented in a generic fashion with the pattern listed above. I wouldn't do this work, or I would retire this work, if Qt-proper were going to take that on. My specific work is for these design goals: - App-specific model that
Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray
Glen Mabey wrote: Hello, For some time, I have been working on a QtCore-based class that would be a container class of arbitrary dimensionality. I did give a presentation on this topic at DevDays-CA: Olivier Goffart responded: Just my personal opinion on this: I do not think this class should be included in QtCore or even in a any module of Qt base. I think this is out of the scope of Qt. I do not see that many uses case for normal Qt applications. Perhaps it would be a better fit in a library that does numeric calculus. I attended Glen's presentation at DevDays-CA. His introduction in this thread is a good overview of his QNDArray class, but I'll add my impression to focus the discussion: Glen's QNDArray (template) class: (a)- approximates the Numpy module available in Python for multi-dimensional data sets (b)- is highly performant (e.g., native C++ with attention to native platform types) (c)- is designed for VERY large data sets to be stored/accessed in a native format (e.g., data access is logically starting at offsets with skip-levels between internal values) Olivier raises a fair point, regarding the nature of QtCore (what should be included in there?), but IMHO the QNDArray makes great sense in the Qt cross-platform-offering (some module). Specifically: (1) It is an enabling technology that encourages Qt/C++ use where other languages/technologies would have been used. Glen's class is the FIRST third-party implementation I've seen (ever) that we could actually use (we work with data sets in the GB and TB level, and time-sensitive performance is critical). If added to Qt, we would consider dropping our in-house implementations to use Glen's QNDArray (this is serious investigation at present). (2) Qt/QML is now heavily focused on OpenGL. We're looking at Glen's QNDArray to be the native data sets that would be manipulated inside the Modern-OpenGL-static-pipeline (great talks by Sean Harmer at DevDays-CA on what's involved there). IMHO, (2) is the stronger argument: Qt needs to provide strong support for users to write their geometry-shaders and vertex-shaders. This is mere raw data-set manipulation. It seems like Qt should provide some out-of-the-box data-set accessor/manipulator for those of us with very large data sets (and of course, it should be fast). So, I'm not picky about which module it ends up within, but I like the idea of the QNDArray in some Qt-proper module. The ideal scenario would be if Qt's OpenGL or charts or other higher-level Qt-proper modules interfaced directly with this large-data-set-object. Because it is a mere representation-format with no external coupling, I'd be fine with it added to QtCore, but I'd accept other suggestions. I agree with Olivier that the numeric calculus domain is somewhat un-bounded. However, it seems like Qt needs to provide a data-set *representation* format, especially since our job in Qt5+ is to implement OpenGL shaders (which are mere raw-data-set-manipulators). --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray
Robert wrote: If added to Qt, we would consider dropping our in-house implementations to use Glen's QNDArray (this is serious investigation at present). What stops you or anyone else from using QNDArray if it is maintained outside of Qt? Nothing (that would be a minor barrier). However, the issue is having a *representation* format that other Qt APIs use directly/natively (so I don't need to marshall/convert from our format to something other Qt APIs can handle). --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT with qws using CL compiler
amogh kudari wrote: Hi All, Currently I am using cygwin build environment with cl compiler. Is it possible to compile qt with qws using cl compiler on cygwin build environment?.. Thiago Macieira wrote: We barely support cygwin at all. We prefer mingw, which is like cygwin, but without the POSIX adaptation layer. snip, snip, I don't want to sound negative, but unless you have a REALLY strong reason to do this on your own -- don't expect us to help you with a Done codebase -- you may be wasting your time. I really recommend you reset your expectations, abandon QWS and Cygwin, and move on to Qt 5 and QPA with either Mingw or standard MSVC. RECALL: - Microsoft supported POSIX up to WinXP, which replaced it with Interix - Interix (WinXP and beyond) is-now-dead - The Subsystem for UNIX-based Applications (SUA) was deprecated by Microsoft after the release of Win8 Developer Preview, and will be removed in Win9: http://en.wikipedia.org/wiki/Windows_Services_for_UNIX We use the Microsoft SUA for the POSIX adaptation layer ... but it's incredibly slow and has many known problems. I don't recommend going there, and it won't be there in the future. So, I agree with Thiago: Using POSIX on Windows? Just Don't Try. Here's an interesting article from 2010 with a good history of POSIX-on-Windows that fears Interix may be dead, which we now know to be true: http://brianreiter.org/2010/08/24/the-sad-history-of-the-microsoft-posix-subsystem/ The operative term in those comments seems to be, abandonware. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
Unto all so did sayeth Alan:
What should enumeration declarations in QML look like?
Did respondeth Erik:
And, also important: how much slower is it allowed to be than the current
implementation?
I remembered that there was talk about enums in QML before, so I dug
around a bit, and behold:
The problem with enums is that we couldn't make them fast. They will
always be a lot slower than normal string literals. That is mostly because
we could not avoid the name lookup.
Text {
alignment: Alignment.Vertical | Alignment.something
}
there is no way for you to remove the name lookups for Alignment,
Vertical, and something. Also, there is no way for you to distinguish
Types (e.g. Item, Rectangle, and co...) from Enums (in our case
Alignment). That means, you cannot build the correct list of dependencies
when loading a QML Component.
Ouch. That is quite unexpected.
We seem to have multiple intentions regarding adding Enums to QML:
(1) Those with a native (C/C++) background may have thought Enum to be
faster than String (e.g., performance-goal)
(2) Some may prefer the cleaner-look by using an unquoted Enum over a
quoted string literal
(3) Some may expect a compile-time check for (valid) enumerated-values,
as compared with a run-time check with string-lookups (? this may not be
a real consideration depending on how the QML parsing engine works)
(4) Lack of Enums in QML is (another) example of how QML might be
considered a second-class-citizen (mentioned by Chris, another example
being composite types in QML are not backed by a QQmlType and thus are not
available in JavaScript as are types defined in C++)
IMHO, the performance is the biggest issue, as we have currently
work-arounds to enable enumerations in QML.
Some of the post-V8-engine discussion may address the performance issue,
at which point all of the above considerations could be achieved. (Lars
may comment on this?)
So: I want Enums in QML, but only if they are as-fast-or-faster than
string lookups. I'm quite happy to defer this feature until that can be
achieved.
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQml Loader API
Alan spaketh:
Finally Qt 5 brings better QtQml and QtQuick separation! Better, not
perfect. The main things I've heard are missing is dynamic
instantiation of non-Items. What I propose is a new element for the
QtQml module which provides that functionality. Note that while some
people have suggested that Repeater and Loader could just accept
non-Item delegates, they both provide visual item related
functionality. snip,
The big question about this API is whether it's better served with two
elements. I'm thinking it could be done with just a single element,
but maybe it's worth duplicating it to have a Loader-like one (with
just object) and a Repeater-like one (with just objects). Note that
Repeater and Loader have some GUI functionality that is different for
groups versus single objects - Repeater visually reparents all
children (only really useful for groups) and Loader controls the size
of its one object (only really feasible for one). Is it worth making
two separate types?
+1 for two elements, and strong support for the concept itself (QML
instantiation of non-visual elements).
It seems like a good idea to be able to do Loader and Repeater things
on non-visual elements (where setting size is not appropriate), which
is DIFFERENT for visual items (which visually re-parents, and sets
size), and thus we might want NEW TYPES for Loader and Repeater of
non-visual things.
This implies the following possibilities:
- (1) Loader (sets visual item sizing of new thing)
- (a) for visual things (have this now)
- (b) for non-visual things (want?)
- (2) Repeater (re-parents new thing, assigning into Item::children for
parent)
- (a) for visual things (have this now)
- (b) for non-visual things (want?)
Alan's proposal seems to be consistent with the current back-end
implementation:
QObject (NOT-visual-thing, has QListQObject* children)
- QQuickItem (visual thing, has QListQQuickItem* children)
- QItem (visual thing)
Alan's proposed code:
snip,Prototype API of the Instantiator element:
QtObject {
property bool active: true
property
property model model: 1
property Component delegate //Note Component is in the QtQml module
property QtObject object //Convenience for objects[0]
property listQtObject objects
}
This is interesting in the case where a QML element wants to dynamically
instantiate QObject-items (such as from a C++ model), but the QML element
is not a visual-thing.
For example, a QML-delegate (if present) MIGHT NOT be a visual thing,
such as providing a delegate that merely exports-bound-properties from the
C++ object specific to the needs of a given QML application (whereby many
QML applications may share the same C++ back-end-model, but each
renames/translates or subsets the properties specific to the needs of
each QML application).
Another example might be a C++ model of QAction instances (with no visual
consideration) which is exposed to QML, where the QML does not show them in
a view, but rather, associates them with a distributed set of items
(like buttons) that may be visually associated with other (visual) parents.
I re-wrote Alan's proposed code quite a few times, but could not improve
upon what he wrote.
My current impression is that if we had this non-visual-item-Repeater, it
solves a problem whereby the C++ business logic could be sliced
arbitrarily, and I'd never need a (future) QML model that was anything
other than a flat-list (as we have now).
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
People keep asking for enumerations in QML. snip,
Now I don't know when these issues will be
resolved, but there's an important discussion to have before it can
even be scheduled: What would proper enum support look like in QML?
snip,
I'd prefer:
Item {
enum Weather { Raining, Sunny, Cloudy }
property Weather weather: Weather.Sunny;
}
+1 for enums (whatever the reasonable syntax).
If they are added, IMHO they should be available for identifying
States/Transitions, since the string-labels that are currently used are
logically enum values.
And, I'd rather my QML code use the token-unquoted for identifying
states-and-transitions, because I'm lazy (less typing) and it looks
cleaner (QML was brilliant to not quote the keys, like does JSON). ;-))
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Convenience Imports in QML
Alan spaketh:
I've heard complaints about all the varying version numbers used in
QML imports. I don't think we can just standardize, for example on
5.0, because the whole point of modularization is that modules don't
have to move in lockstep anymore. But I did hear an idea at Dev Days
to help confuddled users (thanks Jens!). Theoretically we could have
some helpful convenience imports the same way there are conveience
includes in C++ (like #includeQtCore). So what do people think of
having convenience imports? These would be imports which contain zero
types, but act like a bunch of other imports. For example, there could
be a convenience import like
import Qt 5.0
Which imports all QML modules in the Qt Essentials released with 5.0.0
(except QtQuick 1). It would be the equivalent of
import QtQml 2.0
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Particles 2.0
import QtAudioEngine 1.0
import QtMultimedia 5.0
import QtWebkit 3.0
snip,
This is tricky. I think all solutions would be imperfect, but I like the
convenience import-functions.
I like the idea of the convenience-import, because my code would
just-work with a known-cocktail that is established to work together:
//FILE: MyItem.qml
import Qt 5.0
Item {
// ...my stuff always works, this file is rarely touched
}
I understand others' concerns about load-performance. However, people
don't *have* to use the convenience imports. The issue is that much code
merely wants to use the latest-working-cocktail of code, or the
latest-version of a component, because they don't access the properties
directly (the local file will never break), or their access is minimal (and
it's too much work to keep touching files merely to update the import
version number).
Another option might be a special-version-number like latest that
resolves to the latest-version:
//FILE: MyItem.qml
import QtQuick.Window latest
Item {
// ...my stuff always works, this file is rarely touched
Window {
id: window_a
}
Window {
id: window_b
}
}
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Convenience Imports in QML
I understand others' concerns about load-performance. snip, The concern about load-performance isn't about users now have an informed choice between faster development speed or faster runtime speed. The concern is about people using import Qt 5.0 because it's convenient, and then getting upset when it's too slow at runtime and they don't realize why. We can offer power users this convenient choice when we have a solution for ensuring average users don't accidentally cripple themselves without knowing what they did wrong. Fair point: Be clean up-front so you don't need to clean up later. Another option might be a special-version-number like latest that resolves to the latest-version: // (fictional) import-latest: import QtQuick.Window latest You're basically asking to opt-out of the versioning system. If we thought that was a good idea, we wouldn't require all module imports to be versioned. Well, golly, when you say it like *that*... ;-)) Short explanation is that your deployed applications could easily break and there's no real need to skip versioning. Long explanation is here: http://alan.imagin-itis.net/?p=322 . That link is a good read. You addressed this point (in the link above) with: *Q:* What if I always want the latest and greatest? *ML:* You don’t. snip I now withdraw my comment, and concede that specific-versioning-on-import is a, good idea. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
snip, updating the QtService Component , I would like to open a new Qt Playground project to create a new equivalent +1 IMHO this would be a cross-platform useful module that I'd vote to ultimately end-up within Qt-proper. Disclosure: I traded emails with BRM off-list, and would like to help. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone mbroa...@gmail.comwrote: On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay charleyb...@gmail.comwrote: snip, updating the QtService Component , I would like to open a new Qt Playground project to create a new equivalent +1 IMHO this would be a cross-platform useful module that I'd vote to ultimately end-up within Qt-proper. Disclosure: I traded emails with BRM off-list, and would like to help. --charley Would you guys like to get into your design a little here? Did you mean that you would be creating two classes: QCoreService/QGuiService (though I'm not sure why one would want a gui service, maybe to use some of the graphics classes?). Also, could you speak to your ideas for the pluggable backend? Will you target systemd as a reference implementation? Matt [UPDATE], I was typing this while BRM responded. Read his email, it's a more specific design-ideas answer. However, I'll still reply with this email, since it talks about other higher-level issues-to-be-resolved, and brings the discussion current with what this proposed-playground is to do. [...what follows is what I was typing when BRM responded...] I'm second-seat (Ben/BRM is taking the lead). I defer to Ben/BRM for any corrections needed from malicious dis-information created as a result of this email, but here's a bullet-list of early thoughts: TODAY: (a)- The existing QtService is an add-on (not in Qt-proper), but people use it, and it serves a purpose to help provide a cross-platform service/daemon application API. (b)- The existing QtService works for Qt4x (likely needs-work to support Qt5) GOAL: After this effort, the result could be considered as a Qt5+ add-on for cross-platform service/daemon support, and possibly considered for inclusion in a future Qt release (e.g., perhaps Qt5.1+) POSSIBLE ISSUE: An unfortunate name collision (or user-confusion) is possible with class names created from this effort to provide a cross-platform service/daemon API, and those classes within the Qt Service Framework (which has a different purpose). USE GOAL: Very simple API to create a service/daemon (server-side), or client-process instance (client-side), such as merely instantiating an object. Current thoughts are to make this similar to merely instantiating a QCoreApplication or QGuiApplication. (For example, the user may merely instantiate from within main() a service-application-instance or client-to-service-application-instance). (SEE BRM's EMAIL FOR MORE DETAIL.) CURRENT DESIGN THOUGHTS: Speculative design is to: (a)- Make QtService (currently a template) a non-template (e.g., directly-instantiable) (b)- Improve shut-down semantics (e.g., current QtService just does a hard-kill on the server process, so no waiting/clean-up is performed, including within threads; this should handle a graceful resource clean-up) (c)- Improve robustness (e.g, better use of waits/resource clean-up; the current QtService works, but can leave applications broken at times) (d)- Implementation likely enforces a local-to-the-same-computer client/server inter-process communication (e.g., using something like QLocalSocket) (Might consider future expansion of non-local-to-the-same-computer). (e)- Platform-specific registration (e.g., properly handle systeminstall/update, system-start, on-demand-start, system-remove/uninstall, etc.) Would by-default support a command-line interface, and maintain compatibility between client/server process. Further development could add other interfaces (e.g., systemd) to integrate with other systems more easily. FWIW. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Examples packaging
Maurice spaketh: snip, My question is, what are the benefits compared to picking the example source code from the source package directly. Does anybody really want to have prebuilt binaries in the examples directory? Current assumption is that you go through the list via Qt Creator and build the examples are required for testing purposes. Alan respondeth: To my knowledge the point of having prebuilt examples is for use in QtDemo. This demo application did a great job showcasing Qts functionality even before developers chose to start an IDE. +1 IMHO, it's quite important for people to be able to see-and-run the demos before starting the IDE, before doing anything. With the new dynamic interfaces, and rich network capability, etc., these demos should really *attract* developers to adopt Qt, and we want to make that introduction as easy-and-exciting-as-possible. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms
Friedemann said he'd like to have msvc 2010 64 bit as reference platform, maybe replacing msvc 2010 32 bit. Really? I would assume that 32-bit is still a significantly-large audience that we could *add* 64-bit, but that we likely would need to keep 32-bit (for a while). Have developers really cut-over to 64-bit *deployment*? (We only deploy 32-bit to enable a single set of binary-installers for many target platforms, including embedded, even though yes, some of those target platforms happen to be 64-bit.) If msvc 2010 32-bit is dropped as reference/tier-1, then we would probably need to update our deployment to have two sets of installers (32-bit because of embedded needs, but also 64-bit because that would be the new reference/tier-1). This is only an observation (not a criticism) -- we'd like to take our embedded to 64-bit eventually, but I'm unsure of when the generic-user-base will no longer have a plethora of 32-bit-Windows user operating systems. So, question: How many developers target 64-bit Windows exclusively (not 32-bit-Windows)? (Has that day come?) --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms
Kai spaketh: The list of reference Tier 1 platforms at http://qt-project.org/wiki/Qt-5#Platforms is somewhat out of date ... Here is a new proposal snip, Seems fine to me. An aside -- serious suggestion: We are successfully using the, MSVS2010, SP1 compiler within the MSVS2008 IDE using the steps found here: http://www.codeproject.com/Tips/105011/Using-Visual-Studio-2008-IDE-with-Visual-C-2010-co IMHO, the MSVS2010 IDE is, badly-broken and quite unusable for our needs. REQUEST: For the Tier-1 MSVS2010, SP1, Win7-32bit release, IT WOULD BE NICE if QMake would still have the OPTION to generate MSVS2008 *.vcproj instances. Please. Pretty Please. And then, I will send you home-made cookies. Every month. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of WP8 port
Tuukka spaketh: What comes to WP8 we believe it is more important to tackle Android and iOS first, as discussed earlier. It does not mean we do not care about WP8. There is just so much more user base in Android and iOS that we think it would be outright stupid not to address those. +1 As a commercial customer, we're keeping an eye on WP8, but Android and iOS have already demonstrated strong demand by our users. We're very interested in those going to Tier 1, and we expect it to be very positive for the Qt community as-a-whole. Further, it looks like WP8 really requires MSVS2012, and we have it in-house in evaluation-mode (e.g., porting code, qualifying it for our needs). IMHO it's very understandable why some people don't/can't adopt the new tool-chain within a few weeks of its release, and may wait for Service Pack 1 before trusting it for production use. Given all the news about Win8/WP8, it makes sense to start looking at it, and (of course) with all the Microsoft-go-native it makes sense that Qt would straddle all those platforms. But, the here-and-now-real-world-demands seem to suggest a very obvious allocation-of-scarce-resources to established platforms while the Win8/WP8 tool chain shakes-out and the market-adoption (user-demand) is better understood. @Davide, honest questions (we're looking at these too): - Would you intend development for WP8 on anything other than MSVS2012? (It was only released a month ago, when will you be ready to trust it for production use?) - Are you intending on targeting WP8 exclusively (not Android nor iOS)? (Is that driven by your market segment, customer demands, or are you only ready to support a single target platform?) I'm interested in these answers, as these has been active discussions for us lately. Thanks! --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On the reliability of CI
Shawn Rutledge spaketh: Personally I think the fundamental problem which CI could do better is to triage problems. snip, I think when a test fails, the CI system should try to break down the patch set in some way. For example it could divide the patch set in half, arbitrarily, and see if half of them will integrate successfully, then the other half, and continue this recursively until the one bad patch is found, or at least a smaller subset. snip, But this is a technical problem, seems like it should have a technical solution. I can only imagine for example that Google has a better system for internal development, I just don't know what it is. Agree with your post. It's work, though. On Google, I've read extensively about their internal engineering tools (build, test, regression, distribution, etc.) The Google Engineering Tools official blog spot is: http://google-engtools.blogspot.com/ There's some good stuff in there about CI systems, and it's similar to what you propose. Example blog post there: http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html Summary for those that don't want to RTFA: (1) Check-ins trigger build-and-test activity before is-found-good (2) While previous build-and-test activity is in-progress, new check-ins are queued (3) Build-and-test is predictive-optimized to build-and-test only what is impacted by the actual changes (only run the needed tests, not all-the-tests) (4) Upon fail, it does the unwind-the-grouped/queued check-ins to find the failed commit, and remove it (allowing the others to pass -- same as what Shawn suggested) Google claims this system works on their C++ code base with 20+ code changes per minute, and 50% of the files changing each month. My conclusion: Brilliant. But, sounds like dedicated resources required to get the tooling in place, and to maintain it (probably dedicated resources in an ongoing basis, we all know regression-test maintenance can be expensive despite it being essential). --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
Wow. I don't usually rubber-neck as I drive by car-crashes, but I must say, this has been one of the more fascinating email chains. Not because of content; but rather, because in my introverted I'm-so-lonely! world, observing humans-being-human has recently become fascinating to me. I had to LMAO when Godwin's law got invoked so fast. Must be a record. My summary (for those that don't want to read further): You're a smart guy, but you're hurting those you're trying to help. Your message is lost because it is so loud, that no one can hear it. I personally would be sorry to see you go, but I understand that such a departure can be a positive healing experience for both you and the Qt community. Since your email announces your departure, I'm responding. I'm not trying to feed-a-troll, and you must admit that you qualify. However, I have specific observations related to the discussion: technical, governance-oriented, and psycho-social. The casual reader will want to stop reading now. On Fri, Oct 19, 2012 at 9:18 PM, d3fault d3faultdot...@gmail.com wrote: On Fri, Oct 19, 2012 at 3:37 PM, Knoll Lars lars.kn...@digia.com wrote: This is just wrong, and I'm getting tired of your ramblings on this mailing list. Just because you send something to the ML and people get tired of answering you doesn't mean your proposal is accepted. I was writing that tongue in cheek and mocking Thiago. Sarcasm You. Ouch. There you're just being mean, as the relational expression does not expand upon your defense/justification. It's really hard to discuss (an implication of an ideas-exchange-back-and-forth) if the sides do not respect each other (there's no point to discussion in that case). That's where we are now. You're frustrated, trying to reverse a lack-of-good-faith (as perceived by at least one side) with further evidence of lack-of-good-faith. My impression of you: You're really smart with significant Qt use-history. I've watched you in many threads on this list, and it's clear you know a lot, and you've made helpful comments/responses on questions including quite technical aspects of Qt internals. I don't agree with you on some project-direction-issues like QWidget/QML, but see the chance for common-ground with some reasonable concessions (e.g., an eventual all-C++-API). However, my summary report would have to be: 15% -- Devil's advocate arguing 30% -- Constructive answers/discussions-to-technical-questions 55% -- Bomb-throwing We have a fully worked out proposal by Rich on the table that many people agreed with, and we'll stick with it for now. His proposal is alright, with the exception of handling incoming vulnerabilities. He didn't even discuss the subject, so what do you even mean sticking with it? Lars, in his role of Chief Maintainer, is trying to conclude a topic after extensive discussion. His job is significant only in those cases where consensus cannot be reached, but a decision is required. This topic appears to warrant that intervention, so Lars is legitimately exercising his duty. Your concession is interesting: His proposal is alright, with the exception of handling incoming vulnerabilities. That was not previously clear to me in the discussion (I may have missed that, there was lots of exciting talk to obscure the point), but this statement is quite clear and constructive. We can focus on the single topic of disagreement (incoming vulnerabilities). ISSUE: Identified vulnerabilities could go to a public-security-list or closed-security-list. PRECEDENT: Significant (large) community (open-governance) projects have done either; examples in this thread include Linux Distros using closed-security-lists, as was tentatively-agreed as the direction within the Qt-community (so that decision can't be crazy-stupid with such precedent). TRADE-OFF: (a) a public-security-list invites script-kiddies to cause mischief without working hard, as exploits are publicly-announced/available before fixes (b) a closed-security-list is a layer requiring mischief-makers to work-a-little-harder to get into the list, and maintain a presence; the benefit is that they may have strategic access to exploits between the announcement-on-the-closed-list and public-disclosure (at which point there would be a fix). COMMUNITY CONCERNS: There's a lot in this section, and this is your main argument. However, I'll put forth a few. (a1) Interruptions/noise is higher with public (v. closed): As an administrator/user, announcement of a security issue without a fix is likely not-actionable, or the shut-my-stuff-down action is a costly over-response. I must await a second announcement, and the first announcement is noise to which I cannot respond, but against which I am now liable (e.g., you've added to my noise, and to my liability, without a benefit). (a2) Risk/exploits are higher with public (v. closed): The script kiddies are invited to cause mischief with publicly-announced
Re: [Development] How about the future of qbs after Nokia sells Qt to Digia?
Yuchen spaketh: I noticed Nokia stop developing qbs for a long time, and qtcreator's wip/qbs seems stop developing too. And for now Nokia sells Qt to Digia, I want know how about the future of qbs? If the Digia give up qbs, I will choice CMake as my build system. So, any news or commens are very welcome! I was wondering this too -- Digia, care to comment? I know there are lots of things going on, so it's likely details like the qbs effort may take some time to plan-out. However, it would be good to get-a-feel for direction for an effort like qbs. Even if the answer is, We're looking into it, and will get back to you later, that's fine. However, if the decision is made, please let us know. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Message to the Qt Community on behalf of Tuukka Turunen
We just renewed our Qt Commercial licenses through Digia. Happy to do it. Good value. Great code base. Tuukka has been great about Digia's very-public-goal to keep the *same code* in Qt releases (Commercial and at qt-project.org). That's what we want too. Great stuff! --charley On Thu, Aug 9, 2012 at 12:28 PM, Karl Ruetz karl.ru...@ruetzdogz.comwrote: ** All I can say is, Thank God. I should say, Thank Digia. Karl On 2012-08-09 02:39, Wilhelm Taht wrote: I’m sending this to you on behalf of Tuukka Turunen. Dear all, I am happy to let you know that today Digia announced its plans to acquire the Qt technology and assume main responsibility for all Qt activities from Nokia. This includes driving forth the Qt Project together with the community. The acquisition also includes a part of the Nokia Qt team. Read the full blog post for more details: http://www.digia.com/en/Blogs/Qt-blog/Tuukka-Turunen/Dates/2012/8/Digia-extends-commitment-to-acquire-Qt-from-Nokia Best, Tuukka Turunen Director of RD Digia, Qt qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can we have id's in dynamically generated elements for the next QML?
Thanks, Alan -- very rich email that helps me think about declarative-model-instance-handling. Alan spaketh: snip, What is QML declarative-best-practice for models? Reusable components/delegates, where data propagates in one direction, is the best-practices pattern that obviates this need. snip, For list delegates, this is managed through the model. Individual delegates should only depend on the model for state and interaction. If that's not enough you probably need a custom view, because views are supposed to handle the majority of the UI logic of the data.[1] snip, [1] A future research topic that I'm keen on, one of these days, is to better componetize the Model/View split. QML has very simplified models, but the Views are immense and in some ways restrictive. Sometime people just use a Repeater/Column/Flickable for flexibility, but that's not viable for large data sets. There's clearly a better split which would allow for more of the View to be written in QML, like the UI logic, while not forcing such large tradeoffs. After the successful completion of that research project, suggesting that you create your own view would just mean another QML file in your project. I'm very interested in that future-research-topic (we can discuss offline in the future when you have time), IMHO some work here is needed. For example, consider a large/rich model of a file-system where you want rich view(s) of *all* dirs-and-files. Example visualizers might be like: http://lifehacker.com/219058/geek-to-live--visualize-your-hard-drive-usage The dynamic/animated nature of QML seems like a QML implementation (with-or-without-C++) could be gorgeous/rich/useful. If your efforts provided specific insight and guidance to applications like that, it would be ever-so-super-spiffy! ;-) --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Essentials
Agree with Thiago: For 3D and Location, I have a feeling it's a little premature, but I can't blame you for it. Especially in Location's case, with lots of plugins to be kept in working order, it might be tricky in the current situation. Qt3D might be quite mature, actually, since it's been around for longer and has no platform-specific dependencies other than OpenGL. I can't blame you for it, and can adapt to the changes. IMHO they did really good work with 3D and it provides high QML value if we can establish a solid understanding of its support going forward. (I really liked 3D being in Qt essentials.) Lars' reasoning on the JS Backend seems solid. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods
Thiago spaketh: I'd like to propose we add Q_DECL_NOEXCEPT to many methods in our API. We already took the decision to turn exception off in most modules, except QtCore and where exceptions were used, like QtXmlPatterns. This is the next step. The Q_DECL_NOEXCEPT macro expands to noexcept, which is a new C++11 keyword. It is equivalent to noexcept(true), also new in C++11, and it means the method declares that it does not throw any exceptions. The benefits are: - callers do not need to emit exception handlers around such functions - the compiler may assume that no exception unexpectedly happens inside that function body, foregoing exception handlers inside it as well. The first behaviour is present with a C++03's empty exception specification (i.e., throw() in the function declaration), but the second behaviour is new in C++11. In the previous standard, the compiler was forced to emit exception code for the case when exceptions did happen even when they shouldn't. For that reason, the C++03 exception specification is deprecated. The drawback is that it makes the code ugly. The macro expands to nothing in C++98 mode. That means code using the API so marked and compiling in C++98 mode will simply not gain the benefits of the keyword, but should see no side effects. The presence of the keyword does not affect binary compatibility. With the Itanium C++ ABI, it's not present in the mangling. MSVC2010 does not supoprt it yet, so I cannot verify what it does. However, since C++11 support cannot be turned on or off on it, the keyword will be enabled or it won't depending on the compiler version, which means that binary compatibility is irrelevant. But if it does encode it in the mangling, we will not be able to add the keyword to methods in 5.1 or later. Totally agree, support Q_DECL_NOEXCEPT being added to many methods in the API. I've seen many developers confuse exception-handling with normal-error-handling, and think it would be best to establish clarity for those operations that do not throw (and which logically should never throw). This is consistent with the C++11 intent of increased type safety, and we should use it, IMHO. The benefits seem compelling: (a) It better documents the design/implementation details (b) It may lead to more efficient compiled-binary I concede Thiago's identified drawback: (c) It makes the code ugly ...however, it adds-the-caveat that the code ugliness is the same as saying it better documents the design/implementation detail. Since this is a cross-platform reusable library and users rely upon the Qt docs anyway, I don't think that's much of a penalty (if any). The question that remains is: what methods shall we add this to? We can add it to any method for which we can *prove* that it will never throw, which are: - leaf functions - functions calling only C functions or other noexcept functions Outside of QtCore, I propose we add it only to methods that are called often and frequently. In QtCore, I propose we add it to most tool methods that are provably noexcept. For example, the qHash functions, QMutex, our memory allocation routines (the throwing is in inline code), etc. PS: to be clear: new throws. I'd vote to add-it-everywhere-possible, starting with those Thiago identified. IMHO it should be good practice for developers to add-this-to-their-API-review-checklist to use the Q_DECL_NOEXCEPT everywhere possible as they grow/maintain their APIs. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can we have id's in dynamically generated elements for the next QML?
Mark spaketh:
Sadly, QML 1 doesn't have id in dynamically generated id. That is a
real big pain if you want to drag/drop something since then you
need... an id! Right now i'm trying to fight against a lot of issues
that wouldn't even be there if i simply had an ID. You can read more
about that in this blog post:
http://kdeblog.mageprojects.com/2012/08/01/what-will-qml-calendar-have-progress-update-qml-issue/
I'm also curious to know why the decision was ever made to have
dynamically generated elements exist without id?
Is there any possibility that QML 2 (or QML 2.1 or whatever comes
after 2) is going to have ID's for generated elements?
This is an interesting thing that I'm still trying to grok (the
direction-forward is not obvious to me yet, and I'm not sure what the
Trolls have discussed on IRC).
I know it's been discussed (a little), and that I'm not sure I'm about to
add much.
IMHO the issue is this declarative-approach, which IMHO is quite new as a
paradigm. The QML components/items themselves are independent-actors.
They don't use layouts *explicitly* in the parent/child relationship, and
shouldn't (but yes, layouts can be implemented to visually place
collections of items, and that is legitimate). While imperative
organization is possible, it seems it should be discouraged as
not-best-practice.
I'm not-yet sure whether IDs are part of that topic:
*- I *know* instance-IDs are needed for imperative.
*- I *don't* know if instance-IDs are needed for declarative.
(This is my internal speculation/mapping, I'm just trying to
understand/grok the new paradigm to where best-practices become obvious
to me.)
For example, in the design/problem you describe, the following design
option *might* be reasonable without IDs (and I concede many other design
options exist if we *do* have IDs):
*- The MyCalendarEntry (QML component, no GUI real estate) has a
DateTimeSpan property which implies where it is on a calendar.
*- A MyCalendarItem (QML item, with GUI real estate) parents (or
references) a SINGLE MyCalendarEntry to represent that
MyCalendarEntry. (Conceivably it would be 1:1, but it seems reasonable
to have many MyCalendarItem GUI-things represent the same
MyCalendarEntry instance if there were many views of that one entry
in different calendar-rendering-scenarios.)
*- Each MyCalendarItem (QML GUI item) is an independant-actor which
finds-its-place upon a parent MyCalendarDisplay QML GUI item. The
parent MyCalendarDisplay has its own layout that physically arranges
its children, which occupy their own real-estate-needs (based on their
internal MyDateTimeSpan property). (For example, perhaps the
calendar-display is a MyCalendarDay or MyCalendarWeek or
MyCalendarMonth GUI-item, and there would be different layouts for each
of those instances.)
*- This works without-instance-IDs because creating a MyCalendarEntry
would *automatically* trigger creation of a MyCalendarItem, which is
*automatically* parented by a MyCalendarDisplay, and which physically
places the items with Z-order. The drag/drop manipulation would directly
manipulate the DateTimeSpan in the MyCalendarEntry, through the
handles on the MyCalendarItem.
Of course, another design option would be for the MyCalendarEntry QML
component to have a C++ back-end-object with a unique ID, which could be
used for a universal ID from within QML.
I dunno. I'm about to embark on a fairly large Qt5/QML effort and that's
the kind of design I'm looking at, and I'll know more when I get deeper.
At the moment, though, I concede it would not take much for me to agree
with you that IDs could/should be added to the next QML spec...
Specifically for your question:
I'm also curious to know why the decision was ever made to have
dynamically generated elements exist without id?
I'm not an authority, and can only speculate, but I was initially confused
about this too. (NOTE to the casual reader, the Item { id: my_id; } is
not the ID we're discussing, we're talking about an instance-unique ID.)
However, after a time, I came to understand that the declarative approach
seems to imply:
(a) Items are implicitly-aggregated based on parents and properties
(e.g., typically not explicitly-aggregated)
(b) Declaratively changing an item's parent and/or properties (such as
events-on-implied-items) should *implicitly* cause animations and
re-aggregations (such as implied re-parenting and re-layout on the
display), and you're not supposed to need to do the
explicit-place-this-item-here thing.
As a possible secondary issue, if the QML item represents/wraps a C++
object, then the ID is trivially handled with an application-specific
identifier (that's typically how mine work, where the identifier has
compound-application-specific-state).
The question in my mind, of course, is the same as yours:
(1) If ID is not really needed, what is the best-practices
declarative-QML-design-pattern that would do what we need? (One possible
Re: [Development] QFileSystemWatcher and Recursive Monitoring
snip, please share thoughts on QFileSystemWatcher (maybe monitor-recursive) As you say, applications which are watching (possibly large) directory trees will likely have their own database of content which they will compare any changes to. The app can optimize this in domain-specfic ways, such as not recording any information about types of files it doesn't care about. I'd like to kind-of-disagree here: IDEs like QtCreator or any-other-developer-IDE would need to monitor large directory trees, and may not rely upon their own databases. It would be nice to have this recursive-monitoring for things like build-system-daemons. The goal is central-notification-from-many-large-file-system-roots, and that seems like a fairly useful abstraction that could be used by many application-specific tools. Really good work, IMHO, comparing about the cross-platform issues. Bummer about the Mac. It would be curious if that were to change going-forward (as the future is larger hard drives, and more reliance upon files as everybody goes SSD-fast). I'd *prefer* a QFileSystemWatcherRecursive implementation, even if it could not be cross-platform (e.g., problems on the Mac). I understand why that's not preferred -- we want to get away from system-specific anomaly. Mostly, I'd hope that over time, there would be a technical solution to get it working on the Mac, but at least let people could start using it on Windows/Linux. I could be talked out of this, though. Just my $0.02. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
João spaketh: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. André respondeth: That's essentially option (D) with a somewhat longer lead time. João respondeth again: Somewhat. If it's a binary break we should still call it Qt 6. I'm thinking we should get 5.0 out, use 5.1 to stabilize, react to feedback and generally (im)prove on the Qt 5 vision. Some container changes sneaked in, but they're not what we're trying to deliver *now*. In parallel, we actually write the container changes everyone's up in arms about (Thiago's changes are unfinished and not-fully-published work in progress), we review those changes, take them for a spin, kick the hell out of those tires and then make an informed decision whether it is worth the binary break and how to handle it, in case it is. Besides autotests coverage, we also have no benchmarks showing improvements. I assume we can see improvements for the inlining of size and offset/data in iteration benchmarks, but we haven't fully explored the impact of *growing* the size of the container itself. Anyway, we can discuss potential options now, but we can't make any decisions and can hardly make commitments, other than than let's do the container changes and release them when they're ready. IMHO this seems reasonable. I view QML2 as the stabilized version of QML1 (significant technical differences, as well as underlying implementation). I was quite impressed with what QML1 offered (it's a new paradigm), but I think the community would benefit from learning-to-work with QML2 as opposed to extending their learning curves on QML1. I understand the value of the container-changes, and while warranted, it doesn't seem to be the biggest part of the core-offering of Qt5, and it's possible some of the benchmarks/changes associated with that effort might be better understood after the C++11 Rvalue-references are better implemented and made available through compiler vendors. The ideal for me is that if container-changes would push the Qt release back six months (to arbitrarily pick-a-fictitious-number), I'd rather have a release now, and another release in six months. I know it's been discussed before (don't want to re-open that discussion), but I don't care about binary compatibility (I know how to recompile); and only somewhat care about interface compatibility (adding-member-functions seems incredibly cheap to me, I'd prefer to have the APIs mature properly since they represent new designs); and, I'd support any renaming/refactoring to enforce best-practice-use-models as these are discovered when applying this new paradigm. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Move math3d from QtGui to QtCore
snip, possibly move math3d out of QtGui (maybe to QtCore)? I agree with Laszlo: The 3D-math stuff is generally useful, and need not be coupled to QtGui. (We have domain-specific reasons for using 3D-math stuff outside GUIs, separate of Laszlo's interest in QtAudio3D which also does not want to couple to QtGui -- we cannot couple to QtGui either.) Thiago spaketh: I'm waiting for a reason to be in QtCore before I accept the classes into my lib. snip, Thiago doesn't want QtCore to be a dumping-ground Laszlo respondeth: You wanna me heading towards a math add-on module for these few classes? Thiago again: I don't know what other applications would use these classes you're proposing to move. You have to show me that. We have various (domain-specific) layout-things that do 2D and 3D math. Also, typesetting problems are non-GUI (they are division-of-resources-or-real-estate-among-entities, and typically require weighting and transforms). Specifically for us, we have to deal with optical-components-within-an-active-photonic-model (think an-optical-verision-of-CAD), and none of this is GUI (it's all model). On top of that, we actually do GUI-rendering, but the coordinates themselves are in the non-GUI model (e.g., separate library, sometimes separate executable.) As an aside, this is one of the projects we were going to move-to-try-out-QML-in-Qt5 when it's closer to release. (We currently have our own 2D and 3D math libs, but if Qt had a non-GUI coupled lib, we could use it.) I know these are only a few classes (at the moment) in Qt5, and perhaps won't justify their own QtMath3D lib (perhaps). However, it does make sense to me that this kind of logic should be co-located with QLine and QPoint. For example, our current home-grown stuff is in MyGeometry3D package, which includes 2D and 3D points, lines, rects, and other general math stuff. For our purposes, it does not couple to any-other-libs, and we have a design requirement that it does not couple to GUI. Just a thought. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Move math3d from QtGui to QtCore
snip, possibly move math3d folder out-of-QtGui charley spaketh: snip, need not-coupled-to-GUI domain-specific math3D stuff (We currently have our own 2D and 3D math libs, but if Qt had a non-GUI coupled lib, we could use it.) Thiago respondeth: Can you tell me whether those classes would suffice to your needs? Inside math3d I see some qvector) stuff (2d, 3d, 4d), a qgenericmatrix, qmatrix4x4, and some math-utility stuff (2d, 3d). Short answer: Yes, we could use this. Some Qt stuff is better than our home-grown stuff (like fuzzy-compare and other quaternion stuff -- we didn't do that, we are mostly Cartesian, but expect to need more transform-stuff as we move to OpenGL, and we would prefer to not write that). Both Qt and ours should both be cross-platform, but Qt is proven and ours is not, so that would be in-Qt's-favor. We have a domain-specific need for 2DMatrix-inversion, which isn't yet supported by Qt, but that's easy enough to add (just standard matrix-math-inversion). (There's a special-case where some 2D matrixes cannot be inverted, and we had to handle that, so it would be nice if Qt's implementation dealt with that too. There's another special case where you can fiddle with a cannot-be-inverted matrix to make it invertible, and it would be nice if Qt's implementation did that too.) But, worst case, we could use Qt's class and have an external algorithm do that inversion. (I'll also check at work to see if we can contribute that code, maybe, I don't know.) However, the biggest-advantage that I see for us to move to Qt's classes would be for us to *avoid* the marshaling-to-a-different-data-structure when interfacing with Qt's GUI or other modules (e.g., exposing Qt-classes as bound-properties to QML), so that we don't keep copy-constructing QVector3D from MyVector3D. There's not really anything special or clever in our code, we just needed it throughout our model. So, it would be nice to have one-set-of-point-and-line-and-vector-and-matrix-types. If it didn't really fit-in to the QtCore (I see your point), I'd probably vote to put it into a QtGeometry (or QtGeometry3D). Even if it's currently small, I expect it would grow -- it would be nice to have a package where we could dump new algorithms that are generally useful. For example, (our domain again), we deal with *lots* of N-dimensional parametric data. There are *tons* of generic-algorithms that are useful to identify populations, establish bounds on data sets, perform smoothing, compute population-and-data-set-statistics, perform transforms, establish contours, etc. We have algorithms for all of these on 1D and 2D and some 3D, and are moving more into N-D. Any of these algorithms could be interesting/relevant to a number of applications, from mere GUI-manipulation, to audio-data-sets, to edge-detection, to GIS/Spatial-data-analysis/Remote-Sensing, etc. (Our domain uses them for biology/cell-populations.) For example, it would be nice IMHO for QVector2D to have even-basic-stuff like min, max, and maybe mode. For our domain, we live-and-die on CV and Standard Deviation, so if those had to be external to QVector, that's ok. (We compute all stats through one-pass-through-the-matrix, and it is incredibly fast.) However, QVector2D already supports addition-and-subtraction-and-scaling (we need those), so it's useful now. (Hmm... QVector2D is based on qreal, would be nice if we had an integer option, as we often increment(x,y) when they represent 2D-histograms. Ours are all implemented as templates. But, we could go-all-floating as long as the performance was there.) I'm not sure where Qt/QML is at-the-moment with handwriting-recognition or stylus-input (e.g., gestures-algorithms), but those types of gesture/stroke-analysis would also lend-well to 2D data-set-algorithms (usually 3+D, as one must deal with stylus pressure and velocity in addition to the 2D surface). I don't mean to explode this topic. However, my selfish goal would be: (1) GUI-Model-Reflection -- Generic math/geometry data structures *not* coupled-to-GUI, but which are the same physical types *used* by GUI. Then, the GUI would merely reflect-the-model-directly (e.g., no marshaling-to-different data-structures.) (We did this in the past in MFC, amazingly fast, I can elaborate if people are interested.) (2) Out-Of-The-Box-Basics -- Generic math/geometry algorithms to manipulate/transform/compute-stats (just basic stuff would be great, some of that is already present through fuzzy-compare and rotateVector, etc.). ...and it would be simple for users to extend with their own domain-specific algorithms as-needed. But, we could share algorithms more, as IMHO most domain-specific algorithms are actually generically-useful algorithms that are surprisingly applicable/relevant to completely-unrelated domains. For example, I've personally implemented some very-rich typesetting libraries. However, when it comes-down-to-the-details, the heavy-lifting
Re: [Development] Move QAction from QtWidgets to QtGui
How would you suggest solving it? QAction does have stuff like bool showStatusText(QWidget *widget=0); QWidget *parentWidget() const; QListQWidget * associatedWidgets() const; friend class QWidget; so it seems difficult to make it avoid depending on widgets without breaking API compatibility, which is why I figured we would need a separate Qt Quick action class. Do you have any better ideas? André respondeth: Would it not be possible to split QAction in two classes, just like QApplication was split? We could perhaps create a QCoreAction, that has no GUI dependencies at all but just has the core functionality: representing an action, a way to trigger that action, and the state of that action. Things dependent on QtWidgets could stay in QAction itself, which would probably subclass QCoreAction. QAction would stay in QtWidgets, but QCoreAction could live in QtGui or even QtCore. Having an action class that is independent of GUI-like things like icons would be great to have for C++ as well. It makes it less awkward to use Q(Core)Action's in business-layer objects to expose functionality. The GUI layer could simply wrap these actions then and only add the GUI-dependent properties like icons. +1 from me. We would use QCoreAction (in our domain, lots of business-model internals, hardware device interfaces, etc.) We *cannot* link GUI things into our embedded control-systems. Because we don't have that, we create our own Functor-like classes that do what QCoreAction would do if it existed. Good call on past design decisions to break-out QCoreApplication. Multi-threaded command-line utilities implemented using Qt on the back-end are awesome. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mutex future directions
snip, QMutex future-direction-discussion I've followed this very technical discussion from the beginning-- impressive array of topics. Thanks to all digging into this, and great thanks to Thiago for opening the issue. I have a question on the point of recursive-locks: I understand recursive-locks (e.g., recursive-lock-count) were not part of the original QMutex, and were added later. I understand it's merely a count-lock-wrapper around the *real* lock. Further, I understand that recursive-locks can help get-one-out-of-a-corner-in-which-they-find-themselves, where the lock was already taken by the current thread and we don't want to deadlock when accidentally attempting the lock again. This problem tends to occur in designs where the lock is implied for (small) transactional operations, *and* for (large) transactional operations that tend to trigger implicit execution of those (small) transactional operations *within* the large transactional operation. I agree with Oliver: *) I think recursive mutex don't deserve improvements on the detriment of normal ones From a practical standpoint, I understand why recursive mutexes exist (see description above). However, from a *logical/cleanliness* standpoint, every time I've used them, I've later re-factored to where I do *not* do mutex-recursion. (Currently I use no recursive mutexes.) Do people really use them intentionally (do designs legitimately require them), or are they as I suspect, a way to get-yourself-out-of-trouble when your design failed to account for proper transactional granularity? --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 missing features
snip, theme GUI interfaces for QML A theme manager will make the things much more simpler and clear for the user and when it comes to add support for other platforms. snip, Let me try explain more: From user perspective: snip, want to re-use controls with different themes From developer perspective who wants to add support for another platform snip, re-using controls on new platforms I want to specify simple attributes to the theme manager and it should do the magic for me, something similar with Qt Style Sheets, of course now you'll say that it was too complex and almost nobody use it, I agree that it was complex but something simple must take its place, because I believe that something is better than nothing :) ! _This_. We have the same code on touch-interfaces and desktop. We need this. We're using Qt Style Sheets, and they work ok. (Could be more elegant, but is good enough, and it *works*.) IMHO, it seems like this theming and styling thing should be so much *easier* with QML. But, I'm not seeing approaches (yet) on these lists that will work for us. This is not a complaint: The QML declarative paradigm is new, and we must think about these theme-issues in a new paradigm. (This is a very positive thing, IMHO.) But, my point: We need *ANY* theme/style-convention that *WORKS*. I explored many designs in the way-way-way past, and they all worked to varying degrees of success (so we have lots of options): http://lists.qt.nokia.com/pipermail/qt-qml/2010-November/001772.html Summary: We (internally) are pursuing theming-and-styling through centralized convention with our QML components. Because we must enforce these types of conventions ourselves, things like the QML desktop widgets don't exactly work for us, because they don't follow our theme-conventions. (Recall that *by-definition*, themes/styles work *only* because components follow a convention.) And, we've not fully established what *should* be these conventions (they are in flux), but we *know* we *need* these conventions. So, for us, if it can't be themed, we won't/can't use it. Period. YMMV, I'm not-at-all disagreeing with other approaches, and understand why graphic designers are writing custom QML components for their own purposes, without centralized options for themes/styles. That's not us, though: Even for our highly-custom applications, we *demand* a single location to maintain the default-font-color for the application. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
3) Need a couple of better names for partial matching: - partial match preferring a complete match - partial match returning whatever match (partial or complete) is found first PCRE uses Soft and Hard respectively (which are quite meaningless to me). PreferCompleteMatch / PreferFirstMatch? I so very much prefer generic-to-specific in names for better auto-completion and grouping of like-minded, like: - PreferMatchComplete - PreferMatchFirst --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] check, Mate!
Stephen Kelly spaketh: http://boost.2283326.n4.nabble.com/Boost-with-Darwin-Mac-gcc-4-0-1- td2580330.html So, keep in mind - for portability treat 'check' as an out of bounds name for a method or variable. Thiago Macieira respondeth: Also to avoid: sun m_volume And a hint: whenever you get an error from the compiler that doesn't make sense at all, check the preprocessed output. +1 Some responsible individual should make a list of such things. Also to avoid: - COLOR_BACKGROUND - EXIT_SUCCESS - CopyFile - CreateDirectory - GetDriveType - IsCharAlpha These are somehow leveraged through MSVS internals and do not respect class/namespace boundaries (possibly through the preprocessor, as Thiago suggests.) Each one of the above represent extended periods of suffering for me (due to ambiguous compiler and sometimes runtime error), minutes of my life essence that I will never get back. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
I'm quoting Robin's email (with some of my comments), because I think it was a great message that I don't want lost: On Thu, Dec 15, 2011 at 2:16 PM, Robin Burchell robin...@viroteck.netwrote: Hi Tuukka, (now that I've left some hours to digest this...) 2011/12/15 Turunen Tuukka tuukka.turu...@digia.com: So now there is total of 108 improvements and bug fixes available in Qt Commercial 4.8.0 that are not part of the LGPL release. I want to underline that this is not the intended way of differentiating our offering. Going forward I hope that we can be more aligned. I would like to see most of the current delta integrated to Qt by the time of 4.8.1, if it is possible. First: let me say thanks for bringing this up sooner rather than later. That is certainly quiet a backlog (in a bad way), and one that should be addressed ASAP, if not yesterday :). It's also pleasing to hear that you want to work to bring these changes back to the Qt Project. We're a Qt Commercial customer, and attended the Commercial Forums at Qt Developer Days in San Francisco a few weeks ago, so this was not a surprise to us. The issue was explained (multiple development processes at different organizations, current in-inefficiencies synchronizing maintenance among the participants), and the greatest concern seemed to be that the community-as-a-whole might be confused about how/why this result-came-about, when the only issue is simply that community-management is still in the process of being launched, and we have not yet established efficient synchronization across the different structures. Agree with Robin: This is an important issue (technical backlog), and it is A Good Thing(TM) it was brought up through a clear message to the community in a timely manner. Further, having the benefit of more-in-depth-information shared by Digia at Developer Days, IMHO this is merely a process issue (albeit a real one). Digia did important work with these changes that benefit the *whole* community, and the goal is to share them with the *whole* community. We (the whole community) merely need a process that permits this to happen as efficiently as possible, and IMHO everybody is already on-board with a positive work-together Goal-And-Attitude to ensure we all vector in the same direction. In short, my opinion is simply: This is merely a (short-term) result from the fact that multiple processes-and-structures currently exist. We can improve this. I see only positive intent-and-actions among all the players, so this clearly seems resolvable. In my opinion, there's two issues that need addressing here. The first (already brought up) is gerrit. Gitorious' merge requests are painful for everyone involved, so they're just going to slow you down. Once things get into Gerrit, assuming they work in a similar fashion to Qt 5, I think you'll find that changes can get pushed forward a fair bit easier (especially assuming you know the right people to poke for reviews, which I expect you do for the most part). The second is that these changes have been going to Qt 4.8. Some people seem to have assumed this was an issue, but I'm not entirely sure this was correct, as I seem to recall that Ossi had a magical script to somehow mangle changes from 4.x into Qt 5.x[1] - and if that is the case, there really isn't much further problem I think. If this script doesn't do what I'm hoping, then we're going to have to figure out how to get this work into Qt 5 with the minimum of pain (meaning as soon as possible), before merging becomes impossible or at least impractical. Very good points. So anyway, the summary of my thoughts on solving this would be: - get 4.x into Gitorious ASAP +1 - get the changes into 4.x (can probably be ongoing while the above isn't finished, but will be helped) +1 - cherry-pick them into Qt 5 (in any way possible) to make sure work isn't lost or duplicated, since I assume that your customers will be asking about Qt 5 sooner rather than later :) +1 We are a commercial customer, and yes, we want Qt5 sooner. ;-)) ...and we're back to working as one big, happy family in Gerrit :) [1]: http://lists.qt-project.org/pipermail/development/2011-November/000483.html - though this repo has apparently been merged into qtrepotools. Really good points and suggestions by Robin, +1. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt platform and theme plugins
morten spaketh: Those of you that follow the commits on Gerrit closely may have noticed the new QPlatformTheme API and wondered what it is. In short, the QPlatformTheme API is there to support deeper platform integration, indepentently of QPlatformIntegration. snip, I am *very* interested in this effort -- IMHO we absolutely need to be able to establish the look-and-feel for applications in a centralized manner (color schemes, fonts, button styles, etc.) snip, QPlatformTheme currently has API for dialogs and system menus. Which APIs belong in QPlatformTheme is up for debate; we want to share as many platform abstractions as possible between QtWidgets and QtQuick, but at the same time some of the APIs might be to tied to the QWidget world. From the description, this appears to be an effort to establish a common API or approach for *both* Qt5Widgets and QML2+? That's what I'd be most excited about (one approach). Selfishly, I'm mostly focused on QML 2+ in Qt5+, even we'll have legacy widget styling needs at some level after migrating to Qt5, (we're currently using Qt stylesheets). --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] This week in Qt 5 development (week 49)
On Fri, Dec 9, 2011 at 12:49 PM, Marcus D. Hanwell marcus.hanw...@kitware.com wrote: 2011/12/9 Stephen Kelly stephen.ke...@kdab.com: On Friday, December 09, 2011 20:12:05 Stephen Kelly wrote: This week: Oops, sorry. This was not intended for the Qt mailing list. I was compiling it for colleages. I would love to see something like this on the Qt development list, even if accidentally distributed to a wider audience! +1 --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On Monday, 5 de December de 2011 14.50.23, Jeff Mitchell wrote: At the Contributor Day in San Francisco, a number of people met to discuss some of the issues involving QtNetwork, espcially QNetworkAccessManager (QNAM). The overall idea is that eventually QNetworkAccessManager, which is meant to generally be one-per-application, must be made thread-safe in order to fulfill this desired use. Here are the notes from the discussion: snip, 2011/12/5 Thiago Macieira thiago.macie...@intel.com I've been thinking... snip I updated the wiki page with Thiago's comment: https://wiki.qt-project.org/Qt_Contributors_Day/Qt_Networking_Discussion --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick becomes a separate module
snip, Kent upcoming patch changes Den 02. des. 2011 09:33, skrev ext Kent Hansen: Hi, See https://bugreports.qt.nokia.com/browse/QTBUG-22889 Once http://codereview.qt-project.org/#change,9948 goes through CI, This seems like important info, so I made a page on the wiki: https://wiki.qt-project.org/Transition_from_Qt_4.x_to_Qt5 Is that wiki location the proper place for such things? Feel free to move it or correct me as needed. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
Reading Alan's post a couple times, I *think* this summarizes to:
(a)- A new Window{} element is being proposed for QML that is different
from the current QML components. Specifically, the new Window{} is a
top-level concept, where you could have more-than-one, such as one for
each monitor. Other QML components could be instantiated *within* the new
Window{}, but a Window{} itself is a top-level item.
(b)- The new QML Window{} element may break QWidget menus/toolbars within
that Window{}.
(c)- The new QML Window{} behaves differently from other QML components
which may be used *within* that Window{}. Specifically, QML components
can move/resize based on QML source code, but the top-level Window{}
would be anchored/sized based on the launching C++ program (not based on
QML API).
(Please feel free to correct my impression -- Alan's email was fine, my
brain is just small and I'm trying to understand all of the implications
for what Alan is proposing.)
My impressions:
(1) This makes sense to me (I like this proposal). I've tried to create
desktop gadgets with QML, or otherwise have more-than-one top-level QML
window into which I could put QML components, and I think it would be much
easier if we distinguished between these two types of real-estate (e.g.,
IMHO it would be nice to distinguish between top-level real-estate, and
nested QML components that move around that top-level real estate).
Logically, the top-level real-estate represents the device (e.g., like
the whole phone screen), while the nested real estate represents
space-within-that-top-level-device. (This seems elegant.)
(2) I don't have a strong opinion on whether the top-level Window{}
should have size/placement attributes exposed to QML. Alan's proposal to
*not* have that seems fine with me (I just need a way to anchor the
desktop gadget, or place it on the desktop where it needs to go, and it's
fine if I can do it only through the C++ application.) I *assume* the
Window{} will have some kind of frame-with-title on the desktop so the
user could size/move it? If not, no biggie, I can do that myself.
(3) I don't care if menus/toolbars are broken. IMHO, (as Alan suggests),
they would be done again in QML (so they could be skinned/sized
properly), or they would be done with a different metaphor (there are lots).
(4) Perhaps off-topic for this thread, IMHO this type of
desktop-and-mobile-unification is really important to think-through
(that's how I see this proposal). I like what is proposed, but we may need
some iteration as we experiment on both desktop and mobile. I see this
proposal as simpler and more bounded than other unification concerns I have
(for QML), such as skinning-styles and layout.
Do I properly understand what is being proposed?
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
