pull-request: trip management, next try

[Dirk Hohndel]

On Sep 2, 2012, at 11:45 PM, Henrik Brautaset Aronsen wrote:

> At 02.09.12 21:16, Dirk Hohndel wrote:
>> I don't think so. I think trip haters should have the ability to turn
>> the auto generation of trips off.
> 
> I don't hate trips.  I just want to be in control of them. Especially: I want to be able to group my dive trips into groups, and keep the other dives outside any groups (at the top level), at the same time.  That doesn't seem to be possible now.

It should be. Actually, it is :-)

> At 03.09.12 07:00, Dirk Hohndel wrote:
>> here's the next attempt. This adds the menu item that Linus asked for
>> and it fixes the crash that Miika found.
> 
> If I import the test dives ("Autogroup" off), ("Automatic grouping" on), the dives are grouped. When I enable "Autogroup", the groups disappear.  If I disable it again, the groups reappear.  Shouldn't it be the other way around?

Funnily enough, I know exactly why that's the case.

Try this patch:

index 03d2862..a2f130a 100644
--- a/gtk-gui.c
+++ b/gtk-gui.c
@@ -815,6 +815,7 @@ static GtkWidget *get_menubar_menu(GtkWidget *window, GtkUIManager *ui_manager)
 {
        GtkActionGroup *action_group = gtk_action_group_new("Menu");
        gtk_action_group_add_actions(action_group, menu_items, nmenu_items, 0);
+       toggle_items[0].is_active = autogroup;
        gtk_action_group_add_toggle_actions(action_group, toggle_items, ntoggle_items, 0);
 
        gtk_ui_manager_insert_action_group(ui_manager, action_group, 0);

> Also, Subsurface crashed when I removed a topmost dive from a group:
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   org.hohndel.subsurface            0x000000010735887e move_dive_between_trips + 430 (divelist.c:1297)
> 1   org.hohndel.subsurface            0x0000000107358fe6 insert_trip_before + 1078 (divelist.c:1378)
> 2   org.hohndel.subsurface            0x00000001073591bb remove_from_trip_cb + 219 (divelist.c:1416)
> 3   libgobject-2.0.0.dylib            0x0000000107fa3104 g_closure_invoke + 308

Haven't seen this before. Will investigate.

/D