Subject: Re: FVWM: combining old fv2m2 and new RedHat v7.2(enigma)

From: Olivier Chapuis <[email-masked]>
Date: Wed, 9 Jan 2002 19:06:16 +0100

On Tue, Jan 08, 2002 at 11:52:39AM -0800, E Frank Ball wrote:
> On Tue, Jan 08, 2002 at 02:28:21PM -0500, Thomas A. Gardiner wrote:
> } Okay, so I'll take a shot at this.
> } 
> } Why do you prefer fvwm2 about version 2.0?
> 
> One thing I liked better on fvwm2 version 2.2 over version 2.4 was when
> I used the windowshade function it did not put the window border on the
> bottom of the shaded window (titlebar) on the old version and it does on
> the new version.  The new version is prettier, but the border on the
> bottom just gets in the way too often.
> 

Is this a bug? I added a draw decoration in the unshade loop
and it seems that this cause no problem, I will even say that
there is less flickering. Should I commit this to 2.5.0 and
2.4.5?

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

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 11 Jan 2002 15:26:18 +0100

On Fri, Jan 11, 2002 at 11:47:43AM +0100, Dominik Vogt wrote:
> On Thu, Jan 10, 2002 at 09:17:43PM +0100, Olivier Chapuis wrote:
> > On Thu, Jan 10, 2002 at 04:23:38PM +0100, Dominik Vogt wrote:
> 
> [snip]
> 
> 
> > > Again: If any of this is vital to be fixed, split up the decor_w
> > > into pieces again, draw the border into a pixmap and set the
> > > pixmap as the background pixmap of the eight decoration windows.
> > > This way, you would not have to redraw the borders at all because
> > > the X server takes care of it.  Hey, I like that idea :-)
> > 
> > So, you will go to implement it? This will be great. Maybe it
> > will be the occasion to add NoSideBorder / SideBorder and
> > NoTopBottomBorder / TopBottomBorder Style?
> 
> I'd really like to redo the decoration drawing stuff.  I think
> much speed can be gained with the pixmap background approach.  If
> only there were not so many bug reports I have to take care of ...
> 

Maybe I can try to do it (without the new styles) after I finish
the transparent support for the modules. In any case Conditional
style and bugs fix are more important.
About the bugs what about a kind of todo-2.4-2.5 into the cvs?
I went to the bug tracking system yesterday it is not easy to
work with it especially if you do not have a permanent connection.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 11 Jan 2002 15:15:04 +0100

On Fri, Jan 11, 2002 at 11:54:42AM +0000, Tim Phipps wrote:
> [email-masked] wrote:
> 
> >The eight sub windows are already there.  In the distant past,
> >fvwm painted the borders directly into these windows.  I
> >introduced the decor_w to be able to draw the decorations into a
> >single window so that you don't have to repeat the same drawing
> >commands eight times.  The windows are still there, but nowadays
> >they are input_only windows.  That would be quite easy to change.
> 
> They aren't there for NoHandle style windows. If you are going to change 
> this you should make sure they are always there but with a cursor that 
> reflects Handles/NoHandles and that they return the correct context for 
> mouse/key bindings (F for Handles, S for NoHandles). Then you can remove 
> decor_w altogether.
> 
> This won't give you perfect unshade looks because the side handle 
> windows height will have to be the height required for unshaded looks 
> and so some of the handle marks won't show up. If the corner handles are 
> set to normal size it will look a bit screwy in the first steps of 
> unshading.
>

Maybe the only part of the borders which should be drawn are
these handle marks? At some point(s) on the (un)shading these
handles should be redrawn / erased ?

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 11 Jan 2002 15:40:41 +0100

> mouse/key bindings (F for Handles, S for NoHandles). Then you can remove 

In the end all I have to do is to reactivate the code that we had
before I introduced the decor_w.

> and so some of the handle marks won't show up.

No, this should work fine.  If I set a tiled background pixmap,
the server always knows what to draw.  We don't even need to
select Expose events on the border.

> If the corner handles are 

The handle marks would have to be drawn into the corners.  The
horizontal marks must be disabled when the window is shaded.

> I guess the stacking order for the windows (bottom to top) will be: left 
> & right sides, corners, top and bottom, title, client.

Sounds correct.

> Don't forget to switch off backing store on your server when testing 
> this, and do all combinations of titleattop/bottom, handles/nohandles, 
> inset/noinset, hiddenhandles/nohiddenhandles, fvwmborder/mwmborder, 
> windowshadshrinks/scrolls.

Hey, wasn't this exactly what I said In one of my previous mails?
;-)

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Fri, 11 Jan 2002 15:20:47 +0000

> before I introduced the decor_w.

Don't do that, there were lots of minor bugs with the drawing of 
FvwmBorders and noinset and hiddenhandles. I seem to remeber this all 
started when someone (possibly me) removed the 1 pixel border (X-window 
border not FVWM border) around the fvwm frame window for FVWMBorder 
style windows. That was done to get rid of some of the wandering window 
features of the 2.0 series of FvwmWinlist etc.

Removing the x-window border caused FvwmBorder windows to be drawn wrong 
and the easiest way to fix the mess was to do all the drawing in one 
window. Maybe it's time to ditch FvwmBorder style (I don't think it was 
ever designed, it just turned out like it did and some people liked it).

> select Expose events on the border.

Agreed, not getting Expose events would be good.

> horizontal marks must be disabled when the window is shaded.

Oh I see. I thought that the sides would have a top and bottom shadow 
around them. If the mark is drawn competely in the corners then it all 
works fine.

The only problem I can think of is that the corners will have to be made 
slightly bigger than they are. It will look the same but the point at 
which the cursor changes from side to corner will be changed (no-one 
will notice ;-)

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 11 Jan 2002 16:35:28 +0100

> work with it especially if you do not have a permanent connection.

Yes, Jitterbug is a pain.  You can download the whole bug database
as a .tar.gzip from some server that Jason provides (I don't have
the URL handy at the moment).  Or you can just download the
incoming and confirmed directories.  To file new bug reports you
can simply send a mail to the jitterbug address although you'll
just get the text in the body of the report without any of the
fields filles in.  Jitterbug seems to be purely mail oriented.
The bug database is simply a bucket of mails for each action you
do with a bug report.

About the bugs:  A new "to do" is probably not a good permanent
solution, but collecting the bugs somewhere is definitely better
than leaving them in our mail boxes forever.

Bye

Dominik ^_^  ^_^