tcl-mac — Q&A for Tcl on the Macintosh platform

Re: [MACTCL] error building tk 8.5.8 on OS X 10.6

[daneyul <da...@co...>]

>> You might try the cocoa branch of 8.5.9 that is in the Fossil sources to
build on Snow Leopard. 

Thanks for the advice.   I'm afraid that's a bit easier said than done for a
non-fossil user.  (I'm sure it's great for the core developers...but
yikes--that is one grisly hard-to-figure-out interface for someone just
looking to grab a particular instance of source code).  

After I have a beer (or two) I'll give it another shot.  Thanks again.






-- 
View this message in context: http://old.nabble.com/error-building-tk-8.5.8-on-OS-X-10.6-tp27167210p32501077.html
Sent from the tcl-mac mailing list archive at Nabble.com.

Re: [MACTCL] error building tk 8.5.8 on OS X 10.6

[Jeff H. <je...@ac...>]

On 2011-09-19, at 4:03 PM, daneyul wrote:
> Same situation, build 8.5.9 on Snow Leopard, same errors.
> 
> As the macox Readme says it should be,  -arch i386 IS set.  
> 
> TCL goes fine, but the TK portion blows up with the previously listed issue. 
> 
> Anyone know what's the cause?

You might try the cocoa branch of 8.5.9 that is in the Fossil sources to build on Snow Leopard.

Jeff

Re: [MACTCL] error building tk 8.5.8 on OS X 10.6

[daneyul <da...@co...>]

Same situation, build 8.5.9 on Snow Leopard, same errors.

While I understand (as the macox Readme says).  -arch i386 IS set.  

TCL goes fine, but the TK portion blows up with the previously listed issue. 

Anyone know what's the cause?

Thanks!



  


-- 
View this message in context: http://old.nabble.com/error-building-tk-8.5.8-on-OS-X-10.6-tp27167210p32499155.html
Sent from the tcl-mac mailing list archive at Nabble.com.

[MACTCL] Tk with Xft enabled ...

[Luc M. <mo...@ig...>]

Hello all !

I'm porting my Tcl/Tk app on a mac. This is my first attempt to develop on a Mac, so sorry if my questions are naives.
First of all, I must use a 8.6 X11 Tcl/Tk version, which uses Xft. When compiling Tk, the --enable-xft flag is set, but configure reports an error as it can't find the Xft.h header file. This file exists, in /usr/include/X11/Xft/, as on a normal unix platform, but it isn't seen by the system header path.
I'm working with Mac OSX 10.5.8, XCode 3.1.

Is it possible to build a Xft enabled Tk ? And if so, how do I add /usr/include/X11/Xft/ to the system headers path ?

Many thanks in advance !!
Luc



----------------------------------------------------------------
Dr. Luc Moulinier,
Laboratoire de Biologie et Génomique Intégratives
IGBMC
1, rue Laurent Fries
67 404 ILLKIRCH Cedex
Phone : +33 (0)3 88 65 32 79
----------------------------------------------------------------

Re: [MACTCL] Have to click twice

[Steven <ste...@ya...>]

Thanks for the reply :)

Steven wrote:

