On Friday 27 December 2013 20:27:48 Marco Martin wrote:
> On Friday 27 December 2013 09:50:46 Àlex Fiestas wrote:
> > So, if DataEngines are needed (I do not doubt that) let's continue having
> > them but let's stop pretending they are not public API or that they are
> > meant only for a quick hack
On Friday 27 December 2013 09:50:46 Àlex Fiestas wrote:
>
> So, if DataEngines are needed (I do not doubt that) let's continue having
> them but let's stop pretending they are not public API or that they are
> meant only for a quick hack. We don't want hacks do we? :p
+1 for de-hackify them ;)
my
On Tuesday 24 December 2013 20:13:58 Marco Martin wrote:
> for many things yes, but they are not mutually exclusive.
> I see imports more as standalone, high quality,stable api public libraries,
> while dataengines more as q quick mean of data fetching.
Please, DataEngines have given us many issues
On Tuesday 24 December 2013, Mark Gaiser wrote:
> On Tue, Dec 24, 2013 at 5:34 PM, Marco Martin wrote:
> > Hi all,
> > I decided to give a crack to an old pet peeve of mine (and quite a sore
> > point, if we look around in dataengines): integration of dataengines and
> > normal QAbstractItemModels
On Tue, Dec 24, 2013 at 5:34 PM, Marco Martin wrote:
> Hi all,
> I decided to give a crack to an old pet peeve of mine (and quite a sore point,
> if we look around in dataengines): integration of dataengines and normal
> QAbstractItemModels.
> Now, one could ask why not doing everything as imports
Hi all,
I decided to give a crack to an old pet peeve of mine (and quite a sore point,
if we look around in dataengines): integration of dataengines and normal
QAbstractItemModels.
Now, one could ask why not doing everything as imports of either qobjects with
an api or models.. fair enough and t
