← Back to team overview

kicad-developers team mailing list archive

Re: A few questions about preferences

 

Thanks, Orson, makes sense.  I didn’t see any other use of this helper and the other panels seem to contain these handlers, so I could only speculate about it.  You’re right, there’s no use of functions in EDA_DRAW_PANEL_GAL, I guess I was thinking about a case where the mouse prefs were hung off of EDA_DRAW_PANEL_GAL as they are in EDA_DRAW_PANEL.


Thanks, again,

Garth

On Oct 27, 2014, at 1:44 AM, Maciej Sumiński <maciej.suminski@xxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/27/2014 04:00 AM, Garth Corral wrote:
>> 
>> Hi guys,
>> 
>> I have a a few questions for someone more familiar with the code
>> than me.  Mostly about preferences, but also one random question
>> that has me scratching my head, bearing in mind that I’m not a C++
>> guy.  I’ll start with that one.
>> 
>> Is there a reason that WX_VIEW_CONTROLS coerces it’s aParentPanel
>> argument to its superclass type?  EDA_DRAW_PANEL_GAL instantiates
>> one of these and passes an instance of itself, but WX_VIEW_CONTROLS
>> coerces it to a wxWindow*.  This means casting is needed to get at
>> the subclass’ public members.   Again, I’m not a C++ guy, but I
>> couldn’t figure out the reason for this.
> 
> Hi Garth,
> 
> WX_VIEW_CONTROLS was written to work with any generic wxWindow. There
> is no casting to EDA_DRAW_PANEL_GAL as it uses only functions offered
> by wxWindow class.
> 
>> Another question about the current implementation.  I notice that
>> neither the EDA_DRAW_PANEL_GAL nor EDA_3D_CANVAS honor the mouse
>> preferences, e.g. middle button panning, and making them do so
>> essentially requires duplicating what is implemented for
>> EDA_DRAW_PANEL.  It seems like these preferences belong somewhere
>> else, like maybe EDA_DRAW_FRAME (or maybe there’s somewhere more
>> appropriate).  I guess my question is whether anyone has done any
>> work in this area or looked at it enough to have an opinion about
>> it.
> 
> It would be better if it was unified and specified in only one place.
> At first sight, EDA_DRAW_FRAME seems like a good candidate, but only
> for preferences that are common to every panel.
> 
> Another solution would be to provide a class that stores common
> preferences (e.g. EDA_PREFERENCES) and then other classes that extend
> it to provide settings specific to an application (e.g.
> EDA_PREFERENCES_PCBNEW).
> 
> I hope that one day we will use GAL exclusively, and the problem of
> separate settings will disappear.
> 
> Regards,
> Orson
> 
>> And finally, a more generic user level question spawned by the
>> above.  Given that kicad is migrating toward a more unified UI via
>> Kiway, is there a story for how preferences will be handled.
>> Currently, for instance, one has to go to the eeschema preferences
>> and the pcbnew preferences to change the same set of prefs for some
>> things.  Is there a plan to unify this in any way.  Seems like this
>> is complicated by the ability to run the applications standalone,
>> because the above makes perfect sense in that scenario.  If you
>> view these as part of the same application, though, it seems
>> cumbersome.  Just curious.
>> 
>> 
>> Thanks,
>> 
>> Garth
>> 
>> 
>> 
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~kicad-developers Post to     :
>> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>> https://launchpad.net/~kicad-developers More help   :
>> https://help.launchpad.net/ListHelp
>> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBAgAGBQJUTgXhAAoJEBRwGu1hpbJ1TJYIAKcZuXwkhgjqKvjKwvu2tHNr
> oiGyPO63fPmx29aBAz1AUHz8NhdgD88nq4Sn9LdmKJ10AsyKxlxKPuqShgUS2LSH
> c40wS+vQP2/CP0WalHf3xrkkE5Ye9I/dZ0tRn3xOf6ANCNL9UppmsUDwAG1GI5tt
> dJWCzqahcWDIvOyOu6Oln+n2woibUOoJE50+2O69QvBNSC/z63I4O2Hsl6j/cxqX
> fhhRZrcqk2lgghff8nc3m1JrVPxJ5elY97cug47DVLdg/yZHVq5NtVeSKX8b9IH3
> YIvZ2VKx715BLL2cbkIjoF8tdnzOeYYLxBr6iSXNo+jG3F1OHZD6VvdvhzH5Eng=
> =B2t8
> -----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME cryptographic signature


References