> > With multi window apps, a friend has been lamenting
> having to click twice when switching between windows (ie -
> one click to get focus, another click to activate a widget),
> which is unlike on Linux and Windows.
...
> > Has anyone successfully tried this, or worked around
> the "have to click twice" issue in some other way ? Perhaps
> it's possible with an Operating System tweak, or even a
> custom compilation of Tcl, which we already include with our
> App (http://scidvspc.sf.net) because of problems with Snow
> Leopard's Wish 8.5.7.

Kevin wrote:

> I'm not sure I see the issues you are reporting. I have
> downloaded your
> app and can click on a button in a background window
> ("click-through"
> behavior) just fine.

This is very suprising. On our systems, with numerous Tcl builds  we haven't been able to do this. 

> In any event, the build of Tk you are using appears to be
> obsolete--it's
> based on Carbon as far as I can tell. No bugs in that
> branch of Tk are
> being fixed at this point.

And this is also very suprising. While i'm mainly concerned with finding a click-through solution, (as we now longer have known bugs with our built-in framework), i have to comment on this.

Considering the amount and severity of bugs in tk-cocoa (re the "[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no updates, multiple drawing of buttons" thread), i can't imagine how you suggest using it for our project, which handles huge databases and is a serious Chess database app - generally rivalling commercial products.

Reliability is everything in a database, and bugs in OSX Tcl is definitely the issue for us. The 32 bit build we use is the only one that works for us, after weeks and months of trial and error, messing with SnowLeopard's Wish, and learning how to build our own. Our app is very resource intensive, and probably exposes lots of frailities in OSX wish that are otherwise hard to pin-point.

(For example, on wish-8.5.7 it performs perfectly on Linux and Windows, but using Snow-Leopards Wish-8.5.7, the program crashes shortly after loading any moderate sized PGN file or database. And exhibits *unusual* behaviour and coredumps when using tk_dialog shortly before program exit. The program can be linked against your systems Framework by downloading source ( https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-4.5.tgz ), and installing into /usr/local with "./configure && make install && scid". Here http://scidvspc.sourceforge.net/tmp/sa.tar.bz2 is a small database containing 30,000 chess games. The maximum database size is ~ 16 million.)

Anyway, i understand your desire to move people to Cocoa, but considering the issues you have, which reflect our frustrating testing .... we are definitely using Carbon. ( And I should mention my OSX packager feverently wanted to use Cocoa, but gave in after much frustration).

We could suggest using Scid vs. Mac as a stress test for Tcl/Tk. It does so admirably ;> But i've found debugging it's coredumps very hard, though OS X *does* provide detailed backtraces, and the OS has never crashed for either of us i think.

----------------------

Sorry to take up so much of your time, but back to our small problem which hardly matters really ;>

I thought it was a known fact that Tk toplevels didn't have click-through on OS X. (ie - when one ScidvsMac toplevel has focus, clicking a button on another toplevel (say, the game-list) doesn't actuate the button, but merely gives the other toplevel focus.)

I don't suppose others can verify whether the App 
( http://sourceforge.net/projects/scidvspc/files/mac/ScidvsMac-4.5.dmg/download) which should definitely link to our Tk Framework AFAIK, "clicks through" (or not) for them. 

The App is an i386/PPC universal, (though PPC seems immune to all of the serious bugs that we had, despite testing with tcl-8.5.7 on the PPC box).

cheers, Steven

Re: [MACTCL] Have to click twice

[Kevin W. <kw...@co...>]

On 9/8/11 8:05 PM, Steven wrote:
> With multi window apps, a friend has been lamenting having to click twice when switching between windows (ie - one click to get focus, another click to activate a widget), which is unlike on Linux and Windows.
>
> I tried declaring secondary toplevels as transient, but to no avail.
>
> ... So now my only idea is an ugly hack like what i've outline below. We collect the FocisIn click, and generate an extra Button event at the same window location. I havent written anything yet.
>
> Has anyone successfully tried this, or worked around the "have to click twice" issue in some other way ? Perhaps it's possible with an Operating System tweak, or even a custom compilation of Tcl, which we already include with our App (http://scidvspc.sf.net) because of problems with Snow Leopard's Wish 8.5.7.
>
> Cheers, Steven Atkinson

I'm not sure I see the issues you are reporting. I have downloaded your 
app and can click on a button in a background window ("click-through" 
behavior) just fine.

In any event, the build of Tk you are using appears to be obsolete--it's 
based on Carbon as far as I can tell. No bugs in that branch of Tk are 
being fixed at this point.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[MACTCL] Have to click twice

[Steven <ste...@ya...>]

With multi window apps, a friend has been lamenting having to click twice when switching between windows (ie - one click to get focus, another click to activate a widget), which is unlike on Linux and Windows.

I tried declaring secondary toplevels as transient, but to no avail.

... So now my only idea is an ugly hack like what i've outline below. We collect the FocisIn click, and generate an extra Button event at the same window location. I havent written anything yet.

Has anyone successfully tried this, or worked around the "have to click twice" issue in some other way ? Perhaps it's possible with an Operating System tweak, or even a custom compilation of Tcl, which we already include with our App (http://scidvspc.sf.net) because of problems with Snow Leopard's Wish 8.5.7.

Cheers, Steven Atkinson

---------------------------------------

# Try to catch focus-in button press, and pass to widget
# (rough outline only)

rename toplevel tk_toplevel

proc toplevel {w args} {
  tk_toplevel $w $args  
  bind $w <FocusIn> {GenerateExtraClick %W %x %y}
}

proc GenerateExtraClick {w x y} {
  if {[focus was achieved with button click ?]} {
    event generate $w <Button-1> -button 1 -rootx $x -rooty $y
  }
  # May-be necessary ?
  bind $w <FocusIn> {} 
  bind $w <FocusOut> {
    bind $w <FocusIn> {Generate_extra_click %W %x %y}
  }
}

Re: [MACTCL] TkMacOSXDrawbableWindow problem

[Kevin W. <kw...@co...>]

Hi Alexander,

On 9/4/11 2:07 PM, Alexander Agathos wrote:
> Hi Kevin,
>
> I am working to make Togl (you know the OpenGL interface for OpenGL)
> work under Tk-Cocoa, the days of Carbon are over.

Correct.

> I am linking the Proposed Patch by Chimera :
>
> http://plato.cgl.ucsf.edu/trac/chimera/browser/trunk/foreign/Togl/togl-cocoa.patch
>
> The problem is with TkMacOSXDrawbableWindowRef, this function does not
> exist and as the patch info tell, you need a patch to Tk-Cocoa to expose
> the window. So TkMacOSXDrawbableWindowRef is a custom function that one
> should make.
> What I did is to download the tarball of TCL/TK 8.5.9 backported for
> Cocoa and write this function in tkMacOSXXStubs.c
>
>
> WindowRef
>
> TkMacOSXDrawableWindowRef(Drawable d){
>
>      WindowRef windowRef = TkMacOSXDrawableWindow(d);
>
> return windowRef;
>
> }
>
>
> And compiled the tk framework.
> Did I do the right thing?

I'm not sure if you're doing the right thing or not. That patch appears 
to be entirely focused on Togl's own API and does not require any 
special patching of Tk itself. You might want to ask the Togl developers 
how they integrate it, as I believe their app Chimera uses the same code 
base for Tk as you are trying to do.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] TkMacOSXDrawbableWindow problem

[Alexander A. <ale...@gm...>]

Hi Kevin,

I am working to make Togl (you know the OpenGL interface for OpenGL) work
under Tk-Cocoa, the days of Carbon are over.
I am linking the Proposed Patch by Chimera :

http://plato.cgl.ucsf.edu/trac/chimera/browser/trunk/foreign/Togl/togl-cocoa.patch

The problem is with TkMacOSXDrawbableWindowRef, this function does not exist
and as the patch info tell, you need a patch to Tk-Cocoa to expose the
window. So TkMacOSXDrawbableWindowRef is a custom function that one should
make.
What I did is to download the tarball of TCL/TK 8.5.9 backported for Cocoa
and write this function in tkMacOSXXStubs.c


WindowRef

TkMacOSXDrawableWindowRef(Drawable d){

    WindowRef windowRef = TkMacOSXDrawableWindow(d);

    return windowRef;

}

And compiled the tk framework.
Did I do the right thing?
Inspite of solving this issue instead of getting a drawable for OpenGL
window, I get a white window, OpenGL commands work but the problem is that
they are not rendered. Any suggestions on this?
Even if I solve this issue I will still need to include the tk framework
when I distribute my program since the program will search in the Tk
framework on another machine to find TkMacOSXDrawbableWindowRef.

Thanks,
Alexander.

On Sun, Sep 4, 2011 at 6:02 PM, Kevin Walzer <kw...@co...> wrote:

> On 9/2/11 6:21 AM, Alexander Agathos wrote:
> > Hi,
> >
> > I am working on a code that has TkMacOSXDrawbableWindowRef, this function
> is no longer supported in TCL/TK 8.5.9 Cocoa should I replace it with
> TkMacOSXDrawbableWindow? I have tried this and the linker can't find it and
> returns an error. I have tried recompiling the Cocoa based TCL/TK 8.5.9 with
> no luck the function can't be found. What should I do?
> >
> > Cheers,
> > Alexander.
>
> It might be helpful if you gave more detail on what you are trying to do
> and posted some sample code, as well as the error messages you are seeing.
>
> --Kevin
> --
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
>

Re: [MACTCL] TkMacOSXDrawbableWindow problem

[Kevin W. <kw...@co...>]

On 9/2/11 6:21 AM, Alexander Agathos wrote:
> Hi,
>
> I am working on a code that has TkMacOSXDrawbableWindowRef, this function is no longer supported in TCL/TK 8.5.9 Cocoa should I replace it with TkMacOSXDrawbableWindow? I have tried this and the linker can't find it and returns an error. I have tried recompiling the Cocoa based TCL/TK 8.5.9 with no luck the function can't be found. What should I do?
>
> Cheers,
> Alexander.

It might be helpful if you gave more detail on what you are trying to do 
and posted some sample code, as well as the error messages you are seeing.

--Kevin
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[MACTCL] TkMacOSXDrawbableWindow problem

[Alexander A. <ale...@gm...>]

Hi,

I am working on a code that has TkMacOSXDrawbableWindowRef, this function is no longer supported in TCL/TK 8.5.9 Cocoa should I replace it with TkMacOSXDrawbableWindow? I have tried this and the linker can't find it and returns an error. I have tried recompiling the Cocoa based TCL/TK 8.5.9 with no luck the function can't be found. What should I do?

Cheers,
Alexander.

Re: [MACTCL] Dvorak - Qwerty input method?

[Kevin W. <kw...@co...>]

On 8/18/11 7:46 AM, Adrian Robert wrote:
> Hi,
>
> I updated my input manager patch at:
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=3205153&group_id=12997&atid=112997
>
> to handle this case.  I don't really know my way around the issue well enough to test it thoroughly though, so help on that would be appreciated.
>
> thanks,
> Adrian
>
>
Adrian,

Thanks for this--I'll review it as soon as possible. I appreciate your 
work on the patch.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] Dvorak - Qwerty input method?

