cylinder editing

[Tomaz Canabrava]

I completely agree that we need to rework thst part, too many indirections
making the code very fragile. For that I can hold on doing code for 4.3 =p
Em 02/07/2014 01:25, "Benjamin" <nystire at gmail.com> escreveu:

> 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
>>
>>
> _______________________________________________
> 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/118c70a8/attachment.html>