On 10/27/18 1:43 PM, Daniel wrote: > On 27/10/2018 19:33, Richard Kimberly Heck wrote: >> On 10/24/18 7:36 AM, Daniel wrote: >>> On 24/10/2018 12:20, Daniel wrote: >>>> On 24/10/2018 11:40, Daniel wrote: >>>>> On 23/10/2018 18:37, Daniel wrote: >>>>>> On 23/10/2018 11:21, Daniel wrote: >>>>>> [...] >>>>>>> One thing I couldn't try out is the Advanced Search & Replace >>>>>>> dialog when docked to the top or bottom. I remember that this is >>>>>>> possible, for example, on MacOS but it seems not to be on Windows. >>>>>>> So, it would be great if someone could test what it looks like >>>>>>> when docked to the top.[...] >>>>>> >>>>>> This was apparently due to a bug in Qt 5.11.2. Docking works fine >>>>>> in Windows with Qt 5.9.7. Top/bottom docked looks a bit ugly (as it >>>>>> used to). I'll try to fix it. >>>>> >>>>> New patch attached. Also a screen capture as an example of how I >>>>> changed things. >>>>> >>>>> Two things I noticed: >>>>> >>>>> - The Quick Find & Replace dialog had a variable height but there >>>>> were no elements in it that would need a variable height so I fixed >>>>> it. But maybe there is a specific reason for not having dialogs with >>>>> fixed sizes in general? >>>>> >>>>> - There is something strange going on with the size of the Advanced >>>>> Find and Replace Widget. >>>>> >>>>> When docked to the top (or docked to the top and then undocked) its >>>>> minimum height is the minimum height it has when docked to the side. >>>>> But since the box layout is switched from horizontal to vertical >>>>> this makes no sense. >>>>> >>>>> And also when the widget is first called it is on the side and can >>>>> be made rather narrow. But once it has been docked to the top and >>>>> back to the side it cannot be as narrow any more since it is >>>>> restricted to the minimum width as if it were docked to the top (or >>>>> docked to the top and undocked). >>>>> >>>>> Is this a known problem? >>>> >>>> Sorry, I saw another dialog (Compare) for improvement on my way out. >>>> Patched in the attachment. Screen captures attached as well. >>> >>> Didn't know that the last open tab in the Creator becomes the >>> default... fixed version attached. >> >> >> I had a look through this. Unfortunately, these *.ui patches are >> basically impossible to read. There are too many changes shown, and I >> anyway can't tell what the effect is likely to be. So the only thing we >> can do is commit and test. I think it's too late for 2.3.2, but we can >> commit as soon as 2.3.x is open. >> >> Unfortunately, the patch does not apply to master. That's not terribly >> surprising, because of how the *.ui changes work. (You really only >> change a few things, but the file actually changes quite a lot.) So >> we'll need to redo it, in effect, for there. That could be committed >> right now, though. >> >> Riki > > Thanks for taking a look. Yes, there were quite some changes that > seemed reasonable to me. I hope they are rather safe but I have only > tested them on Win10. > > I guess the problem of porting goes both ways, right? So, a patch for > master would also be hard to apply to 2.3.x?
When there are changes to *.ui files, yes, I expect so. Usually changes to *.cpp files and the like port easily, or can be easily fixed. > I could just redo all the changes for a new patch. There were quite a > few but I think I'd be quickly done. OK. > By the way, is there a point in creating separate patches, i.e. one > for each dialog? It wouldn't hurt. It would at least make it easier to find problems, if any arise. Riki
