Re: [PATCH] CCR Import from CSV: Calculate correct nitrogen and helium gas pressures

2014-11-03 Thread Willem Ferguson 

On 03/11/2014 11:59, Paul Sargent wrote:

On 3 Nov 2014 08:35, Robert Helling hell...@atdotde.de wrote:


On 03.11.2014, at 09:26, Willem Ferguson willemfergu...@zoology.up.ac.za 
wrote:


You guys have the experience. Please advise??  Robert, your opinion?


IMHO having special, hardcoded meanings for 0 and 1 is bad and also for the 
future having symbolic names is much better even if at the moment they always 
have the values 0 and 1.

I would agree. If someone is planning a dive or entering gases manually then 
fixed indices well be a total pain.

Paul


Paul,
Currently, when CCR data files are imported, cylinder 0 is used for 
oxygen because that is probably the single least variable among 
different CCR systems. Then cylinder 1 is used for the diluent gas 
because all CCR systems require a diluent gas. When it comes to other 
additional cylinders I agree that almost unlimited freedom should exist. 
But as far as the cylinders are concerned that are monitored by the CCR 
computer(s), cylinders 0 and 1 are dedicated because that is with what 
one has to start off with. Does this bring about any specific 
difficulty, even in using the planner? How would a Shearwater diver 
think about these issues?


Now please do not deduce that I am trying to make a case for hard 
coding. Not at all. I am trying to discover how other CCR divers think 
that have a totally different frame of mind from what I am thinking 
about, because this might bring me new insights. Please comment, will you?

Kind regards,
willem

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: trying to figure out the filter code

2014-11-03 Thread Tomaz Canabrava 
On Mon, Nov 3, 2014 at 10:21 PM, Dirk Hohndel d...@hohndel.org wrote:

 So I'm trying to understand how this all hooks together and it's clear
 that there's some Qt magic in the background that I'm missing...


There is a bit of black magic, yes.

So, everytime a filter is changed, *every* row on the dive list is send to
a specific function,
trips and dives, doesn't matter:

this one:
bool MultiFilterSortModel::filterAcceptsRow(int source_row, const
QModelIndex source_parent) const

but if you wanna check if something happened just *after* the filter was
due,
you need to implement something inside of the

void MultiFilterSortModel::myInvalidate()
{
invalidate();
 // HERE.
}

The 'invalidate()' method is internal to Qt and all it does is mark the
model as dirty and filter everything again based on the filterAcceptsRow.


 Let's assume I want to have a function called every time the filters
 change. How would I go about this?


Add it after the invalidate() call.
or create a new signal inside of MultiFilterSortModel called
'filterFinished()', call it after the invalidate() call, and connect it to
your own slot.



 Another question. In the regular model code for the dive list - we have
 lots of selection modification code there. That needs to become aware of
 filter data so that selecting a trip in the filtered view only selects the
 dives inside this trip that are visible under the filter - and similarly,
 the trip row in the view needs to show the number of visible dives in that
 trip, not the number of total dives in that trip.


Very hard to do with our current setup:
 The state of the DiveModel is unchanged, we are applying a filter on top
of it.
 so it doesn't know about the filter at all.


 To illustrate:

 I have a trip with 12 dives

 I filter for dives with Buddy Tomaz

 Then only the 6 dives with Tomaz are shown, but similarly the trip summary
 row should read

 Dive trip (6 dives)

 instead of (12 dives)

 So when I'm in TripItem::data() member, how can I figure out how many of
 the dives in that trip are visible with the current filter?


*right now* we cant. simple as that ( unless we do something really ugly to
the code. )
so, Options:

1 - We hack around that, but the code will be easy to break and hard to
maintain, for now.
2 - We hm
okay, some light came, maybe we can.

the MultiFilterProxyModel acts as 'proxy' so we can use it's own data()
method to retrieve information about
the filtered trip - but I'm not really sure it works, I need to test and
see, the setup should be as this:

1 - Implement the data() method for MultiFilterProxyModel,
if the current index is a dive, call the default implementation
if the current index is a trip, verify the number of children it has in the
proxy model, not in the real model.
return the correct string.





 I'm not asking you to implement any or all of this - I'm hoping that
 you'll be able to teach me enough to understand how all this works so I
 can implement it myself.

 /D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: trying to figure out the filter code

2014-11-03 Thread Dirk Hohndel 
On Mon, Nov 03, 2014 at 10:47:56PM -0200, Tomaz Canabrava wrote:
 On Mon, Nov 3, 2014 at 10:21 PM, Dirk Hohndel d...@hohndel.org wrote:
 
  So I'm trying to understand how this all hooks together and it's clear
  that there's some Qt magic in the background that I'm missing...
 
 There is a bit of black magic, yes.

Beginning to shine a light on it :-)

 but if you wanna check if something happened just *after* the filter was
 due,
 you need to implement something inside of the
 
 void MultiFilterSortModel::myInvalidate()
 {
 invalidate();
  // HERE.
 }
 
 The 'invalidate()' method is internal to Qt and all it does is mark the
 model as dirty and filter everything again based on the filterAcceptsRow.

Excellent. I just did that and I think I managed to clean up part of the
issues with the selection. I pushed two changes that did that.

  Another question. In the regular model code for the dive list - we have
  lots of selection modification code there. That needs to become aware of
  filter data so that selecting a trip in the filtered view only selects the
  dives inside this trip that are visible under the filter - and similarly,
  the trip row in the view needs to show the number of visible dives in that
  trip, not the number of total dives in that trip.
 
 
 Very hard to do with our current setup:
  The state of the DiveModel is unchanged, we are applying a filter on top
 of it.
  so it doesn't know about the filter at all.
 
 
  To illustrate:
 
  I have a trip with 12 dives
 
  I filter for dives with Buddy Tomaz
 
  Then only the 6 dives with Tomaz are shown, but similarly the trip summary
  row should read
 
  Dive trip (6 dives)
 
  instead of (12 dives)
 
  So when I'm in TripItem::data() member, how can I figure out how many of
  the dives in that trip are visible with the current filter?
 
 
 *right now* we cant. simple as that ( unless we do something really ugly to
 the code. )
 so, Options:
 
 1 - We hack around that, but the code will be easy to break and hard to
 maintain, for now.
 2 - We hm
 okay, some light came, maybe we can.
 
 the MultiFilterProxyModel acts as 'proxy' so we can use it's own data()
 method to retrieve information about
 the filtered trip - but I'm not really sure it works, I need to test and
 see, the setup should be as this:
 
 1 - Implement the data() method for MultiFilterProxyModel,
 if the current index is a dive, call the default implementation
 if the current index is a trip, verify the number of children it has in the
 proxy model, not in the real model.
 return the correct string.

I got stuck there - didn't manage to figure out how to do that. :-(

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface