Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Hi!

I have a question regarding how can i use the pimpl idiom in the kbd navigation 
case.
The editor private members will be defined in g_editor.c.
But since i'm moving the core kbd navigation stuff to it's own file 
(g_kbdnav.c) i must have a way of accessing this t_kbdnav struct on that file.

Currently i've used the solution (example below) of implementing a 
canvas_getkbdnav(t_canvas *x) function on g_editor.c that returns a pointer to 
it's t_kbdnav struct.

Is this okay/good? Why?

Note:
I could make canvas_getkbdnav(t_canvas *x) static and pass a t_kbdnav pointer 
as a parameter from g_editor to the kbdnav stuff. The problem is that i also i 
need to call some kbdnav function from the iemgui files (g_toggle.c, 
g_hslider.c, etc) because they have custom drawing functions that need to call 
some kbdnav logic to draw the in/outlet selection.



--g_canvas.h--

typedef struct _editor {
...
void *e_privatedata;
} t_editor;

--g_editor.c--

typedef struct _editor_private {
#ifdef HAVE_KEYBOARDNAV
t_kbdnav kbdnav;
#endif
} t_editor_private;

t_kbdnav* canvas_getkbdnav(t_canvas *x)
{
...
}

--g_kbdnav.h--

EXTERN t_kbdnav* canvas_getkbdnav(t_canvas *x);

--g_kbdnav.c--

void kbdnav_somefunction(t_canvas *x)
{
t_kbdnav *kbdnav = canvas_getkbdnav(x);
...
}


Cheers,
Henri.




De: Christof Ressi 
Enviado: terça-feira, 16 de julho de 2019 14:32
Para: Henri Augusto Bisognini 
Cc: pd-dev@lists.iem.at 
Assunto: Aw: Re: [PD-dev] First complete keyboard navigation prototype

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;
#endif
} t_editor_private;

the "t_keyboardnav" struct is defined in "g_keyboardnav.h" and its methods 
implemented in "g_keyboardnav.c". Both only get compiled when needed.

Hope this makes sense.

Christof

Gesendet: Dienstag, 16. Juli 2019 um 16:51 Uhr
Von: "Henri Augusto Bisognini" 
An: "pd-dev@lists.iem.at" 
Betreff: Re: [PD-dev] First complete keyboard navigation prototype
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

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

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;
#endif
} t_editor_private;

the "t_keyboardnav" struct is defined in "g_keyboardnav.h" and its methods 
implemented in "g_keyboardnav.c". Both only get compiled when needed.

Hope this makes sense.

Christof

Gesendet: Dienstag, 16. Juli 2019 um 16:51 Uhr
Von: "Henri Augusto Bisognini" 
An: "pd-dev@lists.iem.at" 
Betreff: Re: [PD-dev] First complete keyboard navigation prototype
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 
Enviado: sábado, 15 de junho de 2019 17:11
Para: Henri Augusto Bisognini
Cc: pd-dev@lists.iem.at
Assunto: Aw: Re: [PD-dev] First complete keyboard

Re: [PD-dev] First complete keyboard navigation prototype

[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;

#endif

} t_editor_private;

 

the "t_keyboardnav" struct is defined in "g_keyboardnav.h" and its methods implemented in "g_keyboardnav.c". Both only get compiled when needed.

 

Hope this makes sense.

 

Christof

 


Gesendet: Dienstag, 16. Juli 2019 um 16:51 Uhr
Von: "Henri Augusto Bisognini" 
An: "pd-dev@lists.iem.at" 
Betreff: Re: [PD-dev] First complete keyboard navigation prototype



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 
Enviado: sábado, 15 de junho de 2019 17:11
Para: Henri Augusto Bisognini
Cc: pd-dev@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 possi

Re: [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 
Enviado: sábado, 15 de junho de 2019 17:11
Para: Henri Augusto Bisognini
Cc: pd-dev@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" 
An: "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  em nome de IOhannes m zmölnig 

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
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Christof Ressi]

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" 
An: "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  em nome de IOhannes m zmölnig 
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







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

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Please excuse my ignorance on that matter but could you give me a brief 
explanation of the problem at hand?


De: Pd-dev  em nome de IOhannes m zmölnig 

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

