Custom sort order in wxDataViewListCtrl

[Iwbnwif Yiw]

Is it possible to implement a custom sort order in wxDataViewListCtrl?

It seems the Compare() function is implemented in wxDataViewListModel and there doesn't appear to be a way to replace it. 

This is unlike (for example) wxTreeListCtrl which has a SetItemComparator() method.

[Vadim Zeitlin]

On Thu, 31 Mar 2016 15:26:55 -0700 (PDT) Iwbnwif Yiw wrote:

IY> Is it possible to implement a custom sort order in wxDataViewListCtrl?

I don't think so, you would need to use the full wxDataViewCtrl for this.
As I keep saying, wxDataViewListCtrl is really more trouble than it's
worth...

IY> This is unlike (for example) wxTreeListCtrl which has a SetItemComparator()
IY> method.

wxTreeListCtrl is built on top of wxDataViewCtrl directly, not the "List"
variant.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Iwbnwif Yiw]

 I don't think so, you would need to use the full wxDataViewCtrl for this.
As I keep saying, wxDataViewListCtrl is really more trouble than it's
worth...

Thank you for an amazingly fast response!!

I have seen you mention that wxDataViewListCtrl isn't brilliant once or twice ;) but never really understood why.

Out of interest, is it the control that is at fault or the list model that it's built around?

 

[Vadim Zeitlin]

On Thu, 31 Mar 2016 15:41:14 -0700 (PDT) Iwbnwif Yiw wrote:

IY> I have seen you mention that wxDataViewListCtrl isn't brilliant once or
IY> twice ;) but never really understood why.
IY>
IY> Out of interest, is it the control that is at fault or the list model that
IY> it's built around?

I don't like neither the API nor the implementation of this class. IMO it
should have had the same, or at least similar, API as wxListCtrl to help
people migrate from it. Or it could be more like wxTreeListCtrl (which is
basically my attempt to make a simple to use wxDataViewCtrl when you don't
want to define your own model). But having wxDataView{List,Tree}Ctrl which
are neither particularly nice to use, nor compatible with wx{List,Tree}Ctrl
nor even provide full access to wxDataViewCtrl functionality (as you've
just discovered again) doesn't make sense.

Unfortunately I have no idea what to do about it. We really can't have
another list-like control in wx, there are already too many...

[Andreas Falkenhahn]

On 01.04.2016 at 00:30 Vadim Zeitlin wrote:

> On Thu, 31 Mar 2016 15:26:55 -0700 (PDT) Iwbnwif Yiw wrote:

IY>> Is it possible to implement a custom sort order in wxDataViewListCtrl?

> I don't think so, you would need to use the full wxDataViewCtrl for this.

No, it's actually possible. I implemented this successfully some weeks ago. You
just have to derive a new class from wxDataViewListStore, associate it with the
wxDataViewListCtrl using AssociateModel() and then override the Compare() method
with your custom sorting logic.

This works fine here *except* this very annoying bug (hint, hint) that
wxDataViewListCtrl doesn't swap the client data when sorting items. Cf. my bug
report here:
http://trac.wxwidgets.org/ticket/17446

But if you don't use SetItemData() then this won't be a problem... custom
sorting itself is working fine here.

--
Best regards,
Andreas Falkenhahn mailto:and...@falkenhahn.com

[Iwbnwif Yiw]

No, it's actually possible. I implemented this successfully some weeks ago. You
just have to derive a new class from wxDataViewListStore, associate it with the
wxDataViewListCtrl using AssociateModel() and then override the Compare() method
with your custom sorting logic.

Oh yes, of course - thank you for that!  I had forgotten that AssociateModel() was still available in wxDataViewListCtrl. That actually sounds quite straightforward.

In the meantime, I took a look at the way wxTreeListCtrl was allowing custom sorting. I think it would be quite easy to replicate the same method in wxDataViewListModel and emerge it in a friendly way in wxDataViewListCtrl. I still think that this may be worthwhile, although your simple solution has reduced my motivation slightly.

But if you don't use SetItemData() then this won't be a problem... custom sorting itself is working fine here. 

Luckily I don't - for now  :)

[Iwbnwif Yiw]

 I don't like neither the API nor the implementation of this class. IMO it
