I haven’t given it that much thought, but after I see an any lightweight (or not) GUI system, I go looking if it supports lists. And how light or elegant is the code to create list with custom layouts of widgets. Code for displaying a button, text entry or even select box is more or less similar with any system. But the simplicity breaks down or shows up with these composite and repetitive (and ideally, not necessarily) widgets, and you will probably need sooner or later.
This library looks really nice and is really really minimal, but it would be nice to see how they would solve something like that.
This is only tangentially related… but I was coincidentally doing a new list viewer thing in my gui library and wondering what you’d think of the api:
import arsd.minigui;
import std.conv;
void main() {
auto mw = new MainWindow();
static class MyListViewItem : GenericListViewItem {
this(Widget parent) {
super(parent);
label = new TextLabel("unloaded", TextAlignment.Left, this);
button = new Button("Click", this);
button.addEventListener("triggered", (){
messageBox(text("clicked ", currentIndexLoaded()));
});
}
override void showItem(int idx) {
label.label = "Item " ~ to!string(idx);
}
TextLabel label;
Button button;
}
auto widget = new class GenericListViewWidget {
this() {
super(mw);
}
override GenericListViewItem itemFactory(Widget parent) {
return new MyListViewItem(parent);
}
override Size itemSize() {
return Size(0, scaleWithDpi(80));
}
};
widget.setItemCount(500);
mw.loop();
}
Let me briefly explain: the GenericListViewWidget pretends to load an arbitrary number of list items by using a list item factory to create just enough items that can be visible on screen at a time (plus a couple more like the current keyboard focus which might have scrolled out of view but still can be interacted with). It requires each item to be the same height, so when the user tries to scroll to position X, it can do a quick divide to get the item index that should be visible there. Then, it calls that showItem function to tell the list item to load the content at that index into its children.
Events from items can check the currentIndexLoaded method to know which item they’re supposed to operate on.
The idea here is to keep the user-visible illusion of the thing containing however many entries (here 500 due to that penultimate call, but it is the same if it is 50 or 5,000) while only actually keeping a fixed, small amount in the actual ui. The illusion is fairly convincing, as I scroll it, I can’t tell it isn’t actually 500 items.
But the fixed size, the factory, and the load item thing do need a bit of boilerplate…
It’s not that I’m GUI specialist. Looking at your example I like that it’s minimal and it makes sense. It’s also good that you made it not render all the records, but just mainly the visible at any point, with widget reuse.
One thing I’m not sure about is where do you define the layout of the list item, the positions of label and button?
Yeah, I just figured since you said you look for that kind of thing you might have some comments, at least a second set of eyes beyond my own on how the api is coming along lol.
One thing I’m not sure about is where do you define the layout of the list item, the positions of label and button?
My library offers a few options there, the default being a vertical split. So each child gets maximum width of its parent, then the height is split among all the children. It starts at evenly, then adjusts based on min/max height and a stretch factor (it is based on css flexbox, if you’re familiar with that). You can also change to a horizontal split which does the same but swaps the dimensions. Nesting those can go a long way - the general rule is each parent lays out its children. You can also make everything a child of a StaticLayout or a GridLayout and define more of it yourself (static layout needs to set x,y,width,height in your own code, gridlayout does similar but it is divided by the actual size to give up the space).
I’m not super happy with this, I’ve read about some other concepts like anchors in the Mac world that looks cook, but meh my nested child layouts pretty much work for me so it has stayed this way for a long time.
Ooh, cool! Kind of makes me want to experiment with extremely small code size/extremely simple windowing systems like NanoX
I haven’t given it that much thought, but after I see an any lightweight (or not) GUI system, I go looking if it supports lists. And how light or elegant is the code to create list with custom layouts of widgets. Code for displaying a button, text entry or even select box is more or less similar with any system. But the simplicity breaks down or shows up with these composite and repetitive (and ideally, not necessarily) widgets, and you will probably need sooner or later.
This library looks really nice and is really really minimal, but it would be nice to see how they would solve something like that.
This is only tangentially related… but I was coincidentally doing a new list viewer thing in my gui library and wondering what you’d think of the api:
Let me briefly explain: the GenericListViewWidget pretends to load an arbitrary number of list items by using a list item factory to create just enough items that can be visible on screen at a time (plus a couple more like the current keyboard focus which might have scrolled out of view but still can be interacted with). It requires each item to be the same height, so when the user tries to scroll to position X, it can do a quick divide to get the item index that should be visible there. Then, it calls that
showItemfunction to tell the list item to load the content at that index into its children.Events from items can check the
currentIndexLoadedmethod to know which item they’re supposed to operate on.The idea here is to keep the user-visible illusion of the thing containing however many entries (here 500 due to that penultimate call, but it is the same if it is 50 or 5,000) while only actually keeping a fixed, small amount in the actual ui. The illusion is fairly convincing, as I scroll it, I can’t tell it isn’t actually 500 items.
But the fixed size, the factory, and the load item thing do need a bit of boilerplate…
It’s not that I’m GUI specialist. Looking at your example I like that it’s minimal and it makes sense. It’s also good that you made it not render all the records, but just mainly the visible at any point, with widget reuse.
One thing I’m not sure about is where do you define the layout of the list item, the positions of label and button?
Yeah, I just figured since you said you look for that kind of thing you might have some comments, at least a second set of eyes beyond my own on how the api is coming along lol.
My library offers a few options there, the default being a vertical split. So each child gets maximum width of its parent, then the height is split among all the children. It starts at evenly, then adjusts based on min/max height and a stretch factor (it is based on css flexbox, if you’re familiar with that). You can also change to a horizontal split which does the same but swaps the dimensions. Nesting those can go a long way - the general rule is each parent lays out its children. You can also make everything a child of a StaticLayout or a GridLayout and define more of it yourself (static layout needs to set x,y,width,height in your own code, gridlayout does similar but it is divided by the actual size to give up the space).
I’ve done more web work than desktop gui, so that comes through at a bunch of points. But I do have one example with a picture here in the docs https://arsd-official.dpldocs.info/arsd.minigui.html#examples
I’m not super happy with this, I’ve read about some other concepts like anchors in the Mac world that looks cook, but meh my nested child layouts pretty much work for me so it has stayed this way for a long time.
There are lists in main.c unless you mean something else?