Very well done! It's interesting that the two status bars don't even align with each other. The cutoff top and bottom also suggest that the QWebEngineView is getting wrong video information somehow, or can't understand it correctly. Is there any chance that you use an display multiplier other than 100%?
Qt reacts to an environmental variable named QT_WIN_DEBUG_CONSOLE. If you set it to *new* Qt will write stdout and stderr to a new console or to *attach* to try to write them to the launching console. This is Windows only. Maybe setting this variable would be helpful. You could also subclass the statusbar and make it print a message to the console when it is created. Everything might happen too quickly but maybe there is something to be learned. You might also add a button that creates the status bar, or use a QTimer to create it after a delay. I bet that the double status bar won't happen then. I don't have multiple monitors, but aren't there different ways to configure them? I'm thinking of extending the screen across several monitors as opposed to having one screen per monitor. Maybe Windows or the graphics driver are sending confusing information about this to Qt. On Friday, November 29, 2024 at 4:04:40 AM UTC-5 [email protected] wrote: > 在2024年11月28日星期四 UTC+8 13:00:27<[email protected]> 写道： > > On Wednesday, November 27, 2024 at 8:34:00 PM UTC-5 [email protected] > wrote: > > Hello Thomas, > > Yesterday, I mentioned that disabling the timer resolved the issue, > meaning the UI dragging problem disappeared. However, the layout > functionality was affected. I suspect the problem lies in the run_layout > function. > > I also tried reducing the timer delay, but the issue still persists. > > Today, I further traced the code and focused on the restoreFromLayout > function in qt_layout.py. When I removed vr3 as shown below, the UI behaved > normally: > if *0*: # has_vr3 > if (vr3 := self.find_widget('viewrendered3_pane')) is None: > import leo.plugins.viewrendered3 as vr3_mod > vr3 = vr3_mod.getVr3({'c': self.c}) > vr3.setParent(self) > > At this point, the UI issue was resolved. I did some additional testing > and found that enabling viewrendered.py in @enabled-plugins instead of > viewrendered3.py prevented the UI's border dragging issue in Leo. > > Therefore, the root cause seems to be related to vr3. My initial guess is > that there might be an issue with the hierarchy or parent-child > relationship set by vr3. I will investigate this further when I have more > time. > > VR3 yes, hierarchy no. It's timing matter. VR3 takes some time to > instantiate because the QWebEngineView has to create an instance of the > Chrome browser component, which is large and complex. The Chrome browser > component is not a Qt program but has to be created and encapsulated by the > QWebEngineView. That is relatively slow. I'm not sure but I think the > Chrome instantiation may happen asynchronously. VR only has to create a > QTextBrowser which is much simpler and faster. I spent a lot of time on > this matter trying to get everything (I mean both for VR and VR3 being > enabled) to work right when I developed the new layout system. > > The QTimer delay is there because without it, the layout command often was > not available and so the initial layout failed to complete, apparently > because the commandDict had not been finalized yet. At least, it did not > contain the layout commands at that time. The delay is intended to provide > time for this initialization. Today I tried values of the delay down to > 10ms and didn't get any errors. I suggest setting it to 30ms, and see if > your double scrollbar goes away. > > If not, I suggest trying to find just where and when the components that > are erroring get set up. I had thought you were taking about a double > status bar but now you are talking about border dragging. I urge you not to > assume you know exactly where the issue is located yet, or even what the > nature of the problem is that results in the UI visual symptoms. As I said > earlier, the layout code does not use or move the status bar at all. But it > could conceivably happen that the status bar is only partially completed at > the time the initial layout is executed. It's hard for me to believe but > maybe it could happen. If so, maybe the initial layout execution could be > run a little later. > > So far as the layout hierarchy is concerned, it is necessary that VR/VR3 > (and all the layout components) be in some location where they can be found > when the layout code runs. For the initial layout, this means that VR/V3's > parent widget must be one of (main_splitter, secondary_splitter, > DW.layout_cache). In the code fragment above, VR3 is made a child of the > DW.layout_cache by the last line: vr3.setParent(self). When executing a > new layout, the layout code identifies any components that aren't going to > be used in the new layout and makes them children of the DW.layout_cache > widget. This includes any new splitter or other widgets that some script > may have inserted to make a custom layout. This requirement makes sure that > these widgets can be found again for reuse. Then it tries to find the > widgets that will be used by the new layout. If a new splitter is > specified, the layout code will create it and insert it into the new layout. > > You can that the design of the layout code sets specific requirements on > the parent-child relationships of the widgets in the layouts. The concept > is simple and flexible; you can't go changing them, otherwise some or all > of the layout commands will not work. > > I still haven't been able to cause any of your symptoms to happen, neither > on my Windows 10 computer nor on any of several Linux VMs I've tried. No > one else has complained yet about anything like these problems. So it's > likely to be related to something specific to your computer. Perhaps it's > a graphics card producing different timings; perhaps Qt doesn't work well > with the card; it could even be a Qt bug that affects your computer but not > most others. We can't really know yet. > > Can you check to see if the symptoms only happen with certain outlines, > such as a very small one versus LeoPyRef? If Leo opens with several > outlines open, do these problem only happen once or to they happen for each > outline as you switch to it? Chances are that Leo will open with the > workbook focused. Would you make Leo open with some other outline instead > so we can see if the symptoms still happen? If there is a later version of > PyQt6 and the QWebEngineView would you upgrade to them and see if the > problem goes away? > > I don't want to put your issue down simply to some installation problem on > your particular machine. Anything that happens on your computer could > potentially happen to someone else too. Perhaps we just haven't been > informed of such an incident yet. > > > > Hello Thomas, Today, I traced the vr3 code further and have basically > confirmed that this is an issue with QWebEngineView and not related to vr3. > I wrote a simple standalone app, and the issue still occurs when dragging > the window border to resize it on my computer. > Below is a screenshot. > [image: 5.jpg] > > The screenshot above was taken with a phone. If you use Alt + PrtSc, it > will look like the one below. > > [image: 4.jpg] > > At the moment, I’m not sure if this is a Qt issue or specific to my > computer (I have 4 monitors). I’ll test it on another computer later to > verify. > > Additionally, I believe this should not affect Leo's next release. > > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/leo-editor/c0fdb57a-0af5-49c5-93f3-a8436a5c6159n%40googlegroups.com.
