I've added an alternative implementation which keeps just one global counter (instead of one per parent widget). This implementation is simpler as it doesn't modify the TkWindow and Tk_FakeWin structures.
File Added: patch_tip306_global
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd rather have the counter kept in the TkMainInfo, as that's a structure that is more thoroughly out of the way of the user and yet won't have threading issues. (Different threads will have their own main windows...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Currently the counter is not really global: it's a static variable in the NameWindow() function, so I'd say it is thoroughly out of the user's way... Of course, it's not thread-safe , but I thought that Tk was inherently not thread-safe?
If it must be thread-safe, maybe TkDisplay is the right place to store it? See the comments about TkDisplay in tkInt.h:
/*
* One of the following structures is maintained for each display containing a
* window managed by Tk. In part, the structure is used to store thread-
* specific data, since each thread will have its own TkDisplay structure.
*/
typedef struct TkDisplay {
...
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We want Tk to become thread-safe; adding in stuff that isn't *now* is silly (all the MacOSX stuff notwithstanding). Yet I for one have used multiple displays in the same interpreter, so storing the counter in the display is also somewhat dodgy (or rather, proving that isn't is awkward). What there *is* that is safe to use is the TkMainInfo, which is restricted to a thread and so wholly safe to use.
Meh, this whole feature should be pretty straight-forward to code up anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
new pach (replaces previous one)
Logged In: YES
user_id=1388916
Originator: YES
New reference implementation for TIP 306. Added check for already existing (manually defined) widget names.
File Added: tip306.patch2
Logged In: YES
user_id=1388916
Originator: YES
I've added an alternative implementation which keeps just one global counter (instead of one per parent widget). This implementation is simpler as it doesn't modify the TkWindow and Tk_FakeWin structures.
File Added: patch_tip306_global
alternative implementation
I'd rather have the counter kept in the TkMainInfo, as that's a structure that is more thoroughly out of the way of the user and yet won't have threading issues. (Different threads will have their own main windows...)
Currently the counter is not really global: it's a static variable in the NameWindow() function, so I'd say it is thoroughly out of the user's way... Of course, it's not thread-safe , but I thought that Tk was inherently not thread-safe?
If it must be thread-safe, maybe TkDisplay is the right place to store it? See the comments about TkDisplay in tkInt.h:
/*
* One of the following structures is maintained for each display containing a
* window managed by Tk. In part, the structure is used to store thread-
* specific data, since each thread will have its own TkDisplay structure.
*/
typedef struct TkDisplay {
...
}
Why the resistance to doing it right?
We want Tk to become thread-safe; adding in stuff that isn't *now* is silly (all the MacOSX stuff notwithstanding). Yet I for one have used multiple displays in the same interpreter, so storing the counter in the display is also somewhat dodgy (or rather, proving that isn't is awkward). What there *is* that is safe to use is the TkMainInfo, which is restricted to a thread and so wholly safe to use.
Meh, this whole feature should be pretty straight-forward to code up anyway.
implementation which keeps the counter in TkMainInfo
Ok, I've added a new patch, which keeps the counter in TkMainInfo.
(I had no resistance, just questions...)
File Added: tip306_maininfo.patch