Advanced Table usage

[halsten-dev]

Hi,

As started discussing in #5356

I wanted to continue digging the advanced usage of tables.

In my case, I want to use a Table to render the result of a query executed in DB. So I've setup a working Table with Dynamic headers and content based of the result of a query.

My table cells are rendered as a simple custom widget that simply contains a canvas.Text and render itself inside a container.NewScroll. So big values are not overflowing on next columns.

The issue with that, is that the scroll event is not executed on the Table itself anymore when my mouse is on a cell. Even if scrollbars are not visible in the hoovered cell. Something should propagate the scroll event in my opinion.

Next, the sort question. I guess it's something we have to fully manage by hand ?

Thanks a lot for sharing your knowledge on the subject.

[andydotxyz]

The issue with that, is that the scroll event is not executed on the Table itself anymore when my mouse is on a cell. Even if scrollbars are not visible in the hoovered cell.

Yes that is true - if a widget responds to an event it won't propagate to a parent element. It makes everything a lot simpler but has some drawbacks. Were we to change that to allow propagation then probably that would apply to all events and everything gets a lot more complicated. If there a way to handle it neatly that would be cool. But having two scrollers inside each other isn't really ideal, Apple documents against this.

A random question here - did you consider a label with truncation turned on? (you mentioned not having the scroll visible so thought I would ask).

Next, the sort question. I guess it's something we have to fully manage by hand ?

Yes - the table does not know anything about your data.

[andydotxyz]

I also manage a function that return true or false to determine if the menu should be activated or not. This is lacking too in Fyne.

What does "activated" mean? We have disabled and checked as options and I thought that would cover the usages...

[halsten-dev]

Simple example. I want to have a menu that is activated only when I select an element of a list.

With Fyne menu, I would have to have a function that test if the condition is met or not and set the disabled option. The problem is, that for a single menu it's ok. But, when you have dozens. It's starting to get ugly. The thing is that the if ... else... thing is not that elegent too. So what I first ended up doing is that in my method I would disabled all my menus and then manage only the activation condition.

Now with the manager I simply have attached to my menu items a function that simply check it's condition and return true or false if the item should be activated or not. That's the most beautiful way of doing it, in my opinion. Each item managed their own activation logic. But, in the back it simply set the disabled option of course. It's just a neater way to write things.

Hope it makes sens :)

[andydotxyz]

I'm not too sure that I understand what lack you are describing. your code can define a function() bool which will set the menu item disabled state.

	item := fyne.NewMenuItem("Optional", myFunc)
	item.Disabled = shouldDisable()

[halsten-dev]

Indeed.
The problem here would be that the holding of all the item menu need to be custom tailored and a simple loop on all item would not really be possible if items do not have the save activation function.

var item1 fyne.MenuItem
var item2 fyne.MenuItem

item1 = fyne.NewMenuItem("Optional1", myFunc)
item1.Disabled = shouldDisable1()

item2 = fyne.NewMenuItem("Optional2", myFunc2)
item2.Disabled = shouldDisable2()

...

func UpdateMenu() {
    item1.Disabled = shouldDisable1()
    item2.Disabled = shouldDisable2()
}

With my approach I simply loop my menu items definition and call their activation func.

Maybe I'm missing something, but it seems to me that it is clearer :

// UpdateMenu goes through all menus items to check if they need to be activated or not
func (m *Manager) UpdateMenu() {
	for _, item := range m.MenusItems {
		if item.ActivationCondition != nil {
			active := item.ActivationCondition()
			item.Instance.Disabled = !active
		}
	}
}

I did invert the disabled logic too because my head works the other way around 😄

[andydotxyz]

Iterating through a UI to apply what might have changed is the wrong way, quite inefficient.
When something changes update it - either directly or you could use data binding.

Anyhow this is quite off topic, so I you've got a problem or another question best to open a new issue or discussion.