Hi,
> Also this value will be set manually in the code or is there anyway to set it via some config file/some other way?
here's what you usually do:
#ifndef HAVE_KEYBOARDNAV
#define HAVE_KEYBOARDNAV 0 /* pick your default value */
#endif
This makes sure that HAVE_KEYBOARDNAV is always set to a value, but you can override it at compile time by adding "-DHAVE_KEYBOARDNAV " to the preprocessor flags. Since we're using autotools, you (or someone else :-) would also add an option to "configure", e.g. "--enable-keyboardnav" and "--disable-keyboardnav".
> What should i do? Change those methods so they're not static anymore?
That's totally fine! Making it non-static just means that other implementation files can use it by forward declaring it (we do this quite a bit in Pd). In your case, you can add the declaration to your header file. Note that there's a risk that evil Pd external developers will find it, so better add a big disclaimer that the implementation may change anytime :-)
> By the way i wanted to hear more from you guys about the experience when trying the kbdnav prototype! :) Almost no one commented.
To be honest, I forgot about it because I got sucked up in other things, but I'll try it out when I have time! Thanks for the reminder!
Christof
Gesendet: Dienstag, 20. August 2019 um 05:07 Uhr
Von: "Henri Augusto Bisognini"
An: "pd-...@lists.iem.at"
Betreff: Re: [PD-dev] First complete keyboard navigation prototype
Thanks a lot for your input Christof!
If i may let me ask a couple of question:
1) I've been wandering through the sources and i'm not sure: where should i put the "#def HAVE_KEYBOARDNAV"? Also this value will be set manually in the code or is there anyway to set it via some config file/some other way?
___
2) Also i've put a big portion of the code in a g_kbdnav.c file a long with it's forward declarations in g_kbdnav.h.
Why it was in g_editor? Because it uses canvas_connect_with_undo, for example, which is static.
What should i do? Change those methods so they're not static anymore?
Or maybe put a "helper function" inside g_editor.c?
in g_editor.c:
void kbdnav_connect_with_undo(t_canvas *x, t_float index1, t_float outno, t_float index2, t_float inno){
connect_with_undo(x, index1,outno, index2, inno);
}
in g_kbdnav.c:
[...]
kbdnav_connect_with_undo(...)
[...]
Or should i do something else?
___
By the way i wanted to hear more from you guys about the experience when trying the kbdnav prototype! :)
Almost no one commented.
Best,
Henri.
From: Christof Ressi
Hi,
> 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.
exactly.
> When using the pointer to implementation idiom, wouldn't the pointer itself change the size of the struct?
yes, it will
> 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.
usually, externals shouldn't care about the *size* the t_editor struct (at least I can't think of any use case), so you can get away with adding new fields at the end (although it's certainly not recommended). Note that those headers aren't really public anyway!
However, appending fields conditionally can lead to problems:
struct Foo {
int a;
#ifdef FOO_EX
int c;
#endif
};
Now let's say we need to add another member:
struct Foo {
int a;
#ifdef FOO_EX
int c;
#endif
in b;
};
If the host compiles with FOO_EX defined and the client doesn't, the latter will assume a wrong offset for 'b'.
The solution is to add a field for private data *once*. The advantage is that a) we can hide the private data and b) we can extend it without worrying about compatibility:
struct Foo {
int a;
PrivateFoo *p;
};
We can still add public members if needed:
struct Foo {
int a;
void *private;
int b;
};
'private' points to a private data structure that is not be visible to clients. There you can conditionally enable members without problems:
struct PrivateFoo {
#ifdef USE_BAR
struct MyFeature feature;
#endif
};
MyFeature could be in a seperate source file together with your methods and it only gets compiled when needed.
Again, have a look at the "t_canvas_private" struct and the "gl_privatedata" member of "_glist" (aka "t_canvas") and do the same for "_editor", e.g.:
in g_canvas.h:
typedef struct _editor {
...
void *e_privatedata;
} t_editor;
in g_editor.c:
#ifdef HAVE_KEYBOARDNAV
#include "g_keyboardnav.h"
#endif
typedef struct _editor_private {
#ifdef HAVE_KEYBOARDNAV
t_keyboardnav keyboardnav;
