<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>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.</div>
<div> </div>
<div> </div>
<div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Christof</div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Samstag, 15. Juni 2019 um 19:58 Uhr<br/>
<b>Von:</b> "Henri Augusto Bisognini" <msndohenri@hotmail.com><br/>
<b>An:</b> "pd-dev@lists.iem.at" <pd-dev@lists.iem.at><br/>
<b>Betreff:</b> Re: [PD-dev] First complete keyboard navigation prototype</div>
<div name="quoted-content"><!--P {
margin-top: 0;
margin-bottom: 0;
}
-->
<div>
<div style="font-family: Calibri , Helvetica , sans-serif;font-size: 12.0pt;color: rgb(0,0,0);">Please excuse my ignorance on that matter but could you give me a brief explanation of the problem at hand?</div>
<div>
<div id="appendonsend"> </div>
<div style="font-family: Calibri , Helvetica , sans-serif;font-size: 12.0pt;color: rgb(0,0,0);"> </div>
<hr style="display: inline-block;width: 98.0%;"/>
<div id="divRplyFwdMsg"><font color="#000000" face="Calibri, sans-serif" style="font-size: 11.0pt;"><b>De:</b> Pd-dev <pd-dev-bounces@lists.iem.at> em nome de IOhannes m zmölnig <zmoelnig@iem.at><br/>
<b>Enviado:</b> sexta-feira, 14 de junho de 2019 04:37<br/>
<b>Para:</b> pd-dev@lists.iem.at<br/>
<b>Assunto:</b> Re: [PD-dev] First complete keyboard navigation prototype</font>
<div> </div>
</div>
<div class="BodyFragment">
<div class="PlainText"><font size="2"><span style="font-size: 11.0pt;">On 6/13/19 7:34 PM, Henri Augusto Bisognini wrote:<br/>
> 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.<br/>
><br/>
<br/>
i haven't looked at the actual code, but what you describe here, is that<br/>
you are actually changing the size of a quasi-public struct and thus the<br/>
memory layout as presented to externals.<br/>
<br/>
which means that a version of Pd that has the keyboard-navigation<br/>
enabled is (partly) *binary-incompatible* with a version of Pd that does<br/>
not have the keyboard-navigation enabled.<br/>
<br/>
bummer :-(<br/>
<br/>
gfmadr<br/>
IOhannes</span></font><br/>
</div>
</div>
</div>
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at <a href="https://lists.puredata.info/listinfo/pd-dev" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a></div>
</div>
</div>
</div>
</div></div></body></html>