[PATCH] Separate download code sharable between desktop & mobile
dirk at hohndel.org
Sun Jan 31 13:05:35 PST 2016
On Sun, Jan 31, 2016 at 10:27:01PM +0200, Willem Ferguson wrote:
> The object here was just to get the desktop version to work normally, given
> the removal of some code.
> Filtering is certainly a priority, but probably implementing another method
> of the same class.
That seems like a sensible plan.
> >That filename is confusing... based on reading what you are doing there
> >below I don't think this is the "manager".
> >Also, since it is supposed to be used both from desktop and mobile it
> >would have to be either in subsurface-core or (with a little restructuring
> >- as really it should hold only the models) in qt-models.
> I thought it should go somewhere where both projects can easily see it.
> Desktop-widgets is clearly not appropriate.
> Same applies to qt-mobile. Maybe subsurface-core. let me just tell you what
> my vision has been. That this new class
> contains numerous methods (e.g. filtering of dc names, other interactions
> with the downloadFromDCWidget, (there
> are quite a few methods still to be added) as well as the interfacing
> (effectively the models) for the QML. Would it
> be advantageous to keep the models and the methods separate?
I think it's useful to place the model in qt-models - but if it is easier
to keep it together with the other code, then let's put it in
> >So fill_computer_list() right now populates the vendorList which is part
> >of the DownloadFromDCWidget... not sure how you can do this in a helper
> >function that's part of a different class without passing that list around
> >Ah, that's how you are doing it... I don't think that's a good way to do
> >this. I'd create the model in the helper and pass that around instead of
> >just a string list.
> Will do that. That was part of my considerations during the process,
> but I was not sure the existing models used by the desktop were very useful,
> that is after looking at the code on the qt-models directory.
It's always possible that we run into issues later, but the first goal, I
think, should be to have one model shared by both UIs.
> >I see that you took what must have seemed like a reasonable first step in
> >abstracting this out by moving just the creation of the QStringList into a
> >helper function. I keep thinking that we should abstract this out at the
> >QAbstractListModel level...
> Am I understanding you right?
> The class (downloadmanager) should inherit from QAbstarctListObject
> not from QObject? Makes sense.
The tricky thing here is that we have actually two classes. One class that
holds the vendors and an instance of the other class (which holds the
model per vendor)
So DiveComputerVendor and DiveComputerModel would be reasonable class
names, I guess. And yes, derived from QAbstractList. You could put them
both in qt-models/divecomputerclasses.cpp/.h
More information about the subsurface