Prev: accessing GUI with TWAPI (was: Accessing GUI of CAD through Tcl/Tk)
Next: Where can I find "tcom" package for Linux?
From: ggw on 14 Dec 2009 23:32
Ignorance on my part. There are so many things to learn about Tk/Tcl
when coming forward from the Tk4 world. My one and only search last
January did not turn up an explicit suggestion except in "specialized"
versions. Also, at the time, I was attempting to compile it for myself
and got all fouled up with Expect not behaving at all well. I was
ultimately waved off and *told* to use ActiveTcl which I did. It
worked so I stopped looking at any of it.

Now (again) my situation has changed. A question on this forum is
quite inexpensive as long as I can take the heat for not working it
out for myself.

The older I get, the less proud I am. I take suggestions seriously.

Yours is wonderful news, and it gives me a clear direction to go.

Thanks. (You also helped me last January, too)

ggw
On Dec 14, 3:12 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:
> On Dec 14, 3:33 am, ggw <gwy...(a)io.com> wrote:
>
>
>
> > On Dec 13, 2:58 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> > wrote:
> > [ If, instead of describing the somewhat short-sighted "solution" ]
>
> > OK.
> > - - - - - - - - - - - - -
> > I want Tk to handle the X11 events (redraw the screen) for an
> > existing, Expect controlled, program that updates a file of a
> > rectangle of pixel data.
>
> > - - - - - - - - - - - - -
>
> > This Solaris  program modifies a file that that it thinks is a screen..
> > Expect/Tk wrap the program (adding mouse support in particular) and
> > handle transferring of the file data to the screen.  Works like a
> > charm with old Tk4.0's TkCanvas.c modified to do just that. However,
> > modifying TkCanvas.c is best avoided, hence I seek confirmation (or
> > not) that today's Tk "can do".
>
> To transfer data to screen, the normal script-level way is to use a Tk
> (photo) image, assuming the format is among the supported ones:
>
>     image create photo myimg
>     myimg read $filename
>
> alternatively (eg if the data come over a pipe instead of a regular
> file),
>
>     set data [read $channel $length]
>     myimg data $data
>
> As a last resort, eg if the format is a bit more exotic, you can write
> an extension to populate the above photo image's buffer with data at
> the C level.
>
> What's important though is that none of these approaches needs a
> dedicated patch to the core. Please tell me what prevents you from
> going that route.
>
> -Alex

From: ggw on 14 Dec 2009 23:35
Your suggestions are numerous. If my progress gets too slow, I come
back to them for inspiration, but for now they seem a bit too hazy and
I hate to keep asking, "What does this mean?... and this?"

