VBox does not hide in case of overflow

[Konubinix]

I am not sure wether it is the same problem as #583.

I am using flexx 0.8, from pypi.

With this simple example

#!/usr/bin/env python3
# -*- coding:utf-8 -*-

from flexx import flx

class Test(flx.VBox):
    def init(self):
        for i in range(50):
            flx.Label(text=f"{i}")

def main():
    flx.App(Test).serve()
    flx.start()

if __name__ == "__main__":
    main()

In chromium 81.0.4044.92, I can scroll the webpage. IIUC, this is not the expected behavior. I can see in the inspector that it has "overflow: hidden", since it is a Widget.

By tweaking the example, I can retreive the overflow: hidden behavior doing

#!/usr/bin/env python3
# -*- coding:utf-8 -*-

from flexx import flx

class Test(flx.Widget):
    def init(self):
        dummy_widget = flx.Widget()
        with flx.VBox():
            for i in range(50):
                flx.Label(text=f"{i}")

def main():
    flx.App(Test).serve()
    flx.start()

if __name__ == "__main__":
    main()

Note the dummy_widget above the VBox. Without the dummy widget, the page is still scrollable.

[almarklein]

I can reproduce this in Firefox. It looks like this happens because the VBox sets it's min-height. The VBox is a layout that works "bottom up", trying to maintain a size that makes sense for it's children (and their children, etc...)

I think that we should prevent the min-height from being set when the widget is the main widget.

[Konubinix]

Thank you for taking the time looking at this bug. In the mean time, I get used to nest layouts in widgets when they don't work as expected.

[Konubinix]

IIUC, the VBox widget is meant to have a size big enough to contain its children. In that case, the VBox widget will never overflow. And because it is nested in a Widget, that doesn't have a style "height: 100%", the page is scrollable. When putting the VBox into a Layout, that has the style "height: 100%", the page has the expected behavior. Is that right?

In that case, once I understand the behavior of VBox, it makes sense and sounds sensible. May be this could be considered more a bug in the documentation that implies that the Layout take 100% of the available space and no more.

Would it work to add a div with "height: 100%" in the VBox that would contain the div for which max-height may be big?

<div height="100%"> <- the HVLayout
  <div max-height="big">
     ...children
  </div>
</div>

[Konubinix]

Actually, I am writing an application using flexx and speding a fair amount of time reading the code to undertand how it works. I wish I could contribute in the future.

I think flexx is really awesome.

[almarklein]

IIUC, the VBox widget is meant to have a size big enough to contain its children. In that case, the VBox widget will never overflow.

Yeah, the VBox and HBox try to communicate the required size to their parent (this is what I meant with "bottom-up"). The VSplit and Vfix work the other way around: they divide the available space for their child widgets, without considering the children's needs.

The toplevel browser window should (I think) be considered a top-down widget: this is the available space, deal with it. If you want a scrollable space, make your toplevel widget scrollable. In that sense, the current behavior is a bug.

Or ... we say that it depends on the kind of layout of the toplevel widget. In that case the current behavior is a feature, and indeed needs to be better documented. I'm not sure yet what fits best, to be honest :) leaving this open for now ...

I think flexx is really awesome.

Thanks! Though I should also warn you that as a project becomes bigger, the mix of real Python and PScript (Python-that-is-really-js) quickly results in confusion, especially if multiple people work on a project. This is why I don't think Flexx will become mainstream.

[Konubinix]

Anyway, once I understood the behavior of VBox and HBox, things became much easier.

Here is the reason why I find flexx awesome.

At several occasions, I have projects that I want to share with non-technical people. Asking them to use the command line it of course out of the question. Those friends use linux, windows, iphones, android etc.

Before smartphones were everywhere, I shared the projects in zipped python applications with a tk interface. It worked, was multi-plaftorm, in spite of the old-looking interface.

I also observed that now, browser have become the standard interface for mostly anything, so I tried using that technology. But, then I needed to write the backend, the frontend and then host both. It struck me as being too much work compared to what I needed.

Then I discovered Kivy, another awesome project, it is not at all web based, but allows to create a python application with a modern interface on linux, windows and android rather easily. The drawback is that building with the android sdk needs several GB of hard drive an a rather powerful computer. And it was not web based, in this world with browsers that are more and more present and featureful.

Then, I found out about flexx, and it just was the perfect fit. Now, I can write a simple interface within minutes, and share it without doing all the boilerplate each time.

For about 4 years I have known flexx, I have written nine applications for personal projects (unfortunately, most of them used flexx v0.4.2 and need to be rewritten), some of them I used on a daily basis. For instance, every day, I read my mails using a MUA written in flexx.

I understand that once the project get bigger, things are difficult to handle. Yet, in most of the classical web projects I have seen so far (professionally and personally), things became messy anyway, therefore perhaps it is not that much due to Python vs PScript. Also, IMHO, the work you did with the actions/reactions and the advice to use a common Store as an interface between the parts of the application make things much more readable.

On the other hand, for an professional application, with several people working on it, I agree that flexx might not be the good choice. But for small scale applications with few people working on it, proofs of concept etc. I think it is a perfect choice.

[almarklein]

Thanks for that feedback! It's really nice (and motivational) to hear how and why you're using Flexx :)