should have had the same, or at least similar, API as wxListCtrl to help
people migrate from it. Or it could be more like wxTreeListCtrl (which is
basically my attempt to make a simple to use wxDataViewCtrl when you don't
want to define your own model).

Firstly, thank you - I really appreciate this insight.

No doubt, wxTreeListCtrl has the better API. However, and with the greatest respect, there are a few reasons why I choose wxDataViewListCtrl instead:

1. Unless I have completely missed it, wxTreeListCtrl doesn't have a friendly 'list' API, i.e. you cannot address items by 'row'. I appreciate that you can create a 'flat' tree (as per the sample). No doubt row access can be emulated with GetRootItem(), GetFirstChild() and iterating on GetNextSibling() but IHMO it is less intuitive than GetValue (variant&, row col) or GetTextValue (row, col).
2. In the documentation for GetView() it says "This method may return NULL in the future, non wxDataViewCtrl-based, versions of this class, use GetView() unless you really need to use wxDataViewCtrl methods on the returned object". I think it also says something similar in the header. IMVHO this is possibly not a good thing to say, wxDataViewCtrl seems to be the most advanced, maintained list-like control in wxWidgets so it feels better to use it or something derived from it. If wxTreeViewCtrl is going to change substantially in the future then that's a worry, maybe I will have relied (deliberately or inadvertently) on wxDataViewCtrl behavior and something might get broken.
   
3. There is something weird with wxTreeListCtrl headers. You can see this clearly in the sample (at least MSW and GTK) by repeatedly resizing the window with the mouse. Either the 1st column or the 3rd one starts to consume the whole space. I didn't see the same behavior with other wxDataViewCtrl derivatives.

 

But having wxDataView{List,Tree}Ctrl which 

are neither particularly nice to use, nor compatible with wx{List,Tree}Ctrl
nor even provide full access to wxDataViewCtrl functionality (as you've
just discovered again) doesn't make sense. 

Agreed, but full access to wxDataViewCtrl functionality comes with a health warning on wxTreeListCtrl.

 

 Unfortunately I have no idea what to do about it. We really can't have
another list-like control in wx, there are already too many...

Absolutely agreed, the number of list-like controls (not to mention the third party ones) is rather confusing. I can only offer a humble suggestion and I absolutely appreciate that it all comes down to time.

