[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 23:10:39 PST 2013
Linus Torvalds <torvalds at linux-foundation.org> writes:
> On Sat, Jan 5, 2013 at 10:13 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>> 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).
> Ok, this is getting better. That said, when you add a gas by hand, it
> doesn't get added to the list of gases, so the next waypoint you can't
> just select it again. So the drop-down selection isn't very useful.
Oh yes - it took me another half hour to make this work.
Gtk is so f-ing braindead. You cannot get a useful callback when a new
value has been entered to the ComboBoxEntry... NO-O, that would be too
useful. What you can get is EVERY change (i.e. 'e', 'ea', 'ean', 'ean4',
So instead I am now catching once again ALL events and am filtering for
a TAB. So if you do the sane thing and tab out of the selection, then it
gets added and is available in the next ComboBox.
(I'll push this out in a few minutes)
But seriously, what are the people smoking who are coming up with the
available callbacks for the widgets? Why can't I simply register a
callback "when the user has changed this and left it"?
> But the worst part about any of these interfaces is how you can't fix
> mistakes. I think it would be lovely if it showed the dive as you add
> way-points, so that you can edit it. As it is, now you press "OK", and
> the end result looks bad, and there's no good way to go back and edit
Interesting. I'm sure I can make this work...
> I dunno. And I do think the input fields are much too big. I suspect
> they don't need individual labeling. Just once at the top? That was
> one of the things I liked about the treeview, even if it then sucked
> in so many other ways.
I can look into that as well.
More information about the subsurface