[PATCH 2/2] Do a minimal hook-up of the dive plan tree view to the actual planning
dirk at hohndel.org
Sat Jan 5 15:54:06 PST 2013
Linus Torvalds <torvalds at linux-foundation.org> writes:
> On Sat, Jan 5, 2013 at 1:07 PM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
>> And none of this is hugely tested, but it does seem to at least kind of
>> work. If things like <tab> actually worked while editing the waypoints, it
>> would be approaching being user-friendly.
> So the attached patch (on top of the two other patches, obviously)
> does *not* make <Tab> work, but it does make pressing <Enter> work.
> And by "work" I mean that after you've entered a value it now moves
> automatically to the next input element. So you start the planner
> thing, and do
> +5<Enter>150ft<Enter>20/30<Enter>+5<Enter>150ft<Enter> ...
> to fill in the planning values in the tree view.
You didn't have a Signed-off-by on that one, so my guess is you didn't
want this applied just yet?
> However, there's some confusion about editable tree-views that I do
> not understand. Probably lots of details, but one stands out:
> If you enter the value and press <Tab> instead of <Enter>, something
> odd happens. Instead of moving forward, it does something crazy, and
> then eventually starts complaining about
> (subsurface:23668): Gtk-CRITICAL **:
> _gtk_tree_view_column_start_editing: assertion
> `tree_column->editable_widget == NULL' failed
> which is just crazy talk. It all works if you never touch the <Tab>
> key, though.
> Can anybody see the reason for this crazy gtk behavior? What makes
> enter/tab so different?
I'll take a look
More information about the subsurface