1. Implement a 'list only' mode for wxTreeListCtrl which gives row, column access to data items (including appending, deleting, moving rows etc.).
2. Have wxVariant (or wxAny) getters and setters for data. This avoids [dare I say fiddling around with] *wxClientData etc.
3. Allow editing (maybe this is already possible - I didn't find how to do it).
4. Emphasize that wxTreeListCtrl is THE wxWidgets list-like control, and a simple, but multipurpose wrapper for wxDataViewCtrl (remove any hint that this may change in the future).
5. Add notes that wxDataView{List,Tree}Ctrl, whilst not deprecated, are not the preferred way of displaying data lists and trees for new projects.

I think that, given time, wxDataView{List,Tree}Ctrl will become less prevalent and we will be left with wxDataViewCtrl for fine grained models and wxTreeListCtrl for everything else. wxGrid will still have a place where there is no consistency to the column structure.

Sorry for so many thoughts, but I appreciated your response very much!

[Vadim Zeitlin]

On Fri, 1 Apr 2016 05:59:41 -0700 (PDT) Iwbnwif Yiw wrote:

IY> No doubt, wxTreeListCtrl has the better API. However, and with the greatest
IY> respect, there are a few reasons why I choose wxDataViewListCtrl instead:

Notice that wxTreeListCtrl is absolutely not meant to replace
wxDataViewCtrl, it's intentionally more limited, so if you need something
that it doesn't provide, using wxDataViewCtrl, or even wxDataViewListCtrl,
is the right thing to do.

IY> 1. Unless I have completely missed it, wxTreeListCtrl doesn't have a
IY> friendly 'list' API, i.e. you cannot address items by 'row'. I appreciate
IY> that you can create a 'flat' tree (as per the sample). No doubt row access
IY> can be emulated with GetRootItem(), GetFirstChild() and iterating on
IY> GetNextSibling() but IHMO it is less intuitive than GetValue (variant&, row
IY> col) or GetTextValue (row, col).

Access by row doesn't really make sense as soon as you have branches.
First of all, it's not O(1), as would be expected. Second, it's never clear
if the row is the physical row (depends on the expanded state of the
branches before it) or logical one (as if all the branches were expanded).

IY> 2. In the documentation for GetView() it says "*This method may return
IY> NULL in the future, non wxDataViewCtrl-based, versions of this class, use
IY> GetView() unless you really need to use wxDataViewCtrl methods on the
IY> returned object*". I think it also says something similar in the header.
IY> IMVHO this is possibly not a good thing to say, wxDataViewCtrl seems to be
IY> the most advanced, maintained list-like control in wxWidgets so it feels
IY> better to use it or something derived from it. If wxTreeViewCtrl is going
IY> to change substantially in the future then that's a worry, maybe I will
IY> have relied (deliberately or inadvertently) on wxDataViewCtrl behavior and
IY> something might get broken.

To be honest, this is quite unlikely to happen, but the idea is that if we
can implement wxTreeListCtrl API directly and natively on some platform
(typically this would be MSW...), then we should be able to do it. And yes,
it does mean that you shouldn't use its GetView() unless you really need
to.

IY> 3. There is something weird with wxTreeListCtrl headers. You can see
IY> this clearly in the sample (at least MSW and GTK) by repeatedly resizing
IY> the window with the mouse. Either the 1st column or the 3rd one starts to
IY> consume the whole space. I didn't see the same behavior with other
IY> wxDataViewCtrl derivatives.

This looks like a bug which should be fixed, please report it as usual.

IY> Absolutely agreed, the number of list-like controls (not to mention the
IY> third party ones) is rather confusing. I can only offer a humble suggestion
IY> and I absolutely appreciate that it all comes down to time.
IY>
IY> 1. Implement a 'list only' mode for wxTreeListCtrl which gives row,
IY> column access to data items (including appending, deleting, moving rows
IY> etc.).

I'm not sure if this wouldn't make the control more complicated to use,
thus negating the main reason for its existence...

IY> 2. Have wxVariant (or wxAny) getters and setters for data. This avoids
IY> [dare I say fiddling around with] *wxClientData etc.

I don't think wxVariant is really any better than wxClientData. The latter
is supported to make it simpler to migrate existing code using wxTreeCtrl
to wxTreeListCtrl. And wxVariant doesn't replace client data anyhow, of
course, but rather the item text... I'm really not sure what do you mean
here.

IY> 3. Allow editing (maybe this is already possible - I didn't find how to
IY> do it).

No, it isn't editable. This could indeed be added, provided the API
remains really simple.

IY> 4. Emphasize that wxTreeListCtrl is THE wxWidgets list-like control, and
IY> a simple, but multipurpose wrapper for wxDataViewCtrl (remove any hint that
IY> this may change in the future).

This is simply not the case. wxTreeListCtrl is a simple way to show (not
edit) a relatively small number of items. For anything else you need to use
something else. And, again, while editing could be added, this control
hides the use of the model, similarly to wxSimpleHtmlListBox and
wxHtmlListBox for example, so making it a general wrapper of wxDataViewCtrl
wouldn't make much sense as then it would be as complex as it.

IY> 5. Add notes that wxDataView{List,Tree}Ctrl, whilst not deprecated, are
IY> not the preferred way of displaying data lists and trees for new projects.

For this we need to be able to propose something better instead :-(

[Iwbnwif Yiw]

Notice that wxTreeListCtrl is absolutely not meant to replace
wxDataViewCtrl, it's intentionally more limited

Sorry, I should have been clear, the choice was between wxTreeListCtrl and wxDataViewListCtrl. 

 

or even wxDataViewListCtrl, is the right thing to do.

I really didn't expect you to say that :))

 Access by row doesn't really make sense as soon as you have branches.

Agreed, that is why I proposed a 'list' (aka flat) mode and that row access would only be available in that mode (return NULL, error or similar otherwise).

First of all, it's not O(1), as would be expected. 

Surely, this also applies to wxDataViewListCtrl?

 

IY>    1. Implement a 'list only' mode for wxTreeListCtrl which gives row,
IY>    column access to data items (including appending, deleting, moving rows
IY>    etc.).

 I'm not sure if this wouldn't make the control more complicated to use,
thus negating the main reason for its existence...

This I don't agree with. There isn't necessarily a correlation between the number of member functions and complexity of use. For example, wxString has 100's (at least too many to count right now!) of member functions but it seems pretty easy to use.

Consider a 'flat' list. If I want to add an item to the end, in wxDataViewListCtrl all I need to do is:

AppendItem (const wxVector< wxVariant > &values);

If I understand correctly, to do the same with a flat wxTreeListCtr, I would need to:

1. Get the first item

2. Iterate on GetNextItem() until it fails, temporarily remembering the last item

3. Append a new item to the last item

4. Iterate over the columns populating the item with text.

(granted, step 4 might be needed to populate the wxVector<wxVariant> but I do have the choice to store my data in that format)

And wxVariant doesn't replace client data anyhow, of
course, but rather the item text... I'm really not sure what do you mean
here.

Ah, sorry - this was a mistake, please ignore!

 

This is simply not the case. wxTreeListCtrl is a simple way to show (not
edit) a relatively small number of items. For anything else you need to use
something else. And, again, while editing could be added, this control
hides the use of the model, similarly to wxSimpleHtmlListBox and
wxHtmlListBox for example, so making it a general wrapper of wxDataViewCtrl
wouldn't make much sense as then it would be as complex as it.

IMHO a lot of use cases for list-like controls involve simply displaying rows of data, quite possibly rows from a database? Nothing very complicated is needed to do that, just a quick and dirty way to blast data into the control, find out what the user is clicking on (okay client data is great here!) and maybe make simple edits.

I think we agree that for small numbers of rows, copying to-from a string or variant isn't too bad, so hiding the model is definitely the right thing to do.

 For this we need to be able to propose something better instead :-( 

FWIW I am proposing a wxTreeListCtrl based on wxDataViewCtrl that is a 'true' wx{Tree *and/or* List}Ctrl :)). IMHO the current one almost is this, but not quite.

Then there would be only one [simple, wxDataViewCtrl] control [and associated models] to maintain instead of three.

If necessary, there could be be two compatibility layers to make it look like wxDataView{Tree XOR List}Ctrl controls respectively.

Finally, I am aware that this has 1. gone off topic, and 2. probably taking up too much of your time on a hypothetical discussion. OTOH, maybe I will have a go at this one day. More practically, if there is any interest I would be happy to make a proposal as to how the class might look from a user perspective.

 

[Vadim Zeitlin]

On Sat, 2 Apr 2016 10:04:34 -0700 (PDT) Iwbnwif Yiw wrote:

IY> > or even wxDataViewListCtrl, is the right thing to do.
IY> >
IY> I really didn't expect you to say that :))

I'm realistic, for small lists the choice is between wxListView and
wxDataViewListCtrl and the only advantage of using the former is that it's
native under MSW, but this is less and less important as the "common list
view" control doesn't look very common under Windows 10 any more...

IY> > First of all, it's not O(1), as would be expected.
IY>
IY> Surely, this also applies to wxDataViewListCtrl?

I hope it is, why wouldn't it be?

IY> > IY> 1. Implement a 'list only' mode for wxTreeListCtrl which gives row,
IY> > IY> column access to data items (including appending, deleting, moving
IY> > rows
IY> > IY> etc.).
IY> >
IY> > I'm not sure if this wouldn't make the control more complicated to use,
IY> > thus negating the main reason for its existence...
IY>
IY> This I don't agree with. There isn't necessarily a correlation between the
IY> number of member functions and complexity of use. For example, wxString has
IY> 100's (at least too many to count right now!) of member functions but it
IY> seems pretty easy to use.

wxString is a really bad example of a well-designed class. Sure, there are
plenty of explanations and excuses for this, but I definitely don't want
wxTreeListCtr to turn into something like this.

IY> Consider a 'flat' list. If I want to add an item to the end, in
IY> wxDataViewListCtrl all I need to do is:
IY>
IY> AppendItem (const wxVector< wxVariant > &values);

This is quite clumsy IMO, you're quite unlikely to have your data in
wxVector<wxVariant>, so having separate methods or maybe a method taking
two iterators would have been better.

BTW, with C++11 variadic templates you can have a really nice type-safe
alternative which is not only simpler to use but also helps with errors at
compile-time.

IY> If I understand correctly, to do the same with a flat wxTreeListCtr, I
IY> would need to:
IY>
IY> 1. Get the first item
IY> 2. Iterate on GetNextItem() until it fails, temporarily remembering the
IY> last item
IY> 3. Append a new item to the last item

I don't understand, what's wrong with just calling AppendItem()? The only
problem I can see is if is you want to insert something in the middle
because then you do need to iterate, but this shouldn't be needed very
often, hopefully.

IY> 4. Iterate over the columns populating the item with text.

We could add SetItemValues() overload, this wouldn't add any significant
complexity.

IY> IMHO a lot of use cases for list-like controls involve simply displaying
IY> rows of data, quite possibly rows from a database?

This calls for (in order of preference), full wxDVC, (virtual) wxListCtrl
or wxGrid.

IY> More practically, if there is any interest I would be happy to make a
IY> proposal as to how the class might look from a user perspective.

Deciding on a nice API is half of the work, so I'm definitely interested
in discussing this even if I don't promise to actually do anything about it
immediately.

[Iwbnwif Yiw]

 I'm realistic, for small lists the choice is between wxListView and
wxDataViewListCtrl and the only advantage of using the former is that it's
native under MSW, but this is less and less important as the "common list
view" control doesn't look very common under Windows 10 any more...

OMG, I forgot wxListView! So please correct my earlier comment, a boosted wxTreeListCtrl would mean maintaining 1 control instead of 4! 

(wxListCtrl is a completely different case of course)

 

 wxString is a really bad example of a well-designed class. Sure, there are
plenty of explanations and excuses for this, but I definitely don't want
wxTreeListCtr to turn into something like this.

Good or bad design, it is still relatively simple to use. At least the basic features.

 

 This is quite clumsy IMO, you're quite unlikely to have your data in
wxVector<wxVariant>, so having separate methods or maybe a method taking
two iterators would have been better.

 BTW, with C++11 variadic templates you can have a really nice type-safe
alternative which is not only simpler to use but also helps with errors at
compile-time.

Okay!

 I don't understand, what's wrong with just calling AppendItem()? The only
problem I can see is if is you want to insert something in the middle
because then you do need to iterate, but this shouldn't be needed very
often, hopefully.

Sorry, I take back everything I said! Well it's even easier then, for the list mode just need to overload AppendItem() to always append to the root. 

IY> 4. Iterate over the columns populating the item with text.

 We could add SetItemValues() overload, this wouldn't add any significant
complexity.

That sounds great, maybe consider both wxVector and wxStringArray versions. 

IY> IMHO a lot of use cases for list-like controls involve simply displaying
IY> rows of data, quite possibly rows from a database?

 This calls for (in order of preference), full wxDVC, (virtual) wxListCtrl
or wxGrid.

 Why?! Please bear with me a minute ;)

