[PATCH 2/2] Do a minimal hook-up of the dive plan tree view to the actual planning

[Dirk Hohndel]

I applied the previous two patches as they create useful infrastructure
with the validate functions... but I took things a different direction.
That treeview is not only not working, it's insanely ugly.

Now granted, my previous attempt with the two notebook pages was crazy
in that you would have had to switch between pages to enter dives. And
Linus makes a valid point that crazy is worse than ugly.

So I committed something else.

It's not quite as ugly as Linus' solution.
It's not quite as insanely crazy as my first attempt.

That was the good news :-)

Seriously, I think this is going roughly in the right direction.

It presents a window with one line per waypoint. Pre-populated with the
input fields for four waypoints (target depth, time/duration, gas).

All three reuse the very nice parsing / validation functions that Linus
has written. And gas is implemented as completion / drop down selection
just like buddy, location and some others.

This is hooked up to the planning and works about as well as the test
plan :-)

One thing that doesn't work and that I have wasted more than three hours
today trying to get it to work is to add more input fields for more
waypoints. The code is there... it adds the widgets to the correct vbox
and asks the dialog to be redrawn. But somehow that doesn't work and I
cannot figure out why. Help appreciated.

Anyway, play with it and let me know what you think.

And yes, Jan. We'll add a field for surface pressure and the ability to
have a CCR dive simulated as well. But let's get the basics working,
first.

/D

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.
>
> 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?
>
>                    Linus