Hey John,
I merged your patch set as is for now. We can change this in the future
should we decide it makes sense. wxSizerFlags::GetDefaultBorder() looks
interesting. Maybe we should be using it instead of the hard coded 5.
It does make yet one more argument for coding dialogs by hand unless
Hi Wayne,
In wxSizer, there is an option to use the "default border", which is
preferred to hardcoding a pixel value. This is preferred
apparently[1]. The WX method to do this,
wxSizerFlags::GetDefaultBorder(), is here.[2] (GNOME-HIG compliant 6px
on GTK, 5px on OSX, scaled otherwise).
If we
Hi Wayne,
I know the policy is not to convert wxFB dialogs, but in this case, I
don't see how that dialog could be written neatly in wxFB without
having the derived class tear half of the components down again if
m_read_only is true. The alternative is to duplicate the entire
dialog, which is a
John,
Your patch set looks good and works as advertised. I have a few
nit-pick comments.
I personally prefer making the hotkey list panel hard coded as you did
rather than using wxFB but not all developers share my preference in
this regard. Since this makes the hotkey list panel more
Hi,
Here's a screenshot of the list widget this creates.
I also forgot to mention that this also allows to remove the
"InstallOnPanel" workaround to installing the custom hotkey widget on
the wxFB panel's placeholder panel.
Cheers,
John
On Wed, Oct 3, 2018 at 4:20 PM John Beard wrote:
>
> Hi,
Hi,
Here is a patch sequence for using the hotkey editor widget in a
read-only mode to provide a filterable (and slightly prettier) hotkey
list. This is a 5.1 milestone.
Major details other than the main aim of the list widget:
* There are some "common UI" elements introduced here that should
6 matches
Mail list logo