[Kevin W. <kw...@co...>]

On 8/18/11 1:06 AM, Ned Deily wrote:
> In article<4E4...@co...>,
>   Kevin Walzer<kw...@co...>  wrote:
>> On 8/17/11 5:01 PM, Ned Deily wrote:
>>> In
>>> article<nad...@ne...>,
>>>    Ned Deily<na...@ac...>   wrote:
>>>
>>>> One other, much more serious problem with the 8.5.10.1 Wish (and seen
>>>> with Python IDLE as well):  Qwerty "X" == Dvorak "Q" and pressing Cmd-X
>>>> for the common Edit menu Cut command appears to be interpreted
>>>> unconditionally as Cmd-Q and causes the app to quit!  That's kinda nasty.
>>>
>>> I've opened a Tk tracker issue for this:
>>>
>>> https://sourceforge.net/tracker/?func=detail&aid=3393315&group_id=12997&a
>>> tid=112997
>>>
>>
>> This indeed did seem very odd, but it appears that the Dvorak-Qwerty
>> keyboard layout works that way by design:
>>
>> http://stackoverflow.com/questions/808422/mac-style-dvorak-qwerty-command-keyb
>> oard-mapping-for-windows
>>
>> In other words, the layout reverts to Qwerty when the command-key is
>> pressed. It's a hybrid layout. Why it's set up that way I have no idea,
>> but the issue can probably be avoided with a pure Dvorak layout.
>>
>> So, I don't think there's anything to do here...
>
> I think you misunderstand the problem.  Yes, it is a hybrid layout and
> elsewhere the layout is working as designed.  (I assume the rationale is
> for people who are used to touchtyping Dvorak on a Qwerty keyboard.)
> The problem here is that Cocoa Tk is not handling the revert to Qwerty
> properly when the command-key is pressed.  It appears that the keyboard
> accelerators that appear in the menus *are* properly interpreted in
> Qwerty when cmd is pressed (probably Cocoa is doing this?) but, *in
> addition*, something (the Tk code?) is still trying to use the Dvorak
> layout as menu accelerators at the same time.  This leads to various
> confusions, depending what menu accelerators are defined.  The nasty one
> I noted was the accelerator cmd-X appears to also get interpreted as
> cmd-Q (since Dvorak Q is the Qwerty X key).  That leads me to think this
> might be a symptom of a bigger problem.  Why are keyboard accelerators
> apparently being processed in two different places?  Perhaps there is
> something in Tk that needs to be disable for Cocoa?  Just wild
> speculation on my part as I have no familiarity with the code.
>

OK, I'll take another look. Adrian Robert has been working on an input 
manager patch to address some other issues and he said he is including 
this in his patch.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] Dvorak - Qwerty input method?

[Adrian R. <adr...@gm...>]

Hi,

I updated my input manager patch at:

https://sourceforge.net/tracker/index.php?func=detail&aid=3205153&group_id=12997&atid=112997

to handle this case.  I don't really know my way around the issue well enough to test it thoroughly though, so help on that would be appreciated.

thanks,
Adrian



On 2011/08/18, at 1:06, Ned Deily wrote:

> In article <4E4...@co...>,
> Kevin Walzer <kw...@co...> wrote:
>> On 8/17/11 5:01 PM, Ned Deily wrote:
>>> In 
>>> article<nad...@ne...>,
>>>  Ned Deily<na...@ac...>  wrote:
>>> 
>>>> One other, much more serious problem with the 8.5.10.1 Wish (and seen
>>>> with Python IDLE as well):  Qwerty "X" == Dvorak "Q" and pressing Cmd-X
>>>> for the common Edit menu Cut command appears to be interpreted
>>>> unconditionally as Cmd-Q and causes the app to quit!  That's kinda nasty.
>>> 
>>> I've opened a Tk tracker issue for this:
>>> 
>>> https://sourceforge.net/tracker/?func=detail&aid=3393315&group_id=12997&a
>>> tid=112997
>>> 
>> 
>> This indeed did seem very odd, but it appears that the Dvorak-Qwerty 
>> keyboard layout works that way by design:
>> 
>> http://stackoverflow.com/questions/808422/mac-style-dvorak-qwerty-command-keyb
>> oard-mapping-for-windows
>> 
>> In other words, the layout reverts to Qwerty when the command-key is 
>> pressed. It's a hybrid layout. Why it's set up that way I have no idea, 
>> but the issue can probably be avoided with a pure Dvorak layout.
>> 
>> So, I don't think there's anything to do here...
> 
> I think you misunderstand the problem.  Yes, it is a hybrid layout and 
> elsewhere the layout is working as designed.  (I assume the rationale is 
> for people who are used to touchtyping Dvorak on a Qwerty keyboard.)   
> The problem here is that Cocoa Tk is not handling the revert to Qwerty 
> properly when the command-key is pressed.  It appears that the keyboard 
> accelerators that appear in the menus *are* properly interpreted in 
> Qwerty when cmd is pressed (probably Cocoa is doing this?) but, *in 
> addition*, something (the Tk code?) is still trying to use the Dvorak 
> layout as menu accelerators at the same time.  This leads to various 
> confusions, depending what menu accelerators are defined.  The nasty one 
> I noted was the accelerator cmd-X appears to also get interpreted as 
> cmd-Q (since Dvorak Q is the Qwerty X key).  That leads me to think this 
> might be a symptom of a bigger problem.  Why are keyboard accelerators 
> apparently being processed in two different places?  Perhaps there is 
> something in Tk that needs to be disable for Cocoa?  Just wild 
> speculation on my part as I have no familiarity with the code.
> 
> -- 
> Ned Deily,
> na...@ac...
> 
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
> user administration capabilities and model configuration. Take 
> the hassle out of deploying and managing Subversion and the 
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Dvorak - Qwerty input method?

[Ned D. <na...@ac...>]

In article <4E4...@co...>,
 Kevin Walzer <kw...@co...> wrote:
> On 8/17/11 5:01 PM, Ned Deily wrote:
> > In 
> > article<nad...@ne...>,
> >   Ned Deily<na...@ac...>  wrote:
> >
> >> One other, much more serious problem with the 8.5.10.1 Wish (and seen
> >> with Python IDLE as well):  Qwerty "X" == Dvorak "Q" and pressing Cmd-X
> >> for the common Edit menu Cut command appears to be interpreted
> >> unconditionally as Cmd-Q and causes the app to quit!  That's kinda nasty.
> >
> > I've opened a Tk tracker issue for this:
> >
> > https://sourceforge.net/tracker/?func=detail&aid=3393315&group_id=12997&a
> > tid=112997
> >
> 
> This indeed did seem very odd, but it appears that the Dvorak-Qwerty 
> keyboard layout works that way by design:
> 
> http://stackoverflow.com/questions/808422/mac-style-dvorak-qwerty-command-keyb
> oard-mapping-for-windows
> 
> In other words, the layout reverts to Qwerty when the command-key is 
> pressed. It's a hybrid layout. Why it's set up that way I have no idea, 
> but the issue can probably be avoided with a pure Dvorak layout.
> 
> So, I don't think there's anything to do here...

