keep tcl-program on top 
Author Message
 keep tcl-program on top

I recently asked for an solution to keep a tcl/tk program on top
This could be done with the raise-command

I use the tcl-program on a HP9000-computer with HPUX 10.20 in a Vue
environment
The tcl-program has 2 windows
For 1 window I used the raise-command, in the other window I didn't use the
raise command.

Vue has 4 workspaces.

After I had build the raise-command in the program, and I switched to an
other workspace both windows of the program were put into the new workspace
on the top of the other programs in the new workspace.

Is there someone who can tell us about this ?
It is no problem that the venster in which I use the raise-command is placed
in the new workspace,
but it a great problem that the window in which no raise-command is used
also is placed in the new workspace

Is there someone who can help me ?

Kind regards
Martin Weterings



Sat, 08 Mar 2003 03:00:00 GMT  
 keep tcl-program on top

Quote:
> I recently asked for an solution to keep a tcl/tk program on top
> This could be done with the raise-command

> I use the tcl-program on a HP9000-computer with HPUX 10.20 in a Vue
> environment
> The tcl-program has 2 windows
> For 1 window I used the raise-command, in the other window I didn't use the
> raise command.

> Vue has 4 workspaces.

> After I had build the raise-command in the program, and I switched to an
> other workspace both windows of the program were put into the new workspace
> on the top of the other programs in the new workspace.

> Is there someone who can tell us about this ?
> It is no problem that the venster in which I use the raise-command is placed
> in the new workspace,
> but it a great problem that the window in which no raise-command is used
> also is placed in the new workspace

> Is there someone who can help me ?

Isn't this controlled by the window manager? I think the window manager
decided what windows appear to "stick" to workspaces. Maybe you have an
option set that tells VUE to keep a certain type of window on all workspaces
and it thinks that your application is that type of window.

Just a guess.

L

--
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK

Laurent Duperval                 "Montreal winters are an intelligence test,
                                         and we who are here have failed it."

Penguin Power!         ***Nothing I say reflects the views of my employer***



Sun, 09 Mar 2003 03:00:00 GMT  
 keep tcl-program on top
Laurent Duperval on keeping windows on top:

Quote:
> Isn't this controlled by the window manager?

Couldn't you define an event handler like this:
  wm protocol $window $mumble {raise $window}

Trouble is, what goes in mumble?  How do you find out what window manager
protocols exist on your system?  Is there a comprehensive list somewhere?

Thanks,
Bryce



Sun, 09 Mar 2003 03:00:00 GMT  
 keep tcl-program on top

Quote:

>Couldn't you define an event handler like this:
>  wm protocol $window $mumble {raise $window}

>Trouble is, what goes in mumble?  How do you find out what window manager
>protocols exist on your system?  Is there a comprehensive list somewhere?

The X11 ICCCM (Inter-Client Communications Conventions Manual)
lists three: WM_DELETE_WINDOW, WM_SAVE_YOURSELF, and WM_TAKE_FOCUS.

    + WM_DELETE_WINDOW is the only one that anyone really uses.

    + WM_TAKE_FOCUS should only be used if you've read and understood
      the relevant parts of the ICCCM, which I haven't :-)

    + WM_SAVE_YOURSELF used to be used for session management, but
      it has been deprecated in favor of something really bletcherous
      called ICE.

There's a note in section 4.1.2.7 saying "It is expected that this table
will grow over time," but the same three protocols have been
listed there since the first edition.

SGI's window manager, 4DWm, uses '_WM_QUIT_APP' to indicate an
"exit the entire application" request (as opposed to "close this
particular window, which is what WM_DELETE_WINDOW means).

The Motif Window manager apparently sends _MOTIF_WM_MESSAGES messages;
for what nefarious purposes I don't know.

There may be others; those are the only ones I know of.

--Joe English




Sun, 09 Mar 2003 03:00:00 GMT  
 keep tcl-program on top

Quote:

>Couldn't you define an event handler like this:
>  wm protocol $window $mumble {raise $window}

>Trouble is, what goes in mumble?  How do you find out what window manager
>protocols exist on your system?  Is there a comprehensive list somewhere?

Tk 8.4 is slated to include a [wm style] command, which will give access
to platform specific window style properties.  On Windows at least, this
will include a stayontop style.  If there is an equivalent sort of
functionality for UNIX (I don't know if there actually is a cross-window
manager, cross platform UNIX stay on top property), that will hopefully be
in there too.

So, once 8.4 is out, you should be able to do:

wm style .foo stayontop true

And your window will automagically stay on top of the others in the
system.  Of course, this is highly dependant on whether or not somebody
actually implements the [wm style] command for 8.4; any volunteers?

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions



