cylinder editing

[Benjamin]

I would say it's a good idea, given what you have explained. Not that it's
my place to say such things... :)

Completely random thought. Is there some sort of design
document/model/random scribblings that describe the whole model for
cylinders? Or am I dragging too much of a work attitude into this?

Benjamin
On 2 Jul 2014 06:57, "Rodrigo Severo" <rodrigo at fabricadeideias.com> wrote:

> Please do it.
>
>
> Rodrigo
>
>
> On Wed, Jul 2, 2014 at 12:24 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>> Hi there...
>>
>> I have spent three hours this evening reading and debugging our code
>> around cylinders and editing.
>>
>> It is insane and broken and terrible in more ways that I am able to
>> describe here. Terrible is actually way too kind.
>>
>> The fundamental design how we do things is just simply wrong. For example,
>> when displaying a dive, we don't display the cylinders of that dive, but
>> we copy them into the editedDive and display those cylinders. So part of
>> what you see is current_dive, part is editedDive.
>>
>> If we then start editing a dive, depending on whether we are adding a new
>> dive, planning a dive, editing a regular dive or editing a manually added
>> dive we do different magic things involving not one but TWO other dive
>> pointers, one is "current" inside the CylindersModel, the other one is
>> stagingDive inside the DivePlannerPointsModel. So at any point in time
>> there is current_dive (or master_dive), the editedDive, the stagingDive
>> and the "current" variable pointing to a dive. Oh, did I mention there is
>> another "current" variable in the WeightModel that at times is out of sync
>> with the one in the CylindersModel?
>>
>> Add to that that the diveplanner also does magic things with cylinders and
>> dives. We recreate a new dive for every diveplan divepoint as we plan the
>> dive (Tomaz has complained about that many times). And we track the gas
>> consumption in the cylinders of the dive we are assembling in ways that
>> potentially overwrites data when we edit a manually added dive.
>>
>> Are you confused, yet?
>>
>> Now let's make this clear - a TON of this breakage was done by me and I am
>> not yelling at anyone here for bad design. I am pointing out that this
>> code is in frightening shape and that I'm uncomfortable doing a 4.2
>> release based on what's there. Bugs #553 and #582 are simply symptoms of
>> the mess we (I) have created...
>>
>> What do people think about two weeks for fixing the outstanding bugs
>> including this mess and delaying 4.2 until the end of the month? I know
>> that several people (cough, Tomaz, cough) are itching to work on new
>> things for 4.3... but this would give us more time to polish the planner,
>> the UI, and clean up our logic and data strctures.
>>
>> Thoughts, praise, disagreement?
>>
>> /D
>>
>>
>> _______________________________________________
>> subsurface mailing list
>> subsurface at hohndel.org
>> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>>
>
>
>
> --
>
> *Rodrigo Severo* | DIRETOR DE TECNOLOGIA
> Tel. *+55 61 3030-1515 <%2B55%2061%203030-1515>*
> Siga a Fábrica no twitter:*@empautaclipping*
>
> fabricadeideias.com <http://www.fabricadeideias.com/>
> 12 ANOS DE TECNOLOGIA E COMUNICAÇÃO
> NUMA COMBINAÇÃO PERFEITA
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140702/5fca96b6/attachment-0001.html>