Comments on latest changes

Dirk Hohndel dirk at hohndel.org
Mon Aug 20 10:50:00 PDT 2012


Linus Torvalds <torvalds at linux-foundation.org> writes:

> On Mon, Aug 20, 2012 at 10:04 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>> The constraint that I would enforce is that dive trips need to be
>> sequential, i.e. you can't have a dive in the middle of a trip not be
>> part of a trip.
>
> Well, you also have to have various other consistency issues, like
> nesting. IOW, they presumably would have to nest perfectly, because we
> can't *show* them in the tree structure if they don't.
>
> And possibly limit it to a single layer of nesting (at which point
> "nest perfectly" just means "no overlap").

The more I think about this, I don't think "trips of trips" or "groups
of groups" really is such a useful feature. Or, to phrase it
differently, it only becomes a really useful feature if you allow things
like "a group of all trips to Maui". At which point you can no longer
display things in date order and with groups shown in a tree view.

This is where /I/ would draw the line on usefulness (but I recognize
that others might have different preferences).

> Which in turn really means that it should probably be shown in the xml
> as a true nesting level, and dives need to be inside the group that
> they belong to.

I thought about that and went with the magic dive-like entries as they
seemed easier to implement.

But assuming that all I want to implement here are "real life trips"
then I think the consistency constraint for the hierarchical nesting in
XML match the constraints in real life.

> And once you do that, you might decide that you actually *do* allow
> overlap and/or dives that are outside of a trip despite the date
> (because the nesting structure is not about the date, but about the
> structure of the xml). So then the dive date part becomes irrelevant
> as a global sorting thing, and only relevant to sort within the trip.

Shudder.

> So then you can throw all the constraints away, which would simplify
> some things, at the cost of having the explicit nesting (and the
> explicit nesting does have some cost: it means that you need to have
> ways to move dives between trips etc). 

That I think I want to implement anyway. That's kind of the whole point
of explicit trips, isn't it?

> Throwing constraints away is good, because right now we allow
> importing data from multiple xml files (or other, non-xml sources),
> and that would work fine with explicit nesting in the files
> themselves, but it leads to trouble if we have some date-based
> separate trip-list (what do you do when trips collide because you
> tracked them differently in two files?)

Can you explain a bit more what you mean here? I'm not sure I understand
the issue that you are trying to point out. If you have two dives that
actually overlap then you have inconsistent input data, right?

> Btw, if you do track the trips explicitly (whether as a nesting thing
> or as a "fake dive"), the separate question about "what about
> selection" goes away, because we'd have a structure to remember
> whether a trip is selected or not. So it does solve that problem.

That was part of my thinking :-)

> One of the reasons I'm not a huge fan of explicit trips is that it
> will result in us having to have various new edit dialogs etc for the
> trip data. Stuff we can ignore as long as it's just an implicit
> grouping.

Yes - but I think it would add value for some users. You could note
which hotel you stayed at, which dive operator you went with. Etc.

> But I'm ok with it conceptually (whether implemented as an explicit
> nesting thing or as a magic dive thing). I just suspect it's a
> potential source of *lots* of new issues.

Yes. My code always is :-)

> Doing them as "fake dives" and just using the fake dives as separators
> - not ranges - might be easier. IOW, we could have a zero-length dive
> mean "dive trip starts".

So you would have them "in squence" when it comes to our DIVE_INDEX
field? That has some odd issues when you split a trip in two - you now
need to re-index all dives afterwards. With you removing the
selectiontracker array, is there anything else in the code that uses the
DIVE_INDEX to remember certain dives?

I need to do some more code reading.

/D


More information about the subsurface mailing list