Is this a Layout Bug

[Ray wang]

 When I resize the window by dragging the border, the following issue occasionally occurs: the tab area disappears, and the status bar appears multiple times. It also happens while dragging.  Ver: 6.8.2

  

[Thomas Passin]

I don't know.  I haven't noticed any problem while dragging or resizing.  But there have been one or two times when I've come back to an open Leo window and had some feature missing, like the main menu bar. I can't reproduce the behavior as yet. I don't see how the layout system per se could be causing an issue like this, but maybe all the UI elements need something like a size policy or minimum size set.  That would be a pain and *shouldn't* be necessary. I've seen online that some people seem to have various Qt problems when they don't.

The layout system never touches the status bar.  Someone could write a new layout to move it but no standard layout does so.

I'm fascinated by the moire pattern in your image. Please tell me you didn't print out the screen shot, flatten it onto a table, and take a picture of it. Yet I don't see another way you could have gotten the visible pattern.

[Ray wang]

  This effect is indeed from taking a photo. When using a screenshot, the status area disappears and turns black, like in the image below.

  

[Thomas Passin]

What you describe makes me think that the extra status bar is not actually part of the main Leo window.  It is all very strange!

[Ray wang]

  I used a simple approach: version rollback to locate the issue. So far, I've found that removing the line

 QtCore.QTimer.singleShot(300, run_layout) 

 in qt_frame.py resolves the problem. Can you help me take a look?  

[Thomas Passin]

I added the timer to prevent a problem that I think was a race condition.  With a timer, the delay time is always going to be a guess and maybe it needs to be smaller for your machine.  Still, I don't understand why an extra status bar gets shown.  The layout code does not touch the status bar at all.

I have never seen your symptoms so it's hard for me to know how to proceed.  I don't want to completely eliminate the timer but the delay could be adjusted.  Would you please remind me of your OS and PyQt versions? Also, if you have an unusual  graphics card I would think it could be involved somehow.

Also, would you try reducing the delay in steps, and see how low it has to go before the symptoms disappear? I could try the same value and see if I notice any problems because of it. I could try increasing it to see if I get your symptoms that way.

[Ray wang]

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.

Best regards

[Thomas Passin]

On Wednesday, November 27, 2024 at 8:34:00 PM UTC-5 wzy...@gmail.com 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.

[Ray wang]

Understood, I'm just guessing as well. I'll further investigate the root cause later. 

Thank you for your guidance.  

[Edward K. Ream]

On Thursday, November 28, 2024 at 12:13:01 AM UTC-6 wzy...@gmail.com wrote:

>> 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.

I have been following this conversation with interest. Leo 6.8.3 is scheduled for release on Friday, December 6. I am willing to delay that date by a week or so to resolve this issue. But I won't delay 6.8.3 much longer than two weeks.

Edward

[Edward K. Ream]

On Thursday, November 28, 2024 at 12:13:01 AM UTC-6 wzy...@gmail.com wrote:

>> 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.

[Ray wang]

在2024年11月28日星期四 UTC+8 13:00:27<tbp1...@gmail.com> 写道：

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.

 

  The screenshot above was taken with a phone. If you use Alt + PrtSc, it will look like the one below.

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.

 

[Ray wang]

This is my code: 

[Edward K. Ream]

On Fri, Nov 29, 2024 at 3:04 AM Ray wang <wzy...@gmail.com> wrote:

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.

...

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.

Thanks, Ray, for this good work. I'll release Leo 6.8.3 one week from today.

Edward

[Thomas Passin]

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.