Menu
▾
▴
tcl-mac
|
From: Benjamin R. <Ben...@ep...> - 2003-02-13 15:43:57
|
Hi Jim, > > Vince Darley wrote: > >> (I assume small details like the '+' '-' etc appearing on the > >> traffic light when you mouse-over will be fixed with this) Jim Ingham <ji...@ap...> writes: > This is kind of spooky. I explicitly DON'T add the standard window > handler to new windows when I create them. So what is the handler > that is running the stoplights, then??? It's probably magic ;-). Just to be clear about this I don't think that enabling the standard handler is a good idea. The necessary business is all handled by the current code, or it should be, so that is fine. The patch does only enable the engine to be used by new code. > For now, your patch is pretty benign, because nobody (except for > this mysterious stoplight handler) is really listening to the events > we forward at present. Note that IMEs like the "Character Palette" now come up. They can't do anything yet, because TSM is not initialized (my next patch), but the floating windows work. By the way, is there any way (documented or undocumented) to get an overview which handlers are installed? I mean purely for debugging that would be an important thing to know, right? > For sure when Tk does it's window management thing it doesn't want > somebody else to get in there & mess it up. So in general, I would > tend to be more conservative than you are. So, for instance, if a > mouse up or down event occurs in a window made by Tk, I would NOT > pass it on to whatever other handler might have registered itself > with this window. We can block mouse clicks from distribution if we want, I don't think that's a major problem. OTOH it's pretty clear who is responsible for which click, so no other component has any business to do anything about Tk clicks anyway. Otherwise that would be a serious bug in that component. > I don't intend to sound negative, however. Your idea is a good > foundation for doing experiments. As there start to be other folks > trying to use the events we forward, we will figure out which things > Tk can afford to pass on and which it can't, and set up the code > accordingly. My thoughts exactly. > Note also that they don't work all the way. If you click in a > background window's close box, for instance, it doesn't close, but > rather just foregrounds. We can fix this in Tk I didn't check that before I installed your patch of today. Was there a fix for that in there, because this works correctly as described for me right now? Thanks for working with this, it's encouraging that we seem to be getting somewhere ;-) Another question: Do you have access to a 10.1 installation? With 10.2 not being a free update, there are bound to be some such machines out there. Actually I remember people asking for support for 10.1 (not sure if this was for Tk or Emacs, though). It's quite possible that this or other new code doesn't work there, but it would be good to know either way. so long, benny |
|
From: Jim I. <ji...@ap...> - 2003-02-13 18:48:53
|
Benny, On Thursday, February 13, 2003, at 07:43 AM, Benjamin Riefenstahl wrote: > Hi Jim, > > >>> Vince Darley wrote: >>>> (I assume small details like the '+' '-' etc appearing on the >>>> traffic light when you mouse-over will be fixed with this) > > Jim Ingham <ji...@ap...> writes: >> This is kind of spooky. I explicitly DON'T add the standard window >> handler to new windows when I create them. So what is the handler >> that is running the stoplights, then??? > > It's probably magic ;-). > > Just to be clear about this I don't think that enabling the standard > handler is a good idea. The necessary business is all handled by the > current code, or it should be, so that is fine. The patch does only > enable the engine to be used by new code. Yes, I was worried originally that the stoplights were done by the standard handler, which would have been a pain. Whether magic or no, it is better this way. > >> For now, your patch is pretty benign, because nobody (except for >> this mysterious stoplight handler) is really listening to the events >> we forward at present. > > Note that IMEs like the "Character Palette" now come up. They can't > do anything yet, because TSM is not initialized (my next patch), but > the floating windows work. > > By the way, is there any way (documented or undocumented) to get an > overview which handlers are installed? I mean purely for debugging > that would be an important thing to know, right? If you call one of the DebugPrint functions (either in your code or from gdb) you get the event handler's token in the output. But I don't know how to translate that. And I couldn't find any functions to walk the chain of handlers. There is a tantalizing function: 0x96b1af24 SetEventHandlerDebugName 0x96b1b308 SetEventTargetDebugName but they don't seem to ever get called in the normal course of things. > >> For sure when Tk does it's window management thing it doesn't want >> somebody else to get in there & mess it up. So in general, I would >> tend to be more conservative than you are. So, for instance, if a >> mouse up or down event occurs in a window made by Tk, I would NOT >> pass it on to whatever other handler might have registered itself >> with this window. > > We can block mouse clicks from distribution if we want, I don't think > that's a major problem. OTOH it's pretty clear who is responsible for > which click, so no other component has any business to do anything > about Tk clicks anyway. Otherwise that would be a serious bug in that > component. Right, but we also need to be a bit defensive. > >> I don't intend to sound negative, however. Your idea is a good >> foundation for doing experiments. As there start to be other folks >> trying to use the events we forward, we will figure out which things >> Tk can afford to pass on and which it can't, and set up the code >> accordingly. > > My thoughts exactly. > >> Note also that they don't work all the way. If you click in a >> background window's close box, for instance, it doesn't close, but >> rather just foregrounds. We can fix this in Tk > > I didn't check that before I installed your patch of today. Was there > a fix for that in there, because this works correctly as described for > me right now? Yeah, I fixed this in the patch I sent you. If other folks are interested, I can forward it more generally, but I don't want to spam the list with patches. > > > Thanks for working with this, it's encouraging that we seem to be > getting somewhere ;-) Yeah, this is good. > > Another question: Do you have access to a 10.1 installation? With > 10.2 not being a free update, there are bound to be some such machines > out there. Actually I remember people asking for support for 10.1 > (not sure if this was for Tk or Emacs, though). It's quite possible > that this or other new code doesn't work there, but it would be good > to know either way. No, I don't. The current release of the Developer Tools doesn't run on 10.1, so we don't keep any machines with 10.1 on them. I'll see if I can find one, or if anybody else has one and wants to play guinea pig... Jim -- Jim Ingham ji...@ap... Developer Tools Apple Computer |
|
From: Jim I. <ji...@ap...> - 2003-02-12 06:29:37
|
I was reading through this some tonight. I follow this mostly and the
substance seems fine. You are really a better judge of that than I...
I have a few picky comments...
1) Can you put a comment on the def'n of deadKeyUpState &
deadKeyDownState while you remember what they are for? (And put one on
a line - it is good to do this for statics so they are easier to
identify.)
2) In the GenerateKeyEvent def'n, don't use "unsigned"; they are
defined as UInt32 in Carbon.h so we should use that. It was even more
wrong before, I know that, but...
3) You also need to change the comment in GenerateKeyEvent, since it
isn't passed a window anymore but rather you figure that out down
below...
4) The deadKeyStatePtr should be a pointer (just a typeo, I assume).
5) In this line (tkMacOSXKeyEvent.c:370)
if ((controlKey & e->keyModifiers)
|| chars[i] >= ' ' || chars[i] < 0) {
Is the last statement trying to check whethre the high bit is set? The
compiler complains that this is always false due to data type, so maybe
there is a better way to do this. The Mac part of tk has too many
compiler warnings already, but I would rather not introduce new ones.
6) I know why you write tests "1 == varName" not "varName == 1", but
that style is not used anywhere else in Tcl/Tk, so
it looks very odd to my eye. I will probably change it before
checking it in, or you can if you don't mind...
7) In KeycodeToUnicodeViaUnicodeResource you have:
switch(eKind) {
default: /* Keep compilers happy */
case kEventRawKeyDown:
...
Presumably anything but the kEventRawKey... event kinds are invalid
inputs to the function. You don't ever call this function with
anything else, but still, you should do something like print an error
and return 0 so nobody will make this mistake, or if they do they will
catch it early.
I compulsively fixed some other formatting nits while reading through
your version. I made a diff against the current TOT, and sent that to
you separately (so as not to spam the list too badly.) If you could
start with this, that would be great. Then if you can make these few
changes, and get me the new version, I will check it in and then folks
can give it a try.
Thanks,
Jim
On Tuesday, February 11, 2003, at 08:33 AM, Benjamin Riefenstahl wrote:
>
> The code is now on the patch tracker page
> http://sourceforge.net/tracker/
> index.php?func=detail&aid=622582&group_id=12997&atid=312997,
> as basic-keyboard.2003-02-10.diff plus comment. I hope installation
> works, I got it out yesterday in a bit of a hurry, and there were a
> number of last minute changes.
>
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham
ji...@ap...
Developer Tools - gdb
|
|
From: Benjamin R. <Ben...@ep...> - 2003-02-12 14:32:32
|
Hi Jim,
Jim Ingham <ji...@ap...> writes:
> 5) In this line (tkMacOSXKeyEvent.c:370)
>
> if ((controlKey & e->keyModifiers)
> || chars[i] >= ' ' || chars[i] < 0) {
>
> Is the last statement trying to check whethre the high bit is set?
It's probably that I saw "char" and though I need to cover negative
signed chars. I assume UniChar is garanteed to be defined as unsigned
in some documentation?
> 6) I know why you write tests "1 == varName" not "varName == 1", but
> that style is not used anywhere else in Tcl/Tk, so
> it looks very odd to my eye. I will probably change it before
> checking it in, or you can if you don't mind...
I can change that, but it goes strongly against my grain. I don't
consider that a cosmetic issue. Since I started doing this I also
found that I can actually read this better after a short adjustment
time.
> I compulsively fixed some other formatting nits while reading through
> your version.
I'll try to do better in the future ;-)
> I made a diff against the current TOT, and sent that to you
> separately (so as not to spam the list too badly.) If you could
> start with this, that would be great. Then if you can make these
> few changes, and get me the new version,
I will do that.
so long, benny
BTW:
> The Mac part of tk has too many compiler warnings already, but I
> would rather not introduce new ones.
I had enabled -ansi -Wall and noticed two or three fishy warnings.
Can we enable that in the CVS and check it out?
BTW2:
I have some problems loading the project into the Project Builder
lately. Are there any known problems, should I get an update for
something? The about box says I have 2.1 (Dec2002), IDE 114.0, Code
112.0, Toolsupport 110.0.
|
|
From: Jim I. <ji...@ap...> - 2003-02-12 18:10:10
|
Benny,
On Wednesday, February 12, 2003, at 06:32 AM, Benjamin Riefenstahl
wrote:
> Hi Jim,
>
>
> Jim Ingham <ji...@ap...> writes:
>
>> 5) In this line (tkMacOSXKeyEvent.c:370)
>>
>> if ((controlKey & e->keyModifiers)
>> || chars[i] >= ' ' || chars[i] < 0) {
>>
>> Is the last statement trying to check whethre the high bit is set?
>
> It's probably that I saw "char" and though I need to cover negative
> signed chars. I assume UniChar is garanteed to be defined as unsigned
> in some documentation?
Yup. If you command-double-click on a type name in PB it will usually
take you to where it is defined. UniChar is UInt16.
>
>> 6) I know why you write tests "1 == varName" not "varName == 1", but
>> that style is not used anywhere else in Tcl/Tk, so
>> it looks very odd to my eye. I will probably change it before
>> checking it in, or you can if you don't mind...
>
> I can change that, but it goes strongly against my grain. I don't
> consider that a cosmetic issue. Since I started doing this I also
> found that I can actually read this better after a short adjustment
> time.
Yeah, if it was done this way consistently through-out Tcl/Tk, I would
agree with you. But bouncing back and forth between the two styles
really gives me a headache...
>
>> I compulsively fixed some other formatting nits while reading through
>> your version.
>
> I'll try to do better in the future ;-)
No prob. The MacOSX Tk sources are kind of a mess 'cause I could never
get Ian to take the coding conventions as seriously as I did. I still
find little nits all over when I examine bits of the code closely.
>
>> I made a diff against the current TOT, and sent that to you
>> separately (so as not to spam the list too badly.) If you could
>> start with this, that would be great. Then if you can make these
>> few changes, and get me the new version,
>
> I will do that.
>
>
> so long, benny
>
>
> BTW:
>
>> The Mac part of tk has too many compiler warnings already, but I
>> would rather not introduce new ones.
>
> I had enabled -ansi -Wall and noticed two or three fishy warnings.
> Can we enable that in the CVS and check it out?
Sure, I will have a look. I am not sure that Tcl/Tk guarantees passing
-ansi cleanly - it may still have some K&R'isms, but certainly -Wall
should be clean.
>
> BTW2:
>
> I have some problems loading the project into the Project Builder
> lately. Are there any known problems, should I get an update for
> something? The about box says I have 2.1 (Dec2002), IDE 114.0, Code
> 112.0, Toolsupport 110.0.
>
That is the current latest version, what problems are you having?
Jim
>
--
Jim Ingham ji...@ap...
Developer Tools
Apple Computer
|
|
From: Benjamin R. <Ben...@ep...> - 2003-02-12 18:48:23
|
> Benjamin Riefenstahl wrote: > > It's probably that I saw "char" and though I need to cover > > negative signed chars. I assume UniChar is garanteed to be > > defined as unsigned in some documentation? Jim Ingham <ji...@ap...> writes: > Yup. If you command-double-click on a type name in PB it will usually > take you to where it is defined. UniChar is UInt16. <nitpicking> That's implementation, not documentation ;-). Implementations change. Documentation gives a certain amount of guarantees. But I think we have been there before ... </nitpicking> > > I had enabled -ansi -Wall and noticed two or three fishy warnings. > > Can we enable that in the CVS and check it out? > > Sure, I will have a look. I am not sure that Tcl/Tk guarantees > passing -ansi cleanly - it may still have some K&R'isms, but > certainly -Wall should be clean. Most things that I have looked at seemed like real issues or easily avoided with slight changes. > > I have some problems loading the project into the Project Builder > > lately. Are there any known problems, should I get an update for > > something? The about box says I have 2.1 (Dec2002), IDE 114.0, Code > > 112.0, Toolsupport 110.0. > > That is the current latest version, what problems are you having? It tells me about syntax errors in the project files, even one directly from the CVS. I now noticed that the frameworks mentioned are actually in /System/Library/PrivateFrameworks :-(((. I had to rebuild the system lately, so I may have missed updating those frameworks. |
|
From: Vince D. <vi...@sa...> - 2003-02-11 11:55:41
|
On 9 Feb 2003, Benjamin Riefenstahl wrote: > All in all, I think that only the first item (plain keyboard input > improvements) can be ready in time, the other two issues need more > discussion and more work, at least testing (reproducible test cases) > and probably bug fixes. > > BTW, is there fixed date set for the release? Here's Jeff's reply: > end of month, they should be commiting things now. Freeze around 20th. > >Jeff |
|
From: Mats B. <ma...@pr...> - 2003-02-10 14:23:21
|
Benny wrote: > Event handler changes > --------------------- > > IMEs (like the Character Palette) and other libraries like Quicktime > need a cooperative event handling and the ability to execute selected > Carbon Event handlers. Currently Tk swallows all events, even those > it doesn't actually know or need. My earlier keyboard patch has that, > but Jim Ingham had reservations about it. I haven't seen any test > cases yet for actual problems, so I can't say which details need to be > changed if any. I'll separate this from the preceding point, so we > can install and test it separately. The functions mentioned are of > course important. We should discuss how to get further on this track. I understand that changing fundamental event handling isn't something you should do close to a release, but I would like interested parties to try to pin point any problems with this patch so I can proceed trying to get QuickTimeTcl working properly using the patched AquaTk. I haven't tried it myself yet. Mats |
|
From: Jim I. <ji...@ap...> - 2003-02-10 18:30:57
|
I suggest going the other way round on this. Try out the patch, get fixed what you need for QuickTimeTcl, and then see what else breaks. The problem with using the Carbon event handlers is that they do surprising things behind your back. I bet these things are also changing over time (they did between pre-releases and 10.0, and 10.0 to 10.1 for sure). So it is hard for me to look at a patch and say how it is going to bite us. We are still in an experimentation phase, and since you have something that can push the boundaries, you get the dubious privilege of being one of the experimenters... Jim On Monday, February 10, 2003, at 06:25 AM, Mats Bengtsson wrote: > > Benny wrote: >> Event handler changes >> --------------------- >> >> IMEs (like the Character Palette) and other libraries like Quicktime >> need a cooperative event handling and the ability to execute selected >> Carbon Event handlers. Currently Tk swallows all events, even those >> it doesn't actually know or need. My earlier keyboard patch has that, >> but Jim Ingham had reservations about it. I haven't seen any test >> cases yet for actual problems, so I can't say which details need to be >> changed if any. I'll separate this from the preceding point, so we >> can install and test it separately. The functions mentioned are of >> course important. We should discuss how to get further on this track. > > I understand that changing fundamental event handling isn't something > you should do close to a release, but I would like interested parties > to try to pin point any problems with this patch so I can > proceed trying to get QuickTimeTcl working properly using the > patched AquaTk. I haven't tried it myself yet. > > Mats > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > -- Jim Ingham ji...@ap... Developer Tools Apple Computer |
|
From: Benjamin R. <Ben...@ep...> - 2003-02-10 17:24:03
|
Hi Vince, all, Vince Darley <vi...@sa...> writes: > Given Tk 8.4.2 is going to be released in February, are there any > TkAqua fixes (such as this Option key business) which should go into > it before then? Benjamin Riefenstahl <Ben...@ep...> writes: > International keyboard input > ---------------------------- > > I have a reorganisation and a couple of bug fixes that should be > non-controversial in their substance as they are strictly > improvements on the current status. I'll fix it up, prepare and > upload a new patch to the patch tracker this evening. Done. > this Option key business I changed the comment in the source to reflect the current state: >>>>>>>>>> We have a general problem here. How do we handle 'Option-char' keypresses? The problem is that we might want to bind to some of these (e.g. Cmd-Opt-d is 'uncomment' in Alpha). OTOH Option-d actually produces a real character on MacOS, namely a mathematical delta. The current behaviour is that a binding goes by the combinations of modifiers and base keysym, that is Option-d. The string value of the event is the mathematical delta character, so if no binding calls [break], the text widget will insert that character. Note that this is similar to control combinations on all platforms. They also generate events that have the base character as keysym and a real control character as character value. So Ctrl+C gets us the keysym XK_C, the modifier Control (so you can bind <Control-C>) and a string value as "\u0003". For a different solutions we may want for the event to contain keysyms for *both* the 'Opt-d' side of things and the mathematical delta. Then a binding on Opt-d will trigger, but a binding on mathematical delta would also trigger. This would require changes in the core, though. <<<<<<<<<< so long, benny |
Thanks for helping keep SourceForge clean.
X