[Interest] Write from different thread
Hello. Is it safe to write in to the QTCPSocket from the different threads if socket is protected with mutex? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt5 build failed
Hi, I have configured Qt5 beta using TDM-Mingw32, perl and python (all latest versions) and then tried to build using following commands 1. configure -developer-build -opensource -nomake examples -nomake tests ( to configure) 2. perl build -j 2 (to build) But build has failed after 5 hours of struggle. Can someone help me in making this success. Thanks in advance. Ramakanth Reddy .K Integrated Engineering Services (IES) Mahindra Satyam IT1 Block, First Floor, Wing 1,WST-46, STC, Bahadurpally, Hyderabad, India, Postcode-500043 Phone: +91 40 30635265 Email: ramakanthreddy_kesire...@mahindrasatyam.com [signature1.png]https://twitter.com/MSatInfotainmnt DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. inline: image001.png___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
On Thursday 23 August 2012 08:27:02 Igor Mironchik wrote: Is it safe to write in to the QTCPSocket from the different threads if socket is protected with mutex? Weel, as the docs state, QTcpSocket is reentrant, which does NOT imply it's thread-safe... however, that has nothing to do with the use of mutex'es. HTH, René ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] memory fragmentation?
On quarta-feira, 22 de agosto de 2012 17.09.21, Alex Malyushytskyy wrote: For example: assume you need 1 GB for a single array, and all other data can't grow beyond total 500 MB. First thing you can do - reserve 1 GB the earliest possible, and let other allocation happen normally. Application will not allocate this memory until you commit it. You want to load 50MB file into this memory. Commit 50 MB, You want to load another file which uses 150MB. Commit extra 100 MB. Address space is continues, physically no memory re-allocation occurs, pointers are kept valid. You do not care how 3rd party components (like dlls) do memory allocation. Anyway thanks for comments, I might try to play with custom allocator and custom allocator using sbrk() as you suggested On Linux, you wouldn't allocate 1 GB of memory with sbrk. You'd use an anonymous mmap, which reserves address space but provides no memory backing. The allocation is done on faulting the page. That's how glibc's malloc() serves allocations above a certain adaptive threshold. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
On quinta-feira, 23 de agosto de 2012 09.27.02, Igor Mironchik wrote: Hello. Is it safe to write in to the QTCPSocket from the different threads if socket is protected with mutex? No. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
On Thursday 23 August 2012 10:09:35 Thiago Macieira wrote: On quinta-feira, 23 de agosto de 2012 09.27.02, Igor Mironchik wrote: Hello. Is it safe to write in to the QTCPSocket from the different threads if socket is protected with mutex? No. I know, I was wrong... sorry, totally screwed up with this statement :). See my second post. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
On Thursday 23 August 2012 10:11:08 R. Reucher wrote: On Thursday 23 August 2012 10:09:35 Thiago Macieira wrote: On quinta-feira, 23 de agosto de 2012 09.27.02, Igor Mironchik wrote: Hello. Is it safe to write in to the QTCPSocket from the different threads if socket is protected with mutex? No. I know, I was wrong... sorry, totally screwed up with this statement :). See my second post. OK, I guess I'm a bit too tired today... answering to the wrong posts. Will be quiet now until I got my third coffee or so :). So then my first answer wasn't all that wrong... well, at least :). ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5 build failed
On 2012/08/23 08:30 AM, Ramakanthreddy_Kesireddy wrote: But build has failed after 5 hours of struggle. Can someone help me in making this success. I guess you are a programmer, so when a user gets hold of you and says your program doesn't work, what do you ask them? -- Regards Alex ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5 build failed
On quinta-feira, 23 de agosto de 2012 10.10.27, Thiago Macieira wrote: On quinta-feira, 23 de agosto de 2012 06.30.07, Ramakanthreddy_Kesireddy wrote: I have configured Qt5 beta using TDM-Mingw32, perl and python (all latest versions) and then tried to build using following commands 1. configure -developer-build -opensource -nomake examples -nomake tests ( to configure) 2. perl build -j 2 (to build) But build has failed after 5 hours of struggle. Can someone help me in making this success. Lots of people can help you. Maybe this blog of mine will help you: http://www.macieira.org/blog/2012/05/doesnt-work-doesnt-work/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Proper way of updating a model?
Op 22-8-2012 20:29, Stephen Chu schreef: Now I have a question on how to properly update the model. My model is a read-only representation of a database. I am using a QTreeView to hold the model. The data themselves are not tree-like but I like the visual of QTreeView better. So, you *do* have a table model, but you are just displaying it in a QTreeView? That's very possible, of course. Note that QTableView can be given the same appearance as QTreeView, but is more efficient at layouting because it does not need to deal with the (complex) tree aspects of it. Please keep in mind that *any* model can in principle be viewed in *any* view. You may loose certain aspects of the data of not use all features of the view, but normally, it will work. That's because views only rely on the common interface provided by QAbstractItemModel. The model needs to update itself periodically from the remote database. I keep a QList of data IDs and rebuild the list every time I get a new snapshot from the database. For efficient updating, you will need to keep track of changes: inserts, deletes and updates of items. Just rebuilding will generally not be very efficient. What's the recommended way to reflect the changes to the view? I need to keep the current selection and scroll position of the QTreeView between updates. Do I reset the model? Or do I remove deleted rows and insert new ones? No, resetting is not the way. It will result in loosing selection, scroll position and is generally visually disturbing for the user. As others have notices, the beginInsertRows, beginRemoveRows and their respective end* functions are your tools, together with emitting the dataChanged signal for updates to data. However, it also depends on the size of your dataset. Are you talking 10 rows, 1k, 1M or even more? André ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] memory fragmentation?
22.08.2012, 21:27, Jason H scorp...@yahoo.com: Now, here's my crazy idea. If we have small objects - say Qt's interface classes, and large objects, say Qt's private classes, then could we do some d-ptr trickery where Qt can reallocate and copy/move the memory around and reassign a d-ptr? We can't get all the coolness of .NET's GC, but we can come close, at least for large objects (objects using d-ptrs). We've already talked about the GUI, but what is more interesting to me is a QObject hierarchy (not necessarily QWidgets) in that you could say for this large, old tree of objects, do something that would result in better (more contiguous) memory allocations. I think this idea is more applicable to smart pointers (like QSharedPointer and QSharedDataPointer). GC would be able to move their data without breaking user code (unless somebody stores value of raw pointer somewhere which already may be considered bad practice). It would also be possible to convert some d-ptrs to such smart pointers if there is any gain. -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] memory fragmentation?
On quinta-feira, 23 de agosto de 2012 13.10.27, Konstantin Tokarev wrote: I think this idea is more applicable to smart pointers (like QSharedPointer and QSharedDataPointer). GC would be able to move their data without breaking user code (unless somebody stores value of raw pointer somewhere which already may be considered bad practice). That implies thread-unsafety. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Scripting Debugger
FWIW I think it would be interesting to be able to access a QML debugger outside QtCreator. It would be useful for us in KDevelop [1] at least. It helps maintain the quality of the tooling generated around the technology. Actually for the _JS_ debugger (breakpoints etc) we're just utilizing the v8 debugger protocol: http://code.google.com/p/v8/wiki/DebuggerProtocol The v8 messages are wrapped in a meta-protocol, but that's fairly simple. The other parts of the QML tooling (inspector, console, profiler ...) have their own protocols ... Feel free to grab Aurindam or me on IRC (e.g. #qt-creator channel on freenode) if you need help, or if you have questions. Noted.. But that will only be available in 5.1.0 ... (if at all) Well, what we've been pondering about is providing a fairly simple command line debugger, more of a tech demo. I don't see us providing a full blown standalone GUI debugger as part of Qt ... Regards Kai ~Aurindam ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] memory fragmentation?
23.08.2012, 13:19, Thiago Macieira thiago.macie...@intel.com: On quinta-feira, 23 de agosto de 2012 13.10.27, Konstantin Tokarev wrote: I think this idea is more applicable to smart pointers (like QSharedPointer and QSharedDataPointer). GC would be able to move their data without breaking user code (unless somebody stores value of raw pointer somewhere which already may be considered bad practice). That implies thread-unsafety. Add QManagedPointer (thread-unsafe) There is a lot of software doing most of work in the same thread, so it still can be useful. -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Scripting Debugger
22.08.2012, 23:24, Peter Kümmel syntheti...@gmx.net: I'm looking for a scripting language with a debugger. Binding to C/C++ should be simple and the debugger should be embeddable. I'd recommended you to use Lua. It's very lightweight, very fast and easily embeddable. If your problem is performance sensitive, you can always migrate to LuaJIT which is even faster. It also contains built-in debug library [1] [1] http://lua-users.org/wiki/DebugLibraryTutorial -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
On Thursday August 23 2012, Thiago Macieira wrote: On quinta-feira, 23 de agosto de 2012 09.27.02, Igor Mironchik wrote: Hello. Is it safe to write in to the QTCPSocket from the different threads if socket is protected with mutex? No. To expand on this: QTcpSocket is-a QIODevice which is-a QObject, and no QObject can be protected by a mutex, since it performs implicit event handling which would be very complex to mutex-protect. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Scripting Debugger
On 23.08.2012 11:29, Konstantin Tokarev wrote: 22.08.2012, 23:24, Peter Kümmelsyntheti...@gmx.net: I'm looking for a scripting language with a debugger. Binding to C/C++ should be simple and the debugger should be embeddable. I'd recommended you to use Lua. It's very lightweight, very fast and easily embeddable. If your problem is performance sensitive, you can always migrate to LuaJIT which is even faster. It also contains built-in debug library [1] [1] http://lua-users.org/wiki/DebugLibraryTutorial Yes, Lua would be perfect if there would be Qt based debugger. But always when reconsidering Lua I end up with the conclusion that I'll have to write a debugger. Peter ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] memory fragmentation?
On quinta-feira, 23 de agosto de 2012 11.18.09, André Somers wrote: Op 23-8-2012 3:54, Tony Rietwyk schreef: Hi Jason, If there are 5 public objects whose d-pointers reference the same private object address, how are you going to update them when you relocate the private object? I don't think .Net stores addresses, just handles, so the relocate only needs to update the handle info. That's why you have to go through all of the marshalling crap when you do want to pass the address somewhere! Couldn't that be solved by making d-pointers not MyClassPrivate* but MyClassPrivate**? Then, you'd only need to update one address... All problems in computing can be solved with another level of indirection. Well, all problems but one: that of too many indirections. And in this case, you're adding too many indirections. There are two problems with this solution: 1) you still need a fixed, non-relocating memory region where to store the pointers to the actual objects 2) this requires hitting two cache lines and doing twice the amount of memory accesses to get to the data. I do think the idea is really crazy, but that does not mean that it isn't interesting anyway. I guess you'd need your own allocator for the objects as well. How else are you going to keep track of the actual fragmentation? To complicate it even more: the program could even 'learn' between runs by keeping some stats between runs on memory usage, to influence its own memory allocation strategies... And yes, I understand that such things would be *very* complicated to do well, and might not even work properly. And again: all of this is not thread-safe. You can only move the objects if you guarantee that all threads are blocked from accessing it. Something like keeping a QReadWriteLock per relocatable pointer, if you don't want a Big Application Lock. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
On quinta-feira, 23 de agosto de 2012 11.36.16, Marc Mutz wrote: On Thursday August 23 2012, Thiago Macieira wrote: On quinta-feira, 23 de agosto de 2012 09.27.02, Igor Mironchik wrote: Hello. Is it safe to write in to the QTCPSocket from the different threads if socket is protected with mutex? No. To expand on this: QTcpSocket is-a QIODevice which is-a QObject, and no QObject can be protected by a mutex, since it performs implicit event handling which would be very complex to mutex-protect. On the spot. QMutex-protecting an object doesn't make sense. You need to block the entire thread from executing. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
On 23 August 2012 10:36, Marc Mutz marc.m...@kdab.com wrote: To expand on this: QTcpSocket is-a QIODevice which is-a QObject, and no QObject can be protected by a mutex, since it performs implicit event handling which would be very complex to mutex-protect. A documentation thought: shouldn't we add another category to the thread-safety capabilities of a class or a function? Now we have: 1) non-reentrant: safe to be used by only one thread 2) reentrant: safe to be used by multiple threads, provided that access is serialized (one at a time) 3) thread-safe: safe to be used by multiple threads, even at the same time But probably 1 and 2 should be split into something like 1a) safe to be used by a *specific* thread only (GUI classes = only in the GUI thread) 1b) safe to be used by only one thread (QObjects = use them from the thread they live in.*) 2) reentrant: as above -- Giuseppe D'Angelo * Yes, of course, if you manage to control event dispatching then 1b collapses onto 2, but that's not really how QObjects are meant to be used, is it? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
Hi Giuseppe, I think you got the categories wrong. On Thursday August 23 2012, Giuseppe D'Angelo wrote: Now we have: 1) non-reentrant: safe to be used by only one thread non-reentrant means: no other thread may execute this function while you're calling it. 2) reentrant: safe to be used by multiple threads, provided that access is serialized (one at a time) reentrant means: multiple threads may call this function at the same time, provided the input is different (for member functions, the instance (*this) is input, too!). If you can serialise access (_all_ access), you can even call non-rerentrant functions from multiple threads; the problem is that you usually don't control all access points, so you can't secure them all. As is the case with QObject event handling - you'd at a minimum have to reimplement event() to lock the mutex, but code can also call functions through your meta object, and you don't control the lifetime of the references you hand out to it, so you cannot lock the mutex since you don't know when to unlock again. 3) thread-safe: safe to be used by multiple threads, even at the same time thread-safe means: multiple threads may call this function at the same time, even with the same input (for member functions, that includes on the same instance). Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] g++: command not found error during configuring Qt5
Hi, I'm new to Qt, I tried configured Qt5 on Ubuntu 12.04, and I always end up with following error. Make: g++: command not found Make: *** [project.o] Error 127 *qbase/configure exited with non-zero status. Can you say what does it means. I guess I'm doing some mistake but I don't know what it is :-P. If it is a g++ compiler error I have used this g++-4.4-multilib_4.4.3-4ubuntu5.1_i386.deb am I doing it in a right way. I'm not a geek, but your help is appreciate in this regards. Thanks Regards, K.K DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
Marc replied about functions, but let's talk about classes and objects. That is, let's talk about calling different member functions of a particular class. On quinta-feira, 23 de agosto de 2012 12.00.43, Giuseppe D'Angelo wrote: 1) non-reentrant: safe to be used by only one thread Non-reentrant means this function or class can only be called from one thread at a time, regardless of which object it's operating on. An even stricter requirement is that of GUI classes: not only are they non- reentrant, the only thread where they can be called is the GUI thread. 2) reentrant: safe to be used by multiple threads, provided that access is serialized (one at a time) That's not what it means. It means that it's safe to call these member functions from different threads, provided they operate on separate objects. 3) thread-safe: safe to be used by multiple threads, even at the same time Correct: these functions in this particular class can be called on simultaneously from multiple threads, even on the same object, provided that's all you're doing to this object. By definition, all thread-safe functions are reentrant. There are certain classes in Qt that are hybrid between reentrant and thread- safe: the implicitly-shared container classes. By construction, the const functions are thread-safe and the non-const ones are only reentrant. But note the provided that's all you're doing to this object part: if you're calling a non-thread-safe reentrant functions on that object, you can't use the thread-safe functions at the same time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] g++: command not found error during configuring Qt5
-Original Message- From: interest-bounces+kai.koehne=nokia@qt-project.org [mailto:interest-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of ext Kk_Kishore Sent: Thursday, August 23, 2012 2:24 PM To: interest-requ...@qt-project.org Cc: interest@qt-project.org Subject: [Interest] g++: command not found error during configuring Qt5 Hi, I'm new to Qt, I tried configured Qt5 on Ubuntu 12.04, and I always end up with following error. Make: g++: command not found That's the C++ compiler missing :) Install the packages for Ubuntu that are outlined at http://qt-project.org/wiki/Building-Qt-5-from-Git Regards Kai ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Write from different thread
On 23 August 2012 12:21, Marc Mutz marc.m...@kdab.com wrote: Hi Giuseppe, I think you got the categories wrong. Sorry, I rushed out the email and in the end it turned to be not precise about what I was referring to with safe. On Thursday August 23 2012, Giuseppe D'Angelo wrote: Now we have: 1) non-reentrant: safe to be used by only one thread non-reentrant means: no other thread may execute this function while you're calling it. I was sticking to the Qt conventions http://qt-project.org/doc/qt-4.8/threads-reentrancy.html (which aren't universal, all the opposite). Given your definition one could assume it's safe to call a GUI function from any thread, provided that no other thread is calling it at the same time. Instead it's not. Not sure if non-reentrant is a good definition for such a case. 2) reentrant: safe to be used by multiple threads, provided that access is serialized (one at a time) reentrant means: multiple threads may call this function at the same time, provided the input is different (for member functions, the instance (*this) is input, too!). If you can serialise access (_all_ access), you can even call non-rerentrant functions from multiple threads; the problem is that you usually don't control all access points, so you can't secure them all. As is the case with QObject event handling - you'd at a minimum have to reimplement event() to lock the mutex, but code can also call functions through your meta object, and you don't control the lifetime of the references you hand out to it, so you cannot lock the mutex since you don't know when to unlock again. My point was that most QObject subclasses are marked to be reentrant. While that's true, I wanted ask if it should be made more clear in the docs that QObjects are always potentially accessed by the thread they're living in (due to event dispatching, etc.), and therefore one should refrain from accessing them from other threads. QObjects in general are not tied to a specific thread (whilst instead GUI classes are), but very tied to the thread they live in. Cheers, -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Proper way of updating a model?
On 8/23/12 5:04 AM, André Somers wrote: So, you *do* have a table model, but you are just displaying it in a QTreeView? That's very possible, of course. Note that QTableView can be given the same appearance as QTreeView, but is more efficient at layouting because it does not need to deal with the (complex) tree aspects of it. I choose QTreeView mainly for its look and row-base selection. Our existing app on Mac uses Data Browser control (think Finder) and QTreeView provides the closest look and feel to it. Please keep in mind that *any* model can in principle be viewed in *any* view. You may loose certain aspects of the data of not use all features of the view, but normally, it will work. That's because views only rely on the common interface provided by QAbstractItemModel. Yes, I understand I can use basically any view with and model. And I really appreciate that feature/function. Makes my prototyping a lot easier. For efficient updating, you will need to keep track of changes: inserts, deletes and updates of items. Just rebuilding will generally not be very efficient. That's what I did in the existing app. No, resetting is not the way. It will result in loosing selection, scroll position and is generally visually disturbing for the user. As others have notices, the beginInsertRows, beginRemoveRows and their respective end* functions are your tools, together with emitting the dataChanged signal for updates to data. Thanks to everybody pointing this out. I will give it a try. The issue I have is actually being coming from OS X Data Browser control. It tracks items by user supplied 32-bit IDs instead of indices. That makes updating the list a lot easier by just adding new IDs and removing old one without worrying about the indices change after each insert/remove. And also makes batch operations much more straightforward and efficient. With Qt, I think, I have to add/remove ID and index pair together, one pair at a time, to keep the ID-to-index in sync. I probably can batch insert new ID-index pairs at the end of my list. But since IDs to be removed can be scattered in the list, it will be hard to remove them in batches. However, it also depends on the size of your dataset. Are you talking 10 rows, 1k, 1M or even more? It can be from Ks to 100s of Ks. But I am in the process to redesign it so we'll never deal with more than 10s of Ks. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] memory fragmentation?
On 08/22/2012 07:27 PM, ext Jason H wrote: C++ on .NET functions as it does now, however the compiler introduces the operator of ^ as a type modifier like * (pointer) ^ are handles to managed objects, as * are addresses of objects. The runtime then handles dereferencing the handles for you. jsut like your compiler uses the appropriate instructions with a pointer. Now, here's my crazy idea. If we have small objects - say Qt's interface classes, and large objects, say Qt's private classes, then could we do some d-ptr trickery where Qt can reallocate and copy/move the memory around and reassign a d-ptr? We can't get all the coolness of .NET's GC, but we can come close, at least for large objects (objects using d-ptrs). We've already talked about the GUI, but what is more interesting to me is a QObject hierarchy (not necessarily QWidgets) in that you could say for this large, old tree of objects, do something that would result in better (more contiguous) memory allocations. I'm wondering if you are really trying to solve a problem or you just want to .NETify Qt for the fun of it. Many developers want to have full control on how and when their memory allocations/deallocations occurs. If you start to consider adding a GC into Qt, I think it's time to choose another technology. As I said, if you are really facing fragmentation or performance problem, you can handle them in an ad hoc manner, according to your constraints. Br, Adriano ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Fwd: Is the order of styles within a Qt stylesheet significant?
Hi Atlant,
The rules regarding this are explained in the Qt reference documentation,
in the section called Conflict Resolution in the page called The Style
Sheet Syntax (http://qt-project.org/doc/qt-5.0/stylesheet-syntax.html) -
but in short, if the specificity of two rules is the same, then it is the
last one (that appears in the style sheet) that takes precedence.
Cheers,
Bo
On Thu, Aug 23, 2012 at 3:28 PM, Atlant Schmidt
aschm...@dekaresearch.comwrote:
Folks:
** **
Is the order of styles and sub-styles within a Qt stylesheet ever
significant?
** **
For example (see below), if I had a variety of paragraphs describing
the various types, sub-controls, and states of a widget class, does it
ever make any difference in which order those paragraphs appear?
Or does Qt sort-out all of the more- and less-specific paragraphs,
doing all of the correct inheritance (“cascading”)?
** **
Atlant
** **
--
** **
QPushButton[type=Checkable]:checked
{
image: url(:/icons/checkmark_green_small.png);
image-position: left;
}
** **
QCheckBox[type=YesNoConfirm]::indicator:checked
{
image: url(:/icons/checkmark_green.png);
}
** **
QCheckBox[type=YesNoConfirm]::indicator:unchecked
{
image: none;
}
** **
QCheckBox[type=YesNoConfirm]:checked
{
border-image: url(:/buttons/button_down.png) 30px 36px 31px 34px
stretch;
padding-top: 3px;
}
** **
QCheckBox[type=YesNoConfirm]:pressed
{
border-image: url(:/buttons/button_down.png) 30px 36px 31px 34px
stretch;
padding-top: 3px;
}
** **
QCheckBox[type=YesNoConfirm]:unchecked
{
padding-left: 27px;
}
** **
QPushButton
{
border-image: url(:/buttons/button_up.png) 30px 36px 31px 34px
stretch;
border-top-width:30px;
border-right-width: 36px;
border-bottom-width: 31px;
border-left-width: 34px;
padding-top:-30px;
padding-bottom: -31px;
padding-left: 0px;
font: bold 32px;
color: white;
}
** **
QPushButton:checked
{
border-image: url(:/buttons/button_down.png) 30px 36px 31px 34px
stretch;
padding-top: -28px;
padding-left: 2px;
}
** **
QPushButton:pressed
{
border-image: url(:/buttons/button_down.png) 30px 36px 31px 34px
stretch;
padding-top: -28px;
padding-left: 2px;
}
** **
QPushButton:disabled
{
border-image: url(:/buttons/button_disabled.png) 30px 36px 31px 34px
stretch;
}
** **
** **
--
This e-mail and the information, including any attachments, it contains
are intended to be a confidential communication only to the person or
entity to whom it is addressed and may contain information that is
privileged. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please immediately notify the sender and destroy
the original message.
Thank you.
Please consider the environment before printing this email.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QSettings: is a group present? Crash with qWarning.
Hi,
Looks like your on mac, trying on mine I get this at compilation time:
warning: cannot pass objects of non-POD type 'class QBool' through '...'; call
will abort at runtime
Here is the why of your crash
Hope it helps
Samuel
On 23 août 2012, at 16:51, Sensei wrote:
Hi everyone.
Here's again a question, this time on QSettings with INI files. The
question is simple: how do I know if a group exists in my INI file?
Well, I could ask for all groups with childGroups(), and use the
contains(theGroupName) method.
Except that I don't know why this crashes when used inside a qWarning.
This is the very simple INI file:
[first]
item=2
[last]
size=1
This is the super simple code I've written:
#include QSettings
#include QStringList
int main(int argc, char *argv[])
{
QSettings s(/Users/sensei/Desktop/proj.txp, QSettings::IniFormat);
bool x = s.childGroups().contains(first);
qWarning(Number of groups: %d, s.childGroups().size());
qWarning(Contains [first]: %d, x); // OK
qWarning(Contains [first]: %d, s.childGroups().contains(first)); //
BOOM!
return 0;
}
and your .pro file:
TEMPLATE = app
SOURCES += main.cpp
I don't know why this happens. Any hints? I might be missing something
SO obvious...
Cheers!
PS. My environment is OSX 10.8, the qt installation is the one that I
installed on the previous OSX version. Qt is 4.8.0 (the SDK Maintenance
Tool says I have no updates available).
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] memory fragmentation?
On Linux, you wouldn't allocate 1 GB of memory with sbrk. You'd use an anonymous mmap, which reserves address space but provides no memory backing. The allocation is done on faulting the page. That's how glibc's malloc() serves allocations above a certain adaptive threshold. Thiago, Many thanks for a good comment, It looks like what we actually needed. I will check if anonymous mapping maps are supported on all systems we have to support, this might be a great improvement for our Linux clients :) Alex ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
