wxGrid Choice Renderers/Editors
289 views
Skip to first unread message
Michael Richards
Feb 2, 2014, 12:12:29 AM2/2/14
to wx-...@googlegroups.com
I've been fooling with the grid again. Trying to make a cell that appears as a dropdown box. I think this is a pretty common task, especially given a foreign key type database arrangement. There is a wxGridCellEnumEditor and a wxGridCellChoiceEditor as well as a wxGridCellEnumRenderer.
Based on the description, the wxGridCellEnumEditor seems like it would do the trick. The problem is it only accepts sequential enum entries starting from 0. 
Fulvio Senore
Feb 2, 2014, 6:26:54 AM2/2/14
to wx-...@googlegroups.com
reason that you highlighted.
I also need to let uses choose an element from a database table that
contains a few entries, something VAT codes.
I wrote my custom editor and renderer that implement a combo box that
shows the rows description and tracks the corresponding primary key (an
integer). My renderer does not show the closed dropdown, it only shows
some text.
My solution is surely far from optimal but I can share the code if you
are interested.
Fulvio Senore
Vadim Zeitlin
Feb 2, 2014, 9:31:39 AM2/2/14
to wx-...@googlegroups.com
On Sun, 2 Feb 2014 00:12:29 -0500 Michael Richards wrote:
MR> I've been fooling with the grid again. Trying to make a cell that appears
MR> as a dropdown box. I think this is a pretty common task, especially given a
MR> foreign key type database arrangement. There is a wxGridCellEnumEditor and
MR> a wxGridCellChoiceEditor as well as a wxGridCellEnumRenderer.
MR>
MR> Based on the description, the wxGridCellEnumEditor seems like it would do
MR> the trick. The problem is it only accepts sequential enum entries starting
MR> from 0.
Why is it such a problem though? Couldn't the model (wxGridTable) do the
translation?
MR> Assuming I'm not missing some very obvious way to do this, would there be
MR> any interest in a wxGridCellChoiceEditor and wxGridCellChoiceRender that
MR> allows either a key->value type relation or a value -> value, as the user
MR> wishes with a Renderer that displays the closed dropdown list type control
MR> when not selected?
If we want to do this, then we arguably should do it in
wxGridCellEnumRenderer itself too, shouldn't we? OTOH I am not sure how
common is it to display the dropdown button for inactive cells. Do any
programs really do this?
MR> I think this could really make the wxGridCellEnumEditor obsolete since its
MR> functionality would be a subset. I think also that I could probably
MR> implement this in such a way that the legacy API is still compatible and a
MR> new constructor with some get/setValue/key type things would be the only
MR> additions.
We could extend the existing class, it seems like it shouldn't be
difficult to do it. But I still wonder if handling this at the model level
wouldn't be better.
Regards,
VZ
MR> I've been fooling with the grid again. Trying to make a cell that appears
MR> as a dropdown box. I think this is a pretty common task, especially given a
MR> foreign key type database arrangement. There is a wxGridCellEnumEditor and
MR> a wxGridCellChoiceEditor as well as a wxGridCellEnumRenderer.
MR>
MR> Based on the description, the wxGridCellEnumEditor seems like it would do
MR> the trick. The problem is it only accepts sequential enum entries starting
MR> from 0.
Why is it such a problem though? Couldn't the model (wxGridTable) do the
translation?
MR> Assuming I'm not missing some very obvious way to do this, would there be
MR> any interest in a wxGridCellChoiceEditor and wxGridCellChoiceRender that
MR> allows either a key->value type relation or a value -> value, as the user
MR> wishes with a Renderer that displays the closed dropdown list type control
MR> when not selected?
If we want to do this, then we arguably should do it in
wxGridCellEnumRenderer itself too, shouldn't we? OTOH I am not sure how
common is it to display the dropdown button for inactive cells. Do any
programs really do this?
MR> I think this could really make the wxGridCellEnumEditor obsolete since its
MR> functionality would be a subset. I think also that I could probably
MR> implement this in such a way that the legacy API is still compatible and a
MR> new constructor with some get/setValue/key type things would be the only
MR> additions.
We could extend the existing class, it seems like it shouldn't be
difficult to do it. But I still wonder if handling this at the model level
wouldn't be better.
Regards,
VZ
Michael Richards
Feb 2, 2014, 4:38:05 PM2/2/14
to wx-...@googlegroups.com
On Sunday, February 2, 2014 9:31:39 AM UTC-5, VZ wrote:
On Sun, 2 Feb 2014 00:12:29 -0500 Michael Richards wrote:
MR> I've been fooling with the grid again. Trying to make a cell that appears
MR> as a dropdown box. I think this is a pretty common task, especially given a
MR> foreign key type database arrangement. There is a wxGridCellEnumEditor and
MR> a wxGridCellChoiceEditor as well as a wxGridCellEnumRenderer.
MR>
MR> Based on the description, the wxGridCellEnumEditor seems like it would do
MR> the trick. The problem is it only accepts sequential enum entries starting
MR> from 0.
Why is it such a problem though? Couldn't the model (wxGridTable) do the
translation?
You are correct, it could be made to do this, but of course there are some features like auto-sorting that make it more difficult to do fully. That's one part of the problem, the other is actually drawing the control with the renderer.
MR> Assuming I'm not missing some very obvious way to do this, would there be
MR> any interest in a wxGridCellChoiceEditor and wxGridCellChoiceRender that
MR> allows either a key->value type relation or a value -> value, as the user
MR> wishes with a Renderer that displays the closed dropdown list type control
MR> when not selected?
If we want to do this, then we arguably should do it in
wxGridCellEnumRenderer itself too, shouldn't we? OTOH I am not sure how
common is it to display the dropdown button for inactive cells. Do any
programs really do this?
Moving back to your first point, the EnumRenderer could have been implemented as a normal string renderer with the value functionality doing the translation. I don't know if changing the behaviour of the EnumRenderer is a great plan, even though I feel like it should have shown a choicebox from the beginning. Of course it could simply take a flag to enable this new behaviour. A good example of a program that does this is using (auto) filters in excel or open office calc. It shows a dropdown box in the top cell of a column and you can pick filtering criteria in it. Quickbooks has a slightly different take on it and it shows the control only when that row is selected. I'd be happy with a few flags that allow either.
MR> I think this could really make the wxGridCellEnumEditor obsolete since its
MR> functionality would be a subset. I think also that I could probably
MR> implement this in such a way that the legacy API is still compatible and a
MR> new constructor with some get/setValue/key type things would be the only
MR> additions.
We could extend the existing class, it seems like it shouldn't be
difficult to do it. But I still wonder if handling this at the model level
wouldn't be better.
Like everything I think it's a balance between bloat in the library and programmer productivity. I know in my world I've been asked for it several places in the last year.
Supposing I were to implement and submit it... I think the renderer is the first place to start. I'd subclass a stringrenderer. If the control should not be displayed unless it is selected then the Draw function is as easy as calling the base function. If it were selected I think I could simply do something like: wxRendererNative::Get().DrawChoice( &grid, dc, rect, flags ) and draw the text in after. On this point I'm not sure if there is a way to simple stick a wxChoice control in there. Not really sure if that's possible or not since wxChoice doesn't appear to have a Draw function.
Thoughts?
-Michael
Vadim Zeitlin
Feb 2, 2014, 4:51:36 PM2/2/14
to wx-...@googlegroups.com
On Sun, 2 Feb 2014 13:38:05 -0800 (PST) Michael Richards wrote:
MR> Moving back to your first point, the EnumRenderer could have been
MR> implemented as a normal string renderer with the value functionality doing
MR> the translation. I don't know if changing the behaviour of the EnumRenderer
MR> is a great plan, even though I feel like it should have shown a choicebox
MR> from the beginning. Of course it could simply take a flag to enable this
MR> new behaviour. A good example of a program that does this is using (auto)
MR> filters in excel or open office calc. It shows a dropdown box in the top
MR> cell of a column and you can pick filtering criteria in it. Quickbooks has
MR> a slightly different take on it and it shows the control only when that row
MR> is selected. I'd be happy with a few flags that allow either.
Maybe it would indeed make more sense to have a new wxGridCellChoiceRenderer.
Otherwise, what flags exactly would we need?
MR> Supposing I were to implement and submit it... I think the renderer is the
MR> first place to start. I'd subclass a stringrenderer. If the control should
MR> not be displayed unless it is selected
There is currently no difference in appearance between selected and
non-selected cells.
MR> then the Draw function is as easy as
MR> calling the base function. If it were selected I think I could simply do
MR> something like: wxRendererNative::Get().DrawChoice( &grid, dc, rect, flags
MR> ) and draw the text in after. On this point I'm not sure if there is a way
MR> to simple stick a wxChoice control in there. Not really sure if that's
MR> possible or not since wxChoice doesn't appear to have a Draw function.
No controls have Draw() methods, instead we have wxRendererNative class
which provides some primitives for drawing them. In this case you want to
use its DrawComboBoxDropButton() method.
Regards,
VZ
MR> Moving back to your first point, the EnumRenderer could have been
MR> implemented as a normal string renderer with the value functionality doing
MR> the translation. I don't know if changing the behaviour of the EnumRenderer
MR> is a great plan, even though I feel like it should have shown a choicebox
MR> from the beginning. Of course it could simply take a flag to enable this
MR> new behaviour. A good example of a program that does this is using (auto)
MR> filters in excel or open office calc. It shows a dropdown box in the top
MR> cell of a column and you can pick filtering criteria in it. Quickbooks has
MR> a slightly different take on it and it shows the control only when that row
MR> is selected. I'd be happy with a few flags that allow either.
Maybe it would indeed make more sense to have a new wxGridCellChoiceRenderer.
Otherwise, what flags exactly would we need?
MR> Supposing I were to implement and submit it... I think the renderer is the
MR> first place to start. I'd subclass a stringrenderer. If the control should
MR> not be displayed unless it is selected
There is currently no difference in appearance between selected and
non-selected cells.
MR> then the Draw function is as easy as
MR> calling the base function. If it were selected I think I could simply do
MR> something like: wxRendererNative::Get().DrawChoice( &grid, dc, rect, flags
MR> ) and draw the text in after. On this point I'm not sure if there is a way
MR> to simple stick a wxChoice control in there. Not really sure if that's
MR> possible or not since wxChoice doesn't appear to have a Draw function.
No controls have Draw() methods, instead we have wxRendererNative class
which provides some primitives for drawing them. In this case you want to
use its DrawComboBoxDropButton() method.
Regards,
VZ
Michael Richards
Feb 3, 2014, 12:00:43 AM2/3/14
to wx-...@googlegroups.com
On Sunday, February 2, 2014 4:51:36 PM UTC-5, VZ wrote:
Maybe it would indeed make more sense to have a new wxGridCellChoiceRenderer.
Otherwise, what flags exactly would we need?
I sat down and started implementing it. Have a look at my 2 examples.
http://fastworks.com/staff/miker/grid.jpg
and
http://fastworks.com/staff/miker/grid1.jpg
The grid1.jpg is really busy looking whereas grid.jpg looks considerably cleaner to me. I'm not sure if we should make this decision for an end user so I suggest allowing a flag to show the control always, or only when selected.
MR> Supposing I were to implement and submit it... I think the renderer is the
MR> first place to start. I'd subclass a stringrenderer. If the control should
MR> not be displayed unless it is selected
There is currently no difference in appearance between selected and
non-selected cells.
See the flags idea above. The string renderer does display them differently if they're selected by applying a background colour. In the two images I posted I did not opt to draw the choicebox differently if it was selected. I looked at OpenOffice and Quickbooks to see how they displayed them. OpenOffice darkens the outline around it and Quickbooks does nothing. I don't know how we should deal with it. If I simply use the background colour for a selected cell then the user can decide what they like by setting the cell attributes.
MR> then the Draw function is as easy as
MR> calling the base function. If it were selected I think I could simply do
MR> something like: wxRendererNative::Get().DrawChoice( &grid, dc, rect, flags
MR> ) and draw the text in after. On this point I'm not sure if there is a way
MR> to simple stick a wxChoice control in there. Not really sure if that's
MR> possible or not since wxChoice doesn't appear to have a Draw function.
No controls have Draw() methods, instead we have wxRendererNative class
which provides some primitives for drawing them. In this case you want to
use its DrawComboBoxDropButton() method.
I have the renderer mostly done and working, but now looking at the editor it has a few annoying gotchas. If you click on the cell it does not display the editor, instead it just selects the cell. You have to click a second time to get the editor to work. Looking for consistency I found that OpenOffice and Excel both display the dropdown if you click on the button area of the cell to select it. I'm not really how how to best go about doing this.
Another interesting question, how should we deal with characters such as \t or \n appearing in the text? I believe normally in msw controls simply don't display them. I sort of feel this is the best way to deal with it. Throwing up an assert is most likely to cause issues when the data is pulled from a dynamic source such as a database and will simply offload the pain to the programmer. Is it acceptable for me to implement a wxChoice type interface? Essentially the editor is exactly one of those and I think it would be most consistent to provide the same to the user.
Another interesting question, how should we deal with characters such as \t or \n appearing in the text? I believe normally in msw controls simply don't display them. I sort of feel this is the best way to deal with it. Throwing up an assert is most likely to cause issues when the data is pulled from a dynamic source such as a database and will simply offload the pain to the programmer. Is it acceptable for me to implement a wxChoice type interface? Essentially the editor is exactly one of those and I think it would be most consistent to provide the same to the user.
Vadim Zeitlin
Feb 3, 2014, 8:48:23 AM2/3/14
to wx-...@googlegroups.com
On Sun, 2 Feb 2014 21:00:43 -0800 (PST) Michael Richards wrote:
MR> I sat down and started implementing it. Have a look at my 2 examples.
MR> http://fastworks.com/staff/miker/grid.jpg
MR> and
MR> http://fastworks.com/staff/miker/grid1.jpg
MR>
MR> The grid1.jpg is really busy looking whereas grid.jpg looks considerably
MR> cleaner to me. I'm not sure if we should make this decision for an end user
MR> so I suggest allowing a flag to show the control always, or only when
MR> selected.
The latter screenshot is really unacceptable IMO, so I don't think we
should do this and definitely not by default. The former one looks good in
this example but I wonder if we really should be drawing the cell like this
whenever it is selected or only when it is the current cell. It would seem
a bit weird if by just clicking in the corner of the grid you would change
the appearance of all the choice cells, by making the drop down buttons
appear in virtue of selecting them.
MR> > There is currently no difference in appearance between selected and
MR> > non-selected cells.
MR>
MR> See the flags idea above.
I actually forgot that we do have "isSelected" parameter in
wxGridCellRenderer::Draw(). So yes, we can do this. But I'm still not sure
if we should do this, or should only show the button for the "isCurrent"
cell.
MR> I have the renderer mostly done and working, but now looking at the editor
MR> it has a few annoying gotchas. If you click on the cell it does not display
MR> the editor, instead it just selects the cell. You have to click a second
MR> time to get the editor to work. Looking for consistency I found that
MR> OpenOffice and Excel both display the dropdown if you click on the button
MR> area of the cell to select it. I'm not really how how to best go about
MR> doing this.
This can be handled by overriding StartingKey() and StartingClick()
methods of the editor.
MR> Another interesting question, how should we deal with characters such as \t
MR> or \n appearing in the text? I believe normally in msw controls simply
MR> don't display them. I sort of feel this is the best way to deal with it.
It would seem natural that these special characters are handled in the
same way in the choice renderer as in the normal string renderer. And, in
fact, I think they should reuse the same code for actually displaying text
anyhow.
Editing them is different, as this can't be handled by a normal
wxComboBox, so I guess they should indeed be ignored there...
Regards,
VZ
MR> I sat down and started implementing it. Have a look at my 2 examples.
MR> http://fastworks.com/staff/miker/grid.jpg
MR> and
MR> http://fastworks.com/staff/miker/grid1.jpg
MR>
MR> The grid1.jpg is really busy looking whereas grid.jpg looks considerably
MR> cleaner to me. I'm not sure if we should make this decision for an end user
MR> so I suggest allowing a flag to show the control always, or only when
MR> selected.
The latter screenshot is really unacceptable IMO, so I don't think we
should do this and definitely not by default. The former one looks good in
this example but I wonder if we really should be drawing the cell like this
whenever it is selected or only when it is the current cell. It would seem
a bit weird if by just clicking in the corner of the grid you would change
the appearance of all the choice cells, by making the drop down buttons
appear in virtue of selecting them.
MR> > There is currently no difference in appearance between selected and
MR> > non-selected cells.
MR>
MR> See the flags idea above.
I actually forgot that we do have "isSelected" parameter in
wxGridCellRenderer::Draw(). So yes, we can do this. But I'm still not sure
if we should do this, or should only show the button for the "isCurrent"
cell.
MR> I have the renderer mostly done and working, but now looking at the editor
MR> it has a few annoying gotchas. If you click on the cell it does not display
MR> the editor, instead it just selects the cell. You have to click a second
MR> time to get the editor to work. Looking for consistency I found that
MR> OpenOffice and Excel both display the dropdown if you click on the button
MR> area of the cell to select it. I'm not really how how to best go about
MR> doing this.
This can be handled by overriding StartingKey() and StartingClick()
methods of the editor.
MR> Another interesting question, how should we deal with characters such as \t
MR> or \n appearing in the text? I believe normally in msw controls simply
MR> don't display them. I sort of feel this is the best way to deal with it.
It would seem natural that these special characters are handled in the
same way in the choice renderer as in the normal string renderer. And, in
fact, I think they should reuse the same code for actually displaying text
anyhow.
Editing them is different, as this can't be handled by a normal
wxComboBox, so I guess they should indeed be ignored there...
Regards,
VZ
Michael Richards
Feb 3, 2014, 10:01:55 AM2/3/14
to wx-...@googlegroups.com
On Monday, February 3, 2014 8:48:23 AM UTC-5, VZ wrote:
On Sun, 2 Feb 2014 21:00:43 -0800 (PST) Michael Richards wrote:
MR> I sat down and started implementing it. Have a look at my 2 examples.
MR> http://fastworks.com/staff/miker/grid.jpg
MR> and
MR> http://fastworks.com/staff/miker/grid1.jpg
MR>
MR> The grid1.jpg is really busy looking whereas grid.jpg looks considerably
MR> cleaner to me. I'm not sure if we should make this decision for an end user
MR> so I suggest allowing a flag to show the control always, or only when
MR> selected.
The latter screenshot is really unacceptable IMO, so I don't think we
should do this and definitely not by default. The former one looks good in
this example but I wonder if we really should be drawing the cell like this
whenever it is selected or only when it is the current cell. It would seem
a bit weird if by just clicking in the corner of the grid you would change
the appearance of all the choice cells, by making the drop down buttons
appear in virtue of selecting them.
Our ideas were consistent on not showing the dropdown in an unselected field. I did ask a friend and GUI designer for his opinion and he did bring up an interesting counter-point. Part of good GUI design is making it intuitive and if you don't show at least some visual indicator that a field is in fact a drop-down, you've got a poor GUI design. In my case it works only because I've got it set to select the entire row when you click on it. The suggestion I got was that the default drawing of an unselected cell could be done lighter so it is still evident to the user that it is in fact a dropdown. I have no formal GUI design education so I've been relying on looking at what the "professionals do". The excel/openoffice examples I've been quoting do not select by row and do show the controls. The Quickbooks example I quote does select by row. I'll try to keep an eye out for more examples and see what "they do". At this point, taking my friend's expertise into consideration I think we probably should always show the controls.
Here is the suggestion of my friend. I think we should do this. I can set this up as a flag so we can have both types of functionality and keep both camps happy.
http://fastworks.com/staff/miker/grid2.jpg
This can be handled by overriding StartingKey() and StartingClick()
methods of the editor.
So if you click on the cell with the dropdown it will display the editor rather than having to click on it twice.
MR> Another interesting question, how should we deal with characters such as \t
MR> or \n appearing in the text? I believe normally in msw controls simply
MR> don't display them. I sort of feel this is the best way to deal with it.
It would seem natural that these special characters are handled in the
same way in the choice renderer as in the normal string renderer. And, in
fact, I think they should reuse the same code for actually displaying text
anyhow.
If we do, then there really is no standard way to display an inactive dropdown selection in a multi-line item. I tried to do it in photoshop to see what it could look like but it looked weird.
http://fastworks.com/staff/miker/grid3.jpg
I think ignoring the control chars in both cases is the right thing to do.
Editing them is different, as this can't be handled by a normal
wxComboBox, so I guess they should indeed be ignored there...
I'll do this.
-Michael
Vadim Zeitlin
Feb 3, 2014, 11:32:41 AM2/3/14
to wx-...@googlegroups.com
On Mon, 3 Feb 2014 07:01:55 -0800 (PST) Michael Richards wrote:
MR> Our ideas were consistent on not showing the dropdown in an unselected
MR> field. I did ask a friend and GUI designer for his opinion and he did bring
MR> up an interesting counter-point. Part of good GUI design is making it
MR> intuitive and if you don't show at least some visual indicator that a field
MR> is in fact a drop-down, you've got a poor GUI design.
I disagree with this. IMO it's not very important to show that a field is
a drop down until you get to editing it. Besides, suppose it's a combobox
editor (i.e. you can select one of the existing entries or add a new one).
Then it's semantically exactly the same as a simple text field, the
combobox is just for convenience. Should the choice editor really look
different?
MR> In my case it works only because I've got it set to select the entire
MR> row when you click on it. The suggestion I got was that the default
MR> drawing of an unselected cell could be done lighter so it is still
MR> evident to the user that it is in fact a dropdown. I have no formal GUI
MR> design education so I've been relying on looking at what the
MR> "professionals do". The excel/openoffice examples I've been quoting do
MR> not select by row and do show the controls. The Quickbooks example I
MR> quote does select by row. I'll try to keep an eye out for more examples
MR> and see what "they do". At this point, taking my friend's expertise
MR> into consideration I think we probably should always show the controls.
MR>
MR> Here is the suggestion of my friend. I think we should do this. I can set
MR> this up as a flag so we can have both types of functionality and keep both
MR> camps happy.
MR> http://fastworks.com/staff/miker/grid2.jpg
I think this looks really distracting and also, at least to me, very
unusual. I'd like to see a screenshot of Excel examples, while I'm
absolutely not an Excel expert, I do see Excel spreadsheets from time to
time and I've never seen anything like this.
Anyhow, wxGrid is flexible enough to make it easy to use custom renderers
with it so I think there is no problem if you want to use something like
this in your program, is there? As for wxWidgets, I think the really useful
thing would be to have a more flexible and more convenient editor, so maybe
we should start with this and leave the renderer alone...
MR> > This can be handled by overriding StartingKey() and StartingClick()
MR> > methods of the editor.
MR>
MR> So if you click on the cell with the dropdown it will display the editor
MR> rather than having to click on it twice.
Yes.
Regards,
VZ
MR> Our ideas were consistent on not showing the dropdown in an unselected
MR> field. I did ask a friend and GUI designer for his opinion and he did bring
MR> up an interesting counter-point. Part of good GUI design is making it
MR> intuitive and if you don't show at least some visual indicator that a field
MR> is in fact a drop-down, you've got a poor GUI design.
I disagree with this. IMO it's not very important to show that a field is
a drop down until you get to editing it. Besides, suppose it's a combobox
editor (i.e. you can select one of the existing entries or add a new one).
Then it's semantically exactly the same as a simple text field, the
combobox is just for convenience. Should the choice editor really look
different?
MR> In my case it works only because I've got it set to select the entire
MR> row when you click on it. The suggestion I got was that the default
MR> drawing of an unselected cell could be done lighter so it is still
MR> evident to the user that it is in fact a dropdown. I have no formal GUI
MR> design education so I've been relying on looking at what the
MR> "professionals do". The excel/openoffice examples I've been quoting do
MR> not select by row and do show the controls. The Quickbooks example I
MR> quote does select by row. I'll try to keep an eye out for more examples
MR> and see what "they do". At this point, taking my friend's expertise
MR> into consideration I think we probably should always show the controls.
MR>
MR> Here is the suggestion of my friend. I think we should do this. I can set
MR> this up as a flag so we can have both types of functionality and keep both
MR> camps happy.
MR> http://fastworks.com/staff/miker/grid2.jpg
I think this looks really distracting and also, at least to me, very
unusual. I'd like to see a screenshot of Excel examples, while I'm
absolutely not an Excel expert, I do see Excel spreadsheets from time to
time and I've never seen anything like this.
Anyhow, wxGrid is flexible enough to make it easy to use custom renderers
with it so I think there is no problem if you want to use something like
this in your program, is there? As for wxWidgets, I think the really useful
thing would be to have a more flexible and more convenient editor, so maybe
we should start with this and leave the renderer alone...
MR> > This can be handled by overriding StartingKey() and StartingClick()
MR> > methods of the editor.
MR>
MR> So if you click on the cell with the dropdown it will display the editor
MR> rather than having to click on it twice.
Yes.
Regards,
VZ
Michael Richards
Feb 3, 2014, 1:24:21 PM2/3/14
to wx-...@googlegroups.com
On Monday, February 3, 2014 11:32:41 AM UTC-5, VZ wrote:
On Mon, 3 Feb 2014 07:01:55 -0800 (PST) Michael Richards wrote:
MR> Our ideas were consistent on not showing the dropdown in an unselected
MR> field. I did ask a friend and GUI designer for his opinion and he did bring
MR> up an interesting counter-point. Part of good GUI design is making it
MR> intuitive and if you don't show at least some visual indicator that a field
MR> is in fact a drop-down, you've got a poor GUI design.
I disagree with this. IMO it's not very important to show that a field is
a drop down until you get to editing it. Besides, suppose it's a combobox
editor (i.e. you can select one of the existing entries or add a new one).
Then it's semantically exactly the same as a simple text field, the
combobox is just for convenience. Should the choice editor really look
different?
I'm not a GUI expert. I'll quote what my friend says:
That's a classic case of poor design. One of the basic principles states "Make objects that act differently look different." Nielsen said that 25 years ago and its still true today. In your case the selection acts differently than a text entry item so the above applies. Having said this, poor GUI designs are common and in fact one of the reasons the faculty developed curriculum to address it.
MR> Here is the suggestion of my friend. I think we should do this. I can set
MR> this up as a flag so we can have both types of functionality and keep both
MR> camps happy.
MR> http://fastworks.com/staff/miker/grid2.jpg
I think this looks really distracting and also, at least to me, very
unusual. I'd like to see a screenshot of Excel examples, while I'm
absolutely not an Excel expert, I do see Excel spreadsheets from time to
time and I've never seen anything like this.
This is in fact why I'm interested in allowing a flag to control the behavior. It adds almost 0 bloat to the code as the base class implements the other display methods.
http://fastworks.com/staff/miker/grid-oo.jpg
That one is out of open office. Excel has something similar. Many components are modeled after this.
http://www.loaditup.de/files/490649.jpg
http://www.devmachines.com/productdocs/grid/images/gridrelationdemo.png
http://www.java2s.com/Code/JavaImages/ComboBoxTable.PNG
http://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/qtableitems.png
Anyhow, wxGrid is flexible enough to make it easy to use custom renderers
with it so I think there is no problem if you want to use something like
this in your program, is there? As for wxWidgets, I think the really useful
thing would be to have a more flexible and more convenient editor, so maybe
we should start with this and leave the renderer alone...
I kind of feel like this is giving us a useful editor without the proper way to display it. You are 100% correct that anyone can sit down and implement this themselves, but sometimes I feel the point of a toolkit should be to allow the user to create the interactive items themselves without having to hand code everything. I really prefer the speed and native interfaces
Michael Richards
Feb 3, 2014, 1:29:34 PM2/3/14
to wx-...@googlegroups.com
Aha, flash crashed and I thought an hour of responding had just been wasted.
Only one small thing to add. The advantages of wx for me are that it runs faster and looks more native. The advantages of QT is that you're productive. It's hard to justify not switching to QT when it takes me an entire morning to write and debug a component and my co-worker does the same thing in QT in under 3 minutes. I think if you use google images to look for "TableView Combobox" you will see hundreds of examples where it is used, so this is a feature that would be helpful for the library to have. If you want the Renderer then I'll spend the time to document and submit it. Same goes with the Editor.
-Michael
Only one small thing to add. The advantages of wx for me are that it runs faster and looks more native. The advantages of QT is that you're productive. It's hard to justify not switching to QT when it takes me an entire morning to write and debug a component and my co-worker does the same thing in QT in under 3 minutes. I think if you use google images to look for "TableView Combobox" you will see hundreds of examples where it is used, so this is a feature that would be helpful for the library to have. If you want the Renderer then I'll spend the time to document and submit it. Same goes with the Editor.
-Michael
Vadim Zeitlin
Feb 3, 2014, 1:33:02 PM2/3/14
to wx-...@googlegroups.com
On Mon, 3 Feb 2014 10:24:21 -0800 (PST) Michael Richards wrote:
MR> I'm not a GUI expert. I'll quote what my friend says:
MR>
MR> That's a classic case of poor design. One of the basic principles states
MR> "Make objects that act differently look different." Nielsen said that 25
MR> years ago and its still true today.
Yes, it is definitely true. I just feel that it's irrelevant here because
the objects don't really act differently at all. They are both text strings
and how you edit them is not that important. Showing the difference between
boolean and string or dates and strings is more important (currently we do
the former but not the latter) IMO, because they are really different.
Those are not.
MR> In your case the selection acts differently than a text entry item so
MR> the above applies.
If we start by assuming the thing which is in doubt (whether they act
differently), it's easy to arrive to the desired conclusion, yes :-)
MR> This is in fact why I'm interested in allowing a flag to control the
MR> behavior. It adds almost 0 bloat to the code as the base class implements
MR> the other display methods.
MR>
MR> http://fastworks.com/staff/miker/grid-oo.jpg
Yes, I understand this one... It really does act differently from a normal
cell because it can be changed to resort the table (AFAIU). So yes, showing
the buttons definitely does help here. And, consequently, such a renderer
would be useful at least in some situations.
MR> That one is out of open office. Excel has something similar. Many
MR> components are modeled after this.
MR> http://www.loaditup.de/files/490649.jpg
MR> http://www.devmachines.com/productdocs/grid/images/gridrelationdemo.png
MR> http://www.java2s.com/Code/JavaImages/ComboBoxTable.PNG
MR> http://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/qtableitems.png
Err, exactly half of those (devmachines and java2s ones) actually don't
show the drop down for inactive items, i.e. seem to contradict your point.
But, anyhow, if there is really a strong desire to have such a renderer in
wxGrid -- why not, let's add it.
Regards,
VZ
MR> I'm not a GUI expert. I'll quote what my friend says:
MR>
MR> That's a classic case of poor design. One of the basic principles states
MR> "Make objects that act differently look different." Nielsen said that 25
MR> years ago and its still true today.
Yes, it is definitely true. I just feel that it's irrelevant here because
the objects don't really act differently at all. They are both text strings
and how you edit them is not that important. Showing the difference between
boolean and string or dates and strings is more important (currently we do
the former but not the latter) IMO, because they are really different.
Those are not.
MR> In your case the selection acts differently than a text entry item so
MR> the above applies.
If we start by assuming the thing which is in doubt (whether they act
differently), it's easy to arrive to the desired conclusion, yes :-)
MR> This is in fact why I'm interested in allowing a flag to control the
MR> behavior. It adds almost 0 bloat to the code as the base class implements
MR> the other display methods.
MR>
MR> http://fastworks.com/staff/miker/grid-oo.jpg
Yes, I understand this one... It really does act differently from a normal
cell because it can be changed to resort the table (AFAIU). So yes, showing
the buttons definitely does help here. And, consequently, such a renderer
would be useful at least in some situations.
MR> That one is out of open office. Excel has something similar. Many
MR> components are modeled after this.
MR> http://www.loaditup.de/files/490649.jpg
MR> http://www.devmachines.com/productdocs/grid/images/gridrelationdemo.png
MR> http://www.java2s.com/Code/JavaImages/ComboBoxTable.PNG
MR> http://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/qtableitems.png
Err, exactly half of those (devmachines and java2s ones) actually don't
show the drop down for inactive items, i.e. seem to contradict your point.
But, anyhow, if there is really a strong desire to have such a renderer in
wxGrid -- why not, let's add it.
Regards,
VZ
Michael Richards
Feb 3, 2014, 2:20:31 PM2/3/14
to wx-...@googlegroups.com
On Monday, February 3, 2014 1:33:02 PM UTC-5, VZ wrote:
On Mon, 3 Feb 2014 10:24:21 -0800 (PST) Michael Richards wrote:
MR> I'm not a GUI expert. I'll quote what my friend says:
MR>
MR> That's a classic case of poor design. One of the basic principles states
MR> "Make objects that act differently look different." Nielsen said that 25
MR> years ago and its still true today.
Yes, it is definitely true. I just feel that it's irrelevant here because
the objects don't really act differently at all. They are both text strings
and how you edit them is not that important. Showing the difference between
boolean and string or dates and strings is more important (currently we do
the former but not the latter) IMO, because they are really different.
Those are not.
One could make the argument that a boolean is simply a 0 or a 1 and thus should not have its own editor/render either. The point of a choicebox was to allow the user to pick one of the items, while a text entry field was to allow them to add text. The existing enum editor falls short because it only allows you to use items numbered from 0-n. My proposed solution was to allow a key->value arrangement that could do everything an enum does and more. The idea of the renderer was to visually show the user that the item could be clicked on and changed.
MR> That one is out of open office. Excel has something similar. Many
MR> components are modeled after this.
MR> http://www.loaditup.de/files/490649.jpg
MR> http://www.devmachines.com/productdocs/grid/images/gridrelationdemo.png
MR> http://www.java2s.com/Code/JavaImages/ComboBoxTable.PNG
MR> http://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/qtableitems.png
Err, exactly half of those (devmachines and java2s ones) actually don't
show the drop down for inactive items, i.e. seem to contradict your point.
Not at all. My point with the renderer is that I'd like a flag to control this behaviour because it is useful. When the grid has a row only selection type then it is not as necessary to clutter the screen with the dropdown control. When individual cells are selectable it is necessary, otherwise the user may never know that the cell is non-static and when clicked on will become a dropdown box. GUI people call this the invisible control syndrome.
But, anyhow, if there is really a strong desire to have such a renderer in
wxGrid -- why not, let's add it.
I used up all the time budgeted for this :( I'll try to do it on my own time in the next few weeks.
-Michael
Reply all
Reply to author
Forward
0 new messages