Sun, 09 Mar 2003 03:00:00 GMT  
 keep tcl-program on top

Quote:
>Tk 8.4 is slated to include a [wm style] command, which will give access
>to platform specific window style properties.  On Windows at least, this
>will include a stayontop style.  If there is an equivalent sort of
>functionality for UNIX (I don't know if there actually is a cross-window
>manager, cross platform UNIX stay on top property), that will hopefully be
>in there too.

>So, once 8.4 is out, you should be able to do:

>wm style .foo stayontop true

Awesome!  That will be a welcome addition.  Now,if someone would just
implement a "save window to bitmap" function TK will be perfect (at
least for my needs!)

-daniel



Mon, 10 Mar 2003 03:00:00 GMT  
 keep tcl-program on top
In article


Quote:
> system.  Of course, this is highly dependant on whether or not
> somebody actually implements the [wm style] command for 8.4;
> any volunteers?

Is there any other information available on what sort of options
are under consideration for the command? And any thoughts on the
variety of window managers under UNIX and what should be done for
them? That is, some might pay attention to window hints and all
that, but a lot use some other mechanism to determine whether or
not a window stays on top. Sowhattayagonnado?

Also, I recall seeing somewheres on the Ajuba site a listing of
bugs and enhancements that were up for volunteers to take over.
Any ideas where that might be? I couldn't seem to find it under
the developer's exchange, anyways. Thanks.

: jay
--
Using self-discipline, see http://www.eiffel.com/discipline

Sent via Deja.com http://www.deja.com/
Before you buy.



Mon, 10 Mar 2003 03:00:00 GMT  
 keep tcl-program on top

Quote:


> > system.  Of course, this is highly dependant on whether or not
> > somebody actually implements the [wm style] command for 8.4;
> > any volunteers?

> Is there any other information available on what sort of options
> are under consideration for the command? And any thoughts on the
> variety of window managers under UNIX and what should be done for
> them? That is, some might pay attention to window hints and all
> that, but a lot use some other mechanism to determine whether or
> not a window stays on top. Sowhattayagonnado?

The bug database bug relating to this topic is #4016; you can view it at:

http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=4016

That description suggests access to stay-on-top, window transparency, and
control over whether the window appears in the taskbar on Windows.  I'm
sure there are other feature worth consideration (now would be a good time
to speak up with suggestions, everybody!).

As far as what to do for UNIX and its variety of window managers, I think
a good start would be to check out the ICCCM spec and find out what hint
is supposed to be used to specify stay-on-top, and make sure that the hint
is at least set properly.  Then, I would dig into the WM's that don't
follow the hints and find out how they do things, and see if there is any
degree of standardization between them.  It may be that stay-on-top can
only reliably be implemented on Windows, which is why [wm style] is
described as giving access to WM/OS specific window styles.

Quote:
> Also, I recall seeing somewheres on the Ajuba site a listing of
> bugs and enhancements that were up for volunteers to take over.
> Any ideas where that might be? I couldn't seem to find it under
> the developer's exchange, anyways. Thanks.

The page you are looking for is at this URL:

http://dev.scriptics.com/software/tcltk/8.4.roadmap.html

In addition, for people interested in contributing to the core, I suggest
reading

http://dev.scriptics.com/software/tcltk/contributing.html

Which details ways in which you can contribute, and guidelines for
contributions.

If you are interested in working on any of the projects listed on the

help you get started and coordinate your work with that of other
contributors.  Thanks!

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions



Mon, 10 Mar 2003 03:00:00 GMT  
 keep tcl-program on top
|>
|> I recently asked for an solution to keep a tcl/tk program on top
|> This could be done with the raise-command

   You'll have a problem when you run two of these and they start
fighting about which one stays on top.  You might wish to force it to
the top, but what about the user?  It is their display.

--

This message *may* reflect my personal opinion.  It is *not* intended
to reflect those of my employer, or anyone else.



Mon, 10 Mar 2003 03:00:00 GMT  
 keep tcl-program on top

Quote:
>|> I recently asked for an solution to keep a tcl/tk program on top
>|> This could be done with the raise-command

>   You'll have a problem when you run two of these and they start
>fighting about which one stays on top.  You might wish to force it to
>the top, but what about the user?  It is their display.

for the user:  if the application is sensible, it does the
  stay-on-top only if some checkbox-option is tacked (or not untacked)
  by the user.

if it does not ask the user, then it is just yet another annoying
 application (and *unasked* autoraising is only one of a big lot of
 ways to achieve that).



Tue, 11 Mar 2003 03:00:00 GMT  
 keep tcl-program on top
In article


Quote:
> The bug database bug relating to this topic is #4016; you can view
> it  at:
> http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=4016

