Subject: FVWM: Displaying Miniature-Windows in FvwmPager

From: Werner Fleck <[email-masked]>
Date: Fri, 11 Oct 1996 17:49:38 +0200

Hi,

Can anybody tell me how expensive it would be to extend the FvwmPager module 
so that it displays miniatures of the real windows. This way if you are using 
your workstation primarily for diplaying pictures you would have a nice way to 
navigate on your virtual desktop.

If anybody has done or is working on this please let me know. Or maybe someone 
is willing to this if he gets some financial sponsorship?

Werner

--
Werner Fleck                                  * Phone: +49 40 2 54 59 170
prompt! Medizinische Informationssysteme GmbH * Fax:   +49 40 2 54 59 199
Eiffestrasse 426                              * 
D-20537 Hamburg                               * EMail: [email-masked]

--
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: Dan Espen <[email-masked]>
Date: Fri, 11 Oct 1996 12:30:07 -0400

Werner Fleck <[email-masked]> writes:
> Hi,
> 
> Can  anybody  tell  me  how expensive  it would   be to   extend the
> FvwmPager  module so  that    it displays  miniatures of  the   real
> windows. This way  if you are  using your workstation primarily  for
> diplaying pictures you  would have a  nice  way to  navigate on your
> virtual desktop.

There are a number of programs that already draw their own icons.

For pictures, the  "display" program in  the ImageMagick  package does
what you want.

The one I am most familiar with is XEmacs which includes the live-icon
package which  does a sketch  of the XEmacs   window.  Since XEmacs is
appoximating characters to     pixels, and ignoring title    bars  and
menubars  the logic is fairly simple.   However, if the window manager
attempted to draw the  icon, I think it  would fail miserably. When it
went to reduce a spot in the window containing a character to a pixel,
the  color in  the  background   would  overwhelm  the  color of   the
character.  So  when it tried to draw  a picture of the XEmacs window,
with all  its  glorious color,  all  you would see  is the background,
menubar, toolbar and status line.

> If anybody has done  or is working on  this please let me  know. Or

As I said, ImageMagick would be a place to start.

> maybe someone   is willing to    this  if he gets   some   financial
> sponsorship?

My guess is that money could buy anything.

--
Dan Espen                                    Phone: (908) 699-5570
[email-masked]
444 Hoes Lane  Room RRC 1C-214
Piscataway, NJ 08854
--
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: Markus Gutschke <[email-masked]>
Date: 11 Oct 1996 19:44:57 +0200

Dan Espen <[email-masked]> writes:
> However, if the window manager attempted to draw the icon, I think
> it would fail miserably. When it went to reduce a spot in the window
> containing a character to a pixel, the color in the background would
> overwhelm the color of the character.  So when it tried to draw a
> picture of the XEmacs window, with all its glorious color, all you
> would see is the background, menubar, toolbar and status line.

I do not think, it would look _that_ bad. Of course, an application
knows a lot more about its data and is thus much better suited to
calculate the icon, but even without this knowledge it is possible to
come up with a generic algorithm that looks quite passable. Do a
couple of experiments with "xv" and you will see what I mean.

For instance, open a window of your prefered application and grab its
contents. Then calculate the size that this window will have in the
pager and shrink the grabbed image to this size. If you tell "xv" to
use dithering and to internally compute with true-color values, then
the resulting icon can be told apart from other icons. This will not
help in telling exactly what is displayed in the original window, but
it should give you a basic impression.

Also, an algorithm that wants to do this, could probably enhance the
image quality by using first and second derivatives of the color
gradients in order to detect edges. It would then have to use this
information in order to emphasize structures.

I see a couple of other problems, though:

 - this algorithm takes a lot of time. In order to not eat up all of
   the cpu resources, the process would have to artificially slow down
   and return cpu performance to the system. This means that updates
   do not happen very often.

 - in order to come up with good results it is essential to use lots
   of colors. While this is no problem in a true color environment, it
   could eat up valuable color entries in an 8bit environment. I
   imagine, that there would have to be some rather tricky code to use
   existing color entries. Maybe, the icons could be limited to
   grayscale entries. It might be able to get away with just a few
   discreet values.

 - I am uncertain, whether it would be possible to reflect changes in
   partially or totally obscured windows. Somebody else, who is more
   experienced with the X protocol, will have to provide this
   information.

Markus

P.S.: Sorry, I do not have the time to try implementing this
      algorithm. Even money wont convince me :-)