Re: [PD-dev] First complete keyboard navigation prototype

[Dan Wilcox]

> I could change it to separate it from the rest. But probably i'll need some 
> directions as i'm a newbie.

I would focus first on making it all work. Next would be reorganizing by moving 
stuff around and once we can see all of the changes together, we could offer 
make some suggestions from there.

> So how one should go to keep everything optional?

Best would be to put all of the logic and functions you need for this into a 
separate file, much as how the intelligent patching works. Overriding is then 
as simple as making a dummy file where the functions simply do nothing. There 
might be other ways to do this, such as some sort of function pointer mechanism.

> Using preprocessor #if's to include/exclude code during compilation?

Unless it's something very simple, I would avoid this as it quickly becomes a 
mess.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD-dev] First complete keyboard navigation prototype

[IOhannes m zmölnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

I could change it to separate it from the rest. But probably i'll need some 
directions as i'm a newbie.

Some stuff is already separated such as the hotkey handling which is done in 
kbdnav_key<https://github.com/HenriAugusto/pure-data/blob/f5c39cb5cd7ebc101b0b3d9dcde28491b2093b57/src/g_editor.c#L5025>
 instead of canvas_key (which is already very long).

But there is stuff like the drawing of the rectangles to indicate which 
in/outlet is selected for example, which is done in 
glist_drawiofor<https://github.com/HenriAugusto/pure-data/blob/f5c39cb5cd7ebc101b0b3d9dcde28491b2093b57/src/g_text.c#L1365>
 inside  g_texc.c.

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.

So how one should go to keep everything optional?
Using preprocessor #if's to include/exclude code during compilation?


De: Miller Puckette 
Enviado: quarta-feira, 12 de junho de 2019 00:48
Para: Dan Wilcox
Cc: Henri Augusto Bisognini; pd-dev
Assunto: Re: [PD-dev] First complete keyboard navigation prototype

I agree - I haven't looked at the code but if it can fit easily into Pd's
source tree as a run-time option this would be worth adding.

cheers
M

On Mon, Jun 10, 2019 at 01:59:35PM +0200, Dan Wilcox wrote:
> *Not really feedback, but just a general response.*
>
> One thing I would suggest would be to make this an optional feature in some 
> way. Maybe we can work together with IOhannes and Christof to propose changes 
> to the Pd sources to allow for adding in this kind of functionality without 
> *requiring* it to be built into the core itself. I have been thinking of 
> these kinds of approaches since I see this being a greta feature for the GUI 
> but basically unused for something like libpd. In the latter case, I'd like 
> to simply not compile it and the easiest way would if the main functionality 
> is in a separate set of files that can be left out.
>
> This might be a process that has to happen later on, but something to think 
> of for now in order to balance the addition of new features while maintaining 
> the possibility for a fast, slim core.
>
> > On Jun 10, 2019, at 10:30 AM, pd-dev-requ...@lists.iem.at wrote:
> >
> > Date: Sun, 9 Jun 2019 19:16:36 +
> > From: Henri Augusto Bisognini  > <mailto:msndohe...@hotmail.com>>
> > To: "pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>"  > <mailto:pd-dev@lists.iem.at>>
> > Subject: Re: [PD-dev] First complete keyboard navigation prototype
> > Message-ID:
> >  
> >  >  
> > <mailto:cp2pr80mb0386c0d2c66d1ce34f458be3cc...@cp2pr80mb0386.lamprd80.prod.outlook.com>>
> >
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Thanks Christof! Indeed it's already been very nice to use it during my 
> > tests.
> >
> > I'l probably wrap up a small file containing some basic infos about how 
> > everything works to make it easier for more people to modify the code and 
> > test ideas.
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
>
>
>

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

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

Re: [PD-dev] First complete keyboard navigation prototype

[Miller Puckette]

I agree - I haven't looked at the code but if it can fit easily into Pd's
source tree as a run-time option this would be worth adding.

cheers
M

On Mon, Jun 10, 2019 at 01:59:35PM +0200, Dan Wilcox wrote:
> *Not really feedback, but just a general response.*
> 
> One thing I would suggest would be to make this an optional feature in some 
> way. Maybe we can work together with IOhannes and Christof to propose changes 
> to the Pd sources to allow for adding in this kind of functionality without 
> *requiring* it to be built into the core itself. I have been thinking of 
> these kinds of approaches since I see this being a greta feature for the GUI 
> but basically unused for something like libpd. In the latter case, I'd like 
> to simply not compile it and the easiest way would if the main functionality 
> is in a separate set of files that can be left out.
> 
> This might be a process that has to happen later on, but something to think 
> of for now in order to balance the addition of new features while maintaining 
> the possibility for a fast, slim core.
> 
> > On Jun 10, 2019, at 10:30 AM, pd-dev-requ...@lists.iem.at wrote:
> > 
> > Date: Sun, 9 Jun 2019 19:16:36 +
> > From: Henri Augusto Bisognini  > <mailto:msndohe...@hotmail.com>>
> > To: "pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>"  > <mailto:pd-dev@lists.iem.at>>
> > Subject: Re: [PD-dev] First complete keyboard navigation prototype
> > Message-ID:
> > 
> >  >  
> > <mailto:cp2pr80mb0386c0d2c66d1ce34f458be3cc...@cp2pr80mb0386.lamprd80.prod.outlook.com>>
> > 
> > Content-Type: text/plain; charset="iso-8859-1"
> > 
> > Thanks Christof! Indeed it's already been very nice to use it during my 
> > tests.
> > 
> > I'l probably wrap up a small file containing some basic infos about how 
> > everything works to make it easier for more people to modify the code and 
> > test ideas.
> 
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
> 
> 
> 

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




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

Re: [PD-dev] First complete keyboard navigation prototype

[Lucas Cordiviola]

oops, this feature is already covered on "intelligent patching 
amendments #575"


Mensaje telepatico asistido por maquinas.

On 6/10/2019 5:15 AM, Lucas Cordiviola wrote:
>
>
> Feature request:
>
> Make TAB a shortcut to "goto x++" and SHIFT+TAB "goto x--". This is 
> how web browsers handle navigation on pages. So pressing TAB will 
> navigate through objects. This (i think) will make it easier to patch 
> with the keyboard.
>



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

Re: [PD-dev] First complete keyboard navigation prototype

[Dan Wilcox]

*Not really feedback, but just a general response.*

One thing I would suggest would be to make this an optional feature in some 
way. Maybe we can work together with IOhannes and Christof to propose changes 
to the Pd sources to allow for adding in this kind of functionality without 
*requiring* it to be built into the core itself. I have been thinking of these 
kinds of approaches since I see this being a greta feature for the GUI but 
basically unused for something like libpd. In the latter case, I'd like to 
simply not compile it and the easiest way would if the main functionality is in 
a separate set of files that can be left out.

This might be a process that has to happen later on, but something to think of 
for now in order to balance the addition of new features while maintaining the 
possibility for a fast, slim core.

> On Jun 10, 2019, at 10:30 AM, pd-dev-requ...@lists.iem.at wrote:
> 
> Date: Sun, 9 Jun 2019 19:16:36 +
> From: Henri Augusto Bisognini  <mailto:msndohe...@hotmail.com>>
> To: "pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>"  <mailto:pd-dev@lists.iem.at>>
> Subject: Re: [PD-dev] First complete keyboard navigation prototype
> Message-ID:
>   
>   
> <mailto:cp2pr80mb0386c0d2c66d1ce34f458be3cc...@cp2pr80mb0386.lamprd80.prod.outlook.com>>
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Thanks Christof! Indeed it's already been very nice to use it during my tests.
> 
> I'l probably wrap up a small file containing some basic infos about how 
> everything works to make it easier for more people to modify the code and 
> test ideas.


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



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

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Lucas Cordiviola wrote:

> Right, i could finish the build.
>
> Here on my linux box (Debian9 Xfce) everything is working except the < 
ctrl+'> (control + single quote) to enter the "canvas message console". I can 
enter it as explained in > "connecting_with_the_canvas_msg_console".
>
> Feature request:
>
> I found it difficult to see which cable is selected.
> I suggest making the selected cable "Thicker" or something that makes it 
more visually obvious.



About the hotkey: Oh, there was an typo on the help patch! It is really shift+'

(in reality the hotkey is bind to "quotedbl" in "pd_bindings.tcl", hence the 
shift+single quote)

About the cables: yeah, i've also found it difficult. I've tought about making 
it thicker but i was afraid it would make some confusion with signal cables. 
I've also thought about using different colors but since PD uses black (+gray), 
white and blue i've avoided, for now, using other colors.

When cycling between more than one cable I've tried to display the selected 
cable in blue, making the non-selected cables gray. It helps a little bit but i 
still think we need some that highlights it better.

Some ideas up for discussion (in no particular order)

- Using green to make it more contrasting with the rest.
- Making the line thicker and also green to avoid confusion with signal chords.
- Making the line thicker and using a dashed pattern
- Displaying like with the normal black fill but with an blue outline. (also it 
would be thicker as a result)

There is one option that always struck me as something that would be nice that 
is animating stuff to make them easier to see. But nothing in PD is animated so 
far so right know i'm considering the other options.

What do you think?
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Thanks Christof! Indeed it's already been very nice to use it during my tests.

I'l probably wrap up a small file containing some basic infos about how 
everything works to make it easier for more people to modify the code and test 
ideas.

Cheers,
Henri.


De: Christof Ressi 
Enviado: sábado, 8 de junho de 2019 08:35
Para: Henri Augusto Bisognini; Pd-List
Assunto: Aw: [PD-dev] First complete keyboard navigation prototype

Hi, this looks like wonderful! I'll try it out in a couple of days and give 
feedback. I can also help with code if needed.

My biggest issue with visual programming is the amount of mouse interaction 
needed in contrast to text based programming (especially when sitting in a 
shaky ÖBB-train with a tiny laptop). A keyboard workflow like yours could be 
extremely useful for power users.

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

Re: [PD-dev] First complete keyboard navigation prototype

[Lucas Cordiviola]

Right, i could finish the build.


Here on my linux box (Debian9 Xfce) everything is working except the < ctrl+'> 
(control + single quote) to enter the "canvas message console". I can enter it 
as explained in "connecting_with_the_canvas_msg_console".


Feature request:

I found it difficult to see which cable is selected.

I suggest making the selected cable "Thicker" or something that makes it more 
visually obvious.





:)



