CLIM mail archive
[Prev][Next][Index][Thread]

Re: Overlapping windows to CLIM application frameworks

    Date: Tue, 14 Jul 1992 08:46 EDT
    From: Stefan Bernemann <berni@iml.fhg.de>

	Date: Mon, 13 Jul 1992 19:39 MEST
	From: Jeff Morrill <jmorrill%BBN.COM@fhg.de>

	...

	It sounds like you are trying to implement the "desktop" metaphor.
	This makes a great deal of sense but it may be difficult for clim
	to deal with.

	I have tried implementing it as having a bunch
	of application frames that the user is free to bury, resize, reposition,
	and so on.  The frames are conceptually part of a single activity, and this
	causes some difficulty because it is not clear how they should all
	interact.

    That's exactly what we need, too. Can someone comment on how CLIM 2.0
    will deal with this subject? Are those "frame-managers" the solution
    that clim programmers are to  use/implement (without "multi-proceccing")?

No deep thought has been spent in this area.  Nobody with a vested
interest has submitted any proposal in this area, never mind a coherent
proposal.  As usual, concrete proposals are welcome.

	What a desktop metaphor needs is a single top-level loop for reading
	commands from any of several frames in the desktop.  It is possible
	to trick clim into doing this, but it is a bit of a kludge and
	requires getting your hands dirty with clim internals.

    Can you provide some (example) code, as the documentation on how to
    implement my own top-level loop seems to be too straight for my simple
    mind...
    The lisp listener from the examples also doesn't enlighten me too much
    for this problem. 
    Again, is there a chance that the functionality of this code will be
    part of clim 2.0?

	Even so, clim's design makes this alternative difficult because
	you can't use *application-frame* anymore and because you have
	to keep track of all the frames on your desktop so that things like EXIT
	will do the right thing.  You also must redisplay frame panes
	manually since clim doesn`t know how.

	It is a little easier to associate each frame with its own process.
	Then clim works pretty good, but only because you have
	broken a single activity into artificially many activities.  The
	worst part about this alternative is that you have many input contexts,
	one for each frame, whereas there ought to be only one.

	The impression one gets from reading the clim documentation is that
	there must be a one-to-one correspondence between applications and
	frames.  If you can live with this assumption, then your life will
	be easier.  But I wish the assumption could be removed.


    Thanks a lot - Stefan B.

    Mail: Stefan Bernemann        ! Phone:  +49-231-9743-139
	  c/o FhG IML Dortmund    ! Fax:    +49-231-9743-234
	  Emil-Figge-Str. 75      ! Email:  berni@iml.fhg.de
	  D-4600 Dortmund 50, FRG !
Follow-Ups: References:
Main Index | Thread Index