Hi, as IOhannes said, "g_canvas.h" is semi-public in a sense that some externals use it (e.g. iemguts). So unless it is absolutely necessary, we should avoid breaking binary compatibility.
 
 
If the e_kbdnav member is only conditionally enabled with an #ifdef, existing externals (or those not compiled with key-nav-support) will see a different size of t_editor. This is not much of a problem as long as e_kbdnav is the last member of t_editor, but as soon as we add another member, we might run into problems, since this last field will be at a different offset.
 
I think the solution is simple: just add a "void *e_private" member which points to some private data where we can put all stuff which we don't want to expose the header. (This is called the "PIMPL idiom"). e_kbdnav would be the first member of such private data.
 
IOhannes actually did this with the "gl_privatedata" member in t_canvas to hide the undo queue implemention.  The "t_canvas_private" struct currently only has a "t_undo" member but it's possible to add/remove/rearrange members at will without having to think about binary compatibility issues because it's not in a header file.
 
Christof
Gesendet: Samstag, 15. Juni 2019 um 19:58 Uhr
Von: "Henri Augusto Bisognini" <msndohenri@hotmail.com>
An: "pd-dev@lists.iem.at" <pd-dev@lists.iem.at>
Betreff: Re: [PD-dev] First complete keyboard navigation prototype
Please excuse my ignorance on that matter but could you give me a brief explanation of the problem at hand?
 
 

De: Pd-dev <pd-dev-bounces@lists.iem.at> em nome de IOhannes m zmölnig <zmoelnig@iem.at>
Enviado: sexta-feira, 14 de junho de 2019 04:37
Para: pd-dev@lists.iem.at
Assunto: Re: [PD-dev] First complete keyboard navigation prototype
 
On 6/13/19 7:34 PM, Henri Augusto Bisognini wrote:
> Also, in g_canvas.h, inside the "struct _editor" there is a "struct _kbdnav" member. This is the struct that contains the data used in the keyboard navigation.
>

i haven't looked at the actual code, but what you describe here, is that
you are actually changing the size of a quasi-public struct and thus the
memory layout as presented to externals.

which means that a version of Pd that has the keyboard-navigation
enabled is (partly) *binary-incompatible* with a version of Pd that does
not have the keyboard-navigation enabled.

bummer :-(

gfmadr
IOhannes

 
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev