[PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Okay, just help me check if i got it right.

At first i was thinking that when externals, for any reason, used the size of the canvas struct (or any other) it would do so in real time. Like calling sizeof() and stuff.

But it appears that actually the size of the struct is deduced while compiling. So 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.

Is that it?

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.

(I don't have a formal background on programming so forgive me if thats obvious or something.)

________________________________
De: Christof Ressi <christof.ressi at gmx.at>
Enviado: sábado, 15 de junho de 2019 17:11
Para: Henri Augusto Bisognini
Cc: pd-dev at lists.iem.at
Assunto: Aw: Re: [PD-dev] First complete keyboard navigation prototype

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 at hotmail.com>
An: "pd-dev at lists.iem.at" <pd-dev at 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 at lists.iem.at> em nome de IOhannes m zmölnig <zmoelnig at iem.at>
Enviado: sexta-feira, 14 de junho de 2019 04:37
Para: pd-dev at 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 at lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190716/509ff98f/attachment.html>