Mensaje telepatico asistido por maquinas.

On 6/8/19 1:23 AM, Henri Augusto Bisognini wrote:
Sorry, it seems that i've uploaded the wrong "g_text.c" version to the kbd_nav 
branch. I should be fixed now.


De: Lucas Cordiviola <mailto:lucard...@hotmail.com>
Enviado: sábado, 8 de junho de 2019 01:10
Para: Henri Augusto Bisognini; pd-dev@lists.iem.at<mailto:pd-dev@lists.iem.at>
Assunto: Re: [PD-dev] First complete keyboard navigation prototype


When trying to build on Debian I get this errors:



''


g_text.c: In function ‘canvas_howputnew’:
g_text.c:166:40: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( x->gl_editor->e_kbdnav.kn_navigating && 
x->gl_editor->e_kbdnav.kn_ioindex > 0 ){
^
g_text.c: In function ‘canvas_obj’:
g_text.c:237:41: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( gl->gl_editor->e_kbdnav.kn_navigating && 
gl->gl_editor->e_kbdnav.kn_ioindex != 0 ){
 ^
g_text.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-format-truncation’
cc1: warning: unrecognized command line option ‘-Wno-stringop-truncation’
cc1: warning: unrecognized command line option ‘-Wno-cast-function-type’


''

Mensaje telepatico asistido por maquinas.

On 6/7/19 11:52 PM, Henri Augusto Bisognini wrote:
Hi!

I've finally managed to get time to finish a prototype for a keyboard 
navigation interface. I mixed some ideas i had with some I've seen in Desire 
Data's old screenshot gallery (http://artengine.ca/desiredata/).

I've recorded some gifs to demonstrate it. (https://imgur.com/gallery/WSB40P7). 
It shows me using the help patch (which i've put in 
7.stuff/keyboard.navigation). You can read about which keys to use in the 
comments.

The source can be found on my GitHub, on the kbd_nav branch 
(https://github.com/HenriAugusto/pure-data/tree/kbd_nav)

Basically I've wanted to try:

- navigating through objects/inelts connection with ctrl+arrows (cmd+arrows on 
Mac)
- automatically positioning new objects according to selected inlet/outlet
- a console bar to send messages to the focused patch
- ability to display each object index (to be used with the functionalities 
below)
- a new "goto" canvas message to select any object in the patch
- a "magnetic connector" that connects the selected in/outlet to the nearest 
ins/outs
- a "digit connectors" that displays indexes 0 to 9 for the 10 nearest possible 
connections. Just press the number and it will connect it for you
- pd can automatically fill for you a "connect" message in the console 
containing the info for the selected inlet/outlet. It will even select for you 
the part you need to fill
- You can click objects with shift+enter. Mostly useful for sending bangs and 
opening subpatches/abstractions

Everything is intended to be as minimal as possible and very easy to use. I 
wish to propose we study including it in vanilla.

Well, what do you guys think?

This is my first time working on a project this big so help me out if i did 
anything incorrectly. I've been testing the major functions on Win for a while 
now but couldn't test on mac/linux.

Cheers,
Henri.



N�n�r)em�h�yhiם�w^���



___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev

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

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Sorry, it seems that i've uploaded the wrong "g_text.c" version to the kbd_nav 
branch. I should be fixed now.


De: Lucas Cordiviola 
Enviado: sábado, 8 de junho de 2019 01:10
Para: Henri Augusto Bisognini; pd-dev@lists.iem.at
Assunto: Re: [PD-dev] First complete keyboard navigation prototype


When trying to build on Debian I get this errors:



''


g_text.c: In function ‘canvas_howputnew’:
g_text.c:166:40: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( x->gl_editor->e_kbdnav.kn_navigating && 
x->gl_editor->e_kbdnav.kn_ioindex > 0 ){
^
g_text.c: In function ‘canvas_obj’:
g_text.c:237:41: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( gl->gl_editor->e_kbdnav.kn_navigating && 
gl->gl_editor->e_kbdnav.kn_ioindex != 0 ){
 ^
g_text.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-format-truncation’
cc1: warning: unrecognized command line option ‘-Wno-stringop-truncation’
cc1: warning: unrecognized command line option ‘-Wno-cast-function-type’


''

Mensaje telepatico asistido por maquinas.

On 6/7/19 11:52 PM, Henri Augusto Bisognini wrote:
Hi!

I've finally managed to get time to finish a prototype for a keyboard 
navigation interface. I mixed some ideas i had with some I've seen in Desire 
Data's old screenshot gallery (http://artengine.ca/desiredata/).

I've recorded some gifs to demonstrate it. (https://imgur.com/gallery/WSB40P7). 
It shows me using the help patch (which i've put in 
7.stuff/keyboard.navigation). You can read about which keys to use in the 
comments.

The source can be found on my GitHub, on the kbd_nav branch 
(https://github.com/HenriAugusto/pure-data/tree/kbd_nav)

Basically I've wanted to try:

- navigating through objects/inelts connection with ctrl+arrows (cmd+arrows on 
Mac)
- automatically positioning new objects according to selected inlet/outlet
- a console bar to send messages to the focused patch
- ability to display each object index (to be used with the functionalities 
below)
- a new "goto" canvas message to select any object in the patch
- a "magnetic connector" that connects the selected in/outlet to the nearest 
ins/outs
- a "digit connectors" that displays indexes 0 to 9 for the 10 nearest possible 
connections. Just press the number and it will connect it for you
- pd can automatically fill for you a "connect" message in the console 
containing the info for the selected inlet/outlet. It will even select for you 
the part you need to fill
- You can click objects with shift+enter. Mostly useful for sending bangs and 
opening subpatches/abstractions

Everything is intended to be as minimal as possible and very easy to use. I 
wish to propose we study including it in vanilla.

Well, what do you guys think?

This is my first time working on a project this big so help me out if i did 
anything incorrectly. I've been testing the major functions on Win for a while 
now but couldn't test on mac/linux.

Cheers,
Henri.



N�n�r)em�h�yhiם�w^���
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Lucas Cordiviola]

When trying to build on Debian I get this errors:



''


g_text.c: In function ‘canvas_howputnew’:
g_text.c:166:40: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( x->gl_editor->e_kbdnav.kn_navigating && 
x->gl_editor->e_kbdnav.kn_ioindex > 0 ){
^
g_text.c: In function ‘canvas_obj’:
g_text.c:237:41: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( gl->gl_editor->e_kbdnav.kn_navigating && 
gl->gl_editor->e_kbdnav.kn_ioindex != 0 ){
 ^
g_text.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-format-truncation’
cc1: warning: unrecognized command line option ‘-Wno-stringop-truncation’
cc1: warning: unrecognized command line option ‘-Wno-cast-function-type’


''

Mensaje telepatico asistido por maquinas.

On 6/7/19 11:52 PM, Henri Augusto Bisognini wrote:
Hi!

I've finally managed to get time to finish a prototype for a keyboard 
navigation interface. I mixed some ideas i had with some I've seen in Desire 
Data's old screenshot gallery (http://artengine.ca/desiredata/).

I've recorded some gifs to demonstrate it. (https://imgur.com/gallery/WSB40P7). 
It shows me using the help patch (which i've put in 
7.stuff/keyboard.navigation). You can read about which keys to use in the 
comments.

The source can be found on my GitHub, on the kbd_nav branch 
(https://github.com/HenriAugusto/pure-data/tree/kbd_nav)

Basically I've wanted to try:

- navigating through objects/inelts connection with ctrl+arrows (cmd+arrows on 
Mac)
- automatically positioning new objects according to selected inlet/outlet
- a console bar to send messages to the focused patch
- ability to display each object index (to be used with the functionalities 
below)
- a new "goto" canvas message to select any object in the patch
- a "magnetic connector" that connects the selected in/outlet to the nearest 
ins/outs
- a "digit connectors" that displays indexes 0 to 9 for the 10 nearest possible 
connections. Just press the number and it will connect it for you
- pd can automatically fill for you a "connect" message in the console 
containing the info for the selected inlet/outlet. It will even select for you 
the part you need to fill
- You can click objects with shift+enter. Mostly useful for sending bangs and 
opening subpatches/abstractions

Everything is intended to be as minimal as possible and very easy to use. I 
wish to propose we study including it in vanilla.

Well, what do you guys think?

This is my first time working on a project this big so help me out if i did 
anything incorrectly. I've been testing the major functions on Win for a while 
now but couldn't test on mac/linux.

Cheers,
Henri.



N�n�r)em�h�yhiם�w^���
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Hi!

I've finally managed to get time to finish a prototype for a keyboard 
navigation interface. I mixed some ideas i had with some I've seen in Desire 
Data's old screenshot gallery (http://artengine.ca/desiredata/).

I've recorded some gifs to demonstrate it. (https://imgur.com/gallery/WSB40P7). 
It shows me using the help patch (which i've put in 
7.stuff/keyboard.navigation). You can read about which keys to use in the 
comments.

The source can be found on my GitHub, on the kbd_nav branch 
(https://github.com/HenriAugusto/pure-data/tree/kbd_nav)

Basically I've wanted to try:

- navigating through objects/inelts connection with ctrl+arrows (cmd+arrows on 
Mac)
- automatically positioning new objects according to selected inlet/outlet
- a console bar to send messages to the focused patch
- ability to display each object index (to be used with the functionalities 
below)
- a new "goto" canvas message to select any object in the patch
- a "magnetic connector" that connects the selected in/outlet to the nearest 
ins/outs
- a "digit connectors" that displays indexes 0 to 9 for the 10 nearest possible 
connections. Just press the number and it will connect it for you
- pd can automatically fill for you a "connect" message in the console 
containing the info for the selected inlet/outlet. It will even select for you 
the part you need to fill
- You can click objects with shift+enter. Mostly useful for sending bangs and 
opening subpatches/abstractions

Everything is intended to be as minimal as possible and very easy to use. I 
wish to propose we study including it in vanilla.

Well, what do you guys think?

This is my first time working on a project this big so help me out if i did 
anything incorrectly. I've been testing the major functions on Win for a while 
now but couldn't test on mac/linux.

Cheers,
Henri.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev