Subject: FVWM: socket ala CORBA, silly idea?

From: Michael Corrieri <[email-masked]>
Date: Mon, 04 May 1998 07:58:22 -0600

Why not just socket fvwm ala CORBA, and let anyone use whatever (oo)
language they want?

You could just publish the interfaces (if you do it right, CORBA will
publish the interfaces for you, we just pass out the ORBs).

Finis.

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Albrecht Kadlec <[email-masked]>
Date: 04 May 1998 23:13:33 +0200

> publish the interfaces for you, we just pass out the ORBs).

I'd like to be able to kill windows by combining any of the info FvwmIdent
supplies and any other external info like core size or whatever bites me
tomorrow, with just some lines of any interpreted language, but WITHOUT
writing an own module in C.

1) Fvwm2's internal language cannot do everything.
2) An external language still cannot access fvwm2's internal information.

ad 1)	At least chuck can and should not include a full language into FVWM.
	At least as long as the V in Fvwm stand for "Versatile" and the F
	for "still useable" :-)

ad 2)	I'm talking about window position, window flags, window stacking
	order & the like. 

	Fvwm already has pretty much internal data, but it's less effort 
	and more versatile to let e.g. python access & manipulate the
	window data structure than to reproduce all possibilities of
	python. 

when .fvwmpipe came up, I thought: 
why not just let fvwm read stdin / write stdout in a _really_ _basic_ maybe
just _machine_readable_ language and feed that language interpreter from
any subtle frontend.

hmm, I didn't get to think further ....
at least you can send fvwm some commands via FvwmPipe. It'd be nicer, if
you also got some info from fvwm (e.g: which windows exist, which one has
focus), before you do something to them.

anyway:

Either there's a full language in fvwm2, or a possibility to export fvwm2's
native (!) functions & datastructures (!!) to any unix program.

Anything inbetween is orders of magnitude less useable.

I vote for elaborating on 2) rather than 1)
-- 
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
The pyroheliometer sensitivity was insufficient to record starlight,
and we observed no significant solar radiation at night :-)
		-- Nick Pine, looking for solar energy
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Michael Corrieri <[email-masked]>
Date: Mon, 04 May 1998 19:08:35 -0600

> I vote for elaborating on 2) rather than 1)

(and much other important stuff I snipped, you can refer to his post)

I would say #2 is the best way. You would never find yourself at this crossroads
again. Period.

And CORBA is the standard the whole industry has gone, with the exception of
Microsoft (they want us to use DCOM, and I refuse). Good riddance.  Strong
Middleware makes strong enterprise applications. We could easily get the
published specs and make it truly CORBA compliant. Yikes.

Then let the user decide what language (or any other modules, if any) he wants.

I would think a converter for existing scripts would be pretty acceptable to
current users.