World: r3wp

I've got a shell/rebol script (test-get-process-id.r) which starts 
with a shebang line, then the rebol header etc. :


#!/home/anton/dev/rebol/view/rebview2.7.006.4.2 -cswq --script test-get-process_id.r
rebol [
...


what's strange is that rebol starts up in trace mode, so it outputs 
a lot of trace information to the bash shell. I'd like to suppress 
the trace mode, and it's strange that it is switched on without me 
asking for it. Anybody have any information on this?

According to USAGE, trace mode is enabled with the -t flag.

I found the problem - I shouldn't have specified the rebol script 
file on the shebang line. That's given automatically.

It should be simply:

#!/home/anton/dev/rebol/view/rebview2.7.006.4.2 -cswq
rebol [
...

I now seem to be able to list windows associated with a given process 
id. I've tried the konsole pid, and I get five result windows...

Damn! It doesn't seem to work for rebol.

Time to go to the next level of hackery.

Just noticed an existing tool 'zenity' that might be able to change 
rebol window titles.
I might check that out later.
http://tripie.sweb.cz/utils/wmctrl/

Anton, you can get info on your own process from /proc/self

Gabriele, thanks, I'm having a look inside. Do you know if associated 
windows can be found?

It looks, probably, like the window id of the shell rebol sits in 
can be found in /proc/self/environ

call "echo $WINDOWID"    <-- prints an integer. Probably still the 
shell window.

I'm still looking for a way to identify the windows opened by a rebol 
process... Lots of info to wade through.

Isn't any such info under Linux also dependant upon using various 
window managers/toolkits?

I don't think so. The window managers sit on top of the X Windows 
system and get it to do the basics - opening windows etc.

http://library.gnome.org/devel/gdk/unstable/gdk-X-Window-System-Interaction.html
- there is for e.g. gdk window lookup func, which says something 
about wrapping some native window handle. Dunno what they are talking 
about, but maybe you will find some pointers. Well, you probably 
investigated many such docs, so maybe useless link ...

Well, there could be something there (I had a quick look), but I 
probably want to target the X Window core system, or, look at all 
resources allocated by a process and then see which ones are opened 
windows.

I will ask one person tomorrow whom I do regard being a guru. Not 
sure he is working with windows - he's a typical kernel and console 
guy :-)

Thanks, I hope he knows something.

Tomorrow I'll try the X.org mail lists.

I got reply from my other colleague who started to write video player 
upon ffmpeg. He uses SDL, and there is a parameter called - SDL_NOFRAME. 
Maybe you could look, how SDL handles it? What is more - their wrappers 
should be cross-platform, so we might find solution for more than 
one OS actually ....

Firefox has kiosk mode where window frames and titles disappear...may 
work differnetly than normal windows without titlebars..maybe simpler 
to do

SDL is something definitely worth checking out, but Rebol does not 
use SDL, it uses X windows, and I want the pointer to those windows 
opened by Rebol.

In order to manipulate windows opened by Rebol, I need to have the 
pointer to them. There is no escaping this.

Anton - I know. My point is, that if SDL can do it, cross platform, 
looking into their source will reveal actually HOW they do it, no? 
They have to call some Linux underlying code, to achieve no-border 
window. ...

Right, but before I get to manipulating the window, I need to have 
the window pointer. If I don't have a way of getting that from the 
process id,  then it remains hypothetical.

X.org maillist doesn't have any easy answers to this, either. Looks 
like it really is time to hack. This will be a big job.

if [ -f bin/FaxDispatch ]; then
	. bin/FaxDispatch	
    fi

what's the meaning of this shell script ?

-f ... is that equivalent to exists?

Yes.

Search for "-f file" in bash manpage.

-f file
	True if file exists and is a regular file.

There's a whole host of other one-letter variants for checking other 
types of objects that may be present in the filesystem.

It's completely brain-damaged for bash to use one-letter options 
for this - but that's the situation.

Maybe some small hints in there? http://tonyobryan.com/index.php?article=9

Maybe, or definitely? I've been following "maybes" for about 16 hours 
now.

Ok, it does look quite useful. (But only after you have the window 
pointer.)

exactly, the pointer ... don't ask me about usefulness, I have little 
to zero C knowlege, so :-) Waiting for my friend's reply ....

Hmm, so I downloaded SDL sources, looked thru it, but not knowing 
C properly it is not clear to me, what is happening there :-) But 
decomposing various video related parameters I got down to:

SDL_windowid = SDL_getenv("SDL_WINDOWID")


So they seem to get windowID from SDL_getenv call, which is function 
simply getting environmental vars ... so - probably not helpful either 
:-)

So, maybe REBOL process should be responsible to update/provide some 
environmental var for particular window? Is it possible REBOL process 
is not simply doing so?

Probably that env var is set up by SDL, and only for a window which 
the SDL system knows about. Since rebol doesn't use SDL to open its 
windows, SDL (most likely) won't know about those windows.

But anyway, I'm heading down the DLL injection path, using LD_PRELOAD. 
I have a simple LD_PRELOAD example working, which intercepts calls 
to the time() function (and works with rebol). The next example I'll 
try will intercept X window calls.

I know that SDL can't help you to get REBOL's window handles :-) 
I just thought that we might look into how others are obtaining them, 
and then to try similar aproach for REBOL. But anyway, you surely 
will find your way thru!

Ok, I can now intercept the XCreateSimpleWindow call ! Woo!  The 
hard part seems over... Now to remember what I wanted it for...

:-)

The 'xprop' command can see the hacked-in process id. Proof of concept.

Joining more dots - the C code can match the pid to the window. Now 
I can sleep.

anton you mean that you have REBOL callbacks being triggered when 
it tries to open the window!!!!!   :-D

?

Not Rebol callbacks. A DLL built using C is injected using LD_PRELOAD 
when running any executable. The executable I'm interested in is 
Rebol, of course. This injected code intercepts calls to XCreateSimpleWindow 
(which creates the X Windows window), and adds some properties to 
it, including one which stores the process id of the application 
opening the window. This means that each X window can be ensured 
to have the process id of the application that opened it (which is 
otherwise not mandated by X). So I could do that to any program and 
it would ensure that there is a way to get the process id. I'm doing 
it to Rebol, and this means it is now possible for another DLL function 
(called from Rebol) to scan all the windows opened on the X display 
and see which one has the Rebol process id. All you need is the process 
id, and this is easy to do with a very small DLL function call.

I was starting to think about how I could possibly get a rebol callback 
happening, though. That should obviate the need to scan all open 
windows, which is a crude way of getting information.