Re: Custom Dialog Problems and Observations

On 25.04.2020 06:44, Lawrence Gray wrote:
> matter as they are all predetermined. But rather than having to revise 
> the list of properties and values manually, I was suggesting/hoping 
> for some way to move up/down the list with selectors or some other means.

You can use Ctrl+X, Ctrl+C, Ctrl+I, Ctrl+R to edit. I'm not sure whether 
a spin button or so would look nice.

Using "Code to be inserted after" is probably the easier way, though, as 
you can just copy and paste example code from the documentation and the 
demos.


> With regards to the sequence I have been using 
> Frame->sizer->panel->sizer.... except in this case of the speedmeter 
> where I started with what was provided. I notice that wxGlade-0,9,9pre 
> enforces the paradigm you suggested. No argument from me. I also noted 
> that the code generated by 0.9.9pre does

The new structure is not enforced. You still can use any combination you 
want:
     Frame -> sizer -> panel -> sizer
     Frame -> panel -> sizer     (this is the recommended way and 
available from the creation dialog)
     Frame -> sizer      (absolutely not recommended for Windows)
     Frame -> sizer - > Notebook     (a particularly ugly structure)
     Frame -> Notebook


> not include class functions __set_properties and __set_layout. 
> Everything is rolled up into the __init__ function. I am not a fan of 
> this style and I hope this is not a permanent change or have I missed 
> a toggle in the wxglade application to alter this behaviour. I like 
> the organization these class functions provide.

Have you ever created a GUI manually? I doubt that you have splitted it 
this way as it's almost impossible to read and maintain. Also it breaks 
the association of controls with their labels and therefore makes it 
difficult to use screen readers.
In addition, without the split it's possible to achieve almost anything 
with the "Code to be inserted" properties. With the split the results 
are more or less unpredictable.

I thought about a 'create_gui' and 'create_menu' method, but with these 
it's difficult for the user to see how the extra code properties are to 
be used. (Mainly because then the frame extra code would be in a 
different method.)

> I read in one of your replies on the issue trackers that you were 
> planning to provide, in v1.1, complete listing of event types in the 
> event panel. Are you considering the same for all available properties 
> for widgets? I'm sure you have.
>
I don't have such plans. I would accept a pull request, though. This 
would require someone to extend the wconfig.py files with lists of 
supported properties. Then, a dir(widget) minus the supported properties 
could be shown for the user to select. Maybe together with a help button 
to open the wxPython documentation.

My focus for 1.0 is the internal structure. For 1.1 Undo and Re-do are 
on the list and most likely the event editor. With the events, the 
difficult part is to find a proper structure / grouping such that the 
user is able to find the relevant events without being overwhelmed by 
the sheer number of available events.


Regards,

Dietmar

_______________________________________________
wxGlade-general mailing list
wxGlade-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/wxglade-general