I think you misunderstand the problem.  Yes, it is a hybrid layout and 
elsewhere the layout is working as designed.  (I assume the rationale is 
for people who are used to touchtyping Dvorak on a Qwerty keyboard.)   
The problem here is that Cocoa Tk is not handling the revert to Qwerty 
properly when the command-key is pressed.  It appears that the keyboard 
accelerators that appear in the menus *are* properly interpreted in 
Qwerty when cmd is pressed (probably Cocoa is doing this?) but, *in 
addition*, something (the Tk code?) is still trying to use the Dvorak 
layout as menu accelerators at the same time.  This leads to various 
confusions, depending what menu accelerators are defined.  The nasty one 
I noted was the accelerator cmd-X appears to also get interpreted as 
cmd-Q (since Dvorak Q is the Qwerty X key).  That leads me to think this 
might be a symptom of a bigger problem.  Why are keyboard accelerators 
apparently being processed in two different places?  Perhaps there is 
something in Tk that needs to be disable for Cocoa?  Just wild 
speculation on my part as I have no familiarity with the code.

-- 
 Ned Deily,
 na...@ac...

Re: [MACTCL] Dvorak - Qwerty input method?

[Kevin W. <kw...@co...>]

On 8/17/11 5:01 PM, Ned Deily wrote:
> In article<nad...@ne...>,
>   Ned Deily<na...@ac...>  wrote:
>
>> One other, much more serious problem with the 8.5.10.1 Wish (and seen
>> with Python IDLE as well):  Qwerty "X" == Dvorak "Q" and pressing Cmd-X
>> for the common Edit menu Cut command appears to be interpreted
>> unconditionally as Cmd-Q and causes the app to quit!  That's kinda nasty.
>
> I've opened a Tk tracker issue for this:
>
> https://sourceforge.net/tracker/?func=detail&aid=3393315&group_id=12997&a
> tid=112997
>

This indeed did seem very odd, but it appears that the Dvorak-Qwerty 
keyboard layout works that way by design:

http://stackoverflow.com/questions/808422/mac-style-dvorak-qwerty-command-keyboard-mapping-for-windows

In other words, the layout reverts to Qwerty when the command-key is 
pressed. It's a hybrid layout. Why it's set up that way I have no idea, 
but the issue can probably be avoided with a pure Dvorak layout.

So, I don't think there's anything to do here...

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] Dvorak - Qwerty input method?

[Ned D. <na...@ac...>]

In article <nad...@ne...>,
 Ned Deily <na...@ac...> wrote:

> One other, much more serious problem with the 8.5.10.1 Wish (and seen 
> with Python IDLE as well):  Qwerty "X" == Dvorak "Q" and pressing Cmd-X 
> for the common Edit menu Cut command appears to be interpreted 
> unconditionally as Cmd-Q and causes the app to quit!  That's kinda nasty.

I've opened a Tk tracker issue for this:

https://sourceforge.net/tracker/?func=detail&aid=3393315&group_id=12997&a
tid=112997

-- 
 Ned Deily,
 na...@ac...

Re: [MACTCL] Dvorak - Qwerty input method?

[Ned D. <na...@ac...>]

In article <658...@ac...>,
 Jeff Hobbs <je...@ac...> wrote:
> On 2011-08-15, at 5:49 PM, Ned Deily wrote:
> > Has anyone had any experience using Aqua Tk (either Carbon or Cocoa) 
> > with the Mac OS X Dvorak - Qwerty Cmd input method.  (See System 
> > Preferences -> Language & Text -> Input Sources).  The idea behind it is 
> > to have a Dvorak keyboard layout except when the Command key is pressed 
> > (as when using keyboard accelerators): then the keyboard reverts to a 
> > standard Qwerty layout.  I had never run into it before until someone 
> > submitted this Python issue:
> > 
> >    http://bugs.python.org/issue12748
> > 
> > As I noted in the issue, I'm really not keen on tracking this down 
> > further myself at the moment but I thought I'd bring it up here in (1) 
> > to see if anyone else had any experience using this input method with Tk 
> > apps (in particular, with text processing and keyboard menu 
> > accelerators) and (2) to bring it to the attention of anyone who might 
> > want to look into it sometime.
> 
> Just an FYI that I tried this out and could confirm it with older builds, but 
> not the latest 8.5.10 Cocoa (ActiveTcl 8.5.10.1 in particular), which 
> includes fixes from Kevin Walzer on command-key handling.
> 
> I tested this by using the (wacky) Dvorak-Qwerty Cmd layout in tkcon, and 
> finding that Cmd-N (new window) and Cmd-T (new Tab) still worked while 
> regular input was Dvorak layout.

