Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
Perhaps it makes sense to use the standard .po file format for locales, its pretty simple and would be easy to parse in Tcl. I imagine there are tools for working with .po files, so then we could use those. Then init_locale() could read the .po into a hashtable, i.e. $hashtable($key). My guess is that a big hashtable would be faster than the current say() procedure, but I could be wrong.
Or maybe a locale namespace makes more sense, it would just be lots of variable names, something like:
namespace eval ::pd_locale:: { variable file_new variable file_open variable file_save variable file_saveas ... variable edit_undo variable edit_redo variable edit_cut variable edit_copy ... variable put_object variable put_message variable put_numberbox variable put_symbolbox variable put_comment ... }
Then to use them:
$rootmenu add command -label $::pd_locale::file_new -accelerator "$accelerator+N" $rootmenu add command -label $::pd_locale::file_open -accelerator "$accelerator+O" $rootmenu add command -label $::pd_locale::file_save -accelerator "$accelerator+S"
But I suppose it might make more sense to programmatically declare the 'variable's.
.hc
Actually, I just found out that the GNU gettext utils for .po files are included in Tcl/Tk in a package called "msgcat". Here's a little bit more on the topic:
http://www.gnu.org/software/automake/manual/gettext/Tcl.html
.hc
On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote:
Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
Perhaps it makes sense to use the standard .po file format for locales, its pretty simple and would be easy to parse in Tcl. I imagine there are tools for working with .po files, so then we could use those. Then init_locale() could read the .po into a hashtable, i.e. $hashtable($key). My guess is that a big hashtable would be faster than the current say() procedure, but I could be wrong.
Or maybe a locale namespace makes more sense, it would just be lots of variable names, something like:
namespace eval ::pd_locale:: { variable file_new variable file_open variable file_save variable file_saveas ... variable edit_undo variable edit_redo variable edit_cut variable edit_copy ... variable put_object variable put_message variable put_numberbox variable put_symbolbox variable put_comment ... }
Then to use them:
$rootmenu add command -label $::pd_locale::file_new -accelerator "$accelerator+N" $rootmenu add command -label $::pd_locale::file_open -accelerator "$accelerator+O" $rootmenu add command -label $::pd_locale::file_save -accelerator "$accelerator+S"
But I suppose it might make more sense to programmatically declare the 'variable's.
.hc
Ok, responding to myself again :D It turns out that msgcat has been part of Tcl since 8.1:
http://tcl.tk/man/tcl8.4/TclCmd/msgcat.htm
It looks like this is definitely the way to handle locales.
.hc
On Jan 5, 2009, at 7:18 PM, Hans-Christoph Steiner wrote:
Actually, I just found out that the GNU gettext utils for .po files are included in Tcl/Tk in a package called "msgcat". Here's a little bit more on the topic:
http://www.gnu.org/software/automake/manual/gettext/Tcl.html
.hc
On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote:
Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
Perhaps it makes sense to use the standard .po file format for locales, its pretty simple and would be easy to parse in Tcl. I imagine there are tools for working with .po files, so then we could use those. Then init_locale() could read the .po into a hashtable, i.e. $hashtable($key). My guess is that a big hashtable would be faster than the current say() procedure, but I could be wrong.
Or maybe a locale namespace makes more sense, it would just be lots of variable names, something like:
namespace eval ::pd_locale:: { variable file_new variable file_open variable file_save variable file_saveas ... variable edit_undo variable edit_redo variable edit_cut variable edit_copy ... variable put_object variable put_message variable put_numberbox variable put_symbolbox variable put_comment ... }
Then to use them:
$rootmenu add command -label $::pd_locale::file_new -accelerator "$accelerator+N" $rootmenu add command -label $::pd_locale::file_open -accelerator "$accelerator+O" $rootmenu add command -label $::pd_locale::file_save -accelerator "$accelerator+S"
But I suppose it might make more sense to programmatically declare the 'variable's.
.hc
Hi all:
just a quick reply before i take some days off traveling a bit.
ok, i will look into the msgcat and ths locale stuff you mentioned. but meanwhile, i have started porting the locale system in desiredata to the new pd-devel, which i think could work nicely too, without adding any overhead. its done through a method which will look up locale names given by a file, which can be specified in the rc file, or as a commandline option. the localed files are just .tcl script calling the lookup method with the key value for storing all the terms.
take a look at it and if we really need a change, then we can see how best to change it. another reason that i would be more for staying with the locale system of desiredata is that we could simply reuse all the locale files (with permission) done for it so far, which is quite a fair bit(check the locale directory in /src at the dd branch).
my 0.01C:)
cheers
chun
Hans-Christoph Steiner said :
Actually, I just found out that the GNU gettext utils for .po files are included in Tcl/Tk in a package called "msgcat". Here's a little bit more on the topic:
http://www.gnu.org/software/automake/manual/gettext/Tcl.html
.hc
On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote:
Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
Perhaps it makes sense to use the standard .po file format for locales, its pretty simple and would be easy to parse in Tcl. I imagine there are tools for working with .po files, so then we could use those. Then init_locale() could read the .po into a hashtable, i.e. $hashtable($key). My guess is that a big hashtable would be faster than the current say() procedure, but I could be wrong.
Or maybe a locale namespace makes more sense, it would just be lots of variable names, something like:
namespace eval ::pd_locale:: { variable file_new variable file_open variable file_save variable file_saveas ... variable edit_undo variable edit_redo variable edit_cut variable edit_copy ... variable put_object variable put_message variable put_numberbox variable put_symbolbox variable put_comment ... }
Then to use them:
$rootmenu add command -label $::pd_locale::file_new -accelerator "$accelerator+N" $rootmenu add command -label $::pd_locale::file_open -accelerator "$accelerator+O" $rootmenu add command -label $::pd_locale::file_save -accelerator "$accelerator+S"
But I suppose it might make more sense to programmatically declare the 'variable's.
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I hear you about reusing existing code, but I think there are a number of code reasons to use msgcat: - a well debugged and optimized library - it is a widely used standard, so its well documented (esp. compared to our code ;) - there are existing tools to make translating easier
I'll happily write a script to convert the existing locales to the msgcat/gettext format if you handle writing the code. :D
hc
On Jan 6, 2009, at 11:03 AM, [*~] wrote:
Hi all:
just a quick reply before i take some days off traveling a bit.
ok, i will look into the msgcat and ths locale stuff you mentioned. but meanwhile, i have started porting the locale system in desiredata to the new pd-devel, which i think could work nicely too, without adding any overhead. its done through a method which will look up locale names given by a file, which can be specified in the rc file, or as a commandline option. the localed files are just .tcl script calling the lookup method with the key value for storing all the terms.
take a look at it and if we really need a change, then we can see how best to change it. another reason that i would be more for staying with the locale system of desiredata is that we could simply reuse all the locale files (with permission) done for it so far, which is quite a fair bit(check the locale directory in /src at the dd branch).
my 0.01C:)
cheers
chun
Hans-Christoph Steiner said :
Actually, I just found out that the GNU gettext utils for .po files are included in Tcl/Tk in a package called "msgcat". Here's a little bit more on the topic:
http://www.gnu.org/software/automake/manual/gettext/Tcl.html
.hc
On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote:
Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
Perhaps it makes sense to use the standard .po file format for locales, its pretty simple and would be easy to parse in Tcl. I imagine there are tools for working with .po files, so then we could use those. Then init_locale() could read the .po into a hashtable, i.e. $hashtable($key). My guess is that a big hashtable would be faster than the current say() procedure, but I could be wrong.
Or maybe a locale namespace makes more sense, it would just be lots of variable names, something like:
namespace eval ::pd_locale:: { variable file_new variable file_open variable file_save variable file_saveas ... variable edit_undo variable edit_redo variable edit_cut variable edit_copy ... variable put_object variable put_message variable put_numberbox variable put_symbolbox variable put_comment ... }
Then to use them:
$rootmenu add command -label $::pd_locale::file_new -accelerator "$accelerator+N" $rootmenu add command -label $::pd_locale::file_open -accelerator "$accelerator+O" $rootmenu add command -label $::pd_locale::file_save -accelerator "$accelerator+S"
But I suppose it might make more sense to programmatically declare the 'variable's.
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hans-Christoph Steiner said :
I hear you about reusing existing code, but I think there are a number of code reasons to use msgcat:
- a well debugged and optimized library
- it is a widely used standard, so its well documented (esp. compared to
our code ;)
- there are existing tools to make translating easier
I'll happily write a script to convert the existing locales to the msgcat/gettext format if you handle writing the code. :D
ok sure i can understand, i will look into the msgcat stuff next week when my travel finishs and get back into the swing of things.
cheers
chun
hc
On Jan 6, 2009, at 11:03 AM, [*~] wrote:
Hi all:
just a quick reply before i take some days off traveling a bit.
ok, i will look into the msgcat and ths locale stuff you mentioned. but meanwhile, i have started porting the locale system in desiredata to the new pd-devel, which i think could work nicely too, without adding any overhead. its done through a method which will look up locale names given by a file, which can be specified in the rc file, or as a commandline option. the localed files are just .tcl script calling the lookup method with the key value for storing all the terms.
take a look at it and if we really need a change, then we can see how best to change it. another reason that i would be more for staying with the locale system of desiredata is that we could simply reuse all the locale files (with permission) done for it so far, which is quite a fair bit(check the locale directory in /src at the dd branch).
my 0.01C:)
cheers
chun
Hans-Christoph Steiner said :
Actually, I just found out that the GNU gettext utils for .po files are included in Tcl/Tk in a package called "msgcat". Here's a little bit more on the topic:
http://www.gnu.org/software/automake/manual/gettext/Tcl.html
.hc
On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote:
Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
Perhaps it makes sense to use the standard .po file format for locales, its pretty simple and would be easy to parse in Tcl. I imagine there are tools for working with .po files, so then we could use those. Then init_locale() could read the .po into a hashtable, i.e. $hashtable($key). My guess is that a big hashtable would be faster than the current say() procedure, but I could be wrong.
Or maybe a locale namespace makes more sense, it would just be lots of variable names, something like:
namespace eval ::pd_locale:: { variable file_new variable file_open variable file_save variable file_saveas ... variable edit_undo variable edit_redo variable edit_cut variable edit_copy ... variable put_object variable put_message variable put_numberbox variable put_symbolbox variable put_comment ... }
Then to use them:
$rootmenu add command -label $::pd_locale::file_new -accelerator "$accelerator+N" $rootmenu add command -label $::pd_locale::file_open -accelerator "$accelerator+O" $rootmenu add command -label $::pd_locale::file_save -accelerator "$accelerator+S"
But I suppose it might make more sense to programmatically declare the 'variable's.
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Jan 11, 2009, at 11:01 PM, [*~] wrote:
Hans-Christoph Steiner said :
I hear you about reusing existing code, but I think there are a number of code reasons to use msgcat:
- a well debugged and optimized library
- it is a widely used standard, so its well documented (esp.
compared to our code ;)
- there are existing tools to make translating easier
I'll happily write a script to convert the existing locales to the msgcat/gettext format if you handle writing the code. :D
ok sure i can understand, i will look into the msgcat stuff next week when my travel finishs and get back into the swing of things.
Excellent! Let me know when you want me to convert those files... :D
.hc
cheers
chun
hc
On Jan 6, 2009, at 11:03 AM, [*~] wrote:
Hi all:
just a quick reply before i take some days off traveling a bit.
ok, i will look into the msgcat and ths locale stuff you mentioned. but meanwhile, i have started porting the locale system in desiredata to the new pd-devel, which i think could work nicely too, without adding any overhead. its done through a method which will look up locale names given by a file, which can be specified in the rc file, or as a commandline option. the localed files are just .tcl script calling the lookup method with the key value for storing all the terms.
take a look at it and if we really need a change, then we can see how best to change it. another reason that i would be more for staying with the locale system of desiredata is that we could simply reuse all the locale files (with permission) done for it so far, which is quite a fair bit(check the locale directory in /src at the dd branch).
my 0.01C:)
cheers
chun
Hans-Christoph Steiner said :
Actually, I just found out that the GNU gettext utils for .po files are included in Tcl/Tk in a package called "msgcat". Here's a little bit more on the topic:
http://www.gnu.org/software/automake/manual/gettext/Tcl.html
.hc
On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote:
Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
Perhaps it makes sense to use the standard .po file format for locales, its pretty simple and would be easy to parse in Tcl. I imagine there are tools for working with .po files, so then we could use those. Then init_locale() could read the .po into a hashtable, i.e. $hashtable($key). My guess is that a big hashtable would be faster than the current say() procedure, but I could be wrong.
Or maybe a locale namespace makes more sense, it would just be lots of variable names, something like:
namespace eval ::pd_locale:: { variable file_new variable file_open variable file_save variable file_saveas ... variable edit_undo variable edit_redo variable edit_cut variable edit_copy ... variable put_object variable put_message variable put_numberbox variable put_symbolbox variable put_comment ... }
Then to use them:
$rootmenu add command -label $::pd_locale::file_new -accelerator "$accelerator+N" $rootmenu add command -label $::pd_locale::file_open -accelerator "$accelerator+O" $rootmenu add command -label $::pd_locale::file_save -accelerator "$accelerator+S"
But I suppose it might make more sense to programmatically declare the 'variable's.
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Wed, 7 Jan 2009, Hans-Christoph Steiner wrote:
I hear you about reusing existing code, but I think there are a number of code reasons to use msgcat:
- it is a widely used standard, so its well documented (esp. compared
to our code ;)
So, do you really think that Tcl's GetText 'format' is being used at all outside of Tcl? It's not like it's the same format as used in GNU GetText.
- there are existing tools to make translating easier
Which tools? Never heard of them.
- a well debugged and optimized library
Do you need a well debugged and optimised library for accessing a hashtable when the language already has commands for accessing hashtables freely?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jan 23, 2009, at 10:37 AM, Mathieu Bouchard wrote:
On Wed, 7 Jan 2009, Hans-Christoph Steiner wrote:
I hear you about reusing existing code, but I think there are a number of code reasons to use msgcat:
- it is a widely used standard, so its well documented (esp. compared
to our code ;)
So, do you really think that Tcl's GetText 'format' is being used at all outside of Tcl? It's not like it's the same format as used in GNU GetText.
Considering Tcl's msgcat is listed in the official GNU gettext manual as "fully portable", I think it is safe to say yes:
http://www.gnu.org/software/automake/manual/gettext/Tcl.html
- there are existing tools to make translating easier
Which tools? Never heard of them.
Here is one: http://www.gted.org/
- a well debugged and optimized library
Do you need a well debugged and optimised library for accessing a hashtable when the language already has commands for accessing hashtables freely?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Do you really think that accessing a hashtable is all there is to localization? How about parsing the names of the locales (en_US, en_US.UTF-8, en_GB, etc.)? That is non-trivial and handled by msgcat, as are many other things we haven't thought of, but the people who have been working on gettext/msgcat since
.hc
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
On Fri, 23 Jan 2009, Hans-Christoph Steiner wrote:
On Jan 23, 2009, at 10:37 AM, Mathieu Bouchard wrote:
So, do you really think that Tcl's GetText 'format' is being used at all outside of Tcl? It's not like it's the same format as used in GNU GetText.
Considering Tcl's msgcat is listed in the official GNU gettext manual as "fully portable", I think it is safe to say yes: http://www.gnu.org/software/automake/manual/gettext/Tcl.html
But Tcl's msgcat is using its own *.msg file format instead of *.po.
Here is one: http://www.gted.org/
Does it support Tcl's *.msg files, or only *.po ? I only see a mention of *.po.
Do you need a well debugged and optimised library for accessing a hashtable when the language already has commands for accessing hashtables freely?
Do you really think that accessing a hashtable is all there is to localization? How about parsing the names of the locales (en_US, en_US.UTF-8, en_GB, etc.)? That is non-trivial and handled by msgcat, as are many other things we haven't thought of, but the people who have been working on gettext/msgcat since
Yeah, this is what most of the msgcat library does. If you remove the locale autodetection code from it, there's not much code left. I don't really mind setting the language myself though. Yet it'd be fine with me if the locale were autodetected.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jan 23, 2009, at 1:08 PM, Mathieu Bouchard wrote:
On Fri, 23 Jan 2009, Hans-Christoph Steiner wrote:
On Jan 23, 2009, at 10:37 AM, Mathieu Bouchard wrote:
So, do you really think that Tcl's GetText 'format' is being used at all outside of Tcl? It's not like it's the same format as used in GNU GetText.
Considering Tcl's msgcat is listed in the official GNU gettext manual as "fully portable", I think it is safe to say yes: http://www.gnu.org/software/automake/manual/gettext/Tcl.html
But Tcl's msgcat is using its own *.msg file format instead of *.po.
Here is one: http://www.gted.org/
Does it support Tcl's *.msg files, or only *.po ? I only see a mention of *.po.
"GNU gettext has support (since V 0.13 [1]) for Tcl msgcat and conversion tools from and to PO format. http://ftp.gnu.org/gnu/gettext/"
.hc
Do you need a well debugged and optimised library for accessing a hashtable when the language already has commands for accessing hashtables freely?
Do you really think that accessing a hashtable is all there is to localization? How about parsing the names of the locales (en_US, en_US.UTF-8, en_GB, etc.)? That is non-trivial and handled by msgcat, as are many other things we haven't thought of, but the people who have been working on gettext/msgcat since
Yeah, this is what most of the msgcat library does. If you remove the locale autodetection code from it, there's not much code left. I don't really mind setting the language myself though. Yet it'd be fine with me if the locale were autodetected.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
On Fri, 23 Jan 2009, Hans-Christoph Steiner wrote:
Does it support Tcl's *.msg files, or only *.po ? I only see a mention of *.po.
http://wiki.tcl.tk/1488 "GNU gettext has support (since V 0.13 [1]) for Tcl msgcat and conversion tools from and to PO format. http://ftp.gnu.org/gnu/gettext/"
But GTED does not use GNU gettext for parsing. Just a quick look at the source code makes me think that it does not parse .msg files directly either. Well, I guess it's not a big deal, nothing that a makefile can't fix.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hans-Christoph Steiner wrote:
Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards
I agree they are very messy.
I am totally for a remake of gui objects, with cleaner code, better functionality, and all the best. I believe much time must be spent on design of this, creating a common codebase for such objects, an API, a set of user requirements, and so on....
which collaborative tool could help in this phase? wiki?
just to throw in some ideas: * powerful sliders which allow to select range (i.e. a second handle comes in) * sliders and radio are basically the same type of object, just that a radio only would allow integer values * a bitmap object is missing (a seqence of bits.... just another representation of an integer) also, that could be 2-dimensional, allowing grid of bits... but that falls out of generality with the radio/slider objects * preferences dialogs as pd patches? (this may be too ambitious)
my 0.02
compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include
where exactly does the locale applies to those objects? I mean I see really few text around those objects. could you provide a practical example?
btw I see this could apply well in a bigger picture... e.g. when rewriting the pd.tk ui
translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
would be nice to see a demo of it! :)
On Jan 5, 2009, at 7:43 PM, mescalinum@gmail.com wrote:
Hans-Christoph Steiner wrote:
Hey Chun, all,
I am thinking that for adding locales to pd-devel, we should leave iemgui out of it. It is very messy code that has a lot of legacy use, so that the iemgui stuff would need to have full backwards
I agree they are very messy.
I am totally for a remake of gui objects, with cleaner code, better functionality, and all the best. I believe much time must be spent on design of this, creating a common codebase for such objects, an API, a set of user requirements, and so on....
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/tkwidg...
With tkwidgets, I spent a lot of time working on an API to handle the Tk widgets easily from Pd. Basically the idea is that during runtime, the state of the widget is stored in the Tk widget itself. Then Pd just gets a dump from that widget and saves it. I also have a working code for a common method of dynamically resizing the widgets with the mouse.
My idea with tkwidgets was to make Pd versions of all the standard Tk widgets. The API could then be used to make ttk, bwidgets, or even mescalinumwidgets.
which collaborative tool could help in this phase? wiki?
A wiki works for me, if you want to start one in http://puredata.info/dev/ I am personally trying to express more ideas in code.
just to throw in some ideas:
- powerful sliders which allow to select range (i.e. a second handle
comes in)
- sliders and radio are basically the same type of object, just that a
radio only would allow integer values
- a bitmap object is missing (a seqence of bits.... just another
representation of an integer) also, that could be 2-dimensional, allowing grid of bits... but that falls out of generality with the radio/slider objects
All ideas to try.
- preferences dialogs as pd patches? (this may be too ambitious)
I would really like to see all of the Pd dialogs be Pd patches. IOhannes' iemguts is an important step towards this, since it allows you to tie a Pd patch to the "Properties" menu item.
.hc
my 0.02
compatibility. Instead, I think we should build a new GUI library that includes locale support. In the process we could make a locale API for people who want to write their own GUI objects and include
where exactly does the locale applies to those objects? I mean I see really few text around those objects. could you provide a practical example?
btw I see this could apply well in a bigger picture... e.g. when rewriting the pd.tk ui
translations. I have almost the whole framework for such a library finished, its called 'tkwidgets'.
would be nice to see a demo of it! :)
-- FF
-
[*~] -
Hans-Christoph Steiner -
Mathieu Bouchard -
mescalinum＠gmail.com