How to SNAP top and down menu elements?

[listy]

That's the problem I was talking about, you have an element vertically staked but the height calculation uses a constant that works only when the table is the only element because it is based on the standard tactic title+tab bar



If all your pages have the same layout you can change increase the 168px in:
bvr.src_el.setStyle("height", "calc(100vh - 168px)");
to take in account your custom menu bar height

No, we have bunch of custom layouts, and we use default tables as well.
I'll try to investigate this too 

[Diego]

This problem ha bee an headache for quite some time.

My guess is, we live the default TableLayoutWdg calculation, than each custom layout has a bvr to customize it.

The problem is I cannot find a good way to get the element object, I need something like:

var child = bvr.src_el.getChildbyClass(".spt_table_horizontal_scroll");
child.setStyle("height", "calc(100vh - XXXpx)");

unfortunately the getChildbyClass does not exists.

another idea could be to add an "table_horizontal_scroll_id" kwargs for TableLayoutWdg thats ad an id to the h_scroll widget so we can than use getElementById()

[remkonoteboom]

To avoid a double scrollbar, you have to get everything right. It's really annoying. Sometimes you just want to set an "overflow: hidden" in the right place to get rid of the scrollbar ... which works some of the time, but it's better to avoid it if you can. Basically you have to decide what widget is controlling the scrollbar and everything either needs "height: 100%" (or smaller) or an explicit calc setting that will not produce a scrollbar. It will cascade well if everything is set up correctly.

In this case, we need to be able to set the height of the scroll in TableLayoutWdg to fit the view it is in. I think this is what Diego is talking about. The question is whether this should be done externally by specific class or by a kwargs into TableLayoutWdg. Before we had tried to do this with "window_resize_offset" kwarg, but this used a resize event. This worked, but the calc css is much faster and better.

We do have a specific class on the scroll, but it has a hard coded height to 100%

.my_table .spt_table_scroll {
height: calc(100% - 100px") !important
}

The important is set because it is now set to 100%. If this works, then maybe we can find a better solution.

[Diego]

I think I found a promising way.
If we get the x coordinate of the top of the table we could subtract that to 100vh.
the h_scroll load behavior would be:

Code:

var parent = bvr.src_el.getParent(".spt_tab_content_top");
var is_hidden_row = bvr.src_el.getParent(".spt_hidden_content");

if (parent && !is_hidden_row) {
    var offsets = bvr.src_el.getBoundingClientRect();
    var top = offsets.top + 41;
    bvr.src_el.setStyle("height", "calc(100vh - " + top + "px)");
}

It seems to work quite well for me, I'm not sure where the "41" comes from I found it by trial.

Listy could you test it on your layouts?

The new test verision:
https://github.com/diegocortassa/TACTIC/...out_wdg.py

[listy]

It is working like a charm now!

[listy]

On the last changes I committed, I had started to reorganize the TaskElementWdg, breaking it into some component functions so that the code is much more understandable.  In doing so, I also eliminated a lot of redundant (and even tried a bit of JSX, which is still highly experimental ... more on that sometime later in another post).

I haven't made anything dynamic yet.  Are any of those lists in the drop downs huge?

There is another thing i wanted to tell. I don't know how it's made in web and js, but with the QT i made on demand loading, so i don't have to cache all images before show all elements, but make them just before showing.
In this example, previews and other controls are created when user scrolls items:



(Sorry for showcasing T-H all the time, but this tool was made to cover things i wanted to see in tactic)

[remkonoteboom]

No problem showing it off ... I was thinking of actually putting it on the TACTIC community site at some point.

At any rate, most of TACTIC web UI is dynamically loaded. Even the table is loaded in chunks (however, this is not dynamic in the sense that it is by user event). The hidden rows, for example are dynamically loaded just as in T-H. Even the tabs do not load until called upon.

I am still getting around to finding what the bottlenecks are. I do notice in your images that you have a progress process with an assets count/status ... is widget faster without this (if you know)?

I have also been prototyping the TableLayoutWdg to use div instead of the table. I have put this off for a while, but I think to go to the next level, this has to be done. <table> is just way to unpredictable and is the primary cause of all of the display issues. I actually have the table displaying properly, but the behaviors break (as the structure has changed) but I think will really help with all the table layout bugs.

[listy]

 you have a progress process with an assets count/status ... is widget faster without this (if you know)?

Almost no difference. This widget is cached, so it's pretty fast.

There is some advices from browser btw, which is winking to us about some long js calculations:

[Violation] 'mousedown' handler took 280ms
[Violation] Forced reflow while executing JavaScript took 277ms

When we change tabs.

Almost all activity when tab is changed is Recalculate style.
And there is mouse down timeout in filter_content.js:156

Paper about layouts: https://webcache.googleusercontent.com/s...clnk&gl=ru

[remkonoteboom]

"Almost all activity when tab is changed is Recalculate style."

Interesting. This widget could definitely use some css centralization. It's something I can take a look at.

[listy]

"Almost all activity when tab is changed is Recalculate style."

Interesting.  This widget could definitely use some css centralization.  It's something I can take a look at.

I don't think the problem with the widgets in the rows, but the count of rows and columns are matter.
You can reproduce slowness if you open table with 400+ rows, and 10+ cols.
When such "heavy" table opened the whole browser tab, and even left sidebar became laggy and stutter.

One way is to avoid big tables, but we have something like Assets in Episode, which showing all assets available, so scriptwriter can scroll them and add needed to his episode