Thanks, Jeff, for testing this.  Wacky it is. That reminded me about the 
Wish Widget demo.  Using the Menus and Cascades demo with the latest 
ActiveTcl 8.4 Wish, it did appear that the 
shift-to-Qwerty-when-Cmd-pressed did not happen with 8.4 as you noted.  
With ActiveTcl 8.5.10.1, the switch from Dvorak to Qwerty with Cmd *was* 
followed,  however the Dvorak layout letters were also recognized as 
accelerators.  So, for instance, in the 8.5.10.1 Menus and Cascades demo 
(using a US keyboard with the Dvorak-Qwerty Cmd input method) pressing 
either Cmd-B or Cmd-N (Dvorak "N" == Qwerty "B") caused a "B" to be 
output.  With the 8.4 demo, only Cmd-N produces a "B".  Presumably, the 
right answer is for only Cmd-B to be recognized, not both, so it seems 
neither 8.4.19 nor 8.5.10.1 are doing exactly the right thing.

One other, much more serious problem with the 8.5.10.1 Wish (and seen 
with Python IDLE as well):  Qwerty "X" == Dvorak "Q" and pressing Cmd-X 
for the common Edit menu Cut command appears to be interpreted 
unconditionally as Cmd-Q and causes the app to quit!  That's kinda nasty.

-- 
 Ned Deily,
 na...@ac...

Re: [MACTCL] Dvorak - Qwerty input method?

[Jeff H. <je...@ac...>]

On 2011-08-15, at 5:49 PM, Ned Deily wrote:
> Has anyone had any experience using Aqua Tk (either Carbon or Cocoa) 
> with the Mac OS X Dvorak - Qwerty Cmd input method.  (See System 
> Preferences -> Language & Text -> Input Sources).  The idea behind it is 
> to have a Dvorak keyboard layout except when the Command key is pressed 
> (as when using keyboard accelerators): then the keyboard reverts to a 
> standard Qwerty layout.  I had never run into it before until someone 
> submitted this Python issue:
> 
>    http://bugs.python.org/issue12748
> 
> As I noted in the issue, I'm really not keen on tracking this down 
> further myself at the moment but I thought I'd bring it up here in (1) 
> to see if anyone else had any experience using this input method with Tk 
> apps (in particular, with text processing and keyboard menu 
> accelerators) and (2) to bring it to the attention of anyone who might 
> want to look into it sometime.

Just an FYI that I tried this out and could confirm it with older builds, but not the latest 8.5.10 Cocoa (ActiveTcl 8.5.10.1 in particular), which includes fixes from Kevin Walzer on command-key handling.

I tested this by using the (wacky) Dvorak-Qwerty Cmd layout in tkcon, and finding that Cmd-N (new window) and Cmd-T (new Tab) still worked while regular input was Dvorak layout.

Jeff

[MACTCL] Dvorak - Qwerty input method?

[Ned D. <na...@ac...>]

Has anyone had any experience using Aqua Tk (either Carbon or Cocoa) 
with the Mac OS X Dvorak - Qwerty Cmd input method.  (See System 
Preferences -> Language & Text -> Input Sources).  The idea behind it is 
to have a Dvorak keyboard layout except when the Command key is pressed 
(as when using keyboard accelerators): then the keyboard reverts to a 
standard Qwerty layout.  I had never run into it before until someone 
submitted this Python issue:

    http://bugs.python.org/issue12748

As I noted in the issue, I'm really not keen on tracking this down 
further myself at the moment but I thought I'd bring it up here in (1) 
to see if anyone else had any experience using this input method with Tk 
apps (in particular, with text processing and keyboard menu 
accelerators) and (2) to bring it to the attention of anyone who might 
want to look into it sometime.

Thanks.

-- 
 Ned Deily,
 na...@ac...

[MACTCL] 3rd Call For Papers, 18th Annual Tcl/Tk Conference 2011

[Andreas K. <and...@ac...>]

[[
    Get your papers in.

    The deadline for abstracts and proposals is
    three weeks away.
]]

18th Annual Tcl/Tk Conference (Tcl'2011)
http://www.tcl.tk/community/tcl2011/

October 24 - 28, 2011
Comfort Suites Manassas

Manassas, Virgina, USA

Important Dates:

Abstracts and proposals due   August  26, 2011
Notification to authors       September 12, 2011
WIP and BOF reservations open August   1, 2011
Author materials due          October  9, 2011
Tutorials Start               October 24, 2011
Conference starts             October 26, 2011

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2011 will be held in Manassas, Virgina, USA from
October 24 - 28, 2011. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

This year is the fourth year that the Tcl community is participating
in the Google Summer of Code.  The conference program committee would
like to encourage submissions that report on the Tcl projects selected
for Google SoC 2011.

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 26,
2011. Authors of accepted abstracts will have until October 9, 2011
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

TCLCA receives first publication rights, and expects that this is the
first time the paper is published. Not a retread from another
conference, etc. TCLCA further receives subsequent publication rights,
to handle the Publish-On-Demand nature of Lulu, our vendor for the
dissemination of the conference proceedings. All other rights are
retained by the author. You can put this on your website, include it
in a book, expand it into a novel, sell the movie rights, etc.


Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 1, 2011. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in June 2011. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2011/) and will be published on
various Tcl/Tk-related information channels.

