Re: [Development] sizeHint for QAbstractScrollArea, especially item views
On Thursday, December 22, 2011 18:06:51 Christoph Schleifenbaum wrote: Hi, currently, item views do return a rather random size hint. Some at KDAB, including me, would love to see a size hint actually being related to the scroll area's content. For this, we thought of a method viewportSizeHint which returns the size of the viewport as if there would be no scroll bars required. The most common use case for this is a list or a table of data in a window: a) The ui designer doesn't need to set a custom size for the view, the size hint will make sure all data are visible b) The amount of data might grow, in that case it might made sense to enlarge the view. Imagine three tree views below each other inside a scroll area. If the tree views would stay at their size, a scroll bar would appear in both the tree view and in the surrounding scroll area. This won't happen with a proper size hint combined with a size policy. I'v attached a patch to the current qtbase.git. It does the described behaviour for QScrollArea and QTableView. Try running the example at examples/itemviews/spreadsheet to see what happens if you e.g. resize the columns in the table view. Thoughts? Just bumping this. The patch is in Gerrit http://codereview.qt-project.org/#change,11763 Apart from the layouting use case, the method would make it easier to implement 'Frozen columns' in itemviews using multiple views which interact with each other. I know that there is an example in Qt for that, but that has some inflexibility, such as it needs to call setHorizontalScrollMode(ScrollPerPixel); setVerticalScrollMode(ScrollPerPixel); frozenTableView-setVerticalScrollMode(ScrollPerPixel); so you are no longer in control of your scroll mode. This proposed method would make it possible to implement the scrollbars properly on the container view (which is the issue the example dodges). Thanks, -- Stephen Kelly stephen.ke...@kdab.com | 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 signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On 01/06/2012 12:45 AM, ext craig.sc...@csiro.au wrote: If the rule is that all operations apply to the temp file rather than the originally named file, this will potentially change the behaviour of existing functions that accept a QFile as a parameter. I'm leaning more towards having remove() and rename() still operate on the originally named file since that's what those functions have always meant. The temporary file should be an almost hidden implementation detail of the class in my view. It would have a similar effect to buffering the writes and merely delaying when those writes are committed to the original file, but with the added benefit that you can cancel the write right up until the file is closed. Taking this approach, you have no confusion about which file rename(), remove(), etc. apply to because they still apply to exactly the same file they did before (the original/target file). The temporary file is meant to be an updated version of the real target. If you want to call rename(), you really should first commit any changes and then rename the file. Similarly, if you want to call remove(), you are either removing the original/target or you are wanting to discard your changes in which case a separate function for doing that (as proposed) seems better. Thus, I don't think rename() or remove() should nor need to work on the temporary file. +1 You may also consider whether, instead of adding a separate API for enabling this functionality (e.g. file.setUseTemporaryFile(bool)), one could simply add another QIODevice::OpenModeFlag. Say, QIODevice::Indirect or something. Because the feature is somewhat akin to QIODevice::Unbuffered, ::Append and ::Truncate. - Eirik Aa. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze date?
Hi, for QtWidgets, there is still a lot of work to be done before everything is in place. That is, a lot of stuff needs to happen around: Widgets: QGuiPlatformPluginInterface Gui: QPlatformTheme meaning factoring out the platform-specific code enclosed in Q_WS_XX and moving it into one of those classes, even renaming/reorganizing them. This means breaking source compatibility here - not sure if it is affected by the feature freeze? Regards, Friedemann -- Friedemann Kleint Qt Open Source Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiling Qt5 on Ubuntu Oneiric
On Fri, Jan 6, 2012 at 6:28 AM, Nicola De Filippo nic...@nicoladefilippo.it wrote: Hi, who to compile with success, on which distribution to do? N. So long as you have the requirements, distro really shouldn't matter. I'm sure there's a pretty big mix. I use Fedora 16. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Fri, Jan 06, 2012 at 09:59:10AM +0100, ext Eirik Aavitsland wrote: On 01/06/2012 12:45 AM, ext craig.sc...@csiro.au wrote: The temporary file is meant to be an updated version of the real target. If you want to call rename(), you really should first commit any changes and then rename the file. Similarly, if you want to call remove(), you are either removing the original/target or you are wanting to discard your changes in which case a separate function for doing that (as proposed) seems better. Thus, I don't think rename() or remove() should nor need to work on the temporary file. rename() implicitly closes first, so by definition this would commit and rename the original file. remove() should simply error out, because there is no intuitive answer to the question which of the files to delete. that's why i think it is ok to overload its meaning with rollback() - nobody would expect something different anyway. You may also consider whether, instead of adding a separate API for enabling this functionality (e.g. file.setUseTemporaryFile(bool)), one could simply add another QIODevice::OpenModeFlag. Say, QIODevice::Indirect or something. Because the feature is somewhat akin to QIODevice::Unbuffered, ::Append and ::Truncate. i was thinking the same. Indirect is a bit broad. UseTemporary or SafeWrite would be closer to being intuitive, even if they look less elegant. On Thu, Jan 05, 2012 at 10:38:37PM -0200, ext Thiago Macieira wrote: What happens if you open the file in read or read-write mode while the flag is on? for read-only this is obviously meaningless. the mode is inherently incompatible with read-write without truncate. in read-write with truncate mode, read operations should simply refer to the temporary file. this is consistent with what you would get otherwise (you start with an empty file anyway). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Issues porting android platform plugin from qt-android
On Jan 5, 2012, at 6:33 PM, ext Ismael Luceno wrote: While adapting this code, I found that QPlatformDesktopService is gone. I'm inexperienced with QT, is there some place where I could read about the change and its implications? I don't think this class was ever in Qt, perhaps it was added to the Android port only? - Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze date?
On Friday, 6 de January de 2012 10.16.49, Friedemann Kleint wrote: Hi, for QtWidgets, there is still a lot of work to be done before everything is in place. That is, a lot of stuff needs to happen around: Widgets: QGuiPlatformPluginInterface Gui: QPlatformTheme meaning factoring out the platform-specific code enclosed in Q_WS_XX and moving it into one of those classes, even renaming/reorganizing them. This means breaking source compatibility here - not sure if it is affected by the feature freeze? In the strict sense, I'd say that it's a feature that needs to be complete by the feature freeze. The QtWidgets part of it, at least, is feature-parity with Qt 4, so it's technically not a *new* feature. It does, however, mean that you'll have less time to stabilise the code compared to the rest of Qt. And I do expect this to be an area of serious interest once 5.0 is out: if we don't do a good job, we'll be told desktops no longer matter for Qt, yadda yadda yadda. Where do you expect source compatibility to be broken? -- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Possible bug in signals and slots handling in QML.
Hi, Nice catch. I've added http://codereview.qt-project.org/12392 - feel free to review if you're not beaten to it :) Cheers, Aaron On 06/01/2012, at 1:01 AM, ext Thiago Macieira wrote: On Wednesday, 4 de January de 2012 16.05.36, aaron.kenn...@nokia.com wrote: We don't allow signal or property names to start with an uppercase letter By the way, the caret should point to the uppercase letter, not to property, in: file:///tmp/foo.qml:4:5: Property names cannot begin with an upper case letter property int Foo ^ It does so correctly for signals: file:///tmp/foo.qml:4:12: Signal names cannot begin with an upper case letter signal Foo ^ -- 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 ___ 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] Possible bug in signals and slots handling in QML.
On Friday, 6 de January de 2012 12.26.32, aaron.kenn...@nokia.com wrote: Hi, Nice catch. I've added http://codereview.qt-project.org/12392 - feel free to review if you're not beaten to it :) Thanks for being quick about this likely-to-be-P5-bug :-) Unfortunately, the code is beyond me. -- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Thu, Jan 5, 2012 at 8:32 PM, David Faure fa...@kde.org wrote: Now there's just one question remaining: even if the rule is that all operations apply to the temp file, between open and close... what should QFile::fileName() return? The temp file name, to obey that rule, or the target file name, for symmetry with setFileName()? I'm tempted to say: the latter, because the temp file is really internal, and to prevent surprises (breaking symmetry with setFileName). Of course it means file.remove() won't be the same as QFile::remove(file.fileName()) anymore... :) But imagine the following scenario: file.setUseTemporaryFile(true) file.open() file.write() APP CRASHES If file.fileName() would return the original filename, how one can restore the temp file? Would the temporary filename be deterministic? Cheers, -- --- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia --- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net --- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Fri, Jan 06, 2012 at 12:53:27PM +, ext shane.kea...@accenture.com wrote: the mode is inherently incompatible with read-write without truncate. Not necessarily, it could make sense to copy the original file to the temporary file in this case. i don't think we want that much abstraction. if you mmap, you are usually dealing with rather big files, so better leave it up to the app to implement its own rewind mechanism. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 feature freeze
On 1/6/12 8:32 AM, ext Stephen Kelly stephen.ke...@kdab.com wrote: On Thursday, January 05, 2012 10:04:38 lars.kn...@nokia.com wrote: We have around a month left until Feb 4th, the date I would like to start with a feature freeze for Qt 5, and it's high time we get some more structure behind things to see where we are and what's left to do. I mostly agree with this. First of all, we need to define what the freeze means. I think it should include a couple of things: * No new features go into the affected modules (see below however) What a feature is might need some definition. How do we know a feature commit from a bugfix (or API fix or ...) commit? Are small features 'features'? Eg things similar to http://codereview.qt-project.org/#change,11783 ? Is a feature anything that needs to be documented (because it didn't exist before)? Yes, we don't really have a definition currently. I personally don't mind if the definition is a bit fluffy and allows for judgement calls. But to give some general rules, I'd say that a feature is anything that * adds functionality to the libraries * larger refactoring of code * stuff that has a higher risk of breaking other people's code We should also define which modules are affected by the feature freeze. I think it's most important to freeze things at the bottom of the stack (ie. qtbase and declarative), but we should IMO look at all the modules that are currently considered part of Qt Essentials. In terms of repositories that means: * qtbase * qtdeclarative * qtxmlpatterns * qtmultimedia * qt3d * qtlocation * qtsystems * qtsensors * qtwebkit (even though that's working slightly differentŠ) Please tell me if you see larger issues with any of the above repositories. Do the people working on them (the ones that are not qtbase) think early February is a reasonable target for them for feature freeze? Will they also add to the Qt 5.0 feature blocking bug to help visibility? From talking to them I believe it's ok for most of them. But that's why I'm asking here, so that any maintainer seeing large problems can speak up. Right now we need to get an overview over what's left to do before the freeze (and the possible exceptions to the freeze). The wiki page we have right now (https://wiki.qt-project.org/5.0_Feature_Targets) is a good start, but won't really allow us to follow progress towards the freeze in a decent way. To get this overview, let's have one blocker bug for the feature freeze. I already have https://bugreports.qt.nokia.com/browse/QTBUG-20885 as a meta task for the larger changes that need to happen for Qt 5.0, and would like to use this one to track what need to happen before the feature freeze. The bug is also a good start, but it is a problem that people who are not Nokia employees do not have enough karma to do useful things with the bug tracker (assign and be assigned bugs, set priorities etc). Any timeline on that? We also can't move existing bugs to be a subtask of that one. Can someone please move https://bugreports.qt.nokia.com/browse/QTBUG-22622 to be a subtask of QTBUG-20885? Yes, this sucks. I thought this had been fixed by now. I'll follow up on Monday to see when the move of bugreports to qt-project.org will happen and how we can fix permissions. This means that if you have something that you think needs to be done before the feature freeze (or is a feature that you need to get in as an exception later on), please create a JIRA task for it and make it a sub task of QTBUG-20885. It would be great if you could all spend some minutes this week to do this so that we have a decent overview early next week. Some of the items on the wiki are done, others are 5.x material and others should be migrated. I might be able to do that later, but other volunteers are welcome. Will you keep that bug clean of tasks people put there that can wait until 5.1? (Again, the karma issue) I'll keep track of things, yes. To be able to reach the feature freeze, we'll all need to focus now on doing the changes that we can't postpone to Qt 5.1, and get them done within the next couple of weeks. It'll be quite a bit of work, but this work will define how Qt 5 will look like in the end. Is there any update on your json object plans? Is that aimed at 5.0 or should it wait for 5.1? It's not on the blocker list, since it's technically not something that couldn't be done for 5.1. But I am still planning to get it in. I'm mostly done by now, there's a little bit of work left to make it safe on big-endian machines (I'll need to find one to actually run the tests though...), do an API review and write docs. I should be done with that and have it ready by end of next week. To summarize here's what we need to do now: * Create JIRA tasks for everything you think needs to be done before the feature freeze and add them as subtasks to QTBUG-20885 * tasks that are not done by Feb 4th need to be
Re: [Development] Feature freeze date?
On 1/6/12 1:59 PM, ext Friedemann Kleint friedemann.kle...@nokia.com wrote: Hi, The QtWidgets part of it, at least, is feature-parity with Qt 4, so it's technically not a *new* feature. It does, however, mean that you'll have less time to stabilise the code compared to the rest of Qt. And I do expect this to be an area of serious interest once 5.0 is out: if we don't do a good job, we'll be told desktops no longer matter for Qt, yadda yadda yadda. Where do you expect source compatibility to be broken? The work to be done is (as I see it): - Think of a plugin API/ class structure such for desktop themes. It should be usable for QtWidgets as well as for potential QML desktop components, so. it should probably go to QtGui with no dependency to the QtWidget classes (partially already visible in the QPlatformDialogHelper classes). I seem to remember there were also plans for a separate QtDesktop library .. not sure if that makes sense. It has also has to account for different Desktops on one platform (think KDE/Gnome/Unity on Linux). That requires some thought and some reorganization of classes, I suppose. I actually was seeing this mostly as 5.1 material. For widgets in 5.0 we can IMO simply continue to use what we have and hook up the styles and other parts that require native handles through the platform integration. - Go over the modules and factor out platform stuff like: #if defined(Q_WS_WIN) SystemParametersInfo(SPI_GETDROPSHADOW, 0, shadow, 0); shadowWidth = shadow ? 0 : 6; } #elsif defined(Q_WS_MAC) shadowWidth = #endif The API needs to be as flexible as possible (QVariant themeHint(enum what)). Still, if the feature freeze happens before finishing the reorganization or important stuff that needs to go to those plugins is discovered later on, there is a chance for source compatibility breakage. Same as above. I agree with you in an ideal world, and the more we can do here for 5.0 already the better. But if we don't get it all done and do have some platform dependencies in there, it's most likely not the end of the world for 5.0 :) Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 feature freeze
On Friday, January 06, 2012 15:41:19 lars.kn...@nokia.com wrote: This gives us both an incremental way to test the features, and one well defined time where we merge them all into master. Great, sounds good to me. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | 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 signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Thursday 05 January 2012 22:38:37 Thiago Macieira wrote: On Thursday, 5 de January de 2012 22.48.32, David Faure wrote: Solution 2: how about making this functionality part of QFile itself? No need to port to another class anymore, just enable the safety feature by calling file.setUseTemporaryFile(true). What happens if you open the file in read or read-write mode while the flag is on? I think that should just ignore the request for a temp file, since it cannot possibly be honoured. Or if you prefer it could print a warning and fail. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Friday 06 January 2012 09:50:14 Artur Souza (MoRpHeUz) wrote: On Thu, Jan 5, 2012 at 8:32 PM, David Faure fa...@kde.org wrote: Now there's just one question remaining: even if the rule is that all operations apply to the temp file, between open and close... what should QFile::fileName() return? The temp file name, to obey that rule, or the target file name, for symmetry with setFileName()? I'm tempted to say: the latter, because the temp file is really internal, and to prevent surprises (breaking symmetry with setFileName). Of course it means file.remove() won't be the same as QFile::remove(file.fileName()) anymore... :) But imagine the following scenario: file.setUseTemporaryFile(true) file.open() file.write() APP CRASHES If file.fileName() would return the original filename, how one can restore the temp file? Would the temporary filename be deterministic? No, no, the whole idea of this feature is not to use the temp file as a backup. If the app crashes, you lose your partially-writen temporary file. That's fine, it was partial anyway, why would you want to use it? I think you're confusing this with a backup feature, which is unrelated. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Fri, Jan 6, 2012 at 2:36 PM, David Faure fa...@kde.org wrote: No, no, the whole idea of this feature is not to use the temp file as a backup. If the app crashes, you lose your partially-writen temporary file. That's fine, it was partial anyway, why would you want to use it? I think you're confusing this with a backup feature, which is unrelated. Yeah, I understand that the main use case is not using it as a backup :) I was just thinking that the use cases are very similar and depending the way you implement it, it's possible to use it to restore i.e. your document if your text editor written in Qt crashes... But if to support this you need to pollute the API, than it's ok to forget the use case :) Cheers, -- --- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia --- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net --- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
- finalise the class name (I think QDns was suggested) Could we get this point settled once and for all? My suggestions: - QDnsLookup (my preferred one, as the object represents a lookup and its result) - QDnsInfo (similar to QHostInfo) - QDns Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On Friday, 6 de January de 2012 18.46.16, Jeremy =?ISO-8859-1?Q?Lainé?wrote: - finalise the class name (I think QDns was suggested) Could we get this point settled once and for all? My suggestions: - QDnsLookup (my preferred one, as the object represents a lookup and its result) Go for it. - QDnsInfo (similar to QHostInfo) - QDns -- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze date?
On Friday, 6 de January de 2012 15.45.13, lars.kn...@nokia.com wrote: - Go over the modules and factor out platform stuff like: #if defined(Q_WS_WIN) SystemParametersInfo(SPI_GETDROPSHADOW, 0, shadow, 0); shadowWidth = shadow ? 0 : 6; } #elsif defined(Q_WS_MAC) shadowWidth = #endif The API needs to be as flexible as possible (QVariant themeHint(enum what)). Still, if the feature freeze happens before finishing the reorganization or important stuff that needs to go to those plugins is discovered later on, there is a chance for source compatibility breakage. Same as above. I agree with you in an ideal world, and the more we can do here for 5.0 already the better. But if we don't get it all done and do have some platform dependencies in there, it's most likely not the end of the world for 5.0 :) Any and all Q_WS_* outside the platform plugins must be gone by the time of 5.0 release. They are dead code. -- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Friday 06 January 2012 11:41:05 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote: Solution 2: how about making this functionality part of QFile itself? No need to port to another class anymore, just enable the safety feature by calling file.setUseTemporaryFile(true). This is what I've started doing in the attached patch, but I'd like to gather feedback before polishing it up. One issue is that after doing file.setUseTemporaryFile(true) and file.open(), all the operations on the file object are no longer operating on the given fileName, but on the internal temporary file. That's what we want for writing, but maybe it could confuse people that remove() or rename() leaves the existing file untouched? I think it would simply have to be documented: when enabling the feature, all that happens between open() and close(), happens on the temp file. I don't support putting this in QFile as has been suggested as, from my experience with it, this will open a can of worms in maintenance and subtle issues cropping up in user code such as the ones being discussed: what's fileName()? Does it exists() before commit? What do remove() and rename(newName) do? If we go towards the idea that the temp file is really internal (as the idea of a mode flag would point to), then fileName() can keep being the target file, exists() will only be true if it already existed before starting to write. If it didn't exist before, then f.open(); f.write(); f.exists() is very fragile anyway, isn't it? It sounds like the result depends on whether OS flushed it to disk or not... So this doesn't seem like a valid use case anyway. When it comes to remove and rename, they are already documented to close the file first, so this would finish the writing operation, and no surprises will happen to the user calling them. No issue of which file is it about, there is only one file after close() anyway. I think if we think of the tempfile as an internal buffering mechanism rather than a second file exposed via the qfile api, then all these issues of which file is this about now don't happen at all. I think we would be well served by an API that exposes a QIODevice interface plus additional interface for commit/rollback. This represents more porting effort for the application developer. I have seen it in KDE in the past, where having to manage one more object, but only in writing mode, not in reading mode, and making sure to call commit/rollback on it, was a lot of trouble, compared to the initial code that was simply using a QFile for all that. Enabling a flag on that QFile would have been s much easier. The other question is, would one have to call commit/rollback explicitely, or should QFile::close() (and the dtor) do the committing? I think commit should require explicit action, for instance, by explicitly calling close(). I don't like having the destructor automatically commit (even if it calls close) though. QFile's destructor has always called close(), that's in everyone's mind, so I don't think we want explicit and implicit close to work differently, that would be very confusing. When writing to a file, you normally don't have to confirm yes I want to commit my changes. So the safer use of a temp file shouldn't require this either, others have convinced me in this thread. An exception being thrown in the middle of a save operation could potentially unwind the stack, call the destructor and commit a transaction half-way through. Exception handling is a new argument though. But doesn't the current QFile have the exact same issue then? You start writing, throw an exception, dtor calls close, there you go. The use of an internal temporary file doesn't change this at all, so I don't see why it should behave differently. If one can throw exceptions in the middle of a save operation, he'll need a RAII class that calls rollback, I would think. What happens to writes happening after a commit, though? This problem doesn't happen if commit == close(). You can't write after closing, that much is obvious to everyone. And how should one rollback? Explicit file.rollback(), or in the existing file.remove()? Oswald suggested doing that in close()/remove() directly, and getting rid of commit()/rollback(). Opinions? I wouldn't like remove() to be doing anything different from what it does now: delete the file pointed to by fileName. Here, I agree. remove() is close()+remove(fileName), so in all cases (tempfile or not), it will remove the target file completely. Rolling back should be a different method, I'm convinced of that now. Not only is it much clearer, it also doesn't break the above rule. Solution 1: using a separate class for handling the QTemporaryFile and the rename call. KDE's KSaveFile and QtCreator's SaveFile do that. The code of such a class is quite easy. The downside is that from an API point of view, it's a bit weird. You have to use this
Re: [Development] QFile: writing via a temporary file
On Fri, Jan 6, 2012 at 9:38 PM, David Faure fa...@kde.org wrote: It could even add an unnecessary need for casting, I could imagine: a public method takes a QFile, then you realize it should handle disk-full situations better, so you pass it a QSaveFile and you have to downcast it internally to call rollback in case of a truncated write...). This doesn't sound appealing. A QFile builtin feature makes this much nicer. I agree, for what it's worth. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QFile: writing via a temporary file
On Friday, 6 de January de 2012 17.22.18, Artur Souza (MoRpHeUz) wrote: If the app crashes at any other point, i.e. after close(), and then the 'target' file is the one you want to open anyway. The saving happens into the temp file. So there is nothing to restore in case of a crash, that's the whole point of not touching the existing file until the final atomic renaming. So in fact I think you're confused about where the writing happens Got it Thanks for the clarification! Another important thing is that, even without crashing, the target file is never found in an in-between state. It's either the old state or the new one. Anyone reading from the file will not see modifications done on-the-fly. Moreover, filesystems on Linux (at least) are tuned so that, if the renaming is recorded, the data was too. There was an issue with early ext4 that those were not synchronised: the writing of the rename happened up to 30 seconds before the writing of the file's data. That meant a crash in that rather large window of time would leave the file empty upon reboot. -- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze date?
On 1/6/12 8:08 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On Friday, 6 de January de 2012 15.45.13, lars.kn...@nokia.com wrote: - Go over the modules and factor out platform stuff like: #if defined(Q_WS_WIN) SystemParametersInfo(SPI_GETDROPSHADOW, 0, shadow, 0); shadowWidth = shadow ? 0 : 6; } #elsif defined(Q_WS_MAC) shadowWidth = #endif The API needs to be as flexible as possible (QVariant themeHint(enum what)). Still, if the feature freeze happens before finishing the reorganization or important stuff that needs to go to those plugins is discovered later on, there is a chance for source compatibility breakage. Same as above. I agree with you in an ideal world, and the more we can do here for 5.0 already the better. But if we don't get it all done and do have some platform dependencies in there, it's most likely not the end of the world for 5.0 :) Any and all Q_WS_* outside the platform plugins must be gone by the time of 5.0 release. They are dead code. True, unless we decide to set the defines for QtWidgets. But you're right, it would be a lot better to get them out and move the code into a platform plugin. Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Removing QBool?
QBool was introduced in Qt4 because qt3 had int contains(...) so there was a need for a compile error when writing (if contains(...) == 2). But it surprises people, e.g. this code doesn't compile: QSettings::setValue(foo, qstringlist.contains(bar)); And I've seen customer code using QBool as a bool container... If it exists in Qt, it must be better... Shouldn't we clean that up for Qt5 and just use a bool for the contains method again? The Qt4 API ensures that nobody still has if (contains()==2) in their code anyway. I can make the change next week if it's okay with everyone. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze date?
On Friday, 6 de January de 2012 22.10.53, lars.kn...@nokia.com wrote: True, unless we decide to set the defines for QtWidgets. But you're right, it would be a lot better to get them out and move the code into a platform plugin. I'm not sure having the defines in QtWidgets would help in all cases. It might be as much effort to make it work with the platform plugin and get the necessary hooks into it than to do it right. I'm guessing here. -- 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