Full wxDVC: Optimum results, but need to write a custom model - okay if just one table / query (database) or object list (other things), but if 20, 30 or more with different fields, data types etc. it's a lot of work. Oh yes, the thing to do would be to write a model base class and subclass it for each different object list, perhaps a more generic one for re-use. If you are me, sooner or later you will end up with something looking a awfully like a wxDataViewListModel and wonder why I didn't just use it in the first place!!

wxListCtrl: Possibly, but isn't the only advantage a virtual table? If there are 100000 rows, then sure but I think it is quite common to have a 1000 rows or less of data to display which these days are fine without a virtual table. wxListCtrl is obviously important for laying out data in different ways, like icons and text, thumbnails etc.

wxGrid: This I really don't understand. wxGrid is great, but I think its strengths lie elsewhere. For instance where data is not consistent between rows (some have 20 columns, some have 5), merging cells, showing images in some cells etc.

 Deciding on a nice API is half of the work, so I'm definitely interested
in discussing this even if I don't promise to actually do anything about it
immediately.

Of course, I totally understand that this is not a priority. 

[Vadim Zeitlin]

On Sat, 2 Apr 2016 13:14:41 -0700 (PDT) Iwbnwif Yiw wrote:

IY> > I'm realistic, for small lists the choice is between wxListView and
IY> > wxDataViewListCtrl and the only advantage of using the former is that it's
IY> > native under MSW, but this is less and less important as the "common list
IY> > view" control doesn't look very common under Windows 10 any more...
IY>
IY> OMG, I forgot wxListView! So please correct my earlier comment, a boosted
IY> wxTreeListCtrl would mean maintaining 1 control instead of 4!
IY> (wxListCtrl is a completely different case of course)

