<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span>Okay, just help me check if i got it right.<br>
</span>
<div><br>
</div>
<div>At first i was thinking that when externals, for any reason, used the size of the canvas struct <span style="font-family: Calibri, Helvetica, sans-serif; background-color: rgb(255, 255, 255); display: inline !important">(or any other)</span> it would do
so in real time. Like calling sizeof() and stuff.<br>
</div>
<div><br>
</div>
<div>But it appears that actually the size of the struct is deduced <span style="font-family: Calibri, Helvetica, sans-serif; background-color: rgb(255, 255, 255); display: inline !important">
while compiling.<span> S</span></span>o if you write an external it is going to think the canvas struct is the same size as it was in the pd header files that were used during compilation.<br>
</div>
<div><br>
</div>
<div>Is that it?<br>
</div>
<div><br>
</div>
<span>I don't think i quite get something. When using the pointer to implementation idiom, wouldn't the pointer itself change the size of the struct? You've said something about that not being a problem when you add it as the last member of the struct but i
don't understand why and how that would work.</span><br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span>(I don't have a formal background on programming so forgive me if thats obvious or something.)</span></div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>De:</b> Christof Ressi <christof.ressi@gmx.at><br>
<b>Enviado:</b> sábado, 15 de junho de 2019 17:11<br>
<b>Para:</b> Henri Augusto Bisognini<br>
<b>Cc:</b> pd-dev@lists.iem.at<br>
<b>Assunto:</b> Aw: Re: [PD-dev] First complete keyboard navigation prototype</font>
<div> </div>
</div>
<div>
<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="x_quote" style="margin:10px 5px 5px 10px; padding:10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap:break-word">
<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="x_quoted-content">
<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="x_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="x_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="x_BodyFragment">
<div class="x_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>
</div>
</div>
</body>
</html>