osx wish foreground issue

I've search all over for info on this, and only find a couple old hits
that hint at this issue, but I'm sure there must be some simple fix.

If I write a very simple tcl program that creates a button with some
text, center the main window, and execute this from an OSX terminal
command line (like "./mytest.tcl", which causes /usr/bin/wish to run),
the window/button come up *behind* the terminal app. I can't seem to
figure out how to make the app just show up on top of everything, like
most apps I run from the command line.

Any ideas?

I'm relatively new to both TCL and OSX; I don't run into this issue on
windows or linux.

-thomas

On Aug 22, 6:08 pm, blomc...@gmail.com wrote:
> I've search all over for info on this, and only find a couple old hits
> that hint at this issue, but I'm sure there must be some simple fix.
>
> If I write a very simple tcl program that creates a button with some
> text, center the main window, and execute this from an OSX terminal
> command line (like "./mytest.tcl", which causes /usr/bin/wish to run),
> the window/button come up *behind* the terminal app. I can't seem to
> figure out how to make the app just show up on top of everything, like
> most apps I run from the command line.
>
> Any ideas?
>
> I'm relatively new to both TCL and OSX; I don't run into this issue on
> windows or linux.
>
> -thomas

The best I have found so far is this:

catch {
exec osascript -e "tell app \"Finder\"" -e " set frontmost of
process \"Wish Shell\" to true" -e "end"
}

which uses applescript to find the process named "Wish Shell" and
bring it to foreground. This is not robust if there is more than 1
instance of wish running. I haven't figured out how to specify a PID
instead of a process name.

This is incredibly frustrating... Someone please help -- surely there
are OSX folks out there writing tcl apps? Why doesn't the app end up
in the foreground in the first place?

thanks for any advice --thomas

On 22 août, 19:36, blomc...@gmail.com wrote:
> On Aug 22, 6:08 pm, blomc...@gmail.com wrote:
>
>
>
> > I've search all over for info on this, and only find a couple old hits
> > that hint at this issue, but I'm sure there must be some simple fix.
>
> > If I write a very simple tcl program that creates a button with some
> > text, center the main window, and execute this from an OSX terminal
> > command line (like "./mytest.tcl", which causes /usr/bin/wish to run),
> > the window/button come up *behind* the terminal app. *I can't seem to
> > figure out how to make the app just show up on top of everything, like
> > most apps I run from the command line.
>
> > Any ideas?
>
> > I'm relatively new to both TCL and OSX; I don't run into this issue on
> > windows or linux.
>
> > -thomas
>
> The best I have found so far is this:
>
> catch {
> * * exec osascript -e "tell app \"Finder\"" -e " set frontmost of
> process \"Wish Shell\" to true" -e "end"
>
> }
>
> which uses applescript to find the process named "Wish Shell" and
> bring it to foreground. *This is not robust if there is more than 1
> instance of wish running. *I haven't figured out how to specify a PID
> instead of a process name.
>
> This is incredibly frustrating... *Someone please help -- surely there
> are OSX folks out there writing tcl apps? *Why doesn't the app end up
> in the foreground in the first place?
>
> thanks for any advice --thomas

Hi Thomas,

Unfortunately I don't have a Mac handy, but you might try sticking [wm
deiconify $nameofyourtoplevelwindow] in your script to see if that
helps anything. You might check out the wm man page in general to see
if anything there might help.

Sorry to not be of more help. Best luck,
Aric

> Hi Thomas,
>
> Unfortunately I don't have a Mac handy, but you might try sticking [wm
> deiconify $nameofyourtoplevelwindow] in your script to see if that
> helps anything. You might check out the wm man page in general to see
> if anything there might help.
>
> Sorry to not be of more help. Best luck,
> Aric

wm deiconify, raise, and the like have no effect. This seems to be an
issue outside of the scope of the tcl program being interpreted. I
found reference in an old thread discussing GRASS, some tcl GIS-type
software, in which a programmer had *written a simple program*
(presumably Cocoa or Carbon?) that is called by the running tcl
program to bring it to the foreground... What a hack (though perhaps
necessary). I know so little about native osx programming that this
simple approach has eluded me so far (I can get the PID of the running
tcl process, but don't know yet how to write a simple osx app or
script to retrieve the top-level window for a running process and
bring it to foreground).

It is strange that this problem is so little referenced; I wonder if
it has to do with a particular system configuration. The problem of a
tcl app started from command line starting up behind other windows
(e.g. behind the terminal window from which it was launched) has not
always plagued me on osx since I started using it a year ago; at some
point it started happening, perhaps due to some automated system
update etc.

On Aug 22, 4:08*pm, blomc...@gmail.com wrote:
> I've search all over for info on this, and only find a couple old hits
> that hint at this issue, but I'm sure there must be some simple fix.
>
> If I write a very simple tcl program that creates a button with some
> text, center the main window, and execute this from an OSX terminal
> command line (like "./mytest.tcl", which causes /usr/bin/wish to run),
> the window/button come up *behind* the terminal app. *I can't seem to
> figure out how to make the app just show up on top of everything, like
> most apps I run from the command line.

