cycfi
Dynamic length composer?
I might be a bit lost as to how the api for dynamic list is supposed to work, but it seems like the dynamic list is limited to a set size once constructed with fixed_length_cell_composer. Seems like there should be a corresponding "dynamic_length_cell_composer".
This is tricky. I'll have to go back and re-study the code. For now, it will be good if you can give me a use-case example. What are you trying to do?
Was roughly trying to make a combo-box, driven by a vector. The dynamic list seems like it fits the bill, except for the fixed size.
Was roughly trying to make a combo-box, driven by a vector. The dynamic list seems like it fits the bill, except for the fixed size.
That is easy. Monitor the vector changes and make a new list on changes, replacing the old one. The main advantage of the dynamic list's (which should probably be given a better name -- maybe virtual list) is that it only creates the rows on demand as it is presented (those hidden rows will not consume any cycles), so even a million-item list will still be very fast.
Maybe that's what got me a bit lost, there's a vector of rows you're using to draw to the screen with the compose callback with an index. It seems as though there could be similar approach where you're given a user supplied vector and then use that w/ the index to draw?
From the way it seems to work it almost gives me the impression that what I could / should do is write a compose function that takes that index, checks to see if it's within the range of my vector's size and then return an element or a non drawable element.
Maybe that's what got me a bit lost, there's a vector of rows you're using to draw to the screen with the compose callback with an index. It seems as though there could be similar approach where you're given a user supplied vector and then use that w/ the index to draw?
Yes, that is probably doable. Such a 'composer' will have to readjust/prepare the view on vector size changes, so I am not sure if it would amount to the same in terms of performance. May be tricky. I'll have to review the code.
Maybe that's what got me a bit lost, there's a vector of rows you're using to draw to the screen with the compose callback with an index. It seems as though there could be similar approach where you're given a user supplied vector and then use that w/ the index to draw?
Yes, that is probably doable. Such a 'composer' will have to readjust/prepare the view on vector size changes, so I am not sure if it would amount to the same in terms of performance. May be tricky. I'll have to review the code.
If you can make a desired example with some stubbed-out code, I'll see what I can do.
Yes, that is probably doable. Such a 'composer' will have to readjust/prepare the view on vector size changes, so I am not sure if it would amount to the same in terms of performance. May be tricky. I'll have to review the code.
Thinking about it some more. It might not be too difficult. Do you want to give it a try?
I might end up trying to make this work, because I'm absolutely certain I'll want comboboxes / lists in my gui.
Here's a rough snippet, don't know if this is a great example of what it might look like. This is roughly what I was up to, was trying to list out the audio devices with q.
#include "elements.hpp"
#include "q_io/audio_device.hpp"
using namespace cycfi::elements;
namespace q = cycfi::q;
int main(int argc, char *argv[]) {
auto audio_list = q::audio_device::list();
//vague idea of what the constructor might look like
auto audio_list_element = cycfi::elements::element_list(audio_list, [](audio_device &item) {
return //an element here
});
//or
auto audio_list_element = cycfi::elements::element_list(audio_list, [](reference to audio_list, size_t index) {
return // an element here
});
//or
auto audio_list_element = cycfi::elements::element_list(audio_list, [&audio_list](size_t index) {
return // an element here
});
//etc...
```
Oh, for such short lists, you don't need the dynamic list, actually. For example, if you are making menus or vtiles, you can just make them on the fly (e.g. when the menu is clicked). Here's an example:
https://github.com/cycfi/elements/blob/master/examples/menus/main.cpp#L84-L139
I guess he expects to push|pop|insert|emplace items after creation, without recreating the widget, directly like an usual combobox
not only Qt, IIRC from VB6 times, it works like that natively under Windows (CB_{ADD|INSERT|DELETE}STRING and CB_{GET|SET}ITEMDATA)
I guess he expects to push|pop|insert|emplace items after creation, without recreating the widget, directly like an usual combobox
With such an interface, you will have to maintain two containers: the model (or your actual data structure) and the widgets in the UI and make sure they are in sync all the time. Elements, allows you to just create the UI on the fly. It is fast enough. Such a strategy sits between immediate mode UIs such as IMGUI and retained mode UIs. After some level of complexity, you will be going to build and rebuild the widgets anyway. Take Windows explorer or the MacOS finder, for examples. The UI is built dynamically as you browse through the directories and as files are presented. Explorer and finder do not retain and maintain any UIs underneath. They build them on-the-fly.
...They build them on-the-fly.
That being said, it is of course possible to have and maintain composite elements such as vtiles and htiles that you maintain and retain.
Maybe https://github.com/cycfi/elements/blob/master/lib/include/elements/element/grid.hpp#L89-L90
vgrid_composite is one example. Basically, any xxx_composite can be pushed back, inserted, etc. All you have to do is do. a refresh (and maybe re-layout) when the elements/children are added.removed.
This is the same mechanism as the outermost/root "layers" maintained by the view. That is a layer_composite:
https://github.com/cycfi/elements/blob/master/lib/include/elements/element/layer.hpp#L37
Take note how the view holds a layer_composite:
https://github.com/cycfi/elements/blob/master/lib/include/elements/view.hpp#L119
With such an interface, you will have to maintain two containers: the model (or your actual data structure) and the widgets in the UI and make sure they are in sync all the time.
This is usually done (partially or entirely) in some UI frameworks for the specified widget, in this case a dropdown button and a listbox (not menu, it should have also a scrollbar), which holds the items
After some level of complexity, you will be going to build and rebuild the widgets anyway.
I'm not sure about this, once widget were created I always seen to use to keep a ("shared") pointer to those you usually need to make changes, directly or via signals/events, this works on UI like wxWidgets, which uses native controls. Like when changing a layout you discard the current (or just hide and swap with another) and re-parent the previous ones.
After some level of complexity, you will be going to build and rebuild the widgets anyway.
I'm not sure about this, once widget were created I always seen to use to keep a ("shared") pointer to those you usually need to make changes, directly or via signals/events, this works on UI like wxWidgets, which uses native controls. Like when changing a layout you discard the current (or just hide and swap with another) and re-parent the previous ones.
And that is what I mean! And that you can do. In either case, you still rebuild the UI at least partially. Whether you retain some, or build everything on the go, it's up to you. Again the explorer/finder UI are good examples. You build such things dynamically every time.
I wonder if this could be some chance for a contribution to put in gallery? (See also #133)
I wonder if this could be some chance for a contribution to put in gallery? (See also #133)
I'll see what I can do. This is actually what I am doing for the presets in the Ascend plugin:
The Ascend plugin presets is another example of a dynamically created menu. Instead of maintaining a menu list, I just recreate the menu every time the user clicks. That way, I do not have to always sync the menu with the actual available presets that can change any time.
Oh, with contribution I was referring to the OP. So, recreating the menu means that the selected item and item position indexes must be monitored by the programmer. @Andersama I just seen that the pastebin in the other issue I wrote is vanished, if useful for you the code is still here.
Just for the sake of completeness, there is now an example of a dynamic_list with dynamic insert functionality contributed by @johannphilippe :
https://github.com/cycfi/elements/tree/master/examples/active_dynamic_list
@redtide feel free to convert this to a discussion.