ggw
On Dec 14, 3:58 am, hae <r_haer...(a)gmx.de> wrote:
> On 14 Dez., 03:33, ggw <gwy...(a)io.com> wrote:
>
>
>
> > On Dec 13, 2:58 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> > wrote:
> > [ If, instead of describing the somewhat short-sighted "solution" ]
>
> > OK.
> > - - - - - - - - - - - - -
> > I want Tk to handle the X11 events (redraw the screen) for an
> > existing, Expect controlled, program that updates a file of a
> > rectangle of pixel data.
>
> > - - - - - - - - - - - - -
>
> > This Solaris  program modifies a file that that it thinks is a screen..
> > Expect/Tk wrap the program (adding mouse support in particular) and
> > handle transferring of the file data to the screen.  Works like a
> > charm with old Tk4.0's TkCanvas.c modified to do just that. However,
> > modifying TkCanvas.c is best avoided, hence I seek confirmation (or
> > not) that today's Tk "can do".
>
> > > On Dec 13, 8:59 pm, ggw <gwy...(a)io.com> wrote:
>
> > > > Back in the late 1980, our programmers modified tkCanvas.c to have a
> > > > static
> > > >   static XImage *dispixstruct;
> > > >   static char *dispixmapaddress;
> > > >   static int dispixmap_id;
> > > > and modified its DisplayCanvas() to check dispixmapaddress (0 the 1st
> > > > time) and if 0, map a specific file storing its address at
> > > > dispixmapaddress. Then and, there after it, it would
> > > > XPutImage(Tk_Display(tkwin),Tk_WindowId(tkwin),canvasPtr->pixmapGC,
> > > >                      dispixstruct,
> > > >                      screenX1,screenY1,screenX1,screenY1,screenX2-
> > > > screenX1,screenY2-screenY1);
>
> > > > (Another program controlled by Expect would modify that specific
> > > > file.)
>
> > > > That was then. A very easy recompile to get the Tk library, and all
> > > > was cool.
>
> > > > Now, I want to use Tk8.5, in my desire to keep up to date, so I have 2
> > > > questions:
>
> > > >  1) Does Tk have a way these days to accomplish the above without my
> > > > resorting to modifying "official" Tk8.5 source code?
> > > >  2) If "No!" to #1, how can I, after again modifying tkCanvas.c, go
> > > > about making a Tk library. Last XMas I tried doing straight compiles
> > > > on Tk (using gcc), but had trouble.  In this forum I was advised give
> > > > up and use ActiveTcl provided stuff, which I did and was sufficient
> > > > for my needs at the time.
>
> > > > gwy...(a)io.com
>
> > > If, instead of describing the somewhat short-sighted "solution" (the
> > > static), you described the problem (what you want to achieve in terms
> > > of external behavior), I'm sure you'd get back the optimal solution in
> > > no time, and quite possibly one that's compatible with unmodified
> > > wish.
>
> > > -Alex
>
> Why don't you check this file say every 100 ms and then update the
> canvas from script level as Alexandre suggests?
>
> As you are on solaris you don't have dnotify/inotify (linux) or twapi
> (windows) that could inform you with a callback when the file changes.
> But is is only polish, I think.
>
> Ruediger

From: ggw on 16 Dec 2009 22:15
On Dec 14, 3:12 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:
> On Dec 14, 3:33 am, ggw <gwy...(a)io.com> wrote:
>
>
>
> > On Dec 13, 2:58 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> > wrote:
> > [ If, instead of describing the somewhat short-sighted "solution" ]
>
> > OK.
> > - - - - - - - - - - - - -
> > I want Tk to handle the X11 events (redraw the screen) for an
> > existing, Expect controlled, program that updates a file of a
> > rectangle of pixel data.
>
> > - - - - - - - - - - - - -
>
> > This Solaris  program modifies a file that that it thinks is a screen..
> > Expect/Tk wrap the program (adding mouse support in particular) and
> > handle transferring of the file data to the screen.  Works like a
> > charm with old Tk4.0's TkCanvas.c modified to do just that. However,
> > modifying TkCanvas.c is best avoided, hence I seek confirmation (or
> > not) that today's Tk "can do".
>
> To transfer data to screen, the normal script-level way is to use a Tk
> (photo) image, assuming the format is among the supported ones:
>
>     image create photo myimg
>     myimg read $filename
>
> alternatively (eg if the data come over a pipe instead of a regular
> file),
>
>     set data [read $channel $length]
>     myimg data $data
>
> As a last resort, eg if the format is a bit more exotic, you can write
> an extension to populate the above photo image's buffer with data at
> the C level.
>
> What's important though is that none of these approaches needs a
> dedicated patch to the core. Please tell me what prevents you from
> going that route.
>
> -Alex

@Alex

I found this quote through wikipedia and I cannot understand its
import. Why does the event loop not have to handle Expose and redraw
events?

Applications using any of these widget libraries typically specify the
content of the window before entering the main loop and do not need to
explicitly handle Expose events and redraw the window content.

This applies to my situation. It is almost saying I don't have to do
ANYTHING with Tk. Does Tk have some thread to do it? Does it fork the
process whose sole job is to handle expose events? Surely, Tk gets
events when the window I'll be sharing with it changes. But if my
program is under my control and I sit at a prompt with a c "select"
statement that does NOT include X anything, then who (and when) is
handling the Expose when I move a window across my app? Is it in the
graphics card? Is it a built in option of my Xserver? Is it Tk? Is it
Expect? Is there no clear way to find out?

