alternative to wxPropertyGrid
Andrew Trevorrow
can't see all of a long rule/pattern description. There are
other problems:
- It requires wx 2.9+. I'd much rather use my existing 2.8.12
version I use to build Golly on Win XP. I did try using 2.9.1
for Golly but ran into a couple of weird problems (will supply
details if anybody is interested) so went back to 2.8.12.
- More serious is the cosmetic bugs I'm seeing in Ready.
For example, if I click on a value box, edit it, then hit return,
I see remnants of the focus ring left behind. These are probably
Mac-only bugs. Maybe they are easy to fix, maybe not.
Here's a possible alternative to using wxPropertyGrid:
Make the Rule/Properties pane look more like the Help pane.
That is, we dynamically build a page of html data for displaying
all the current settings in a nicely formatted table.
(The HtmlView class could be pulled out of HelpPanel.cpp and
put in separate .hpp/cpp files for re-use.)
To edit these settings the user clicks on a "Change Properties"
button at the top of the pane (like "Contents" in Help pane).
This would bring up a Preferences-like dialog box with
multiple tabs for Rule, Render, Color, Overlay, etc.
The nice thing about this alternative is that it uses wx stuff
we know works well on all platforms.
Andrew
Tim Hutton
On 1 February 2012 12:08, Andrew Trevorrow <and...@trevorrow.com> wrote:
> As Tim mentioned, a big problem with wxPropertyGrid is that we
> can't see all of a long rule/pattern description.
(Looking at the propgrid demo it seems possible that this is a design
decision - click the 'Examples' button and then change the 'Variable
Height Bitmaps'. Only those that fit are drawn. If it's a design
decision true of property grids everywhere then maybe it is something
we should respect, to avoid breaking users' expectations of how
property grids work.)
If custom properties don't work then maybe we can just put
wxStaticText and wxTextCtrl items in a grid sizer to make our own
ersatz property grid. It would let us control the heights.
A workaround might even be more elegant. For example, a complete
beginner might want to see the description of each rule but not want
to be bothered by the technical details, so a separate pane for the
description would work well. More technical users can leave that
'Description Pane' open if they want but can otherwise use the
existing Rule Pane. And if the Description Pane could be like a Help
page and include links to other patterns and websites then that would
be really useful - I'm already wanting that functionality to describe
some of our patterns.
> There are
> other problems:
>
> - It requires wx 2.9+. I'd much rather use my existing 2.8.12
> version I use to build Golly on Win XP. I did try using 2.9.1
> for Golly but ran into a couple of weird problems (will supply
> details if anybody is interested) so went back to 2.8.12.
I've got multiple versions installed on my Windows and Linux boxes,
it's just a matter of telling ccmake or cmake-gui which one to use.
Something similar must be possible on MacOS?
(I recently had problems with the Windows build of Ready using
wx2.9.3. Turned out (r456) that our nmake command isn't always
appropriate and I would get lots of cryptic link errors. I mention
this just in case the issue with Golly and wx2.9 is related.)
> - More serious is the cosmetic bugs I'm seeing in Ready.
> For example, if I click on a value box, edit it, then hit return,
> I see remnants of the focus ring left behind. These are probably
> Mac-only bugs. Maybe they are easy to fix, maybe not.
I don't see that focus ring issue on Windows or Linux. Do you see it
in the propgrid sample?
I've just discovered that since r452 I've been unable to edit the rule
description and pattern description via the "..." button on Windows. I
can't see what would have caused that. I'm working to understand this
at the moment. It still works on Linux.
In checking the above paragraph I've also discovered that Ready's quit
button doesn't work on Linux while a property grid edit box has focus.
It is fine in Windows.
Neither of these issues appears in the propgrid sample on either OS,
so we've obviously done something wrong somehow.
> Here's a possible alternative to using wxPropertyGrid:
>
> Make the Rule/Properties pane look more like the Help pane.
> That is, we dynamically build a page of html data for displaying
> all the current settings in a nicely formatted table.
> (The HtmlView class could be pulled out of HelpPanel.cpp and
> put in separate .hpp/cpp files for re-use.)
>
> To edit these settings the user clicks on a "Change Properties"
> button at the top of the pane (like "Contents" in Help pane).
> This would bring up a Preferences-like dialog box with
> multiple tabs for Rule, Render, Color, Overlay, etc.
For myself, I would prefer we stick with something that supports
in-place editing. I also think that having everything lined up in a
single scrollable table is nice - paradoxically it makes things easier
to find, since you can run your eye down a single line. (In old
versions of Visual Studio the project properties were all in scattered
controls in different tabs and it was a UI disaster. They have since
moved to a property grid.)
But I value cooperation over my preferences so I'm open to debate!
--
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/
Andrew Trevorrow
> If custom properties don't work then maybe we can just put
> wxStaticText and wxTextCtrl items in a grid sizer to make our own
> ersatz property grid. It would let us control the heights.
Yep, I'd prefer that to wxPropertyGrid.
> A workaround might even be more elegant. For example, a complete
> beginner might want to see the description of each rule but not want
> to be bothered by the technical details, so a separate pane for the
> description would work well. ...
I'd prefer to see all properties/settings in one (scrollable) pane.
> I've got multiple versions installed on my Windows and Linux boxes,
> it's just a matter of telling ccmake or cmake-gui which one to use.
> Something similar must be possible on MacOS?
Yep, multiple wx versions isn't the issue. It was easy to build
Golly on WinXP with wx 2.9 -- I just wasn't happy with the resulting
exe, so I uninstalled 2.9. I can put it back for building Ready
(it's just mildly annoying to have to do it only for wxPropertyGrid).
> I don't see that focus ring issue on Windows or Linux. Do you see it
> in the propgrid sample?
Yep, this is a Mac-only bug I've seen in other wx controls. When a
wxTextCtrl gets focus you see a fuzzy blue border around the *outside*
of the box. When it loses focus the border should disappear, but in
Ready's case (and the propgrid sample) some thin blue lines remain.
Probably easy to work around by a suitable Refresh() in the right
place.
> I've just discovered that since r452 I've been unable to edit the rule
> description and pattern description via the "..." button on Windows. I
> can't see what would have caused that. I'm working to understand this
> at the moment. It still works on Linux.
>
> In checking the above paragraph I've also discovered that Ready's quit
> button doesn't work on Linux while a property grid edit box has focus.
> It is fine in Windows.
>
> Neither of these issues appears in the propgrid sample on either OS,
> so we've obviously done something wrong somehow.
Sigh, they sound like problems due to MyFrame::CheckFocus().
This is called in OnIdle to ensure that when our frame window
is active then either one of our panes has focus, or a text ctrl
in the rule pane has focus. This ensures keyboard shortcuts
work correctly at all times. Without CheckFocus() I found that
other controls could get focus (eg. clicking on a disabled toolbar
item) and then I would have to click elsewhere before being able
to use my keyboard shortcuts.
CheckFocus works fine in the Mac Ready (none of the above problems)
but isn't critical so feel free to comment out the call in OnIdle
or put it in an ifdef __WXMAC__ block.
>> To edit these settings the user clicks on a "Change Properties"
>> button at the top of the pane (like "Contents" in Help pane).
>> This would bring up a Preferences-like dialog box with
>> multiple tabs for Rule, Render, Color, Overlay, etc.
>
> For myself, I would prefer we stick with something that supports
> in-place editing.
True, that's the biggest advantage of using wxPropertyGrid
(or wxGrid).
> I also think that having everything lined up in a
> single scrollable table is nice ...
Well you still get that if the html data displays everything in
a nicely formatted 2-column table.
Here's another variant of my suggestion that might be nicer.
Still display all the settings in a table using html, but
each item in the left column would be a special clickable link
that brings up a simple dialog for editing that item's value.
(Our OnLinkClicked code could check for a special urls like
"change:dimensions" or "change:rule_description".)
Still not as convenient as in-place editing but probably nicer
than using a "Change Properties" button that brings up a
complicated multi-tab dialog.
Anyway, I think you should go for what *you* feel is best.
You'll be doing most of the implementing. :) Maybe try the
wxGrid approach first and see how that looks.
Andrew
Tim Hutton
>> I don't see that focus ring issue on Windows or Linux. Do you see it
>> in the propgrid sample?
>
> wxTextCtrl gets focus you see a fuzzy blue border around the *outside*
> of the box. When it loses focus the border should disappear, but in
> Ready's case (and the propgrid sample) some thin blue lines remain.
> Probably easy to work around by a suitable Refresh() in the right
> place.
Is there a bug ticket for this issue do you know? Is is it a problem
in 2.8 too? Is it just a Cocoa issue? Does it affect all wxTextCtrl
items or just the wxPropertyGrid ones? Are there other Mac problems?
Wondering about the health of wxWidgets on MacOS, basically.
>> I've just discovered that since r452 I've been unable to edit the rule
>> description and pattern description via the "..." button on Windows. I
>> can't see what would have caused that. I'm working to understand this
>> at the moment. It still works on Linux.
>>
>> In checking the above paragraph I've also discovered that Ready's quit
>> button doesn't work on Linux while a property grid edit box has focus.
>> It is fine in Windows.
>>
>> Neither of these issues appears in the propgrid sample on either OS,
>> so we've obviously done something wrong somehow.
>
> Sigh, they sound like problems due to MyFrame::CheckFocus().
> This is called in OnIdle to ensure that when our frame window
> is active then either one of our panes has focus, or a text ctrl
> in the rule pane has focus. This ensures keyboard shortcuts
> work correctly at all times. Without CheckFocus() I found that
> other controls could get focus (eg. clicking on a disabled toolbar
> item) and then I would have to click elsewhere before being able
> to use my keyboard shortcuts.
>
> CheckFocus works fine in the Mac Ready (none of the above problems)
> but isn't critical so feel free to comment out the call in OnIdle
> or put it in an ifdef __WXMAC__ block.
Thanks. r463 fixes the Windows problem but I still have the Linux
quit-button issue.
Another problem discovered too, probably related to the recent
accelerator changes: the letter 'w' doesn't get through to the text
controls in the property grid. Is there a reason we can't use
wxWidgets own accelerator support for our accelerator keys?
While I'm asking, I'm also not clear why wxFileConfig was rejected.
I'm sure there are good reasons based on your experience with Golly
but I don't know what they are.
> Anyway, I think you should go for what *you* feel is best.
> You'll be doing most of the implementing. :) Maybe try the
> wxGrid approach first and see how that looks.
If we can resolve the multi-line text and blue border issues as sounds
likely then for now I'm inclined to keep using wxPropertyGrid. I might
have quick peek at what the homebrew grid approach would look like.
Possibly it's unavoidably ugly hence the need for wxPropertyGrid.