Reservations for hotel suites can be made by calling
(703) 686-1100. Be certain to mention that you are with the Tcl/Tk
Conference to get the Tcl/Tk Conference room rate.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://aspn.activestate.com/ASPN/Mail/ to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt              Noumena Corp                    General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.       Program Chair
Cyndy Lilagan           Iomas Research, LLC
Brian Griffin           Mentor Graphics
Ron Fox                 NSCL/FRIB Michigan State University
Arjen Markus            Deltares
Mike Doyle              Iomas Research, LLC
Gerald Lester           KnG Consulting, LLC
Donal Fellows           University of Manchester
Jeffrey Hobbs           ActiveState Software Inc.
Steve Landers           Digital Smarties
Kevin Kenny             GE Global Research Center
Larry Virden            Tcl FAQ Maintainer
Steve Redler IV		SR Technology

Contact Information     tcl...@go...


Tcl'2011 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

Re: [MACTCL] Screen redraw in Tk-Cocoa--sluggish, no updates, multiple drawing of buttons

[Kevin W. <kw...@co...>]

Hi all,

With some additional input from Daniel Steffen off-list, and doing some 
additional review of recent bug reports with Tk-Coca, I've undertaken to 
dig into the issues I first mentioned in this thread, of slow redraw, 
freezes, crashes, etc.

First, I'm setting aside the issue of weird double-renditions of buttons 
that appear in the [wm manage] and [wm forget] commands, because there 
appear to be additional issues with those commands on Aqua, as reported 
here:

http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/34f8d65481c42589#

I'm the one who implemented these commands for Aqua, based on their 
implementations in Windows and X11, but there appear to be issues with 
the commands' stability that are intrinsically in conflict with the way 
windows are handled on OS X--that, according to Daniel, is why these 
were not supported from the start on Aqua. So, if you use these 
commands, proceed with caution.

Otherwise, there actually appear to be several issues here, some of 
which are related, but not all. Below are some relevant bug reports at 
SF and on c.l.t:

Event processing, bug 3028676:
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3028676&group_id=12997

Slow refresh/redrawing, bug 3166688:
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3166688&group_id=12997

Tk locks up when throwing bgerror with menu selection, bug 3285355:
http://sourceforge.net/tracker/?func=detail&aid=3285355&group_id=12997&atid=112997

Slow redraw in text widget:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/ae42036026976a1e#

I've seen all of these myself in one form or another.

To investigate the drawing issues, Daniel suggested running Tk in a 
"drawing debugger" mode, and which I did. Running the Wish demo in the 
debugger mode and also the sample script in 3166688 above, I saw no 
discernible issue with the accuracy of drawing and refreshing. However, 
in the case of 3166688's script (see gui-frames-noupdate.tcl at the SF 
link), the drawing was an order of magnitude slower than in Tk-Carbon. 
(One of the widgets used a randomly generated range of colors to 
exercise the widget.)  The bug report of slow redraw in the text widget 
at c.l.t is a bit different, in that the widget is very slow to refresh 
itself and sometimes requires a mouse click or a window resize to fully 
update itself.

The bgerror issue in bug 3285355 above, which causes Tk to freeze when 
trying to display a modal dialog in reponse to an error thrown from a 
menu or keyboard shortcut, is not so much a drawing error as an event 
processing issue; it seems that events are not being processed. That is 
also the issue directly explored in bug 3028676; if you look at the 
comments there, you see that Daniel indicates the event processing loop 
in Tk-Cocoa is quite different than in Tk-Carbon, in that the event 
notifier is both an embedded and embedding notifier (and presumably more 
complicated than the one in Carbon).

Looking at the confluence of all these bug reports, I'd like to put 
forward two observations about Tk-Cocoa:

1. The event loop/notify cycle, presumably because of its greater 
complexity, is more fragile and more prone to bugs, and this can cause 
issues with application responsiveness in such contexts as the 
bgerror/menu shortcut one.
2. In some cases Tk-Cocoa is noticably slower to redraw and refresh 
widgets than in Tk-Carbon. Whether this is because of its different 
drawing model (adapted from WebKit, which re-implements major portions 
of the NSView drawing model), its more complicated event 
loop/notification cycle, or some complex interaction between the two, 
Tk-Cocoa sometimes feels more sluggish than Tk-Carbon.