--
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: David Wuertele <[email-masked]>
Date: Sun, 13 Oct 1996 15:24:42 +0900

<Clueless User Warning>

How about another X server, kind of like Xest, which would eavesdrop on the
stream of requests to the main X server, and display the same thing except with
automatic subsampling?

Since this nested piggy-back X server would run only at the same time as the
main X server (only faster, due to less data to display), the user should only
perceive the added work as an X server slowdown.  The slowdown would be a small
fraction of the normal latency of the main X server, ideally equal to the ratio 
of the resolution of the piggy-back server to that of the main server.

Could Xnest be mangled to perform such a piggy-back service?

David Wuertele

---

From: [email-masked] (Albrecht Kadlec)
Date: Mon, 14 Oct 96 18:32:53 +0200

>>>>> David Wuertele writes:

D> <Clueless User Warning>
D> How about another X server, kind of like Xest, which would eavesdrop on the
D> stream of requests to the main X server, and display the same thing except with
D> automatic subsampling?

D> Since this nested piggy-back X server would run only at the same time as the
D> main X server (only faster, due to less data to display), the user should only
D> perceive the added work as an X server slowdown.  The slowdown would be a small
D> fraction of the normal latency of the main X server, ideally equal to the ratio 
D> of the resolution of the piggy-back server to that of the main server.

no, subsampling is a hell of a job, if it has to look like the original.

D> Could Xnest be mangled to perform such a piggy-back service?

don't know, but mangling the X server isn't fvwm's job.
If the event stream doesn't carry the information, fvwm2 is left out in the
rain.

well we could of course hook onto the "redraw" event and do a grab
afterwards, hmmmm. I don't like the idea. Sounds like a CPU hog.

albrecht
PS: And yes, the grip of the men in green isn't that strong .... :)
-- 
The secret is to know when to stop,
The secret is to know when to stop,
The secret is to know when to stop - remembering.	-- Tom Cochrane
--
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: Werner Fleck <[email-masked]>
Date: Tue, 15 Oct 1996 08:56:51 +0200

I think I have to make a little bit clearer what we would like to do:

We have made a set of motif applications to display medical greyscale images 
with sizes in the range from about 256x256 up to more than 2048x2048 pixels.

The window contents of the displayed images may change very often (about 10 
frames per second depending on the image size) due to brightness/contrast 
adjustment.

Since there may be many images displayed on many virtual screens (eg. 32 
virtual screens with two images each) displaying the images in the pager would 
be a big aid in navigating the desktop, i.e. to quickly switch to the virtual 
screen with the image I am looking for.

It should be possible to make an extended pager module which displays the 
scaled down images (using a crude scaling algorithm this could be very fast) 
with reduced colors (eg. 16 grey values) only when an application requests the 
pager to do so (eg. by a new x-event).

So I am asking again if anybody has done this or is willing to this if he gets 
some financial sponsorship?

Werner

---

From: Michael Tiefenback <[email-masked]>
Date: Tue, 15 Oct 1996 09:56:58 -0400 (EDT)

On Tue, 15 Oct 1996, Werner Fleck wrote:

> ...
> virtual screens with two images each) displaying the images in the pager 
> would be a big aid in navigating the desktop, i.e. to quickly switch to 
> the virtual screen with the image I am looking for.
> 
> with reduced colors (eg. 16 grey values) only when an application requests 
> the pager to do so (eg. by a new x-event).

I am a simple man and generally seek simple solutions, so I will ask a
simple question:  Can you determine which is the interesting picture by
referencing a name?  The name of a window can be set individually, and
that name is reflected into the pager as a label on the window.  I hope I
do not tax the patience of the list subscribers in posting this. 

It appears that you functionally want a special summary window (which
appears in turn to be most appropriate to obtain from your application
directly in the form of an index page).  This summary window could be
relatively small and could cross-index the other window names.  From
existing fvwm pager labels, you could then easily access the correct
windows.  It seems very appropriate instead of using fvwm-specific
features, for you to consider calling a warp cursor function from this
index page directly to the window manager.  The parent process (I am not 
an X programmer, as will become apparent) should know or have access to 
the window IDs of its children, and should be able to induce the wm to 
warp the cursor to a chosen subwindow, for example, as a result of a mouse 
click in the index window.  xv's "visual schnauzer" mode is an example of 
such an interface without the cursor warp.

Michael Tiefenback