Re: [Development] Removing Wacom support in Qt5
That combination of items just doesn't make sense to me. Your scenario might differ, but try this: a clean Win7 HP or Pro install, get any of the latest Intuos4 driver, Qt 4.8.x (I used the SDK) and QtC 2.5.x, create a new QtQuick UI, just the simple Hello World QtC creates for you. Switch back and forth a few times, bonus points if you do it fast. I promise you will begin to dislike wacom and begin to wonder why this buggy code that helps 1% of Qt Apps has the potential to affect the other 99%. Right know now I need to include a warning note: This software will break if you install wacom drivers for a random Wacom, expensive Wacoms might not break this sw, you're on your own. You got my attention enough that I wanted to look into it (although I'm totally *not* worthy of even attempting to fix stuff in Qt, nor do I have the time for it). I am pretty close to the scenario above. Fresh Win7, just installed the driver for my Intuos4 half an hour ago, fired up QtC 2.5.2 (revision f25dadf80e) as well as QtC 2.4.1 (revision 8cd370e163). Made a QtQuick UI project for Qt 4.8.1 MSVC desktop. Alt-tabbing like crazy yielded no crash, neither for QtC 2.4.1 nor 2.5.2. That was the excepted outcome, right? Can you help me getting there, perhaps? I've played with the pen while fooling around in QtC too. Incidently, for the project I am currently implementing for a company, I switched back from QtC 2.5 to QtC 2.4 exactly due to a huge amount of crashes (and, I think, qml-related as in crashes when switching to the QML designer). But as said, the Intuos driver was installed half an hour ago. Regards, Rene Jensen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] So I've made a QWidgets2 design/prototype... BUT...
On Mon, Jun 25, 2012 at 9:46 AM, Oswald Buddenhagen oswald.buddenha...@nokia.com wrote: On Mon, Jun 25, 2012 at 09:37:27AM +0200, ext Thiago Macieira wrote: On segunda-feira, 25 de junho de 2012 09.02.32, Rene Jensen wrote: Since we have a good tradition of hijacking threads, I'd like to take this opportunity to ask if qt-project.org has established an area where usermade classes, fragments etc. can reside. A central repository just seems more sensible to me. When making a project, there's always some small widget or class system that falls out as a separate generic entity. ... Or is the forum a better place? There is the playground. Yes and no. I am talking about something like http://djangosnippets.org/tags/ They playground sends a massive signal: Only store large scale projects expecting many commits and many contributors here. It does not look suitable for small, one-time solutions to specific problems. You can't specify which Qt version you are browsing solutions for, nor category etc. There is no rating system either. Perhaps the famous Documentation notes could do the trick. Not sure though. Or maybe the good old qt-apps.org site is still the recommended way to publish. Hmm. On a closer look, I'd say it is. Cheers, Rene ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Container refactor update
On Mon, Jun 18, 2012 at 11:58 PM, Thiago Macieira thiago.macie...@intel.com wrote: Here's the current status of my endeavour: Hi Thiago. As you may have figured out by now, I am one of those who plea for an extra set of container widgets deriving from QObject. You know, so they can support slots and signals. But seeing how hard people work to get performance out of the core containers, I guess it will never happen. Yes, of course, it comes from some bad experiences I had learning how to expose QLists to QML. But the discussion is universal in the Qt universe. Is this crazy talk? I would imagine that given a set of containers like ... hmm ... QSmartList, QSmartMap, QSmartHash inheriting from QObject (yes, I know ... moc and templates bla bla - I could live with fixed key/value-types if that's what it takes - java did before going parametric), that us poor programmers would not have to work so hard to keep complicated interconnected data objects synchronized between the UI and e.g. a database or over a network wire. I mean.. SIGNAL(itemAdded) would be nice from time to time. Am I alone in this? What would it take? No clue. I'm sure you all have thought immensely about this before. One simple guess: All methods on a QList needs to check quickly if this is a monitored list when changing it. If so, those methods could notify their depending QObject monitor (QSmartList) which then emitted the signal. Then again, I can easily be convinced that the current approach is better. I wouldn't suggest wrapping plain ol' datatypes inside QObjects for simple Q_PROPERTIES, so why lists and maps? Best regards, Rene Jensen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On QML, ownership, QObject-trees and QSharedPointer
Step 1: mySharedPtr.data() == MyShared* P; Step 2: make sure the QML engine doesn't assume ownership: QDeclarativeEngine::**setObjectOwnership Step 3: hand over P to QML: setProperty or setContextProperty Yep, those steps seem to be the current requirement. If my patches get in (not guaranteed), it will be reduced to just: Step 1: setContextProperty(myname, mySharedPtr); or Step 1: setContextProperty(myname, mySharedPtr.toWeakRef()); depending on your needs. When I said the database layer should preferably remain QML agnostic, I merely wanted to keep patchup code like setObjectOwnership out of a clean set of data classes for purist reasons. (Really it is an exaggeration imho.. I have no problem using stuff from QtDeclarative in code. Will need it for QList properties anyway. It's just a design reflex). Yes, I agree. Leaving out step 2 is bad, right? Yes, and worse it might not obvious to consumers of the API that it's needed. Hi again. I have modified the wiki page that Sivan started (my name in qt-project.orgis Centipede). In my view your advice above is serious enough to warrant a user comment in the footnote section of at least the documentation pages of 4.8. But I cannot for the life of me figure out where to add such comments. Is qt-project.org's user comment system up and running? Best regards, Rene Jensen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On QML, ownership, QObject-trees and QSharedPointer
Question: How can we expose objects governed by QSharedPointer to QML safely? I *can* guarantee the lifecycle beyond the life of my QDeclarativeEngine. If you can guarantee that, then use mySharedPtr.data() as others have said. Just a quick thought, would that suggesion be leading into trouble? In only see one way to do that right: Step 1: mySharedPtr.data() == MyShared* P; Step 2: make sure the QML engine doesn't assume ownership: QDeclarativeEngine::setObjectOwnership Step 3: hand over P to QML: setProperty or setContextProperty When I said the database layer should preferably remain QML agnostic, I merely wanted to keep patchup code like setObjectOwnership out of a clean set of data classes for purist reasons. (Really it is an exaggeration imho.. I have no problem using stuff from QtDeclarative in code. Will need it for QList properties anyway. It's just a design reflex). Leaving out step 2 is bad, right? Best regards, Rene Jensen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] On QML, ownership, QObject-trees and QSharedPointer
learning a new technology just about every week - most in vain. I get my dose of documentation, thank you. Hoping for an enriching debate, Best regards, Rene Jensen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
