kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #15448
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