I took a look at this, and started trying to to look at the related
items. I looked at 4017, and Jeff had added a comment that 4745 needed
to be integrated when 4017 went, but I got a permissioning error when
trying to look at 4745.

Quote:
> As far as what to do for UNIX and its variety of window managers,
> I  think a good start would be to check out the ICCCM spec and
> find out what hint is supposed to be used to specify stay-on-top,
> and make sure that the hint is at least set properly.

Well, on my reading of the ICCCM, it doesn't look like there's really
any hint that would be used to specify stay-on-top, much less any
specific spot in the stacking order, at least, not that the window
manager isn't free to ignore.

Quote:
> Then, I would dig into the WM's that don't follow the hints and
> find out how they do things, and see if there is any degree of
> standardization between them.  It may be that stay-on-top can
> only reliably be implemented on Windows, which is why [wm style] is
> described as giving access to WM/OS specific window styles.

I would think this is likely the case, that is, it might be reliable
only on Windows. There may be other options if the window manager
can be communicated with, but even that may not be that good. For
instance, fvwm could be communicated with but only if it started
the process doing the communication (at least up to 1.24 or round
there -- haven't used it in a while).

Unfortunately, I don't know if there's even a reliable way to
determine which window manager is running. Some create atoms or
properties, but some don't. What you end up with, I think, is
something like a generic interface into XSetWMProperties or
XSetWMHints.

I guess I'm interested in giving this a shot, and am just trying
to nail down some required functionality.

On a related note, I noticed two of the issues (without bug reports)
in the roadmap were "Windows wm rewrite" and "rewrite wm as obj
command". Any more details on those?

Quote:
> The page you are looking for is at this URL:
> http://dev.scriptics.com/software/tcltk/8.4.roadmap.html

Thanks for the pointer to the roadmap.

: jay
--
Using self-discipline, see http://www.eiffel.com/discipline

Sent via Deja.com http://www.deja.com/
Before you buy.



Tue, 11 Mar 2003 03:00:00 GMT  
 keep tcl-program on top

Quote:


> > The bug database bug relating to this topic is #4016; you can view
> > it  at:
> > http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=4016

> I took a look at this, and started trying to to look at the related
> items. I looked at 4017, and Jeff had added a comment that 4745 needed
> to be integrated when 4017 went, but I got a permissioning error when
> trying to look at 4745.

This is an artifact of the bug database implementation here.  We use a
single database to store bugs/rfe's for open-source projects and for our
commercial software.  4745 is a ticket for one of our commercial projects.
As such, it is not publically viewable, and thus the permision error.

Quote:
> Well, on my reading of the ICCCM, it doesn't look like there's really
> any hint that would be used to specify stay-on-top, much less any
> specific spot in the stacking order, at least, not that the window
> manager isn't free to ignore.

Don't worry if the WM ignores it; as long as we set the hint, we can
consider ourselves "out of the loop."  Too bad for you if you are using a
badly behaving WM.

Quote:
> I would think this is likely the case, that is, it might be reliable
> only on Windows. There may be other options if the window manager
> can be communicated with, but even that may not be that good. For
> instance, fvwm could be communicated with but only if it started
> the process doing the communication (at least up to 1.24 or round
> there -- haven't used it in a while).

We should avoid putting WM-specific code in Tk.  With the number and
variety of WM's out there, that is a losing proposition from the very
start.  It can only add complexity and leave people pulling out their
hair.  If there must be WM-specific code, it should go in an extension.

Quote:
> I guess I'm interested in giving this a shot, and am just trying
> to nail down some required functionality.

Excellent!  I'm looking forward to seeing what you come up with, and will
help if I can.

Quote:
> On a related note, I noticed two of the issues (without bug reports)
> in the roadmap were "Windows wm rewrite" and "rewrite wm as obj
> command". Any more details on those?

There are a whole host of minor to medium sized issues with the Windows
implementation of the wm command.  Jeff can provide more information on
that, as he has been dealing with those issues most recently.  Rewriting
wm as an obj command is ineptly named, as wm is already Tcl_Obj'ified.  I
think the intent of that line item was really just to give the wm code a
thorough scrubbing, as it has gotten pretty crusty in places.  Jeff can
expand on this, too.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions



Tue, 11 Mar 2003 03:00:00 GMT  
 
 [ 37 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Keeping top level on top.

2. Keeping a window on top

3. J: keep window always on top?

4. Keep Window On Top

5. Keeping a CW App 'on top'

6. browse:hittop keeps hitting top

7. How to keep a windows frame on top??

8. how to keep the dialogs always on top..

9. Keeping window on top

10. Keeping a 'tool' window on top

11. Keeping out-of-focus toplevel on top

12. Keeping a window on top

 

 
Powered by phpBB® Forum Software