Having identified these issues, I am not sure there is anything that can 
be done to address them at a deep level. Many of Daniel's design 
decisions in developing the Cocoa port of Tk were driven by significant 
differences between the Cocoa model of applications and Tk's, and many 
of the performance/responsiveness issues we are now seeing are likely an 
unavoidable consequence of adapting Tk to fit the Cocoa way of doing 
things. The reason Carbon was initially chosen for the Tk-Aqua port is 
that it more closely matches the Tk (and presumably Xlib) model of doing 
things; Apple, of course, mandated (and, in Tk's case, funded) the 
switch to Cocoa. In any event, even if it is possible to optimize or 
improve these issues, I do not feel qualified to do so, as it touches on 
Tk-Cocoa's internals at such a low level. I am competent to fix simple 
bugs, and have closed many of them in recent months, but re-architecting 
major portions of Tk-Cocoa is not my forte.

One thing that can be done is to experiment with "update idletasks," 
"after 100," etc. in some contexts; if you look at the bug reports 
above, some people have found success with such event-loop manipulation. 
I've dealt with the bgerror issue in my own applications by redefining 
the bgerror procedure to write to standard output.

Of course, if anyone else is inclined to take a closer look at any of 
these issues and submit patches, I will be glad to review and include 
them. However, in the near future  I am probably going to close many of 
the currently reported bugs at SF as unfixable, unless someone else is 
able to present a solution to them.

As always, other viewpoints are appreciated.

Thanks,
Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[MACTCL] Screen redraw in Tk-Cocoa--sluggish, no updates, multiple drawing of buttons

[Kevin W. <kw...@co...>]

[repost from c.l.t, sent there by mistake]

Hi all,

I've been wrestling with a bug in Tk-Cocoa that is leaving me stumped, 
and I'm wondering if anyone else has any insight.

I wrote this code to test some minor updates to the wm manage/wm forget 
commands that I've implemented for Tk. The code should work under the 
latest release of ActiveTcl, if you don't have that version.

The bug I'm trying to track down is an issue with the screen redraw. 
When you run this code in Wish, and click the "dock" button, you'll get 
a new toplevel, per the [wm manage] command. Close the window, and the 
widget is packed again. Click the "dock" button again, and you may see 
*two* buttons drawn in the new toplevel, and/or some blurry lines/spots 
that indicate visual trash that hasn't been cleaned up. It doesn't 
happen on the first firing of wm forget/wm manage, but on subsequent ones.

The code below is the simplest illustration of issues with sluggish or 
incomplete screen redraw that I can come up with. I've observed this in 
Tk-Cocoa for a couple of years now, but others are seeing it also 
(Torsten Berg reported the bug on c.l.t), and it seems to be an issue.

Daniel, if you're reading, any suggestions about where in the source 
tree I should look at to deal with this? Getting deep into the internals 
of Tk drawing is a bit out of my depth, and any pointers are appreciated.

Code is below. (I *hope* this code doesn't display another bug, which is 
a hard crash under certain circumstances with the wm forget command, but 
that's another issue.) Thanks.

proc tearoff {w} {
     global docked
     pack forget $w
     wm manage $w
     update
     wm protocol $w WM_DELETE_WINDOW [list untearoff $w]

     }
     proc untearoff {w} {
     wm forget $w
     pack $w
     }


pack [frame .f]
pack [button .f.b -text "Dock" -command {tearoff .f}]

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [MACTCL] Apple's Tcl/Tk on Lion...

[David Z. <zol...@lr...>]

Le 23 juil. 2011 à 19:56, Jerry LeVan a écrit :

> Hello,
> 
> Is there some mechanism to force Apple's Tcl/Tk to run in 32 bit mode?
> I have some extensions that are only 32 bit…

Build a 32 bits starpack, you'll be sure what you run. ;)

http://wiki.tcl.tk/starpack

-- 
David Zolli
kr...@kr...
http://www.kroc.tk

Re: [MACTCL] Apple's Tcl/Tk on Lion...

[Barry S. <at...@me...>]

Info.plist goes in the Contents folder of your application
Application.app/Contents/Info.plist

It tells MacOS what executable to run [ usually ApplicationName.app/Contents/MacOS/ApplicationName ], and environmental settings / etc.
You can see examples of them in the provided file.

On Jul 23, 2011, at 1:31 PM, Jerry LeVan wrote:

> Where does this go and what is its name and what is it's scope ?
> 
> Is it global? It is my understanding that .environment.plist is only
> for guy based apps.
> 
> Thanks,
> Jerry
> 
> On Jul 23, 2011, at 2:17 PM, Barry Skidmore wrote:
> 
>> Attached in my plist.  Feel free to use it and modify it to meet your needs.
>> 
>> The records of note (modified for you) are:
>> [ This will prefer 32-bit but allow 64-bit, remove the 64-bit entires to not allow 64-bit at all ]
>> 
>> <key>LSMinimumSystemVersionByArchitecture</key>
>> 	<dict>
>> 		<key>i386</key>
>> 		<string>10.6.0</string>
>> 		<key>x86_64</key>
>> 		<string>10.6.0</string>
>> 	</dict>
>> 
>> <key>LSArchitecturePriority</key>
>> 	<array>
>> 		<string>i386</string>
>> 		<string>x86_64</string>
>> 	</array>
>> 
>> <Info.plist>
>> 
>> On Jul 23, 2011, at 12:56 PM, Jerry LeVan wrote:
>> 
>>> Hello,
>>> 
>>> Is there some mechanism to force Apple's Tcl/Tk to run in 32 bit mode?
>>> I have some extensions that are only 32 bit…
>>> 
>>> If I start tclsh with:
>>> 
>>> arch -i386 /usr/bin/tclsh
>>> 
>>> then my older extensions will load.
>>> 
>>> I have some gui-based apps ( wrapped with platypus ) that want to
>>> load the 32 bit (only) versions of the extensions.
>>> 
>>> Is there something like the VERSIONER variables that Python
>>> uses?
>>> 
>>> Is there something I can put into the environment.plist in
>>> .MacOSX to direct gui tcl apps to use 32 bit mode?
>>> 
>>> Thanks for any insights…
>>> 
>>> Jerry
>>> ------------------------------------------------------------------------------
>>> Storage Efficiency Calculator
>>> This modeling tool is based on patent-pending intellectual property that
>>> has been used successfully in hundreds of IBM storage optimization engage-
>>> ments, worldwide.  Store less, Store more with what you own, Move data to 
>>> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
>>> _______________________________________________
>>> Tcl-mac mailing list
>>> tc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>> 
>> Thanks,
>> Barry
>> 
> 

Thanks,
Barry