Just to be clear: wxListView is just a façade of wxListCtrl, in the same
way (but more thinly) as wxTreeListCtr is a façade of wxDataViewCtrl.

IY> Sorry, I take back everything I said! Well it's even easier then, for the
IY> list mode just need to overload AppendItem() to always append to the root.

Hmm, why not.

IY> IY> 4. Iterate over the columns populating the item with text.
IY> >
IY> > We could add SetItemValues() overload, this wouldn't add any significant
IY> > complexity.
IY>
IY> That sounds great, maybe consider both wxVector and wxStringArray versions.

I think it should just be a template and take iterators.

IY> > IY> IMHO a lot of use cases for list-like controls involve simply
IY> > IY> displaying rows of data, quite possibly rows from a database?
IY> >
IY> > This calls for (in order of preference), full wxDVC, (virtual) wxListCtrl
IY> > or wxGrid.
IY>
IY> Why?! Please bear with me a minute ;)
IY>
IY> Full wxDVC: Optimum results, but need to write a custom model - okay if
IY> just one table / query (database) or object list (other things), but if 20,
IY> 30 or more with different fields, data types etc. it's a lot of work. Oh
IY> yes, the thing to do would be to write a model base class and subclass it
IY> for each different object list, perhaps a more generic one for re-use. If
IY> you are me, sooner or later you will end up with something looking a
IY> awfully like a wxDataViewListModel and wonder why I didn't just use it in
IY> the first place!!

