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

[Lubomir I. Ivanov]

On 6 January 2013 09:10, Dirk Hohndel <dirk at hohndel.org> wrote:
> 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',
> 'ean40').
>
> 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"?
>

just tried fixing that in patch:
[PATCH] Planner: hook the gas combo box to a "focus-out" event handler

i've noticed "focus-out-event" works when connecting to the GtkEntry
child inside GtkComboBoxEntry.
not tested on multiple OSes / Gtk versions.

lubomir
--