Table: Any chance for drag and drop?

[malacalypse]

Hello,

I was wondering how much work it would be to support drag and drop functionality. At a minimum: select one or more rows, drop them on another row, trigger some function with the selected rows and target row, and let it do the rest.

If that wouldn't be hard in the current codebase and could be hacked on the go side, let me know, I could maybe take a stab at it with a few clues.

[andlabs]

That would require libui changes, but it's not out of the question.

[malacalypse]

Ok, and is the effort required to get a callback on row select about the same - or can we do that now and I've somehow missed how?

[bcampbell]

My proof-of-concept table selection stuff: #413 (unix only, but I've had essentially comparable code working on Mac and Windows too in a previous attempt). The table selection is an easy intersection of what all the platforms support anyway: single/multi select, callback when selection changes, reading out the rows for the selected items...

I haven't looked in detail, but I suspect user-rearrangable columns are a little more divergent among the platforms...

[malacalypse]

I'd be fine in my use case to just have single and multi select with callbacks, although drag and drop reordering with callback would be icing on the cake. I'll take a look at what you've written, thanks!

[bcampbell]

I'd be fine in my use case to just have single and multi select with callbacks, although drag and drop reordering with callback would be icing on the cake. I'll take a look at what you've written, thanks!

If nothing else, if you took a look at the interface for retrieving the selection and give me your opinion, that'd be great! see https://github.com/bcampbell/libui/blob/table-selection/ui.h#L1465 Better suggestions welcome!

I'm getting to the point where I've got an urgent need for multi-selection & callbacks, as well as some way to manage column widths sensibly. Probably worth pointing out that this kind of stuff isn't planned to happen until after alpha-5 (https://github.com/andlabs/libui/milestone/2 ). So I've been holding off on the windows and mac versions. Also I'm not sure what's going on in the remodel branch. @andlabs: when the remodel branch lands, is it going to require major rewrites for patches like this one?

[andlabs]

That depends. I want to make it so that simple controls are minimally affected, and in all likelihood it's only really going to be boilerplate that will change.

[rubyFeedback]

Does anyone happen to know whether bcampbell's code works?

Perhaps I should explain the context. I am a ruby guy (evident by the name used here); have been using ruby for many years. I came to libui indirectly via kojix2 who maintains ruby bindings. Libui is a GREAT idea.

Before libui I was - and still am - using ruby-gtk. GTK+ (or GTK 4 nowadays) is ok, but it is quite huge. With libui, things are so much smaller and simpler that this is great if I could add additional support in my ruby code for these things. I write modular code, so I use ruby-gtk2 and ruby-gtk3 without a problem. People can choose which one (I default to ruby-gtk3 these days).

So, I have modules, and interface elements such as:

button {
}

A bit like CSS yes? But just ruby code. So the "button" could be defined via ruby-gtk or via ruby-libui. And it would (in theory) work.

Evidently I can only use what libui provides, but as a "fallback" situation this would be GREAT for my use cases. So, I am also fine for "hackish" add-ons. (I target linux mostly; even on windows I can use ruby-gtk just fine via WSL these days, so using libui there is fine.)

So, for me personally, having ANY drag-support, even if buggy or incomplete, and restricted, is perfectly fine. Evidently I assume andlabs wants this to work cross-plattform, but I am happy for anything that really sort of works, even if it is not perfect or complete. My long term goal is to make use of the same DSL for both oldschool-GUIs, smartphone-APPs and of course web-related stuff, so that the button example would work everywhere (though evidently some trade-offs I may have to do). For now I continue to focus on ruby-gtk, but hopefully libui becomes epic! While retaining being not bloated - we have this bloat with gtk and qt already.