Because you don't want to store all database data in the main memory, of
course. Granted, memory is cheap and plentiful nowadays, but reading the
entire table contents in it is still not going to be fast. You should never
use anything like wxDataViewListModel or wxGridStringTable when working
with any realistic database.

IY> wxGrid: This I really don't understand.

I put it last in my list because this is indeed not what I'd recommend
using in this case. But it still could be used, e.g. if you wanted to use
some grid-specific functionality like merged cells, custom borders or,
probably the most common, row headers.

[Iwbnwif Yiw]

Thank you for your continued patience!

IY> OMG, I forgot wxListView! So please correct my earlier comment, a boosted
IY> wxTreeListCtrl would mean maintaining 1 control instead of 4!
IY> (wxListCtrl is a completely different case of course)

 Just to be clear: wxListView is just a façade of wxListCtrl, in the same
way (but more thinly) as wxTreeListCtr is a façade of wxDataViewCtrl.

Well my point was a weak one. I was thinking that the purpose of the façade is mostly for displaying lists, but I maybe its useful for the other modes as well. As you can probably guess, I haven't used it!

 

IY> IY> 4. Iterate over the columns populating the item with text.
IY> >
IY> >  We could add SetItemValues() overload, this wouldn't add any significant
IY> > complexity.
IY>
IY> That sounds great, maybe consider both wxVector and wxStringArray versions.

 I think it should just be a template and take iterators.

Okay, but why not do both. I don't think it would over complicate matters (also see next point).

 

 Because you don't want to store all database data in the main memory, of
course. Granted, memory is cheap and plentiful nowadays, but reading the
entire table contents in it is still not going to be fast.

Exactly! That is why I think it is reasonably common to only display a few 10's or 100's of rows at a time. 

Take the case where the data is coming over a wire for example. Surely the 'big data' (I don't really mean Big Data!) needs to be on the server or wherever. In this case, only the salient rows need to come down the wire and get pushed to the display. If it's not what you want, go back and fetch some more.

Am I getting in out of my depth here? :))

What I am trying to suggest is there are cases where it is better not to store the whole dataset locally, even if it is in compact classes because you just don't need most of it.