You want the special tclCarbonProcesses extension for OS X and to use
the setFrontProcess call.

Jeff

>
> You want the special tclCarbonProcesses extension for OS X and to use
> the setFrontProcess call.
>
> Jeff

Thanks for the tip. I see that this makes a sytem call
to ::setFrontProcess. I also discovered another way to solve this
problem -- wrap the main tcl script in an "application bundle" and
execute it with "open <appname>". This has the advantage lf allowing
me to provide a custom icon file and name the app as desired, such tht
viewing the command bar or tabbing thru apps causes my app to show a
custom icon instead of hte wish icon....

thanks! -thomas

blomcode@gmail.com wrote:
>> You want the special tclCarbonProcesses extension for OS X and to use
>> the setFrontProcess call.
>>
>> Jeff
>
> Thanks for the tip. I see that this makes a sytem call
> to ::setFrontProcess. I also discovered another way to solve this
> problem -- wrap the main tcl script in an "application bundle" and
> execute it with "open <appname>". This has the advantage lf allowing
> me to provide a custom icon file and name the app as desired, such tht
> viewing the command bar or tabbing thru apps causes my app to show a
> custom icon instead of hte wish icon....

BTW, the TclDev Kit from ActiveState has a tool, TclApp, that makes this
real easy to do. It also allows you to generate executables for other OSes
on the Mac.


--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

On Aug 25, 2:02 pm, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
> blomc...@gmail.com wrote:
> >> You want the special tclCarbonProcesses extension for OS X and to use
> >> the setFrontProcess call.
>
> >> Jeff
>
> > Thanks for the tip. I see that this makes a sytem call
> > to ::setFrontProcess. I also discovered another way to solve this
> > problem -- wrap the main tcl script in an "application bundle" and
> > execute it with "open <appname>". This has the advantage lf allowing
> > me to provide a custom icon file and name the app as desired, such tht
> > viewing the command bar or tabbing thru apps causes my app to show a
> > custom icon instead of hte wish icon....
>
> BTW, the TclDev Kit from ActiveState has a tool, TclApp, that makes this
> real easy to do. It also allows you to generate executables for other OSes
> on the Mac.
>
> --
> +--------------------------------+---------------------------------------+
> | Gerald W. Lester |
> |"The man who fights for his ideals is the man who is alive." - Cervantes|
> +------------------------------------------------------------------------+

Thanks, I will look into this.

But I have to say, all of this is quite an effort to go to to simply
get a tcl application to appear in the foreground when launched, which
is expected behavior for any app on any platform that is not
specifically launched as a background process. I don't understand why
tcl/tk apps on the mac don't do this automatically. I suppose this is
an issue with the aqua/tk system, so perhaps I'll ask around there.

-thomas

blomcode@gmail.com wrote:
> On Aug 25, 2:02 pm, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
>> blomc...@gmail.com wrote:
>>>> You want the special tclCarbonProcesses extension for OS X and to use
>>>> the setFrontProcess call.
>>>> Jeff
>>> Thanks for the tip. I see that this makes a sytem call
>>> to ::setFrontProcess. I also discovered another way to solve this
>>> problem -- wrap the main tcl script in an "application bundle" and
>>> execute it with "open <appname>". This has the advantage lf allowing
>>> me to provide a custom icon file and name the app as desired, such tht
>>> viewing the command bar or tabbing thru apps causes my app to show a
>>> custom icon instead of hte wish icon....
>> BTW, the TclDev Kit from ActiveState has a tool, TclApp, that makes this
>> real easy to do. It also allows you to generate executables for other OSes
>> on the Mac.
>>
>> --
>> +--------------------------------+---------------------------------------+
>> | Gerald W. Lester |
>> |"The man who fights for his ideals is the man who is alive." - Cervantes|
>> +------------------------------------------------------------------------+
>
> Thanks, I will look into this.
>
> But I have to say, all of this is quite an effort to go to to simply
> get a tcl application to appear in the foreground when launched, which
> is expected behavior for any app on any platform that is not
> specifically launched as a background process. I don't understand why
> tcl/tk apps on the mac don't do this automatically. I suppose this is
> an issue with the aqua/tk system, so perhaps I'll ask around there.

I think it was a call when the original ports were made and it was decided
to emulate the older unix/X11 behavior and not jump in front of the window
you were focused in.


--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

On Aug 25, 12:18*pm, blomc...@gmail.com wrote:
> But I have to say, all of this is quite an effort to go to to simply
> get a tcl application to appear in the foreground when launched, which
> is expected behavior for any app on any platform that is not
> specifically launched as a background process. *I don't understand why
> tcl/tk apps on the mac don't do this automatically. *I suppose this is
> an issue with the aqua/tk system, so perhaps I'll ask around there.

What you think is not what is true. This is an intentional behavior
on OS X by the OS itself and effects more than Tcl/Tk. Read up on why
in the archives here or the tcl-mac mailing list.

Jeff