#604 was promised to be included in 1.4.1. Is this still going to be included?

The issue mentioned by @mineo in #613 (comment) still exists afaict, 1.4.1 is now on a feature freeze anyway and we'd be migrating to qt5 soon so that PR will need a rewrite.

Sorry if there is some confusion. I mentioned #604 not #613.

#604 (comment)

Point 1 of the #613 (comment) doesn't apply because it relates to features of #613 which are not in #604.

I will take a look at Point 2 again, though I answered @mineo's comments about it perhaps being related to o/s and several comments after that asking that the PR be merged so it could have more extensive testing on non-Windows.

#604 gives a lot of benefits and now it won;t make 1.4.1.

More to the point it is a significant PR which had a lot of my effort and, since I don't have the time to rewrite it for QT5, if there is not gong to be a 1.4.2 it can be included in before you move to v2 with QT5 then this much needed fix is not going to happen,

Might I suggest that it might be better to create a v2 branch and continue development in parallel at least until we get to a beta version of v2. This seems to me to be the point that we can functionally stabilise 1.4, retrofit any 1.4 fixes to v2 and ask people to start coding new PRs against v2 rather than v1.4.

Or perhaps we can merge it after 1.4.1 in order to take it into whatever the next release is - 1.4.2 or v2

@Sophist-UK the plan is that we will make 2.0dev the master and continue the dev for 1.4.X in another branch. You can definitely have it in 1.4.X, in case you don't have the time to port it to Qt5. Albeit after it has been tested and approved by other devs to be working on all 3 major OSes :)

I will look again at the problem reported by @Mimeo (even though I answered his issue at the time) but if it is specific to an o/s I don;t have then I can't fix it.

My point is that sometimes you need to merge it knowing it is imperfect but better than current in order to then improve it still further.

As for branches, IMO it would still be better for this to be merged before 2.0dev is split off even though it is imperfect because the imperfections can then be ironed out.