Now, imagine that the data is coming in as compressed XML or JSON or similar. It's already strings - so, if they don't need formatting, validating etc., why not display them directly?

Okay, definitely out of my depth now! Please do correct me if I am wrong about these things.

[Vadim Zeitlin]

On Sun, 3 Apr 2016 15:14:48 -0700 (PDT) Iwbnwif Yiw wrote:

IY> > Because you don't want to store all database data in the main memory, of
IY> > course. Granted, memory is cheap and plentiful nowadays, but reading the
IY> > entire table contents in it is still not going to be fast.
IY>
IY> Exactly! That is why I think it is reasonably common to only display a few
IY> 10's or 100's of rows at a time.
IY>
IY> Take the case where the data is coming over a wire for example. Surely the
IY> 'big data' (I don't really mean Big Data!) needs to be on the server or
IY> wherever. In this case, only the salient rows need to come down the wire
IY> and get pushed to the display. If it's not what you want, go back and fetch
IY> some more.
IY>
IY> Am I getting in out of my depth here? :))

I don't know, but I think you might be misunderstanding how
wxDataViewListCtrl and wxGridStringTable work. Both of them need to have
*all* the data in memory, you can't use them otherwise. OTOH you can use
(virtual) wxListView or wxGrid perfectly well without loading any data
other than what is currently shown on screen.

The sad case here is wxDataViewCtrl which is definitely supposed to work
like this too, but only really does when using the generic version, the
native ones currently don't work at all with many items. In the OS X case
it at least seems to be "just" due to not doing using the native control
correctly (see http://trac.wxwidgets.org/ticket/16740) but for GTK+ it is
even worse and the native widget just seems to be fundamentally broken (see
http://trac.wxwidgets.org/ticket/16680) and I don't see what could we do
about it.

IY> What I am trying to suggest is there are cases where it is better not to
IY> store the whole dataset locally, even if it is in compact classes because
IY> you just don't need most of it.

Yes, nobody argues with this and this is exactly why I keep saying
wxTreeListCtrl can't be used in all circumstances.

[Iwbnwif Yiw]

IY> Take the case where the data is coming over a wire for example. Surely the
IY> 'big data' (I don't really mean Big Data!) needs to be on the server or
IY> wherever. In this case, only the salient rows need to come down the wire
IY> and get pushed to the display. If it's not what you want, go back and fetch
IY> some more.
IY>
IY> Am I getting in out of my depth here? :))

 I don't know, but I think you might be misunderstanding how
wxDataViewListCtrl and wxGridStringTable work. Both of them need to have
*all* the data in memory, you can't use them otherwise. OTOH you can use
(virtual) wxListView or wxGrid perfectly well without loading any data
other than what is currently shown on screen.

My understanding is as follows:

Virtual tables (i.e. wxListView, wxGrid) can look like huge tables with millions of rows, whereas actually they are [possibly] very small with just a handful of rows, but the rows are the ones that the user wants to see. If the user wants to look at some different rows, the virtual table gets pumped with the new set of rows.

wxDataViewListCtrl does not have a virtual table, so in a basic mode you would [theoretically] have to load millions of rows if it is to be possible for the user to look anywhere in the huge dataset.

Is that basically right?

 

IY> What I am trying to suggest is there are cases where it is better not to
IY> store the whole dataset locally, even if it is in compact classes because
IY> you just don't need most of it.

To amplify: take Google search for example. Type wxWidgets into the Google search box and it will find, straight away, ~500,000 results. But it doesn't show all 500,000 results in a long list and it doesn't send all the results from the Google server to the client (browser). It just sends 10 or so, and gives the user the option to 'page' to some more results if they want to.

Now imagine that instead of a browser you have a wxTreeListView as the user interface. It can still work the same way, displaying 10 or even 100 rows of XML or JSON data no problem (lightning fast). If they are not the wanted rows then the user can tweak their query or look at the next page of results. The wxTreeListCtrl gets cleared and then repopulated with the new data.

My underlying point here is that you can still load data on demand without using virtual tables, the server (remote end) manages that part. So wxTreeListCtrl can still be useful, even if the data it is connected to is huge, providing the server can send only the relevant bits (or at least chunks).

 Yes, nobody argues with this and this is exactly why I keep saying 
wxTreeListCtrl can't be used in all circumstances. 

I agree, I am sure there are circumstances where it is necessary to scroll quickly up and down through a very large number of items. Google image search for example. In those cases wxListCtrl or wxGrid are the better options. (However, if the wxTreeListCtrl could inherit a working virtual table capability from wxListCtrl (rows mode), then that might change the situation)

My proposition is that it is better to have one {tree and/or list} control and one grid control. I think we partially agree on this. The challenge is to make the interface of the 'one size fits all' (!) wxTreeListCtrl simple enough.

[Vadim Zeitlin]

On Wed, 6 Apr 2016 13:47:33 -0700 (PDT) Iwbnwif Yiw wrote:

IY> My understanding is as follows:
IY>
IY> Virtual tables (i.e. wxListView, wxGrid) can look like huge tables with
IY> millions of rows, whereas actually they are [possibly] very small with just
IY> a handful of rows, but the rows are the ones that the user wants to see. If
IY> the user wants to look at some different rows, the virtual table gets
IY> pumped with the new set of rows.
IY>
IY> wxDataViewListCtrl does not have a virtual table, so in a basic mode you
IY> would [theoretically] have to load millions of rows if it is to be possible
IY> for the user to look anywhere in the huge dataset.
IY>
IY> Is that basically right?

Yes.

IY> To amplify: take Google search for example. Type wxWidgets into the Google
IY> search box and it will find, straight away, ~500,000 results. But it
IY> doesn't show all 500,000 results in a long list and it doesn't send all the
IY> results from the Google server to the client (browser). It just sends 10 or
IY> so, and gives the user the option to 'page' to some more results if they
IY> want to.
IY>
IY> Now imagine that instead of a browser you have a wxTreeListView as the user
IY> interface. It can still work the same way, displaying 10 or even 100 rows
IY> of XML or JSON data no problem (lightning fast).

No, it can't for the simple reason that it doesn't use the "paged"
approach used by Google results. You won't be able to scroll seamlessly in
wxTreeListCtrl.

IY> My underlying point here is that you can still load data on demand without
IY> using virtual tables,

This approach will never work with scrolling. You will need to have page
switches outside of the control which is ugly and very unusual in desktop
applications.

[Iwbnwif Yiw]

 This approach will never work with scrolling.

Agreed.

 

You will need to have page switches outside of the control which is ugly and very unusual in desktop
applications.

Not necessarily page switches, but for example on a touch interface you could use gestures. Flick left / right for pages and scroll up or down through a small list to choose the item.

In a more traditional desktop I would encourage users to narrow their search, or have a "Show more results..." button.

Anyway, I think that we should agree to disagree about this :) However, I respect your view so please say more if you would like.

