How to SNAP top and down menu elements?

[listy]

May be, there should be check if this is hidden row widget?

Code:

                if (parent) {
                    var size = parent.getSize();
                    if (size.y > 0) {
                        //bvr.src_el.setStyle("height", size.y - 71);
                        bvr.src_el.setStyle("height", size.y - 90);
                    }
                }

[remkonoteboom]

The double scrollbars was indeed a headache and we were trying all sorts of mechanism to get rid of this. This was especially bad when you resized the window so you have to have these global onResize events.

... however, this problem has been largely eliminated with newer css capabilities using calc. Of course the VFX plugin hasn't quite moved to this yet. You still need to know the exact size of headers for this to work, but you would do

bvr.src_el.setStyle("height", "calc(100vh - 100px)")

as an example. This dynamically calculates what the height should be and can be used to eliminate the double sidebars even on resize of windows.

[remkonoteboom]

Also, listy for the slow change over for tabs, we aren't doing a lot. Basically just setting display for one tab to "none" and display for the other to "block". So the limit here is the refresh of the drawing by the browser.

Now, on screen it's not that much info. As you know there are some massive bvr attributes and they can be removed with "feature/remove_bvr_attrs" project setting. Is your set to "true" and if not, does it make any difference when you set it to "true".

You did mention before that it should be the default. I do agree. There were some places where it could mysteriously break things, however we have been running with it on for a while now. If you could confirm that everything works by using it set to "true", then I could make it the default.

[Diego]

Sure, good idea!
I added the check and pushed to the same branch, hidden rows seems to display correctly now.

Anyway this way of computing the height will work only when the table is the only element in the view.
if you have 2 element in a vertical layout the table will expand to the height of the parent element pushing the other element down.
I'm trying to find a better way to find the correct height.

[listy]

Also, listy for the slow change over for tabs, we aren't doing a lot.  Basically just setting display for one tab to "none" and display for the other to "block".  So the limit here is the refresh of the drawing by the browser.

Now, on screen it's not that much info.  As you know there are some massive bvr attributes and they can be removed with "feature/remove_bvr_attrs" project setting.  Is your set to "true" and if not, does it make any difference when you set it to "true".

You did mention before that it should be the default.  I do agree.  There were some places where it could mysteriously break things, however we have been running with it on for a while now.  If you could confirm that everything works by using it set to "true", then I could make it the default.

About that slow switching. I don't remember on what we are stopped, when we last discussed this, i think it's because some CPU intensive processes. Anyway, we are enabled this proj.setting, and use it in production long time, and not forced any bugs. Without this setting Tactic was slower from 2x to 3x, so it already helps a lot.
Also, my thoughts on this slowness: it's because Tasks Widget, will try to redo same without its row. I am continue to think it's should be some kind of "instanced widget, without lots of real html, and should appear only when it's needed (clicked or hovered)

[remkonoteboom]

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?

[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?

This is extremely exciting about JSX! I temporary stopped my own investigations in the reactJs, in hope it could become a proper part of tactic. So we all be waiting for any news!

We have not more than 25 users in list by now, typically its 2-10~

The slowness thingy, i made some profiles:

http://tacitc-handler.online/assets/todo...s_v001.zip

One of it with less rows, and another default, with all widgts. The "slow" profile took minute to switch between tabs...

[Diego]

The double scrollbars was indeed a headache and we were trying all sorts of mechanism to get rid of this.  This was especially bad when you resized the window so you have to have these global onResize events.

... however, this problem has been largely eliminated with newer css capabilities using calc.  Of course the VFX plugin hasn't quite moved to this yet.  You still need to know the exact size of headers for this to work, but you would do

bvr.src_el.setStyle("height", "calc(100vh - 100px)")

as an example.  This dynamically calculates what the height should be and can be used to eliminate the double sidebars even on resize of windows.

Great, did some test using css calc and it works mush better, thanks.
I pushed it to the same test branch (4.8-sticky-headers)

[listy]

Great, did some test using css calc and it works mush better, thanks.
I pushed it to the same test branch (4.8-sticky-headers)

Works as expected, will try it in prod.

---

Tested in prod.
I think i had to add something to my custom layouts too, so it will not scrollable:

---

Or, may be, same things must be added to CustomLayoutWdg too?

[Diego]

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 in the view 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

I'd like to find a better way to set the height, i think it should be set by a bvr in the custom layout