在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. Understood, I'm just guessing as well. I'll further investigate the root cause later. Thank you for your guidance. -- 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/fa52a6f2-09c1-4c4c-a8e6-7bb4c570c751n%40googlegroups.com.