I think the original point I was making is that wxTreeListCtrl could remove the need for wxDataViewListCtrl and wxDataViewTreeCtrl. However to do the list part, IMHO it would need to have SetTextValue (const wxString &value, unsigned int row, unsigned int col) and wxString GetTextValue (unsigned int row, unsigned int col) methods.

[Vadim Zeitlin]

On Thu, 7 Apr 2016 12:42:17 -0700 (PDT) Iwbnwif Yiw wrote:

IY> > You will need to have page switches outside of the control which is ugly
IY> > and very unusual in desktop applications.
...
IY> In a more traditional desktop I would encourage users to narrow their
IY> search, or have a "Show more results..." button.

Those are, IMO, just (ugly) workarounds for lack of true "virtual"
controls in some UIs.

IY> Anyway, I think that we should agree to disagree about this :) However, I
IY> respect your view so please say more if you would like.

Here you go: I think the "virtual controls" idea is just about perfect by
its simplicity and ease of use. The popularity, not to say ubiquity, of
paged results is IMNSHO only due to lack of support for true virtual
controls.

IY> I think the original point I was making is that wxTreeListCtrl could
IY> remove the need for wxDataViewListCtrl and wxDataViewTreeCtrl. However to
IY> do the list part, IMHO it would need to have SetTextValue (const wxString
IY> &value, unsigned int row, unsigned int col) and wxString GetTextValue
IY> (unsigned int row, unsigned int col) methods.

Sure, I already said that these could be useful additions.