gwyche
From: Alexandre Ferrieux on 17 Dec 2009 03:00
On Dec 17, 4:15 am, ggw <gwy...(a)io.com> wrote:
> On Dec 14, 3:12 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> wrote:
>
>
>
>
>
> > On Dec 14, 3:33 am, ggw <gwy...(a)io.com> wrote:
>
> > > On Dec 13, 2:58 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
> > > wrote:
> > > [ If, instead of describing the somewhat short-sighted "solution" ]
>
> > > OK.
> > > - - - - - - - - - - - - -
> > > I want Tk to handle the X11 events (redraw the screen) for an
> > > existing, Expect controlled, program that updates a file of a
> > > rectangle of pixel data.
>
> > > - - - - - - - - - - - - -
>
> > > This Solaris  program modifies a file that that it thinks is a screen.
> > > Expect/Tk wrap the program (adding mouse support in particular) and
> > > handle transferring of the file data to the screen.  Works like a
> > > charm with old Tk4.0's TkCanvas.c modified to do just that. However,
> > > modifying TkCanvas.c is best avoided, hence I seek confirmation (or
> > > not) that today's Tk "can do".
>
> > To transfer data to screen, the normal script-level way is to use a Tk
> > (photo) image, assuming the format is among the supported ones:
>
> >     image create photo myimg
> >     myimg read $filename
>
> > alternatively (eg if the data come over a pipe instead of a regular
> > file),
>
> >     set data [read $channel $length]
> >     myimg data $data
>
> > As a last resort, eg if the format is a bit more exotic, you can write
> > an extension to populate the above photo image's buffer with data at
> > the C level.
>
> > What's important though is that none of these approaches needs a
> > dedicated patch to the core. Please tell me what prevents you from
> > going that route.
>
> > -Alex
>
> @Alex
>
> I found this quote through wikipedia and I cannot understand its
> import. Why does the event loop not have to handle Expose and redraw
> events?
>
> Applications using any of these widget libraries typically specify the
> content of the window before entering the main loop and do not need to
> explicitly handle Expose events and redraw the window content.
>
> This applies to my situation. It is almost saying I don't have to do
> ANYTHING with Tk. Does Tk have some thread to do it? Does it fork the
> process whose sole job is to handle expose events? Surely, Tk gets
> events when the window I'll be sharing with it changes. But if my
> program is under my control and I sit at a prompt with a c "select"
> statement that does NOT include X anything, then who (and when) is
> handling the Expose when I move a window across my app? Is it in the
> graphics card? Is it a built in option of my Xserver? Is it Tk? Is it
> Expect? Is there no clear way to find out?

Sorry, but I'm having trouble even groking the mindset you're in to
ask such questions :-}

Is this a question out of curiosity, to understand how Tk is working
under the hood for your own education only, or do you really want to
ignore my suggestion to do everything at script level, and stick to
calling Xlib functions ?

If the former:

Tk works in an utterly single-threaded manner (it even doesn't marry
too well with Tcl threads, in case you wonder: all things Tk-ish must
be done in a single thread+interp). This means that the Tcl event loop
(the part of the system sitting on a select() most of the time) reacts
to X events (the X socket being in the select's read mask) when they
occur _and_ Tcl is not doing something else. Single-threaded, repeat.
And what is done on Expose event is entirely decided by the code for
the specific widget. For example, for a canvas with a photo image, it
amounts to drawing the pixmap stored in the image.

If the latter:

Either give a justification for why using script level is
inappropriate, or get lost. I won't promote suboptimal uses of the Tcl/
C interface.

-Alex

From: Uwe Klein on 17 Dec 2009 04:05
Alexandre Ferrieux wrote:
> Sorry, but I'm having trouble even groking the mindset you're in to
> ask such questions :-}

ggw was wondering why one does not have to set up explicit
expose and redraw events. ( and assumed that there are no
implicit event handlers ).

The answer is:

expose and redraw events are handled in the eventloop but behind
the scenes in Tk. The information present on most widgets is
sufficient to handle these events without taking recourse to
application specific programming.

Tk is the holy grail of implicitness ?

uwe


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: accessing GUI with TWAPI (was: Accessing GUI of CAD through Tcl/Tk)
Next: Where can I find "tcom" package for Linux?