I would like my toggle buttons to be layout in a table, and not as a single row.
The number of toggle buttons is not static -
that is upon init I load a resource which contains a list of all the texts that should become the toggle buttons.
Looked at a number of approaches, each has its issues:
Create a list of ToggleButtons and a list of lists of bools to store the appropriate selected state as a data structure to divide the toggle buttons into a number of rows. The problem with this approach is in the implementation of the onPressed method - how to get a reference to the appropriate element in the list of lists of bools? Or in other words - how to get a reference to ToggleButtons object from within the onPressed method?
Use key property to pass the index of the current ToggleButtons. It is not intended for this purpose, so it is a bad practice, also again, there seems to be no straightforward way to access the key property from the onPressed method.
Extend the ToggleButtons class, and specifically override its build method. This is considered an anti-pattern in Flutter in general. Specifically In this approach, as we want all the functionality to remain the same, and change only the internal Row -> Table widget generation in the build method, it looks like we would have to duplicate all the code of this method, which is a bad idea as it might brake things as it changes in future versions of this widget
Create a table of checkbox / switch widgets as an alternative, which should work easily, but I want the look & feel of toggle buttons, not checkboxes or switches :)
I must be missing something simple!
After posting this I have a new idea :)
A table of FlatButtons! Will be probably possible to achieve similar UI to ToggleButtons. Will try it in a bit.
I would still love to hear other suggestions regarding ToggleButtons.
Try using SwitchListTile.
The entire list tile is interactive: tapping anywhere in the tile toggles the switch. Tapping and dragging the Switch also triggers the onChanged callback.
To ensure that onChanged correctly triggers, the state passed into value must be properly managed. This is typically done by invoking State.setState in onChanged to toggle the state value.
The value, onChanged, activeColor, activeThumbImage, and inactiveThumbImage properties of this widget are identical to the similarly-named properties on the Switch widget.
The title, subtitle, isThreeLine, and dense properties are like those of the same name on ListTile.
The selected property on this widget is similar to the ListTile.selected property, but the color used is that described by activeColor, if any, defaulting to the accent color of the current Theme. No effort is made to coordinate the selected state and the value state; to have the list tile appear selected when the switch is on, pass the same value to both.
The switch is shown on the right by default in left-to-right languages (i.e. in the ListTile.trailing slot) which can be changed using controlAffinity. The secondary widget is placed in the ListTile.leading slot.
To show the SwitchListTile as disabled, pass null as the onChanged callback.
Related
I have an entity object, for simplicity lets call it now Todo. I want to have a widget where I can edit multiple of these todos simultaneously, something like EditableTodoList (and this would show a list of EditableTodos).
This widget would recieve a List<Todo> and also something like Function onTodoEdited(Todo).
I am trying to use immutable data, so when an EditableTodo is being edited (and the event gets propagated to the widget which holds the EditableTodoList), I'd create a new List<Todo> which contais the updated Todo, but then EditableTodoList would rebuild with all its EditableTodos inside.
How could I optimize this, that only the relevant EditableTodo is rebuilt? I don't want to hack around with mutating the prop original List<Todo> because that hides greatly an important detail.
Background: currently the state is inside a cubit and I am context.select-ing for every EditableTodo list item the corresponding Todo in the state, this way only the edited item rebuilds. I'd like to decouple this EditableTodoList from the cubit.
Theoretically I assume its not possible, as EditableTodoList is given new properties, so it has to rebuild, and that means all subtree gets rebuilt. EditableTodo cannot be const as its prop is not a constant.
But still, what would be the most elegant way of separating EditableTodoList from the cubit? As it only needs a List<Todo> to show, it should be possible somehow to optimize the rendering of not changed Todos
You should consider how widget, element and render trees work in order to be concerned. There is a great video about Flutter's rendering mechanism. When rebuilding a tree, framework compares the two versions of widgets by using only the key and runtime type values. This means that if you change string value of the Text widget, the same render object with mutated data will be used again. New render object won't be created, which means no unnecessary rebuilds will happen on the render tree. Rebuilding the widget tree is not expensive compared to the render tree.
There is a limit on minimizing the the build scope in the ListView. ListView itself should be rebuilt in order to update an item. So you can't target a spesific item to rebuild. But items can reactively rebuild themselves (eg. an item that listens to a stream can rebuild without effecting the others). Therefore immutable collections doesn't matter in this context since the framework doesn't care the value but key and runtime type. You can either pass a completely modified list or a list with just one element changed, it will have the same effect.
Maybe my question is a nooby one, but i really try to understand how to implement the following operations:
How to add item for a list without the need of rebuilding all list.
How to update a class instance property value.
Does BLoCProvider used only once in a class?
===> I'm asking those question because i see that BLoC working with 'Equatable' and that in a the state class there is always a need to bring default value to the state we provide to the view class.
Another Question (what change the view and operate the state):
Does i need to bring always a list in order for example to update an item from the list or only changing the state+emit(in cubit) will change the state of the application, maybe it realted to BLocListener?
I have an issue with the provider pattern, I have a solution to my problem i just wanted to check its a good method and if there a better alternates.
I am trying to update the text controllers text when they first load the widget to have the value stored in my provider state. Originally, I just created the text controller in the init and just loaded the state in the build method and set the controllers text.
This was working until i wanted to have some validation of the content that would prevent certain things being passed into the state ( for example preventing empty strings).
textController.addListener(() {
if( RULE ABOUT WHETHER TO SET STATE BASED ON TEXT){
state.textField = textController.text;
}
});
The problem arose here, as they user would delete their word and this would fail the rule. The rebuild would occur (as they had pressed a key) and the text.controller would then rebuild to what was in the state (a single letter as it failed the rule). Effectively this prevented them from deleting, which is something i want them to be able to do but for this not to update the state.
I found this library https://pub.dev/packages/after_layout which allows a method to be overridden which is called once immediately after the build.
My solution uses this by creating the text controller in the initstate.
Assigning it to the TextField in the build.
Then creating a local field that would maintain the textField widget string content.
Then in the new afterbuild method i would assign whats on the state to the variable and update the text controllers text to have this value.
Then in the text.controllers text changed listener I used my rule to only update this state if it met the rule. Therefore if they deleted content they shouldn't be able to and closed/reopened the widget the state would rebuild to still have a valid value.
Is using this library a good solution to this or is there a better technique?
---------------- EDIT
Sorry for my wordy first part. I think my main question is just how am i meant to init Controllers if the data i need has to come from the state in the build.
For example.
// This must go in the build as it requires state
myTabsController = TabController(length: myState.list.length, vsync: this);
I'm initialisng the controller every time it builds now... How am i meant to put this in the init but still access the state variables.
(I've tried using the afterFirstLayout() callback from the AfterLayoutMixin but that just causes more problems.
Feel free to ask me to clarify more.
Thanks for your help.
I want to add style classes to elements in a cell (or the td itself) that will change depending on the state of the data in the cell. For example, the cell might have color: red when the data is unsaved, color: blue while the data is being saved, and color: black once the save completes successfully. Code external to the Cell will need access to change the class names, once callbacks are fired, etc.
I have achieved something like this with a hack in my Cell that gets the Element from onBrowserEvent and adds attributes there. I can set the initial style in render and then change it as needed in onBrowserEvent, and even keep track of that element so that external code can use it. This is incomplete, because I can't get the element until onBrowserEvent is called, and annoyingly hacky because I have to set the style in two different places.
What's a better way to achieve this effect without re-rendering the entire table whenever the state of a cell changes?
I found something like
table.setRowStyles(new RowStyles() {
#Override
public String getStyleNames(Contact row, int rowIndex) {
if (row.name.startsWith("J")) {
return "bold";
}
return null;
}
});
which should work in GWT 2.4 to resolve your matter.
The disappointing answer here is that you can't have the best of both worlds - static, all-at-once-rendering, AND dynamic, change-one-element-updating. The only way to change the style of a single cell, within the methods provided by CellTable et al, is to rerender the whole table.
In my own code I've kind of formalized the hacks I made to update single cells at a time, by setting the DOM id of a div rendered to each table cell. Then I can use getElementById and proceed from there. I still avoid the overhead of a full widget. It's a little clunky, but hidden behind a nice interface it's not too bad.
I am writing a custom widget for Gtkmm that is supposed to display a huge dataset (imagine something like a 4096x256 character datasheet).
Mostly for reasons of elegance, but also for a possible usage in a Glade/Gtk-Builder editor, I want this widget to support ScrolledWindow natively, that is, once it is set as the child of ScrolledWindow, it is recognized as a scrollable widget, allowing to set horizontal and vertical Adjustment objects on it, which it can subsequently tamper with.
It appears to do so, I need to do something like this in the constructor of my widget:
// get Gtk C type from wrapper class
GtkWidget* gwidget = this->gobj();
// imagine code here that magically creates a gobject signal,
// that we can catch in C++.
// this is actually the part which I don't know how to do.
guint my_signal = magic_way_to_create_this_signal(
&MyClass::rainbow_unicorn_signal_handler);
// make ScrolledWindow recognize this window as scrollable
GTK_WIDGET_GET_CLASS(gwidget)->set_scroll_adjustments_signal = my_signal;
Later on, the signal emitted by ScrolledWindow when the widget is added needs to be caught by my Widget through a signal proxy method or something? I have no idea.
How can I do this?
The 'magic_way_to_create_this_signal' is g_signal_new(). You call it in your widget's my_widget_class_init() function which is part of the GObject way of defining a class. I'm not exactly sure what the equivalent is in Gtkmm.
See also the footnote in the GTK docs, where it is explained why making a widget natively scrollable is such a hassle.
You could also put your widget into a Gtk::Viewport which adds scrolling capabilities to its child widget.