For the next step in the tkwidgets library is converting [entry],
which I have done a lot of work on, to [text], following the Tk
widget name. (It turns out that "entry" is a different Tk widget).
Now I am going to apply what I have learned to a how library based on
the Tk widgets. I am naming them after the Tk widgets, so that would
mean making an object called [entry] with is a text entry box, and
renaming the currently [entry] to [text]. I am wondering how much
people use the old [entry]. If not much, then I think the easiest
path forward is to remove [entry] from flatspace and maybe stick it
in "deprecated" or a "bbogart" lib.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Tue, 2007-11-13 at 15:53 -0500, Hans-Christoph Steiner wrote:
For the next step in the tkwidgets library is converting [entry],
which I have done a lot of work on, to [text], following the Tk
widget name. (It turns out that "entry" is a different Tk widget).Now I am going to apply what I have learned to a how library based on
the Tk widgets. I am naming them after the Tk widgets, so that would
mean making an object called [entry] with is a text entry box, and
renaming the currently [entry] to [text]. I am wondering how much
people use the old [entry]. If not much, then I think the easiest
path forward is to remove [entry] from flatspace and maybe stick it
in "deprecated" or a "bbogart" lib.
i am very fine with the changes. netpd doesn't officially use it yet, though there will probably be 'chat' based on the new 'text' (afaik, eni made already a chat version based on [entry], but it think, he would agree with better doing the changes sooner than later.)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Now I am going to apply what I have learned to a how library based on
the Tk widgets. I am naming them after the Tk widgets, so that would
mean making an object called [entry] with is a text entry box, and
renaming the currently [entry] to [text].
As [text] is a pretty common word, that could mean anything, it came to my mind: Do you plan some kind of namespace for the new GUI objects?
Ciao
Frank Barknecht _ ______footils.org__
On Nov 13, 2007, at 6:54 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Now I am going to apply what I have learned to a how library based on the Tk widgets. I am naming them after the Tk widgets, so that would mean making an object called [entry] with is a text entry box, and renaming the currently [entry] to [text].
As [text] is a pretty common word, that could mean anything, it came to my mind: Do you plan some kind of namespace for the new GUI objects?
I want to keep the same names as the Tk widgets, that's why I chose
that name. That way it's very easy to use the Tk docs for these
widgets. The options are the same too. It will be in the lib
tkwidgets, so tkwidgets/text will always be possible. Hopefully this
doesn't cause any problems.
These are the widgets I plan on implementing:
http://puredata.info/dev/TkWidget
.hc
There is no way to peace, peace is the way. -A.J. Muste
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I want to keep the same names as the Tk widgets, that's why I chose
that name. That way it's very easy to use the Tk docs for these
widgets. The options are the same too. It will be in the lib
tkwidgets, so tkwidgets/text will always be possible. Hopefully this
doesn't cause any problems. These are the widgets I plan on implementing:
I think, that's a cool list of objects to have and it's great that you're working on it. The names in Tk are very generic, though, which is understandable for Tk itself, as it's largely self-contained. But in Pd, there's even another [scale] waiting to clash with existing objects and (private) abstractions, that's why maybe a short, quickly-to-type namespace should be obligatory. What about [tk/scale]?
Ciao
Frank Barknecht _ ______footils.org__
ya,
i second franks suggestion of prepending a 'tk' to the object, this seems quite self explanitory. a tk.text would work for me, afterall these are quite explicit tk objects and would have no use outside of the tk environment. i'm not sure about a '/' however as it may confuse the concept of 'lib/object' namespacing.. anyhow good work on hcs/bbogarts part.. nice to see tot/toxy/etc is becoming unecessary these days..
completely out of the loop,
dmotd
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I want to keep the same names as the Tk widgets, that's why I chose
that name. That way it's very easy to use the Tk docs for these
widgets. The options are the same too. It will be in the lib
tkwidgets, so tkwidgets/text will always be possible. Hopefully this
doesn't cause any problems. These are the widgets I plan on implementing:I think, that's a cool list of objects to have and it's great that you're working on it. The names in Tk are very generic, though, which is understandable for Tk itself, as it's largely self-contained. But in Pd, there's even another [scale] waiting to clash with existing objects and (private) abstractions, that's why maybe a short, quickly-to-type namespace should be obligatory. What about [tk/scale]?
Ciao
Hans-Christoph Steiner a écrit :
On Nov 13, 2007, at 6:54 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Now I am going to apply what I have learned to a how library based on the Tk widgets. I am naming them after the Tk widgets, so that would mean making an object called [entry] with is a text entry box, and renaming the currently [entry] to [text].
As [text] is a pretty common word, that could mean anything, it came to my mind: Do you plan some kind of namespace for the new GUI objects?
I want to keep the same names as the Tk widgets, that's why I chose
that name. That way it's very easy to use the Tk docs for these
widgets. The options are the same too. It will be in the lib
tkwidgets, so tkwidgets/text will always be possible. Hopefully this
doesn't cause any problems. These are the widgets I plan on implementing:http://puredata.info/dev/TkWidget
.hc
Very nice!
I see you propose to draw a rectangle, what about other shapes? I'm particulary interested by the line. Also, how would we proceed for binding with this set of patches?
On Nov 14, 2007, at 8:14 AM, Patrice Colet wrote:
Hans-Christoph Steiner a écrit :
On Nov 13, 2007, at 6:54 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Now I am going to apply what I have learned to a how library
based on the Tk widgets. I am naming them after the Tk widgets, so that
would mean making an object called [entry] with is a text entry box, and renaming the currently [entry] to [text].As [text] is a pretty common word, that could mean anything, it came to my mind: Do you plan some kind of namespace for the new GUI objects?
I want to keep the same names as the Tk widgets, that's why I
chose that name. That way it's very easy to use the Tk docs for
these widgets. The options are the same too. It will be in the
lib tkwidgets, so tkwidgets/text will always be possible.
Hopefully this doesn't cause any problems. These are the widgets I plan on implementing: http://puredata.info/dev/TkWidget .hcVery nice!
I see you propose to draw a rectangle, what about other shapes? I'm particulary interested by the line.
Hmm, did I add that? I guess so... I don't think I'll include any
shapes in this, just Tk widgets. For shapes, use data structures.
Or for just a rectangle there is [cnv], [grid], [gcanvas] and maybe
others.
Also, how would we proceed for binding with this set of patches?
Binding what to what? Using [canvas_name], [window_name], and
[sys_gui], (or toxy) you can interact with the widgets on a Tcl/Tk
level, then you can do all sorts of stuff.
.hc
All information should be free. - the hacker ethic
Hans-Christoph Steiner a écrit :
Binding what to what?
binding key, mouse, to widgets with having possibility to define binding parameters, idealy, all the connections between widgets could be done with tcl-tk, it would be a lot easier to patch, and we could make nicer and more versatiles interfaces.
Using [canvas_name], [window_name], and [sys_gui],
I've no clue about those objects, where do they come from?
(or toxy)
I'm allready using tow or tot or I send directly parameters to widgets, but it's not easy at all, one have to know perfectly pd inside, and tcl-tk code, that's not my case.
if using toxy/widget and .wid files could be replaced by something easier that wouldn't need to reboot pd at each tries, and with intelligible error messaging, it would be perfect, then many people would be able to create original widgets, with repelling the design limits imposed by actual widgets.
.hc
Patrice Colet a écrit :
Hans-Christoph Steiner a écrit :
Using [canvas_name], [window_name], and [sys_gui],
I've no clue about those objects, where do they come from?
ah ok, it's a new stuff, and this isn't available yet for win32, I built them, it only works in pd-extended version, what can I do for making them win32-vanilla compatible?
On Nov 14, 2007, at 12:27 PM, Patrice Colet wrote:
Hans-Christoph Steiner a écrit :
Binding what to what?
binding key, mouse, to widgets with having possibility to define
binding parameters, idealy, all the connections between widgets
could be done with tcl-tk, it would be a lot easier to patch, and
we could make nicer and more versatiles interfaces.
That would be very nice to have, but I am not addressing that yet.
tot/tow/widget address that, AFAIK. It would be nice to have that
stuff working well in Pd-extended. Any volunteers?
Using [canvas_name], [window_name], and [sys_gui],
I've no clue about those objects, where do they come from?
I recently wrote them, they are in the 0.40.3-extended nightly builds.
(or toxy)
I'm allready using tow or tot or I send directly parameters to
widgets, but it's not easy at all, one have to know perfectly pd
inside, and tcl-tk code, that's not my case.if using toxy/widget and .wid files could be replaced by something
easier that wouldn't need to reboot pd at each tries, and with
intelligible error messaging, it would be perfect, then many people
would be able to create original widgets, with repelling the design
limits imposed by actual widgets.
Federico, Matju and I have talked some about making a Tcl/Tk API for
writing widgets for Pd. But we haven't written any code yet. The
idea would be to extend Federico's tclpd to support the GUI API.
.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
hi all,
maybe a silly question, but:
might it be feasible to use something like tk_text as the name so as to make it obvious which one is being used without having to fight with the namespace issues?
this has probably been discussed to death in the namespace conversation a few months ago....
tm
On 14/11/2007, at 3:12 AM, Hans-Christoph Steiner wrote:
On Nov 13, 2007, at 6:54 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Now I am going to apply what I have learned to a how library
based on the Tk widgets. I am naming them after the Tk widgets, so that
would mean making an object called [entry] with is a text entry box, and renaming the currently [entry] to [text].As [text] is a pretty common word, that could mean anything, it came to my mind: Do you plan some kind of namespace for the new GUI objects?
I want to keep the same names as the Tk widgets, that's why I chose that name. That way it's very easy to use the Tk docs for these widgets. The options are the same too. It will be in the lib tkwidgets, so tkwidgets/text will always be possible. Hopefully this doesn't cause any problems. These are the widgets I plan on implementing:
http://puredata.info/dev/TkWidget
.hc
--
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
AFAIK, there is no existing [text] object besides in the internal
routine inside of Pd.
.hc
On Nov 14, 2007, at 12:07 PM, Tim Boykett wrote:
hi all,
maybe a silly question, but:
might it be feasible to use something like tk_text as the name so as to make it obvious which one is being used without having to
fight with the namespace issues?this has probably been discussed to death in the namespace
conversation a few months ago....tm
On 14/11/2007, at 3:12 AM, Hans-Christoph Steiner wrote:
On Nov 13, 2007, at 6:54 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Now I am going to apply what I have learned to a how library
based on the Tk widgets. I am naming them after the Tk widgets, so that
would mean making an object called [entry] with is a text entry box, and renaming the currently [entry] to [text].As [text] is a pretty common word, that could mean anything, it came to my mind: Do you plan some kind of namespace for the new GUI objects?
I want to keep the same names as the Tk widgets, that's why I chose that name. That way it's very easy to use the Tk docs for these widgets. The options are the same too. It will be in the lib tkwidgets, so tkwidgets/text will always be possible. Hopefully this doesn't cause any problems. These are the widgets I plan on implementing:
http://puredata.info/dev/TkWidget
.hc
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
AFAIK, there is no existing [text] object besides in the internal
routine inside of Pd.
I think, crossing fingers is not really an appropriate way to deal with nameclashes. ;)
While there is no [text] afaik, there are at least [scale] and [image].
Generally I agree with dmotd and Tim, that a "tk"-prefixed name would be good, but a directory namespace would be the least thing to do.
Ciao
Frank Barknecht _ ______footils.org__
On Tue, 13 Nov 2007, Hans-Christoph Steiner wrote:
I want to keep the same names as the Tk widgets
The Tk Widget names are routinely adapted to naming conventions of various programming languages. Thus "button" may change to "Button", "TkButton", "Tk::Button", "tk.Button" or "tk.button" depending on the language, for example.
Thus those names can be different from the original ones as long as there is a systematic pattern that is easy to automate and guess. For example, "button" could become [tk/button] or [tkbutton] or [tk.button] or it could be [tk button] as there is no need to have separate classes for what could be a single generic wrapper, or it could be any of the preceding schemes with a single class because there is no need for a class to have a single class name.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
dmotd -
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Patrice Colet -
Roman Haefeli -
Tim Boykett