table widget

[Xeverous]

Example screenshot: https://github.com/qPCR4vir/nana-docs/raw/master/screenshots/thdy_seq_expl.png (ignore the tree view on the left, although I also want this kind of widget, but this is covered by #39)

What is obvious is that I can fully compose such table from smaller widgets. That's the main goal of elements. I can even have the fancy features like the colored temperature column as on the linked image. What I have concerns about, is performance.

• How the table should be build? Grid? Array of row elements? Array of column elements? I suppose array of rows, since they will be scrolled vertically, but asking for clarity. When going with rows or columns, is there any preferred strategy for calculating optimal column width?
• What if the number of rows is big (say, 10-100k entries)? I suppose I should (re)create widgets only for entries that are visible, but then I wonder what will happen with the implementation of scrolling.
• How the actual data should be accessed? Should the table widget just store a reference to the actual data structure?

[djowel]

Very good questions! I remember doing a demo of an html browser before with Element's predescesor, and it was very fast and efficient, scrolling through pages and pages of content. But thinking back, it can be done better. There should be the notion of hidden virtual elements, where you add content on demand. For really big data, basically, the physical UI structure you have may not necessarily map 1-1 with the logical structure. So you 'materialize' the elements only when needed when they come into view. IMO, this is a concept that even UI libs do not do. I'm not sure how nana does it. I doubt they do the way I described. Look at what facebook is doing, for example. They have an infinite scroll notion where fresh data is materialized only when they scroll into view.

Having said that, this one is not simple and involves a lot of design and strategical implementation to get right. I my mind, this 'virtual' element is normally just a placeholder. Then it gets notified to 'materialize' only when the element gets close to the physical view-port bounds (say page up or down). This strategy is also very effective with data that is computed on the fly, such as, say displaying files and directories, or even some scientific data that is hard to compute all at once. This virtual element should be able to unmaterialize to save on memory when it scrolls out of view within some meaningful distance from the port.

[Xeverous]

it gets notified to 'materialize' only when the element gets close to the physical view-port bounds

This gets problematic when you don't know the size of the widget until its materialized.

I'm thinking whether elements library can help with such complex widgets (eg by certain in-library-code optimizations) or the library user has to implement the whole logic. Just anything that would support implementing such complex tables.

[djowel]

This gets problematic when you don't know the size of the widget until its materialized.

Take a look at what the social media guys are doing. Basically, you initially have a generic, fixed size box. Then it resizes when you actually have the real thing. In the case of FB's infinite scroll, you actually see it materialize as it scrolls into view because it loads them from the web. In my mind, we should perform materialization ahead of time (e.g. when it comes closer to view by a page or so).

[djowel]

Also, I think this is the normal behavior now with, say the MacOS finder. You want efficiency with HUGE data? There's no way around it but make data computed on demand.

[djowel]

Thinking about it some more. Perhaps what we really want is a virtual port that only asks to display a range at any time with a callback to compute some more on demand. Imagine a waveform editor with gigabytes of audio data. In such a case, the normal thing to do is to draw only what's needed given the 'window'. It's the same thing. With elements, you only compose/layout a portion of the data at any given time.

But your intuition is correct. The important thing is how elements can help the client in doing such a thing. I think yes. And the key is abstraction.

[djowel]

This gets problematic when you don't know the size of the widget until its materialized.

Back to this one. Some more thought: there are two kinds here: one that you know the size of the data (no. of rows) ahead of time, and one where you don't. The first is common in typical data structures e.g. streams. The first one can be done by the 'virtual' element I suggested above. The second is just a dynamic data structure with a known data size --easy, esp. if you have fixed row sizes like in your picture.

[Xeverous]

In my case I know the number of rows and it will rarely change (only after certain user actions). So my interest is what API of a potential virtual element can offer to make implementing such table easier. A sort of a vtile/htile element that uses provided callback to materialize rows from the data.

[djowel]

Update: The "dynamic" branch has a new "dynamic" element with an example that dynamically 'composes' 100,000 rows. The demo scrolls through the rows very smoothly with two-finger scroll using a track pad on my Macbook Pro).

Here's a video clip:
https://www.dropbox.com/s/k4f3brl95dgljih/dynamic.mp4?dl=0

The sample code:
https://github.com/cycfi/elements/blob/dynamic/examples/dynamic/main.cpp

[djowel]

Oh, just to be clear, this is just a proof of concept for testing performance, far from the real thing. I tried 1,000,000 elements. It was just as fast.

[Xeverous]

Doesn't build for me :/

[  8%] Building CXX object lib/CMakeFiles/elements.dir/src/element/dynamic.cpp.obj
lib\src\element\dynamic.cpp: In member function 'virtual cycfi::elements::view_limits cycfi::elements::dynamic::limits(const cycfi::elements::basic_context&) const':
lib\src\element\dynamic.cpp:11:53: warning: unused parameter 'ctx' [-Wunused-parameter]
    view_limits dynamic::limits(basic_context const& ctx) const
                                ~~~~~~~~~~~~~~~~~~~~~^~~
