Re: hard-dep for Qt 4.8
2012/1/18 Thomas Zander zan...@kde.org: On Wednesday 18 January 2012 06.35.57 Martin Gräßlin wrote: I didn't say that this is a reason. I wanted to highlight the problem of not depending on 4.8 and everybody using 4.8. I'm not going to start reviewing code for is this a Qt 4.8 change. Martin, if you remember there are a lot of people using KDE that are not 'core' developers. Typically they are one-time developers, they are artists, they are translators etc. I just wanted to point this out since your attitude can easily be mistaken as not caring about the people that are not able to do the Qt upgrade. I do believe you care, and thats why I think its important to indeed put in that little bit of extra time to make sure we don't use Qt4.8 APIs. Or just respond fast to a person noticing the compilation issue. TBH, I am a bit torn here. As much as I agree with everything Martin said, I also sympathize with Thomas, and I really think he has a point. The conclusion is far from obvious, because making life easier for new contributors is not a good reason for making core contributors' life potentially harder. Also, there is a bit of contradiction in the whole discussion: one side says that everyone will be running 4.8 anyway, the other argues people will have difficulty in getting latest and greatest Qt. So it's a distribution problem, more than a technical one, but I think that was already clear. That said, I am in favor of moving to Qt 4.8 for a simple reason: I believe both of you are right, but you are missing a point: the occasional contributor is very likely to work in a branch. The preferred workflow (oh, how many times we discussed that... anyway) is having people doing fixes ALWAYS working in a branch, and forward-port that. This satisfies Thomas' point, as 4.8 depends just on Qt 4.7. Afterwards, the fix can be forward-ported either by maintainers or the dev itself, and verified with the new versions. Feature development and stuff like that require a full-fledged dev environment, whatever it is, full stop. Being too permissive on very relevant contribution might backfire on us. So in this case the Qt version issue shouldn't be even considered - you use what master uses, and you have no arguments against that. At the end of the day, I think we should: - Emphasize the need of working in the stable branch, ESPECIALLY for occasional contributors, who in 90% of cases want to work there - Communicate more with distributors to ensure they ship the right versions - Don't be afraid of jumping forward with dependencies for our unstable branches Just my 2c. P.S.: In my vision, we moved to git also to solve this kind of issues Its not a whole lot of effort, as far as I can tell, but it does have a pretty big influence on our community members that may not have the computer power or computer savy or just the time you have. thanks :) -- Thomas Zander
Re: hard-dep for Qt 4.8
On Wed, Jan 18, 2012 at 8:54 AM, Thomas Zander zan...@kde.org wrote: On Wednesday 18 January 2012 06.35.57 Martin Gräßlin wrote: I didn't say that this is a reason. I wanted to highlight the problem of not depending on 4.8 and everybody using 4.8. I'm not going to start reviewing code for is this a Qt 4.8 change. Martin, if you remember there are a lot of people using KDE that are not 'core' developers. Typically they are one-time developers, they are artists, they are translators etc. I just wanted to point this out since your attitude can easily be mistaken as not caring about the people that are not able to do the Qt upgrade. I do believe you care, and thats why I think its important to indeed put in that little bit of extra time to make sure we don't use Qt4.8 APIs. Or just respond fast to a person noticing the compilation issue. Its not a whole lot of effort, as far as I can tell, but it does have a pretty big influence on our community members that may not have the computer power or computer savy or just the time you have. thanks :) But according to Martin, this isn't just about API changes, it is also about behavior changes. How do you expect people to know if they are relying on a Qt 4.8-specific behavior? -Todd
Re: hard-dep for Qt 4.8
On Wednesday 18 January 2012 09.05.32 Dario Freddi wrote: if you remember there are a lot of people using KDE that are not 'core' developers. Typically they are one-time developers, they are artists, they are translators etc [] That said, I am in favor of moving to Qt 4.8 for a simple reason: I believe both of you are right, but you are missing a point: the occasional contributor is very likely to work in a branch. Dario, you seem to have skipped over my main argument. This is not *just* about code- contributors, although they make a very strong point too. Instaed think of the impact this has on all the groups I mentioned above. Artists trying to follow development. Translators trying to run stuff in order to figure out where a string comes from. Simple bugreporters that have little technical savy but can try out if a bug is still reproducable in 'master'. What some people here are arguing is that its Ok for a huge group of people that help KDE get better to have to wait for various months before they can compile KDE master again. And I want you to think about that long and hard because you may be underestimating the positive influence that group has on our community. Kind of a postscript I just wanted to reply on your argument for a branch. It doesn't in practice apply to the guys coming in with a simple bugfix. Their starting point will very likely be the current main branch. -- Thomas Zander
Re: hard-dep for Qt 4.8
On Wednesday 18 January 2012 10.11.58 todd rme wrote: But according to Martin, this isn't just about API changes, it is also about behavior changes. How do you expect people to know if they are relying on a Qt 4.8-specific behavior? As far as I know there are no forward incompatible behavior changes between Qt4.7 and Qt 4.8 I.e. AFAIK programming for 4.8 using 4.7 APIs but 4.8 behavior will give the same behavior on 4.7.
Re: hard-dep for Qt 4.8
2012/1/18 Thomas Zander zan...@kde.org: On Wednesday 18 January 2012 09.05.32 Dario Freddi wrote: if you remember there are a lot of people using KDE that are not 'core' developers. Typically they are one-time developers, they are artists, they are translators etc [] That said, I am in favor of moving to Qt 4.8 for a simple reason: I believe both of you are right, but you are missing a point: the occasional contributor is very likely to work in a branch. Dario, you seem to have skipped over my main argument. This is not *just* about code- contributors, although they make a very strong point too. Instaed think of the impact this has on all the groups I mentioned above. Artists trying to follow development. Translators trying to run stuff in order to figure out where a string comes from. Simple bugreporters that have little technical savy but can try out if a bug is still reproducable in 'master'. Indeed, I reckon the situation is much more complex than how I painted it What some people here are arguing is that its Ok for a huge group of people that help KDE get better to have to wait for various months before they can compile KDE master again. And I want you to think about that long and hard because you may be underestimating the positive influence that group has on our community I am way, way far from underestimating that, my efforts in helping and mentoring new contributors should speak for me in this regard :) . Kind of a postscript I just wanted to reply on your argument for a branch. It doesn't in practice apply to the guys coming in with a simple bugfix. Their starting point will very likely be the current main branch. And that is exactly my point. This is very likely to happen, but it's wrong. Because for how our repos are structured now, you will need to commit to the stable branch anyway and forward-port your change after that - so it's not like you should start from a stable branch, but you *NEED* to. And this is how our communication towards new people currently fails, and where we are failing in outlining a clear policy on how to contribute to KDE after the big move. If you have a bug in master and in master only, of course this reasoning does not apply, but it's not the point of the discussion. Of course, as I said before, I just gave my 2c, and I really do appreciate your commitment to making KDE more accessible to anyone (and want to thank you for that), I still think your points are way more than valid (especially the ones about non-coders contributors) and it's great that these kind of topics are brought up in these discussions, so again thanks for considering and most of all for making us consider that. Let's try to move the issue another way round: can we think of a way in which we can safely make master depend on new stuff without the risk of hurting these categories? Let me start by saying I don't have an answer for that, or I wouldn't haven posed the question :). When we discussed git workflows in Randa, we tried to paint a situation where unstable branches were clearly marked as such, but it came out to be a too much complex workflow for how our community is structured. I think, again, modularization could help us here. If we take for granted the main issue in this regard are not code contributors, we probably need to find a way to allow the needs of both kinds of contributors to be satisfied. Our commitment to binary compatibility definitely helps here, and we might even think to go as far as (in the future) making just some components dependent on a particular Qt version, since we can afford to do that. But again, that's just a personal rambling and I would welcome brighter opinion. It's very hard to satisfy everybody, but if there's one thing I totally agree with Thomas, as I said in my previous mail, is that our needs should not be a barrier for new people to join in. But I am confident we can get to a sensible compromise. -- Thomas Zander
Re: Review Request: Append .desktop to generated link files to prevent them from being identified as something else
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103691/#review9921 --- kfile/knewfilemenu.cpp http://git.reviewboard.kde.org/r/103691/#comment8202 Ah, the file doesn't exist yet, so this mimetype detection is based on the filename only, so a file without any extension, which would have worked (from the contents), will get a .desktop appended for nothing. I think this should rather be findByNameAndContent(chosenFileName, content) where content is a QByteArray with the header of a desktop file ([Desktop Entry]\n). - David Faure On Jan. 13, 2012, 7:10 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103691/ --- (Updated Jan. 13, 2012, 7:10 p.m.) Review request for kdelibs and David Faure. Description --- The attached patch prevents a user generated link file, e.g. link to URL location, from being identified as something else. For examples, see the bug reported linked to this review request. This addresses bug 224142. http://bugs.kde.org/show_bug.cgi?id=224142 Diffs - kfile/knewfilemenu.cpp fbb0e48 Diff: http://git.reviewboard.kde.org/r/103691/diff/diff Testing --- Generate a link file to a URL location and see what KDE identifies the file as. Thanks, Dawit Alemayehu
Re: Review Request: Use KCoreConfigSkeleton argument type where possible inside the KConfigDialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103719/#review9922 --- Looks good to me as long as we aren't trying to keep BIC in frameworks. If we are, a duplicate method with KConfigSkeleton that simply calls this new method should be added to keep BC. - Jeremy Paul Whiting On Jan. 17, 2012, 9:28 p.m., Laszlo Papp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103719/ --- (Updated Jan. 17, 2012, 9:28 p.m.) Review request for kdelibs and Jeremy Paul Whiting. Description --- Use case: there are applications, like kanagram, which would be nice to have running on several platforms, as in handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms. The additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings which are currently not used in couple of KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors (ie.: the need already arised previously for such an approach); one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added for good. The KConfigDialog constructor does not handle KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is a good way because it does not cause any API break; a simple recompilation is enough in client applications. Diffs - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103719/diff/diff Testing --- Build test on Linux Thanks, Laszlo Papp
Review Request: make Speller::spellCheckerFound() return true when the dict for the current language is found (important when there was no dict for default language)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103729/ --- Review request for kdelibs. Description --- right now in cases when the dictionary for default language cannot be found Speller::spellCheckerFound() always returns false, even after a langcode for the existing dictionary is passed via setCurrentLanguage(). This patch sets spellCheckerFound to true if the dict is found for the language being set, and false in another case. Actually, the patch makes spellCheckerFound just a cached value of d-dict-isValid(). in the bug 256896 you can find users reporting this problem in addition to another one (regarding using 'language_COUNTRY' dictionaries when only 'language' is specified) This addresses bug 256896. http://bugs.kde.org/show_bug.cgi?id=256896 Diffs - kdeui/sonnet/highlighter.cpp 3f478f0 Diff: http://git.reviewboard.kde.org/r/103729/diff/diff Testing --- Thanks, Nick Shaforostoff
Re: Review Request: Append .desktop to generated link files to prevent them from being identified as something else
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103691/ --- (Updated Jan. 18, 2012, 6:26 p.m.) Review request for kdelibs and David Faure. Changes --- Use KMimeType::findByNameAndContent as suggested by David. Description --- The attached patch prevents a user generated link file, e.g. link to URL location, from being identified as something else. For examples, see the bug reported linked to this review request. This addresses bug 224142. http://bugs.kde.org/show_bug.cgi?id=224142 Diffs (updated) - kfile/knewfilemenu.cpp fbb0e48 Diff: http://git.reviewboard.kde.org/r/103691/diff/diff Testing --- Generate a link file to a URL location and see what KDE identifies the file as. Thanks, Dawit Alemayehu
Re: Review Request: Use KCoreConfigSkeleton argument type where possible inside the KConfigDialog
On Jan. 18, 2012, 3:39 p.m., Jeremy Paul Whiting wrote: Looks good to me as long as we aren't trying to keep BIC in frameworks. If we are, a duplicate method with KConfigSkeleton that simply calls this new method should be added to keep BC. We are definitely not keeping BC in frameworks. What, with splitting code into different libs, moving code around, etc. So no issue here. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103719/#review9922 --- On Jan. 17, 2012, 9:28 p.m., Laszlo Papp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103719/ --- (Updated Jan. 17, 2012, 9:28 p.m.) Review request for kdelibs and Jeremy Paul Whiting. Description --- Use case: there are applications, like kanagram, which would be nice to have running on several platforms, as in handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms. The additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings which are currently not used in couple of KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors (ie.: the need already arised previously for such an approach); one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added for good. The KConfigDialog constructor does not handle KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is a good way because it does not cause any API break; a simple recompilation is enough in client applications. Diffs - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103719/diff/diff Testing --- Build test on Linux Thanks, Laszlo Papp
Review Request: Show the correct remote charset in encoding in Konqueror and Dolphin.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103730/ --- Review request for KDE Base Apps and Peter Penz. Description --- The attached patch fixes a logic error in the code that determines which remote encoding should be checked when the Show Remote Encoding menu is shown. The logic flaw only affects when the user chooses an encoding which has similar types, e.g. ISO-8859-1*. This addresses bug 186289. http://bugs.kde.org/show_bug.cgi?id=186289 Diffs - dolphin/src/views/dolphinremoteencoding.cpp 8644f5c Diff: http://git.reviewboard.kde.org/r/103730/diff/diff Testing --- 1.) Connect to a remote server. 2.) Change the remote charset encoding to Western European ( ISO-8859-1 ). 3.) Go back to the remote encoding and check what is selected. Thanks, Dawit Alemayehu
Re: Review Request: Show the correct remote charset encoding in Konqueror's and Dolphin's Set Remote Encoding menu
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103730/ --- (Updated Jan. 18, 2012, 7:03 p.m.) Review request for KDE Base Apps and Peter Penz. Summary (updated) - Show the correct remote charset encoding in Konqueror's and Dolphin's Set Remote Encoding menu Description --- The attached patch fixes a logic error in the code that determines which remote encoding should be checked when the Show Remote Encoding menu is shown. The logic flaw only affects when the user chooses an encoding which has similar types, e.g. ISO-8859-1*. This addresses bug 186289. http://bugs.kde.org/show_bug.cgi?id=186289 Diffs - dolphin/src/views/dolphinremoteencoding.cpp 8644f5c Diff: http://git.reviewboard.kde.org/r/103730/diff/diff Testing --- 1.) Connect to a remote server. 2.) Change the remote charset encoding to Western European ( ISO-8859-1 ). 3.) Go back to the remote encoding and check what is selected. Thanks, Dawit Alemayehu
Re: Review Request: Show the correct remote charset encoding in Konqueror's and Dolphin's Set Remote Encoding menu
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103730/#review9929 --- Ship it! Thanks for the patch, looks fine! - Peter Penz On Jan. 18, 2012, 7:03 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103730/ --- (Updated Jan. 18, 2012, 7:03 p.m.) Review request for KDE Base Apps and Peter Penz. Description --- The attached patch fixes a logic error in the code that determines which remote encoding should be checked when the Show Remote Encoding menu is shown. The logic flaw only affects when the user chooses an encoding which has similar types, e.g. ISO-8859-1*. This addresses bug 186289. http://bugs.kde.org/show_bug.cgi?id=186289 Diffs - dolphin/src/views/dolphinremoteencoding.cpp 8644f5c Diff: http://git.reviewboard.kde.org/r/103730/diff/diff Testing --- 1.) Connect to a remote server. 2.) Change the remote charset encoding to Western European ( ISO-8859-1 ). 3.) Go back to the remote encoding and check what is selected. Thanks, Dawit Alemayehu
Re: Review Request: Show the correct remote charset encoding in Konqueror's and Dolphin's Set Remote Encoding menu
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103730/#review9935 --- This review has been submitted with commit 8f231bd08134f7b1870a9c1747429c1b05174d62 by Dawit Alemayehu to branch KDE/4.8. - Commit Hook On Jan. 18, 2012, 7:03 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103730/ --- (Updated Jan. 18, 2012, 7:03 p.m.) Review request for KDE Base Apps and Peter Penz. Description --- The attached patch fixes a logic error in the code that determines which remote encoding should be checked when the Show Remote Encoding menu is shown. The logic flaw only affects when the user chooses an encoding which has similar types, e.g. ISO-8859-1*. This addresses bug 186289. http://bugs.kde.org/show_bug.cgi?id=186289 Diffs - dolphin/src/views/dolphinremoteencoding.cpp 8644f5c Diff: http://git.reviewboard.kde.org/r/103730/diff/diff Testing --- 1.) Connect to a remote server. 2.) Change the remote charset encoding to Western European ( ISO-8859-1 ). 3.) Go back to the remote encoding and check what is selected. Thanks, Dawit Alemayehu
Re: Review Request: Show the correct remote charset encoding in Konqueror's and Dolphin's Set Remote Encoding menu
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103730/#review9936 --- This review has been submitted with commit e824021d45a989ec75776f14082d6af62223715d by Dawit Alemayehu to branch master. - Commit Hook On Jan. 18, 2012, 7:03 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103730/ --- (Updated Jan. 18, 2012, 7:03 p.m.) Review request for KDE Base Apps and Peter Penz. Description --- The attached patch fixes a logic error in the code that determines which remote encoding should be checked when the Show Remote Encoding menu is shown. The logic flaw only affects when the user chooses an encoding which has similar types, e.g. ISO-8859-1*. This addresses bug 186289. http://bugs.kde.org/show_bug.cgi?id=186289 Diffs - dolphin/src/views/dolphinremoteencoding.cpp 8644f5c Diff: http://git.reviewboard.kde.org/r/103730/diff/diff Testing --- 1.) Connect to a remote server. 2.) Change the remote charset encoding to Western European ( ISO-8859-1 ). 3.) Go back to the remote encoding and check what is selected. Thanks, Dawit Alemayehu
Re: Review Request: Use KCoreConfigSkeleton argument type where possible inside the KConfigDialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103719/#review9937 --- Ship it! Ship It! - Jeremy Paul Whiting On Jan. 17, 2012, 9:28 p.m., Laszlo Papp wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103719/ --- (Updated Jan. 17, 2012, 9:28 p.m.) Review request for kdelibs and Jeremy Paul Whiting. Description --- Use case: there are applications, like kanagram, which would be nice to have running on several platforms, as in handsets; for instance Harmattan on N9. It would be nice to use the same settings code generation in certain cases for all the platforms. The additions of KConfigSkeleton on the top of KCoreConfigSkeleton are the font and color settings which are currently not used in couple of KDE applications. Hence, it should not be mandatory. The kdeui module is unlikely welcome on mobile platforms, especially in appstores with its sizes and complexity for no real need. KConfigDialogManager has apparently already two constructors (ie.: the need already arised previously for such an approach); one with KConfigSkeleton argument type, and yet another with KCoreConfigSkeleton. It looks like a situation where the KCoreConfigSkeleton version was added for good. The KConfigDialog constructor does not handle KCoreConfigSkeleton argument type yet; it has probably somehow been missed so far. Changing the current constructor to KCoreConfigSkeleton usage is a good way because it does not cause any API break; a simple recompilation is enough in client applications. Diffs - kdeui/dialogs/kconfigdialog.h 2ac0eda kdeui/dialogs/kconfigdialog.cpp e815e54 Diff: http://git.reviewboard.kde.org/r/103719/diff/diff Testing --- Build test on Linux Thanks, Laszlo Papp
Re: Re: hard-dep for Qt 4.8
On Wednesday 18 January 2012 10:26:13 Thomas Zander wrote: On Wednesday 18 January 2012 10.11.58 todd rme wrote: But according to Martin, this isn't just about API changes, it is also about behavior changes. How do you expect people to know if they are relying on a Qt 4.8-specific behavior? As far as I know there are no forward incompatible behavior changes between Qt4.7 and Qt 4.8 I.e. AFAIK programming for 4.8 using 4.7 APIs but 4.8 behavior will give the same behavior on 4.7. What comes to my mind is multi thread support for QtOpenGL [1]. That is using threaded OpenGL with Qt 4.8 will work, while it fails with 4.7 without rendering a compile error. Cheers Martin [1] http://labs.qt.nokia.com/2011/06/03/threaded-opengl-in-4-8/ signature.asc Description: This is a digitally signed message part.
Re: Re: hard-dep for Qt 4.8
On Wednesday 18 January 2012 12:53:25 Dario Freddi wrote: Let's try to move the issue another way round: can we think of a way in which we can safely make master depend on new stuff without the risk of hurting these categories? Yes of course. First of all we have to think whether we introduce problems at all. Let's consider translators: they currently work on the branch anyway, so no problem. I hope that they don't waste their time by following master. So whether a Qt 4.8 dependency matters is a question for the time around the string freeze. The next question is whether translators and designers should waste their time on compiling master or if there are better ways to test master. What comes to my mind is for example Project Neon for all Debian based systems installing current master snapshots in a separate directory. I as a developer used it more than once to actual do testing. Another option would be to use susestudio to build a always up to date live cd. I did not find something but this is probably a good idea to create. Last but not least there is the question who could not install Qt 4.8 right now. So let's see: * Fedora: Qt 4.8 in last release * Debian: package in experimental * openSUSE: http://download.opensuse.org/repositories/KDE:/Qt48/openSUSE_Factory/ * Arch: seems to be included * Kubuntu: https://launchpad.net/~kubuntu-ppa/+archive/experimental So personally I don't see a problem here with requiring Qt 4.8. It is not difficult to get those packages (please don't argument now that you still use Kubuntu 10.04 and for that the package does not exist. Wanting to work on the lastest stack requires the latest stack). Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: hard-dep for Qt 4.8
On Thursday 19 January 2012 08.15.39 Martin Gräßlin wrote: As far as I know there are no forward incompatible behavior changes between Qt4.7 and Qt 4.8 I.e. AFAIK programming for 4.8 using 4.7 APIs but 4.8 behavior will give the same behavior on 4.7. What comes to my mind is multi thread support for QtOpenGL [1]. That is using threaded OpenGL with Qt 4.8 will work, while it fails with 4.7 without rendering a compile error. The enum Qt::AA_X11InitThreads is not available in 4.7, which enables the functionality mentioned in the blog. Using that would give a compile error. -- Thomas Zander
