Hans-Christoph Steiner wrote:
Hey Lluis,
Good to hear that you're working on these objects, they are very valuable
contributions that with a little more polish will really round out Pd's capabilities.
As for updating this, I think pdp_colorgrid is currently part of Yves' pidip
code directories.
the new version of colorgrid doesn't need anymore to bundle the image (colorgrid.pnm) file in the package, but it introduces a new dependency to the tk-img library, and i don't know of the availability of this library on every platform, for now i'm sure it's not listed in pd's dependencies... not sure it's the way to go.
second, when you build pidip from source, it defines the path to that image as : #define COLORGRID_IMG PWD"/patches/images/colorgrid.pnm" that insure a compiled PIDIP will find the image..
when it's build in extended, i don't know which path should be given here, as i don't know of a standard path for shared files in pd-extended, well, basically the simplest thing is to put the right path here in SVN, and pidip will keep its way of compiling it.
saludos, sevy
On Apr 1, 2008, at 8:13 AM, ydegoyon@free.fr wrote:
Hans-Christoph Steiner wrote:
Hey Lluis,
Good to hear that you're working on these objects, they are very
valuablecontributions that with a little more polish will really round out
Pd's capabilities.As for updating this, I think pdp_colorgrid is currently part of
Yves' pidipcode directories.
the new version of colorgrid doesn't need anymore to bundle the image (colorgrid.pnm) file in the package, but it introduces a new dependency to the tk-img library, and i don't know of the availability of this library on every platform, for now i'm sure it's not listed in pd's dependencies... not sure it's the way to go.
second, when you build pidip from source, it defines the path to that image as : #define COLORGRID_IMG PWD"/patches/images/colorgrid.pnm" that insure a compiled PIDIP will find the image..
when it's build in extended, i don't know which path should be
given here, as i don't know of a standard path for shared files in pd-extended, well, basically the simplest thing is to put the right path here in
SVN, and pidip will keep its way of compiling it.
How about using the built-in image support? It means the file has to
be a GIF, but since the GIF patent has expired, that shouldn't be any
problem.
.hc
kill your television
S'està citant Hans-Christoph Steiner hans@eds.org:
On Apr 1, 2008, at 8:13 AM, ydegoyon@free.fr wrote:
Hans-Christoph Steiner wrote:
Hey Lluis,
Good to hear that you're working on these objects, they are very valuable
contributions that with a little more polish will really round out Pd's capabilities.
As for updating this, I think pdp_colorgrid is currently part of
Yves' pidipcode directories.
the new version of colorgrid doesn't need anymore to bundle the image (colorgrid.pnm) file in the package, but it introduces a new dependency to the tk-img library, and i don't know of the availability of this library on every platform, for now i'm sure it's not listed in pd's dependencies... not sure it's the way to go.
second, when you build pidip from source, it defines the path to that image as : #define COLORGRID_IMG PWD"/patches/images/colorgrid.pnm" that insure a compiled PIDIP will find the image..
when it's build in extended, i don't know which path should be given here, as i don't know of a standard path for shared files in pd-extended, well, basically the simplest thing is to put the right path here in SVN, and pidip will keep its way of compiling it.
How about using the built-in image support? It means the file has to be a GIF, but since the GIF patent has expired, that shouldn't be any problem.
this could be a good solution but GIF can only handle 256 indexed
colors, so it's not a good solution for a color picker ;(
the strange thing here is that if i use the tk command ::
COLORGRID_SYS_VGUI3("image create photo img%x -data {%s}\n",x,fdata);
with the fdata being a base64 encoded GIF image it works without the
Tk::Img library , but if You try to do the same with a base64 encoded
PNM image you will need to load the Img library to get it work, with
this ::
sys_gui("package require Img\n");
otherwise you will get: "couldn't recognize image data"
it's a really strange thing because PNM is suposed to be also built-in
supported by tk ...
any tips?
.hc
kill your television
This message was sent using IMP, the Internet Messaging Program.
On Apr 24, 2008, at 6:33 PM, lluisgomez@hangar.org wrote:
S'està citant Hans-Christoph Steiner hans@eds.org:
On Apr 1, 2008, at 8:13 AM, ydegoyon@free.fr wrote:
Hans-Christoph Steiner wrote:
Hey Lluis,
Good to hear that you're working on these objects, they are
very valuablecontributions that with a little more polish will really round
out Pd's capabilities.As for updating this, I think pdp_colorgrid is currently part
of Yves' pidipcode directories.
the new version of colorgrid doesn't need anymore to bundle the image (colorgrid.pnm) file in the package, but it introduces a new dependency to the tk-img library, and i don't know of the availability of this library on every platform, for now i'm sure it's not listed in pd's dependencies... not sure it's the way to go.
second, when you build pidip from source, it defines the path to that image as : #define COLORGRID_IMG PWD"/patches/images/colorgrid.pnm" that insure a compiled PIDIP will find the image..
when it's build in extended, i don't know which path should be
given here, as i don't know of a standard path for shared files in pd-extended, well, basically the simplest thing is to put the right path here
in SVN, and pidip will keep its way of compiling it.How about using the built-in image support? It means the file has to be a GIF, but since the GIF patent has expired, that shouldn't be any problem.
this could be a good solution but GIF can only handle 256 indexed
colors, so it's not a good solution for a color picker ;(the strange thing here is that if i use the tk command ::
COLORGRID_SYS_VGUI3("image create photo img%x -data {%s}\n",x,fdata);
with the fdata being a base64 encoded GIF image it works without
the Tk::Img library , but if You try to do the same with a base64
encoded PNM image you will need to load the Img library to get it
work, with this ::sys_gui("package require Img\n");
otherwise you will get: "couldn't recognize image data"
it's a really strange thing because PNM is suposed to be also built- in supported by tk ...
any tips?
Hmm, strange PNM/PGM should work with tk's built-in 'image'. I would
first try making a .pnm file and see if you can get that working.
Then once that is working, try including it as base64.
.hc
.hc
kill your television
This message was sent using IMP, the Internet Messaging Program.
There is no way to peace, peace is the way. -A.J. Muste
Hans-Christoph Steiner hans@eds.org ha escrito:
On Apr 24, 2008, at 6:33 PM, lluisgomez@hangar.org wrote:
S'està citant Hans-Christoph Steiner hans@eds.org:
On Apr 1, 2008, at 8:13 AM, ydegoyon@free.fr wrote:
Hans-Christoph Steiner wrote:
Hey Lluis,
Good to hear that you're working on these objects, they are very
valuablecontributions that with a little more polish will really round out Pd's capabilities.
As for updating this, I think pdp_colorgrid is currently part of
Yves' pidipcode directories.
the new version of colorgrid doesn't need anymore to bundle the image (colorgrid.pnm) file in the package, but it introduces a new dependency to the tk-img library, and i don't know of the availability of this library on every platform, for now i'm sure it's not listed in pd's dependencies... not sure it's the way to go.
second, when you build pidip from source, it defines the path to that image as : #define COLORGRID_IMG PWD"/patches/images/colorgrid.pnm" that insure a compiled PIDIP will find the image..
when it's build in extended, i don't know which path should be given here, as i don't know of a standard path for shared files in pd-extended, well, basically the simplest thing is to put the right path here in SVN, and pidip will keep its way of compiling it.
How about using the built-in image support? It means the file has to be a GIF, but since the GIF patent has expired, that shouldn't be any problem.
this could be a good solution but GIF can only handle 256 indexed
colors, so it's not a good solution for a color picker ;(the strange thing here is that if i use the tk command ::
COLORGRID_SYS_VGUI3("image create photo img%x -data {%s}\n",x,fdata);
with the fdata being a base64 encoded GIF image it works without
the Tk::Img library , but if You try to do the same with a base64
encoded PNM image you will need to load the Img library to get it
work, with this ::sys_gui("package require Img\n");
otherwise you will get: "couldn't recognize image data"
it's a really strange thing because PNM is suposed to be also
built-in supported by tk ...any tips?
Hmm, strange PNM/PGM should work with tk's built-in 'image'. I would first try making a .pnm file and see if you can get that working.
it's done. this is how it works in the previous version (pdp_colorgrid)
Then once that is working, try including it as base64.
no way ;(
I'll try asking in the tk mailing list ...
.hc
.hc
kill your television
This message was sent using IMP, the Internet Messaging Program.
There is no way to peace, peace is the way. -A.J. Muste
This message was sent using IMP, the Internet Messaging Program.
On Apr 25, 2008, at 10:26 PM, lluisgomez@hangar.org wrote:
Hans-Christoph Steiner hans@eds.org ha escrito:
On Apr 24, 2008, at 6:33 PM, lluisgomez@hangar.org wrote:
S'està citant Hans-Christoph Steiner hans@eds.org:
On Apr 1, 2008, at 8:13 AM, ydegoyon@free.fr wrote:
Hans-Christoph Steiner wrote:
Hey Lluis,
Good to hear that you're working on these objects, they are
very valuablecontributions that with a little more polish will really round
out Pd's capabilities.As for updating this, I think pdp_colorgrid is currently part
of Yves' pidipcode directories.
the new version of colorgrid doesn't need anymore to bundle the image (colorgrid.pnm) file in the package, but it introduces a new dependency to the tk-img library, and i don't know of the availability of this library on every platform, for now i'm sure it's not listed in pd's dependencies... not sure it's the way to go.
second, when you build pidip from source, it defines the path to that image as : #define COLORGRID_IMG PWD"/patches/images/colorgrid.pnm" that insure a compiled PIDIP will find the image..
when it's build in extended, i don't know which path should be
given here, as i don't know of a standard path for shared files in pd- extended, well, basically the simplest thing is to put the right path
here in SVN, and pidip will keep its way of compiling it.How about using the built-in image support? It means the file
has to be a GIF, but since the GIF patent has expired, that shouldn't
be any problem.this could be a good solution but GIF can only handle 256
indexed colors, so it's not a good solution for a color picker ;(the strange thing here is that if i use the tk command ::
COLORGRID_SYS_VGUI3("image create photo img%x -data {%s} \n",x,fdata);
with the fdata being a base64 encoded GIF image it works without
the Tk::Img library , but if You try to do the same with a
base64 encoded PNM image you will need to load the Img library
to get it work, with this ::sys_gui("package require Img\n");
otherwise you will get: "couldn't recognize image data"
it's a really strange thing because PNM is suposed to be also
built-in supported by tk ...any tips?
Hmm, strange PNM/PGM should work with tk's built-in 'image'. I would first try making a .pnm file and see if you can get that working.
it's done. this is how it works in the previous version
(pdp_colorgrid)Then once that is working, try including it as base64.
no way ;(
I'll try asking in the tk mailing list ...
I find #tcl on freenode is quite helpful too.
.hc
.hc
.hc
kill your television
This message was sent using IMP, the Internet Messaging Program.
There is no way to peace, peace is the way. -A.J. Muste
This message was sent using IMP, the Internet Messaging Program.
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
-
Hans-Christoph Steiner -
lluisgomez＠hangar.org -
ydegoyon＠free.fr