alecmus / lecui Goto Github PK

I have a suggestion that if possible, add a table ID. The ID does not change when the user sorts the table. And the programmer can either choose to include it or not. I think it would be an amazing feature.

To add a widget to a pane we need to pass a reference to the pane's page as a parameter to the widget's builder.

Why?

Suggestion: Simply pass a reference to the pane, let the widget's builder call the get() method

Instead of

lecui::widgets::label_builder label(pane_one.get(), "my_label");

allow

lecui::widgets::label_builder label(pane_one, "my_label");

When a form's minimize control button is removed through:

#include <lecui/controls.h>
...
lecui::controls ctrls_{*this};
...
ctrls_.minimize(false);
...

the form can still be minimized by using the keyboard shortcut Win+DownArrow. This should not be so.

I am confused by the attribute getters and setters.

For example

https://alecmus.ml/lecui/html/classliblec_1_1lecui_1_1color.html

For the first, how can this be used to set the color?

This question applies to many of the attributes of other clesses too, which only have one getter/setter of this form.

The action handlers for widgets in the title bar are only responding to mouse clicks and the space bar, and not to the Enter key.

In your sample code you construct ( build ) widgets like this

lecui::widgets::label_builder label(pane_one.get(), "my_label");

This looks like it will call the widget's destructor when it goes out of scope. Usually people want to prevent this happening until the application ends, or when the container is destroyed.

A smaller point: it seems odd to me that you are constructing an instance of a widget builder, rather than an instance of a label.

So something like

lecui::widgets::label * plabel1 = lecui::widgets::label_builder( label(pane_one.get(), "my_label");

( the builder returns a pointer to the widget )

or

lecui::widgets::label& label1 = lecui::widgets::label_builder( label(pane_one.get(), "my_label");

( the builder returns a reference to the widget )

Personally, I prefer the second style.

When no pane alias is specified by the user there is no mechanism for containers::pane::pane() to know the alias that is automatically generated in containers::pane::impl::add_pane() and so subsequent calls to containers::pane::get() fail as the alias_ field of containers::pane::impl remains empty.

The selected method on the combobox seems to be failing. May you please attend to it.

How I used it:

widgets::combobox_builder fueltype_cbo(page, "fueltype_cbo");
{
	std::vector<widgets::combobox_specs::combobox_item> fueltypes = {
		{  "Petrol " }, {"Diesel"}
	};

	fueltype_cbo()
		.items(fueltypes)
		.selected("Petrol")
		.color_fill({ 255,255,255,0 })
		.rect().size(200, 25)
		.snap_to(fueltype_caption().rect(), snap_type::bottom, 0);
		fueltype_cbo().events().selection = [](const std::string& selected) {};
}

I seem to be failing to change the colour of the label. I wonder if I am doing it wrong or there is a bug.

This is my code:

widgets::label_builder fuel_caption(coupon_details_pane.get());
	fuel_caption()
		.text("Fuel")
		.color_text(caption_color_)
		.color_fill().green();

I also tried:

.color_fill({0, 0, 0, 100});

And:

.color_fill().get_green();

The liblec::lecui::splash loads images using their pixel-size, resulting in the image looking too small on high-dpi screens.

the table_view_builder takes some time to render data after pushing a row into the table using the push_back function.

like so:

widgets::table_view_builder::specs(*this, main_page_name_ + "/main_tab/coupons/coupons_table")
.data().push_back({ { "#", "7"}, {"Date", "10-June-20"}, {"Issued to", "new"}, {"Serial Number", "added-for-testing"}});

And if you using values that are determined on runtime, the table sometimes doesn't render the data.