cchase@ee.cornell.edu (Craig M. Chase) (09/03/90)
I've started using Tom LaStrange's new tvtwm, and (except for the nasty things it does to this poor little sparcstation 1+.... swap, swap, swap... what I'd give for another 8Mbytes of memory! well not what sun wants, I need both arms and both legs, thank you, but I digress...) I like it very much. However, I've been having some trouble with resizing windows. When I try to resize a window, xterm for example, the window explodes to some ` ridiculous size as soon as I click on the resize box. For example, if I were to try to resize this window, it would jump to something like 180x50, most of which is off of the screen. I only have this problem when I'm away from the upper left hand corner of the virtual root window. So what I end up doing to resize is f.scrollhome, drag the window there, resize it, put it back where it used to be, pan over there, and go back to work. Kind of a nuisance. Has anyone else had this problem. I'm using the tvtwm posted on comp.sources.x with the Official patch applied (why didn't the official patch take care of the &wName, &iName bug in vdt.c? did I apply it wrong?) on a sparcstation 1+ with OS 4.1, gcc... Craig -- ---------------------------------------------------------------------- Craig Chase | Cornell University cchase@ee.cornell.edu | Department of Electrical Engineering ----------------------------------------------------------------------
muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) (09/03/90)
cchase@ee.cornell.edu (Craig M. Chase) writes:
#I've started using Tom LaStrange's new tvtwm, and (except for the nasty
#things it does to this poor little sparcstation 1+.... swap, swap, swap...
#what I'd give for another 8Mbytes of memory! well not what sun wants,
#I need both arms and both legs, thank you, but I digress...) I like
#it very much.
Strange, I run it on an Apollo 2500 with 8Mb, and I notice no performance
difference with twm, while using some xterms too.
Is tvtwm really supposed to be using so much more memory than twm?
#However, I've been having some trouble with resizing windows. When I try
#to resize a window, xterm for example, the window explodes to some `
#ridiculous size as soon as I click on the resize box. For example, if
#I were to try to resize this window, it would jump to something like
#180x50, most of which is off of the screen.
#I only have this problem when I'm away from the upper left hand corner
#of the virtual root window. So what I end up doing to resize is
#f.scrollhome, drag the window there, resize it, put it back where
#it used to be, pan over there, and go back to work. Kind of a nuisance.
I just noticed the same bug.
#Has anyone else had this problem. I'm using the tvtwm posted on
#comp.sources.x with the Official patch applied (why didn't the official
#patch take care of the &wName, &iName bug in vdt.c? did I apply it wrong?)
#on a sparcstation 1+ with OS 4.1, gcc...
So did I.
--
Peter Mutsaers email: muts@fysaj.fys.ruu.nl
Rijksuniversiteit Utrecht nmutsaer@ruunsa.fys.ruu.nl
Princetonplein 5 tel: (+31)-(0)30-533880
3584 CG Utrecht, Netherlands rmtodd@servalan.uucp (Richard Todd) (09/04/90)
muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) writes: >#I've started using Tom LaStrange's new tvtwm, and (except for the nasty >#things it does to this poor little sparcstation 1+.... swap, swap, swap... >Strange, I run it on an Apollo 2500 with 8Mb, and I notice no performance >difference with twm, while using some xterms too. >Is tvtwm really supposed to be using so much more memory than twm? Tvtwm itself doesn't seem to more memory than twm. However, creating the window for the virtual desktop causes the X *server* to eat up more memory (on my Mac IIx, the X server now seems to be running ~4.9M versus ~3M. Of course, this is a color server; it's not surprising that storage for a 1400x1400x8 bit window takes up a good deal of room...) My experience is that as long as you don't have windows taking up more of the desktop than the "real desktop" space (640x480 pixels in my case) you won't notice a difference in performance; the memory for the rest of the virtual desktop stays paged out and doesn't bother anyone. If you start putting stuff on other portions of the virt. desktop, the system thrashes more heavily. >#However, I've been having some trouble with resizing windows. When I try >#to resize a window, xterm for example, the window explodes to some ` >#ridiculous size as soon as I click on the resize box. For example, if >#I only have this problem when I'm away from the upper left hand corner >#of the virtual root window. So what I end up doing to resize is >#f.scrollhome, drag the window there, resize it, put it back where >#it used to be, pan over there, and go back to work. Kind of a nuisance. Yep, I've noticed this bug too. It seems to be a problem in resize.c, where the code for handling the mouse motion is passing the mouse coordinates on the real root window, but the code seems to be treating them as if they were coordinates on the virtual desktop. Alas, I really don't understand this code well enough to come up with a way to fix it... Another workaround is to, instead of clicking on the resize box, to resize your windows by selecting a menu item that does f.resize from the Twm menu. Alas, the nice outline of the window you see as you resize disappears (I think it's being put in the upper left hand corner of the virt. desktop), but at least your window size doesn't get adjusted to absurd values. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp
rodney@solar.card.inpu.oz.au (Rodney Campbell) (09/04/90)
I too have had this problem occur. Resizing windows makes them seem to think they are in the 'home' section of the virtual desktop and thus they resize to radical proportions if they are not in the 'home' section. I also wonder about the official patch not fixing the pointer bug in vtd.c - Tom ???? I have a new question though - Why do sticky windows HAVE to be on top - this can be a real pain sometimes - obscuring the window I want to see..... And can we please have DontMoveOff functionality back (with placement of new windows as well) - I really liked this feature of twm and vtwm and I sorely miss it. Other than that - I love it... Rodney.... ______________________________________________________________________ Rodney Campbell MHSnet: rodney@solar.card.inpu.oz.au Telecom Australia Snail: 8th Floor, 91 York Street Corporate Customer Division Sydney 2000. Integrated Network Products Unit PO Box A226,Sydney South 2000. Customer Applications Research Phone: +61 02 364 3346 & Development Fax: +61 02 262 3813 ______________________________________________________________________
jfy@orion.cis.ksu.edu (Joseph F. Young) (09/04/90)
cchase@ee.cornell.edu (Craig M. Chase) writes: >[...] >However, I've been having some trouble with resizing windows. When I try >to resize a window, xterm for example, the window explodes to some ` >ridiculous size as soon as I click on the resize box. For example, if >I were to try to resize this window, it would jump to something like >180x50, most of which is off of the screen. >I only have this problem when I'm away from the upper left hand corner >of the virtual root window. So what I end up doing to resize is >f.scrollhome, drag the window there, resize it, put it back where >it used to be, pan over there, and go back to work. Kind of a nuisance. >Has anyone else had this problem. I'm using the tvtwm posted on >comp.sources.x with the Official patch applied (why didn't the official >patch take care of the &wName, &iName bug in vdt.c? did I apply it wrong?) >on a sparcstation 1+ with OS 4.1, gcc... >Craig >-- >---------------------------------------------------------------------- >Craig Chase | Cornell University >cchase@ee.cornell.edu | Department of Electrical Engineering >---------------------------------------------------------------------- I believe I have a patch which will fix the resize problem. This is an *unofficial* patch, etc... Please let me know how it works out for you. *** resize.c.original Mon Sep 3 22:42:56 1990 --- resize.c Mon Sep 3 23:11:35 1990 *************** *** 150,155 **** --- 150,159 ---- XGetGeometry(dpy, (Drawable) tmp_win->frame, &junkRoot, &dragx, &dragy, (unsigned int *)&dragWidth, (unsigned int *)&dragHeight, &junkbw, &junkDepth); + if (Scr->VirtualDesktop && !tmp_win->sticky) { + dragx -= Scr->vdtPositionX; + dragy -= Scr->vdtPositionY; + } dragx += tmp_win->frame_bw; dragy += tmp_win->frame_bw; origx = dragx; *************** *** 200,205 **** --- 204,215 ---- dragx = x + tmp_win->frame_bw; dragy = y + tmp_win->frame_bw; + + if (Scr->VirtualDesktop && !tmp_win->sticky) { + dragx -= Scr->vdtPositionX; + dragy -= Scr->vdtPositionY; + } + origx = dragx; origy = dragy; dragWidth = origWidth = w - 2 * tmp_win->frame_bw; *************** *** 431,436 **** --- 441,451 ---- if (dragWidth != tmp_win->frame_width || dragHeight != tmp_win->frame_height) tmp_win->zoomed = ZOOM_NONE; + + if (Scr->VirtualDesktop && !tmp_win->sticky) { + dragx += Scr->vdtPositionX; + dragy += Scr->vdtPositionY; + } SetupWindow (tmp_win, dragx - tmp_win->frame_bw, dragy - tmp_win->frame_bw, dragWidth, dragHeight, -1); -- Joseph Young, KSU Department of Computing and Information Sciences Manhattan, Kansas 66506 Phone: (913) 532-6350 Inet: jfy@ksuvax1.cis.ksu.edu UUCP: {rutgers,texbell}!ksuvax1!jfy -- "MS-DOS...just say no." --
toml@ninja.Solbourne.COM (Tom LaStrange) (09/04/90)
|> However, I've been having some trouble with resizing windows. When I try |> to resize a window, xterm for example, the window explodes to some ` |> ridiculous size as soon as I click on the resize box. For example, if |> I were to try to resize this window, it would jump to something like |> 180x50, most of which is off of the screen. This has been reported and will be fixed in patch #2, coming in the next day or so. |> Has anyone else had this problem. I'm using the tvtwm posted on |> comp.sources.x with the Official patch applied (why didn't the official |> patch take care of the &wName, &iName bug in vdt.c? did I apply it wrong?) |> on a sparcstation 1+ with OS 4.1, gcc... It's because I didn't know about it when patch 1 was sent out. -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
rec@arris.com (Roger Critchlow) (09/05/90)
There's another resize problem in fullzoom(). Zooming a window warps its location to x==0 and/or y==0 on the virtual desktop. I haven't found a fix. -- rec --