pull-request: trip manipulations

Dirk Hohndel dirk at hohndel.org
Sun Sep 2 12:19:53 PDT 2012


Miika Turkia <miika.turkia at gmail.com> writes:

> On Sun, Sep 2, 2012 at 7:39 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>> This is a somewhat more massive change. It adds most of the operations
>> that I think we should support on trips:
>> - a dive can be removed from a trip (and made a top level dive)
>
> Adding top level dive to a trip is rather awkward. Have to create a
> new group and then merge to previous.

Yes - that's one operation still missing.

>> - a dive can be turned into a trip
>> - two consecutive trips can be merged
>
> Merge trip with previous is mis-leading as it is currently merged with
> the one above (with my normal sorting order this means merging with
> next trip).

Previous in the way they are displayed - but you are right, that is
actually illogical depending on the display order. I need to find better
wording for the menu entry - that still is compact yet immediately
obvious what it does.

> Possibility to merge with previous and next would be cool. However,
> once merging selected dives or groups is implemented this might become
> obsolete.

Not sure. I'll need to think about a logical flow for a user and how to
describe this.

>> - a trip can be split in two
>
> If you remove a dive from the middle of a dive trip, the trip will be
> split to two trips with a single top level dive in-between. (This
> makes sense when you know the design but is probably quite confusing
> for new users without background knowledge.)

What else would you want it to do?

>> There are some operations that would make sense to allow on "all
>> selected dives" (e.g., remove from a trip and turn into a trip), but I
>> haven't done that part, yet.
>>
>> Please review for obvious stupidities and most importantly give it a
>> good test... I've been banging on it for the past few days and currently
>> can't seem to find any corner cases where it fails, but most likely that
>> just means I haven't tried hard enough :-/
>
> When opening a log file and enabling the grouping...you have to quit
> subsurface and start again to get the automatic grouping
> "initialized". It would be cool if the grouping would occur on the UI
> when enabling. But if there is technical reason behind not to do it..
> at least inform the user for the need to re-start.
>
> Trying to import older XML file to current one results in a crash:
>
> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_setspecific': Invalid argument.  Aborting.
> Aborted (core dumped)
> #0  0x000000000041439e in fill_ws_list (store=0xe9dce0) at equipment.c:844
> #1  0x0000000000414c35 in weight_completion_cb (widget=0x1249480,
>     model=0x124013000000002, iter=0x414c35, ws_widget=0x7fff3dea3170)
>     at equipment.c:998
>
> I guess this is the same as sorting by any other column than date.

Pthreads crashing? Not sure how I could have caused that. But yes, the
bug that I have just fixed in my tree can give you an inconsistent model
and that could trigger all kinds of other bugs, I guess.

/D


More information about the subsurface mailing list