[ 10%] Building CXX object lib/CMakeFiles/elements.dir/src/element/element.cpp.obj
[ 11%] Building CXX object lib/CMakeFiles/elements.dir/src/element/floating.cpp.obj
[ 12%] Building CXX object lib/CMakeFiles/elements.dir/src/element/flow.cpp.obj
[ 14%] Building CXX object lib/CMakeFiles/elements.dir/src/element/gallery/button.cpp.obj
[ 15%] Building CXX object lib/CMakeFiles/elements.dir/src/element/gallery/check_box.cpp.obj
In file included from lib/include/elements/element/gallery/check_box.hpp:10,
                 from lib\src\element\gallery\check_box.cpp:6:
lib/include/elements/element/gallery/toggle_selector.hpp: In member function 'virtual bool cycfi::elements::toggle_selector::cursor(const cycfi::elements::context&, const cycfi::elements::point&, cycfi::elements::cursor_tracking)':
lib/include/elements/element/gallery/toggle_selector.hpp:40:73: warning: unused parameter 'p' [-Wunused-parameter]
    inline bool toggle_selector::cursor(context const& ctx, point const& p, cursor_tracking status)
                                                            ~~~~~~~~~~~~~^
lib/include/elements/element/gallery/toggle_selector.hpp:40:92: warning: unused parameter 'status' [-Wunused-parameter]
    inline bool toggle_selector::cursor(context const& ctx, point const& p, cursor_tracking status)
                                                                            ~~~~~~~~~~~~~~~~^~~~~~
[ 17%] Building CXX object lib/CMakeFiles/elements.dir/src/element/gallery/icon_button.cpp.obj
[ 18%] Building CXX object lib/CMakeFiles/elements.dir/src/element/gallery/menu.cpp.obj
[ 20%] Building CXX object lib/CMakeFiles/elements.dir/src/element/gallery/radio_button.cpp.obj
In file included from lib/include/elements/element/gallery/radio_button.hpp:10,
                 from lib\src\element\gallery\radio_button.cpp:6:
lib/include/elements/element/gallery/toggle_selector.hpp: In member function 'virtual bool cycfi::elements::toggle_selector::cursor(const cycfi::elements::context&, const cycfi::elements::point&, cycfi::elements::cursor_tracking)':
lib/include/elements/element/gallery/toggle_selector.hpp:40:73: warning: unused parameter 'p' [-Wunused-parameter]
    inline bool toggle_selector::cursor(context const& ctx, point const& p, cursor_tracking status)
                                                            ~~~~~~~~~~~~~^
lib/include/elements/element/gallery/toggle_selector.hpp:40:92: warning: unused parameter 'status' [-Wunused-parameter]
    inline bool toggle_selector::cursor(context const& ctx, point const& p, cursor_tracking status)
                                                                            ~~~~~~~~~~~~~~~~^~~~~~
[ 52%] Building CXX object lib/CMakeFiles/elements.dir/host/windows/base_view.cpp.obj
lib\host\windows\base_view.cpp: In function 'LRESULT cycfi::elements::{anonymous}::on_paint(HWND, cycfi::elements::{anonymous}::view_info*)':
lib\host\windows\base_view.cpp:141:25: warning: narrowing conversion of 'dirty.tagRECT::left' from 'LONG' {aka 'long int'} to 'double' inside { } [-Wnarrowing]
                   dirty.left,
                   ~~~~~~^~~~
lib\host\windows\base_view.cpp:142:25: warning: narrowing conversion of 'dirty.tagRECT::top' from 'LONG' {aka 'long int'} to 'double' inside { } [-Wnarrowing]
                   dirty.top,
                   ~~~~~~^~~
lib\host\windows\base_view.cpp:143:25: warning: narrowing conversion of 'dirty.tagRECT::right' from 'LONG' {aka 'long int'} to 'double' inside { } [-Wnarrowing]
                   dirty.right,
                   ~~~~~~^~~~~
lib\host\windows\base_view.cpp:144:25: warning: narrowing conversion of 'dirty.tagRECT::bottom' from 'LONG' {aka 'long int'} to 'double' inside { } [-Wnarrowing]
                   dirty.bottom
                   ~~~~~~^~~~~~
lib\host\windows\base_view.cpp: In function 'void cycfi::elements::{anonymous}::on_cursor(HWND, cycfi::elements::base_view*, LPARAM, cycfi::elements::cursor_tracking)':
lib\host\windows\base_view.cpp:310:27: warning: unused parameter 'hwnd' [-Wunused-parameter]
       void on_cursor(HWND hwnd, base_view* view, LPARAM lparam, cursor_tracking state)
                      ~~~~~^~~~
lib\host\windows\base_view.cpp: In function 'void cycfi::elements::{anonymous}::on_scroll(HWND, cycfi::elements::{anonymous}::view_info*, LPARAM, const cycfi::elements::point&)':
lib\host\windows\base_view.cpp:337:25: error: assignment of member 'cycfi::elements::point::x' in read-only object
          dir.x *= info->velocity;
                         ^~~~~~~~
lib\host\windows\base_view.cpp:338:25: error: assignment of member 'cycfi::elements::point::y' in read-only object
          dir.y *= info->velocity;
                         ^~~~~~~~

[djowel]

Doesn't build for me :/

It's OK... WIP, just a POC... I'll make it work in all platforms as soon as I can.