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.
--
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/63b945b9-222b-44ac-84b3-ed4e8ffdde4fn%40googlegroups.com.
