nsw@cbnewsm.ATT.COM (Neil Weinstock) (10/11/89)
I would like to propose a change to the system sizing gadget. The way it
is now, the user is too limited in the directions he/she can alter the
window. When trying to right-justify a window of a certain size, it can
become quite a chore. Resize-drag-resize-drag- etc. This is one thing that
I like in MS Windows (gak), that you can drag *any* corner around to resize
the window. I'm not necessarily proposing that that method be proposed, just
something slightly more flexibly than the current version.
I also would like to see what a previous poster proposed: visual display of
the window borders while resizing (would that really be much of a problem to
implement? I wouldn't think so).
________________ __________________ ____________________________
//// \\// \\// \\\\
\\\\ Neil Weinstock //\\ att!cord!nsw or //\\ "Oh dear, now I shall have ////
//// AT&T Bell Labs \\// nsw@cord.att.com \\// to create more Martians." \\\\
\\\\________________//\\__________________//\\____________________________////peter@sugar.hackercorp.com (Peter da Silva) (10/11/89)
In article <5228@cbnewsm.ATT.COM> nsw@cbnewsm.ATT.COM (Neil Weinstock) writes: > I would like to propose a change to the system sizing gadget. Me too. I'd like to at least allow a program to specify that it goes in the top border of the window (SIZEBTOP): Front Close Back | Size +-----------------------------------------------------------------+ |()| Title |//|\\|oO| |-----------------------------------------------------------------| This would let you have resizable windows that didn't waste 2 character columns on the sizing gadget. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
cmcmanis%pepper@Sun.COM (Chuck McManis) (10/12/89)
In article <4341@sugar.hackercorp.com> (Peter da Silva) writes: > ... I'd like to at least allow a program to specify that it goes in the >top border of the window (SIZEBTOP): [cute picture deleted] >This would let you have resizable windows that didn't waste 2 character columns >on the sizing gadget. And my .02 worth, why not make the border the sizing gadget ? If you wanted to sorta OpenLook(tm) like you could draw your corners like so ; ------====+ || || | | Where the double lines are either a different color (pen 3?) or simply a different line pattern. The benefits of having sizing gadgets in all 4 corners is obvious ( you save a window move if your window is in the same corner of the screen that the sizing gadget is in the window. (lower right by default)). If you wanted to be really tricky you could use the other part of the border (between the sizing gadgets) to drag the window around. This has the advantage of being easy to do, and takes up very little screen real estate. Oh and for Peter, you only need (1) Front to back gadget if you think about it, so you could save some space there as well. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "If I were driving a Macintosh, I'd have to stop before I could turn the wheel."
andrewt@watsnew.waterloo.edu (Andrew Thomas) (10/12/89)
In article <5228@cbnewsm.ATT.COM> nsw@cbnewsm.ATT.COM (Neil Weinstock) writes:
I would like to propose a change to the system sizing gadget. The way it
is now, the user is too limited in the directions he/she can alter the
window. When trying to right-justify a window of a certain size, it can
become quite a chore. Resize-drag-resize-drag- etc. This is one thing that
I like in MS Windows (gak), that you can drag *any* corner around to resize
the window. I'm not necessarily proposing that that method be proposed,
just something slightly more flexibly than the current version.
I also would like to see what a previous poster proposed: visual display of
the window borders while resizing (would that really be much of a problem to
implement? I wouldn't think so).
I agree entirely. The best example of a window resize operation is
the way 'twm' does it for X windows. In order to resize a window, you
click on the gadget, then move the pointer outside the window in any
direction. If you exit near the middle of a side, you can only resize
in that direction. If you exit at a corner, you can resize from that
corner. If, for example, you exit from the top, and then move the
pointer down past the bottom of the window, it automatically grabs the
bottom of the window instead and starts resizing from that. This is
similar to (though less versatile and more intuitive than) the method
for resizing used on the Xerox 1108/1186 series of Lisp machines. The
only bad part about this scheme is that you must exit the window in
order to resize. You cannot grab the gadget and simply move into the
window to make it smaller; you must first leave the window and then
reenter. I also think that commands like resize and move should be
abortable by clicking the other mouse button before releasing the
button used to start the operation (see X window manager 'awm').
--
Andrew Thomas
andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo
"If a million people do a stupid thing, it's still a stupid thing." - Opusbader+@andrew.cmu.edu (Miles Bader) (10/12/89)
andrewt@watsnew.waterloo.edu (Andrew Thomas) writes: > I agree entirely. The best example of a window resize operation is > the way 'twm' does it for X windows. In order to resize a window, you > click on the gadget, then move the pointer outside the window in any > direction. God no! TWM's method of resizing is the most totally un-intuitive I've ever used! The functionality-- sure; but don't use the same method! -Miles
jac@muslix.llnl.gov (James Crotinger) (10/12/89)
In article <4341@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <5228@cbnewsm.ATT.COM> nsw@cbnewsm.ATT.COM (Neil Weinstock) writes: >> I would like to propose a change to the system sizing gadget. I'd like to see a resize gadget that works like the one used by the twm X Windows window manager. You click on the gadget (which is in the upper right hand corner of the title bar) and your pointer changes. You then move the pointer to a window border, where it gets attached, and you pull in the direction you like. I don't like the ones where you have to carefully grab some small gadget on one of the edges or corners of the window. Jim
scotth@corp.sgi.com (Scott Henry) (10/12/89)
In article <35609@lll-winken.LLNL.GOV> jac@muslix.llnl.gov (James Crotinger) writes: > In article <4341@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <5228@cbnewsm.ATT.COM> nsw@cbnewsm.ATT.COM (Neil Weinstock) writes: >>> I would like to propose a change to the system sizing gadget. I like what is used in the 4Sight window manager (Silicon Graphics Iris workstation NeWS/X11R3 based). I actually like the 3.1 version better (because all three buttons had unique functions), but the 3.2 version is more approprite for the 2-button Amiga: There are two gadgets in the title bar -- close and iconify; the whole window border (including title-bar) is the click-to-front (left button) gadget (if the mouse didn't move before button release), or window drag (middle button or move with left button); there is a sizing gadget in each corner; right button brings up a pop-up menu with all functions + push, quit & resize. It would be nice to add some method of indicating the rows & columns (either characters for a single-font window, or pixels for a graphics/multi-font window) while sizing. -- Scott Henry <scotth@sgi.com> | Tardis Express -- when it Information Services, | absolutely, positively Silicon Graphics, Inc | has to be there -- yesterday.
jimm@amiga.UUCP (Jim Mackraz) (10/13/89)
In article <126138@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes:
)Oh and for Peter, you only need (1) Front to back gadget if you think about
)it, so you could save some space there as well.
Too late: there's already one depth gadget, and the space earned is
used for something like "zoom."
jimm
--
Jim Mackraz, I and I Computing "... the signs are very ominous,
{cbmvax,well,oliveb}!amiga!jimm and a chill wind blows."
- Justice Blackmun
Opinions are my own. Comments are not to be taken as Commodore official policy.jimm@amiga.UUCP (Jim Mackraz) (10/13/89)
andrewt@watsnew.waterloo.edu (Andrew Thomas) writes: )In article <5228@cbnewsm.ATT.COM> nsw@cbnewsm.ATT.COM (Neil Weinstock) writes: ) ) I would like to propose a change to the system sizing gadget. The way it ) is now, the user is too limited in the directions he/she can alter the ) window. When trying to right-justify a window of a certain size, it can ) become quite a chore. Resize-drag-resize-drag- etc. This is one thing that ) I like in MS Windows (gak), that you can drag *any* corner around to resize ) the window. I'm not necessarily proposing that that method be proposed, ) just something slightly more flexibly than the current version. ) ) I also would like to see what a previous poster proposed: visual display of ) the window borders while resizing (would that really be much of a problem to ) implement? I wouldn't think so). ) )I agree entirely. The best example of a window resize operation is )the way 'twm' does it for X windows. Doesn't sound too good to me, better, perhaps, but not great. I also think that commands like resize and move should be )abortable by clicking the other mouse button before releasing the )button used to start the operation (see X window manager 'awm'). "It's In There." jimm -- Jim Mackraz, I and I Computing "... the signs are very ominous, {cbmvax,well,oliveb}!amiga!jimm and a chill wind blows." - Justice Blackmun Opinions are my own. Comments are not to be taken as Commodore official policy.
gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (10/13/89)
I like the method used on my AT&T 630mtg terminal. Once you select resize, (from a menu selection, then click-selecting a menu... I prefer this method because you don't have to "top" a window to find the resize gadget to move it) an outline appears that is centered on the mouse pointer. The size of that window is "recommended" by the application (it knows how big it needs to be to show its "stuff". An interesting side effect is that this allows me to have a 24x80 window in whatever font I want without having to guess how big 24x80 [or any other size] actually is. Also, trivial things like clocks can say "I only need to be this big", but the user can always size it bigger). If you do not like that size, you can move the pointer to place it where you want one of the corners. Then, you push button-3 and hold it down, moving the mouse to the position of the opposing corner. Releasing button-3 moves the window and resizes it in one step. On the other hand, if you liked the "recommended" size of the window, you can just move it to where you want it and click button-3. Note that both activities are on button-3 which implies that your click in the latter case must be fairly quick and you can not be dragging the mouse while you do it. I have never had the terminal get my intentions confused though, so the timing must not be that critical (clock granularity on the terminal is 1/60th of a second). -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
jonabbey@walt.cc.utexas.edu (Jonathan Abbey) (10/13/89)
In article <4696@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: | | Too late: there's already one depth gadget, and the space earned is | used for something like "zoom." | | jimm | Interesting.. does this imply that clicking in a window automatically moves it to the front, as it does in the Mac? Must we have the active window in front then? Or do you mean to use the two mouse buttons to select what is done, moving away from the status quo of using one mouse button exclusively for menus? Out of curiosity: A lot of people are suggesting a lot of things to be added to v1.4, but it seems that if these suggestions actually stand any chance of being put into v1.4 then v1.4 must be a good deal away. Most of the info I have regarding 1.4 comes from the DevCon, back in June. Have you at this time finalized what features you want to put into 1.4, or is it still up in the air, and to what degree, if I might ask? Additionally, in the latest Amazing, the bandito indicated that the workbench was being redone by a professional graphic artist, while reports from DevCon that I saw indicated few cosmetic changes to the workbench except for the slider gadgets in the corner, the parent gadget, etc. Will we see a totally redesigned workbench style, and if so, will the ASL.library have the same styling as the workbench for uniformity's sake? Sorry for all the nosy questions, thanks for any you can answer. // /\ /\/\ | Jonathan Abbey - jonabbey@doc.cc.utexas.edu - (512) 926-5934 \X/ / \ / \ | Wanted: Programmers interested in 3d graphics/modem games.
nsw@cbnewsm.ATT.COM (Neil Weinstock) (10/13/89)
In article <3851@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: >I like the method used on my AT&T 630mtg terminal. Once you select >[ description deleted ] You might call the 630 resize the other end of the spectrum from the Amiga resize. The problem with that extreme is that you must respecify the entire window every time. Now, there are some times when all I want is to widen a window a bit, to add an extra column or something, and on the 630 I can't do it with maximum ease. Like the Amiga resize, it's not bad or anything, just not as good as it could be. ________________ __________________ ____________________________ //// \\// \\// \\\\ \\\\ Neil Weinstock //\\ att!cord!nsw or //\\ "Oh dear, now I shall have //// //// AT&T Bell Labs \\// nsw@cord.att.com \\// to create more Martians." \\\\ \\\\________________//\\__________________//\\____________________________////
johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) (10/14/89)
In article <4341@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Me too. I'd like to at least allow a program to specify that it goes in the >top border of the window (SIZEBTOP): > Front > Close Back | Size > +-----------------------------------------------------------------+ > |()| Title |//|\\|oO| > |-----------------------------------------------------------------| > >This would let you have resizable windows that didn't waste 2 character columns >on the sizing gadget. Now this idea is great - so simple, but SO useful. When I read this I thought "Now why didn't someone think of this years ago!? Why didn't *I* think of this?" Well, as a person who dislikes sacrificing columnar real-estate for a single 20x20 pixel square ---- I love this idea! Backwards compatible too, and we just have to sacrifice a flag bit. -- ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" PenPal V1.1 for sale: $90. All original disks, manual, box. Registration.
jimm@amiga.UUCP (Jim Mackraz) (10/14/89)
In article <19529@ut-emx.UUCP> jonabbey@walt.cc.utexas.edu (Jonathan Abbey) writes: )In article <4696@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: )| Too late: there's already one depth gadget, and the space earned is )| used for something like "zoom." )| jimm )Interesting.. does this imply that clicking in a window automatically moves )it to the front, as it does in the Mac? Never. If you click the depth gadget, the window comes to the front if it is not already. If you click it when the window is in front, it goes to the back. People like little new habits. There might be a change replacing the phrase "already in front" to "unobscured." )Must we have the active window in )front then? Or do you mean to use the two mouse buttons to select what is )done, moving away from the status quo of using one mouse button exclusively )for menus? Ick. No. )Out of curiosity: A lot of people are suggesting a lot of things to be added )to v1.4, but it seems that if these suggestions actually stand any chance of )being put into v1.4 then v1.4 must be a good deal away. Most of the info I )have regarding 1.4 comes from the DevCon, back in June. Have you at this time )finalized what features you want to put into 1.4, or is it still up in the air, )and to what degree, if I might ask? If the ideas are not already in the code, it will be much less likely that they will be in V1.4. )Additionally, in the latest Amazing, the bandito indicated that the workbench )was being redone by a professional graphic artist, while reports from DevCon )that I saw indicated few cosmetic changes to the workbench except for the )slider gadgets in the corner, the parent gadget, etc. Will we see a totally )redesigned workbench style, and if so, will the ASL.library have the same )styling as the workbench for uniformity's sake? There are styling changes planned both in Intuition and Workbench. There are mechanisms for tweezing up imagery in these, and in applications, to a better level of aesthetics. There are artists. Only a little of this is present in the alpha software that has been distributed. That software had some compositional changes to the Workbench windows. The artwork will complement these changes, but it is really a separate effort. )Sorry for all the nosy questions, thanks for any you can answer. I wonder about them myself. jimm -- Jim Mackraz, I and I Computing "... the signs are very ominous, {cbmvax,well,oliveb}!amiga!jimm and a chill wind blows." - Justice Blackmun Opinions are my own. Comments are not to be taken as Commodore official policy.
peter@sugar.hackercorp.com (Peter da Silva) (10/15/89)
In article <126138@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: > In article <4341@sugar.hackercorp.com> (Peter da Silva) writes: > > ... I'd like to at least allow a program to specify that it goes in the > >top border of the window (SIZEBTOP): > >This would let you have resizable windows that didn't waste 2 character columns > >on the sizing gadget. > Oh and for Peter, you only need (1) Front to back gadget if you think about > it, so you could save some space there as well. But that's not the sort of "space" I care about saving. You can put the kitchen sink in the title bar and so long as it doesn't make it taller I could care less. But if you put anything in any other border you have to thicken the whole border to make room. Putting sizing gadgets in all corners are a good idea, but do it like Microsoft Windows: the whole border is thickened, and grabbing the border anywhere lets you resize the window. Go play with Windows... it's really very well designed, a whole lot better than the Mac (too bad the program interface isn't as nice as the user interface). -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (10/15/89)
In article <4703@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: > [This is why you need only 1 depth gadget, not 2.] >If you click the depth gadget, the window comes to the front if >it is not already. If you click it when the window is in front, it goes >to the back. People like little new habits. There might be a change >replacing the phrase "already in front" to "unobscured." Did you realize that this method is not as powerful as the 2-gadget method (window-to-front, window-to-back gadgets)? Windows that are "sandwiched" between two other windows will require extra clicks for the user to manipulate them. Here's a sample scenario to demonstrate this. Picture three stacked windows, labelled 1, 2, and 3. 1 is on top of 2, and 2 is on top of 3. Window 1 covers exactly the left half of the screen. Window 2 covers the entire screen. Window 3 covers exactly the right half of the screen. The object is to display window 3, which is totally obscured by window 2. With the one-gadget system, what must you do? Well, you can't click on window 3 at all, so you click window 2's gadget. Since window 2 is not in front (window 1 is), it comes to the front. Now click window 2 again to send it to the back, thereby displaying window 3. With the two-gadget system, you just click window 2's "back" gadget, displaying window 3. Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett - Systems Administrator, Computer Science Department | | The Johns Hopkins University, 34th and Charles Sts., Baltimore, MD 21218 | | INTERNET: barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | | COMPUSERVE: >internet:barrett@cs.jhu.edu | BITNET: barrett@jhuvms.bitnet | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
usenet@cps3xx.UUCP (Usenet file owner) (10/16/89)
In article <4703@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: >In article <19529@ut-emx.UUCP> jonabbey@walt.cc.utexas.edu (Jonathan Abbey) writes: > >Never. If you click the depth gadget, the window comes to the front if >it is not already. If you click it when the window is in front, it goes >to the back. People like little new habits. There might be a change >replacing the phrase "already in front" to "unobscured." Ok, from this discussion I have figured out that the title bar is gonna look significatly different. Now a question. I am just finishing up a nifty program that has an iconify gadget place just to the left of the depth gadgets. Is this going to break in 1.4? The way I get it to be there, and show on top of the drag bar is by: win=Openwindow(&nw); AddGadget(win,icongadget); I doubt that this would wwork well if I wanted to put a gadget to the right of the close gadget, since it would cover the title. Is there a better way to put extra gadgets in the title bar and have them not be disturbed by the drag bar, ot the title? If not, is there a way to do it in 1.4? I did try many different things with gadget flags, but only adding the gadget after opening the window worked. Oh, another wish, how about centering window and screen titles? Joe Porkka porkka@frith.egr.msu.edu
bader+@andrew.cmu.edu (Miles Bader) (10/16/89)
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > In article <4703@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: > > [This is why you need only 1 depth gadget, not 2.] > ... > Picture three stacked windows, labelled 1, 2, and 3. 1 is on top of > 2, and 2 is on top of 3. Window 1 covers exactly the left half of the > screen. Window 2 covers the entire screen. Window 3 covers exactly the > right half of the screen. > The object is to display window 3, which is totally obscured by > window 2. > > With the one-gadget system, what must you do? Well, you can't click > on window 3 at all, so you click window 2's gadget. Since window 2 is not > in front (window 1 is), it comes to the front. Now click window 2 again > to send it to the back, thereby displaying window 3. > > With the two-gadget system, you just click window 2's "back" gadget, > displaying window 3. You do need one more click-- but clicking twice instead of once is SO EASY, that it makes little difference. In fact, I would bet that it's easier to do this than decide which of the two existing front<->back gadgets to click on. I know I'm always forgetting which one is which... -Miles
limonce@pilot.njin.net (Tom Limoncelli) (10/16/89)
Depth gadget? Oh yeah, that think that I don't use now that I run dMouse. :-) -Tom "Depth gadgets get obscured, dMouse doesn't" :-) Limoncelli -- Drew University -- Tom Limoncelli C M Box 1060 -- limonce@pilot.njin.net P O Box 802 -- tlimonce@drunivac.Bitnet Madison, NJ 07940 -- 201-408-5389
utoddl@uncecs.edu (Todd M. Lewis) (10/16/89)
In article <Oct.15.16.14.26.1989.20250@pilot.njin.net>, limonce@pilot.njin.net (Tom Limoncelli) writes: > Depth gadget? Oh yeah, that think that I don't use now that I run > dMouse. :-) Gee, Tom. You should start using your think again! :-) :-) :-) --Todd
jimm@amiga.UUCP (Jim Mackraz) (10/17/89)
)>Me too. I'd like to at least allow a program to specify that it goes in the
)>top border of the window (SIZEBTOP):
)> Front
)> Close Back | Size
)> +-----------------------------------------------------------------+
)> |()| Title |//|\\|oO|
)> |-----------------------------------------------------------------|
)>
)>This would let you have resizable windows that didn't waste 2 character columns
)>on the sizing gadget.
)
)
)Now this idea is great - so simple, but SO useful. When I read this I thought
)"Now why didn't someone think of this years ago!? Why didn't *I* think of this?"
Great idea, except you can't make the window taller using the gadget.
Minor problem?
jimm
--
Jim Mackraz, I and I Computing "... the signs are very ominous,
{cbmvax,well,oliveb}!amiga!jimm and a chill wind blows."
- Justice Blackmun
Opinions are my own. Comments are not to be taken as Commodore official policy.jimm@amiga.UUCP (Jim Mackraz) (10/17/89)
In article <2940@jhunix.HCF.JHU.EDU> barrett@jhunix.UUCP (Dan Barrett) writes: )In article <4703@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: )> [This is why you need only 1 depth gadget, not 2.] ) Did you realize that this method is not as powerful as the 2-gadget )method (window-to-front, window-to-back gadgets)? Windows that are )"sandwiched" between two other windows will require extra clicks for the )user to manipulate them. Here's a sample scenario to demonstrate this. ) ) Picture three stacked windows, labelled 1, 2, and 3. 1 is on top of )2, and 2 is on top of 3. Window 1 covers exactly the left half of the )screen. Window 2 covers the entire screen. Window 3 covers exactly the )right half of the screen. ) The object is to display window 3, which is totally obscured by )window 2. ) ) With the one-gadget system, what must you do? Well, you can't click )on window 3 at all, so you click window 2's gadget. Since window 2 is not )in front (window 1 is), it comes to the front. Now click window 2 again )to send it to the back, thereby displaying window 3. ) ) With the two-gadget system, you just click window 2's "back" gadget, )displaying window 3. One extra click without moving, in pathological situations? Can live with that. And of course, in many other situations, what happens is the user clicks on the wrong gadget and spends many mouse clicks getting through the other windows to go fetch it. We'll see how it all works and respond ... jimm -- Jim Mackraz, I and I Computing "... the signs are very ominous, {cbmvax,well,oliveb}!amiga!jimm and a chill wind blows." - Justice Blackmun Opinions are my own. Comments are not to be taken as Commodore official policy.
limonce@pilot.njin.net (Tom Limoncelli) (10/17/89)
(first posting was canceled, ugly spelling error) Depth gadget? What's that? Oh, that thing that always gets obscured by other windows. Tom "Satisfied dMouse user" Limoncelli -- Drew University -- Tom Limoncelli C M Box 1060 -- limonce@pilot.njin.net P O Box 802 -- tlimonce@drunivac.Bitnet Madison, NJ 07940 -- 201-408-5389
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (10/17/89)
For me, the need to click a second time to send a window to the back isn't much of a hardship. Most of the time I want to bring a window to the front when I click its depth gadget. On those occasions when I want to push it to the back and it isn't already the front window I wouldn't mind clicking twice. Because it's the same gadget I wouldn't have to move the mouse, so the effort is minimal. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...uunet!pdn!jc3b21!fgd3
mks@cbmvax.UUCP (Michael Sinz - CATS) (10/17/89)
In article <IZCBZWy00UkaQFAPlV@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: >> In article <4703@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: >> > [This is why you need only 1 depth gadget, not 2.] >> ... >> Picture three stacked windows, labelled 1, 2, and 3. 1 is on top of >> 2, and 2 is on top of 3. Window 1 covers exactly the left half of the >> screen. Window 2 covers the entire screen. Window 3 covers exactly the >> right half of the screen. >> The object is to display window 3, which is totally obscured by >> window 2. >> >> With the one-gadget system, what must you do? Well, you can't click >> on window 3 at all, so you click window 2's gadget. Since window 2 is not >> in front (window 1 is), it comes to the front. Now click window 2 again >> to send it to the back, thereby displaying window 3. >> >> With the two-gadget system, you just click window 2's "back" gadget, >> displaying window 3. > >You do need one more click-- but clicking twice instead of once is SO EASY, >that it makes little difference. In fact, I would bet that it's easier to do >this than decide which of the two existing front<->back gadgets to click on. >I know I'm always forgetting which one is which... Ah, but the real problem is that if window 1 was SIMPLE_REFRESH, the application would need to re-render the window, which could take a while. Also, the extra layer activity will take much more time with MANY windows open on the screen. (I have had many times when I had 15 to 20 windows of various types open on the workbench screen...) This is not to say that the single gadget is bad or good. It is different and will cause a few problems. What I really want is that the screen front/back gadgets look different from the window front/back gadgets. (They are, after all, a different beast...) -- Mike
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (10/17/89)
> )> Close Back | Size > )> +-----------------------------------------------------------------+ > )> |()| Title |//|\\|oO| > )> |-----------------------------------------------------------------| I've puzzled over how this scheme would work myself. I guess you would grab the sizing gadget and be able to move the top and right borders to resize the window. So if you wanted to make the window taller you'd have to drag it down first. Is that right? --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...uunet!pdn!jc3b21!fgd3
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (10/17/89)
Here's a situation where the single depth gadget (brings window to the
front when selected unless the window is already at the front, in which
case it pushes it to the back) requires less work.
You have three windows. Window 1 is small. Windows 2 and 3 are full
screen. You want to leave Window 1 open but you are working mostly from 2
and 3. You want to toggle between 2 and 3 frequently. Right now the
windows are stacked (front to back) 2, 1, 3. Presently, you push
2 to the back, then move the mouse and pop 3 to the front. The single
depth gadget saves you the mouse move.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3jonabbey@walt.cc.utexas.edu (Jonathan Abbey) (10/18/89)
I am quite eagerly looking forward to the new release, am most especially looking forward for the new interface, but I'm not sure I like the sound of this one button window depth mechanism. Admittedly, as an Amiga owner of four years standing I'm an "old dog", but I really think I'll be less comfortable with a one button depth arranger. I really like the control I have with the two buttons. I hope Commodore does some user interaction testing like Apple did while they were designing the Mac's interface, to see which is the more efficient, and which people prefer. In any case, keep up the good work, crew. // /\ /\/\ | Jonathan Abbey - jonabbey@doc.cc.utexas.edu - (512) 926-5934 \X/ / \ / \ | Wanted: Programmers interested in 3d graphics/modem games.
peter@sugar.hackercorp.com (Peter da Silva) (10/18/89)
I suggested moving the sizing gadget to the menu bar. In article <4714@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: > Great idea, except you can't make the window taller using the gadget. Why not? Oh, you have to move the title bar/drag gadget when you resize it, and if it's already at the top of the screen you have to move the window down first. Neither of these are a real problem... just a policy decision (if that). > Minor problem? Very minor. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
peter@sugar.hackercorp.com (Peter da Silva) (10/18/89)
In article <778@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > I've puzzled over how this scheme would work myself. I guess you > would grab the sizing gadget and be able to move the top and right borders > to resize the window. So if you wanted to make the window taller you'd > have to drag it down first. Is that right? Well, unless it was already at the bottom of the screen (like Browser's root window) or at least in the middle (like the default location for a new CLI). Presumably a program that defined SIZEBTOP would put it in a convenient location in the first place. I've used window systems like this before and it's not a problem. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
michael@maui.cs.ucla.edu (michael gersten) (10/19/89)
In article <4386@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >I suggested moving the sizing gadget to the menu bar. > >In article <4714@amiga.UUCP> jimm@batgirl.UUCP (Jim Mackraz) writes: >> Great idea, except you can't make the window taller using the gadget. > >Why not? Oh, you have to move the title bar/drag gadget when you resize it, >and if it's already at the top of the screen you have to move the window down >first. Neither of these are a real problem... just a policy decision (if that). *GRR. <Why did I stop reading the group for a while?> This will cause major problems if a window is resizable and not movable. It will also cause problems if you want to shrink a window. Right now I place my text window where I want the top, put some garbage text in, and then shrink it until there is no wasted space at the bottom. Now there is no way to shrink a window so that there is no wasted bottom space. Besides, any growth/shrinkage must now be followed with a window move. This sounds horrible. Please, keep the size gadget in the corner, and do proper clipping/scrolling so that we can get a 23 by 79 window that only scrolls when data is put in the bottom corner. Or make the top size gadget a serperate option that programs can request. Perhaps a preferences option to decide if the system should map one size gadget to another size gadget. (And how about my favorite beef: an option to force the top right corner of screens (just one pixel) to be screen to front/back gaddgets, regardless of windows). Michael
coco@cbnewsl.ATT.COM (felix.a.lugo) (10/19/89)
[ line eater, #$%$%^$@#$#$^$&^&* ] I don't really think it makes any difference if you have one or two depth gadgets. Consider the case where you have three windows, 1, 2, and 3. 1 is on top, 2 is behind 1, and 3 behind 2. 2 is as big as the screen is, 1 and 3 are the same, but smaller than 2. Suppose you want to bring 3 to the front and that the windows have only one depth gadget. You click on 2, which brings it to the front, you click on 2 again to send it to the back, and then you click on window 3 to bring it to the front. If you had two gadgets; you click on 2's back gadget, and then on 3's front gadget and voila!! You see, it's really a matter of taste and the conditions which you get into. A good idea would be to have a flag, lets say in Preferences, that selects which type of gadget you want to use in your windows. BTW, what about the front/back gadgets in screens????? ______________________________________________________________________ Felix A. Lugo coco@ihlpy.att.com (312) 713-4374
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (10/19/89)
In some article or another, somebody wrote: >> )> Close Back | Size >> )> +-----------------------------------------------------------------+ >> )> |()| Title |//|\\|oO| >> )> |-----------------------------------------------------------------| > > I've puzzled over how this scheme would work myself. I guess you >would grab the sizing gadget and be able to move the top and right borders >to resize the window. So if you wanted to make the window taller you'd >have to drag it down first. Is that right? The DECwindows window manager for X11 (which no one seems to particularly like, mostly because it's a hog), has a scheme like this. There's no close gadget, and the iconize gadget is in the upper left corner. The upper right corner has the depth-arrangement and size gadgets. The default behavior of the depth-arrangement is window-to-back, while a click anywhere else in the window does a window-to-front, but this can be changed (for each window or the default can be changed) so that the depth-arrangement gadget brings the window-to-front, unless it's already there, in which case it does a window to back, and clicking elsewhere in the window set the focus but does not bring the window to the front. The size gadget works like this: you click on the size gadget, hold the left button down, and move the mouse out of the window. Whatever edge you cross follows the mouse. If you want to resize the lower right corner, hit the resize gadget and drag the mouse out the right border and down past the bottom border, and the corner follows the mouse. There's special case code for when the window is at the edge of the screen which lets you still resize the window, though you lose a bit of flexibility. Other X11 window managers may have similar schemes--I know some of the other ones have similar gadgets, but I haven't tried out all the various window managers. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
portuesi@tweezers.esd.sgi.com (Michael Portuesi) (10/19/89)
>>>>> On 18 Oct 89 06:40:35 GMT, jonabbey@walt.cc.utexas.edu (Jonathan Abbey) said:
ja> I am quite eagerly looking forward to the new release, am most especially
ja> looking forward for the new interface, but I'm not sure I like the sound of
ja> this one button window depth mechanism. Admittedly, as an Amiga owner of
ja> four years standing I'm an "old dog", but I really think I'll be less
ja> comfortable with a one button depth arranger.
Well, I'm an Amiga owner of only three years standing, so I can't
"pull rank", but I think the one-button depth arranger is a great idea.
ja> I hope Commodore does some user interaction
ja> testing like Apple did while they were designing the Mac's interface, to see
ja> which is the more efficient, and which people prefer.
I'm not sure Apple did enough testing. Their interface is designed
around the assumption that you will be using a 9-inch screen (pulldown
menus, scrollbars on the righthand sides of windows instead of the
left, trashcan in the lower corner of the Finder display, scroll
arrows at opposite extremes of the scroll bar). The Apple interface
becomes pretty difficult to use once you move to a Radius display, for
example.
The Apple file dialogs do not immediate indicate directory
structure, nor do they indicate the mechanism for moving around in the
directory hierarchy. In user testing of applications software that I
performed for a class on user interface design, at least one of the
users (a Mac novice) was completely befuddled by the standard Mac file
dialog.
The modality of Mac dialogs is also a problem. When a Mac dialog
appears on the screen, access to menus, other windows, and depth
arranging becomes impossible.
I could go on, but suffice it to say that the Mac interface is not the
usability dreamworld it is cracked up to be.
--M
--
__
\/ Michael Portuesi Silicon Graphics Computer Systems, Inc.
portuesi@SGI.COMgregg@cbnewsc.ATT.COM (gregg.g.wonderly) (10/20/89)
From article <2344@cbnewsl.ATT.COM>, by coco@cbnewsl.ATT.COM (felix.a.lugo): > A good idea would be to have a flag, lets say in Preferences, > that selects which type of gadget you want to use in your > windows. I think the answer is to have all of the gadgets and screen/window layouts in preferences. Let me decide where I want the gadgets to be. There could be certain rules like, if I have one scrolling gadget, it has two arrows. If I have one front/back gadget it is a toggle. It is even possible to allow the user to design the gadget that performs the particular operation. It is possible to do that with the shape of the pointer now. Why not use that editing facility (or IconEd) to create the graphic that seems most appropriate. The contact points could be relocatable as the pointer is now. Surely the code in place now is not so inflexible that it could not be generalized to accept all of the parameters for actions of the gadgets as simple rectangles located somewhere in the screen/window rectangle! -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
king@cell.mot.COM (Steven King) (10/20/89)
> [Discussion about putting a size gadget in a window's title bar] > >Great idea, except you can't make the window taller using the gadget. >Minor problem? > jimm So what's the problem? You just use the bottom boundary of the window as your un-moving line, allowing the top boundary (title bar and all) to move freely. (Frankly, I prefer the way sizing is done on my Sun. Too bad I can't afford one of these babys for use at home! :-) /-----------------------------------------------------------------------------\ | It doesn't matter how good a computer it is, | Steve King (312) 991-8056 | | it can't multitask running anything and being | ...uunet!motcid!king | | turned off. | ...ddsw1!palnet!stevek | \-----------------------------------------------------------------------------/
pds@quintus.UUCP (Peter Schachte) (10/20/89)
In article <4386@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >I suggested moving the sizing gadget to the menu bar. Great idea. As you say, it'd save a lot of real estate in sizable windows. Several people have suggested various approaches that allow you to drag any corner of a window to resize it. I think we can all agree this is desirable but, various approaches all have flaws. The twm approach (after selecting the gadget, the next corner of the window which the mouse leaves becomes the one which is sized) is too confusing for novices. The OPEN LOOK/Motif approach of having sizing gadgets all around the window is nice, but forces you to choose between wasting a lot of real estate on wide gadgets or making it difficult to actually hit narrow ones. As usual, Xerox had a solution to this problem, as someone else pointed out. They had a way to move the pointer between corners of the area being established for the window without changing the area. It's kind of hard to explain, but feels very natural. On the Amiga, this could be nicely done by using the sizing gadget as it is (whether at the top or bottom of the window), but when you press the right mouse button (while still holding the left button), you can move the mouse without moving the corner of the window. When you release the right button, the pointer "snaps" to the nearest corner of the window, and you can position that corner where you want it. A nice addition to this, which Xerox doesn't have, is to actually have 8 drag points on the window, each corner and the center of each side. When you release the right mouse button, the pointer would snap to the nearest of these 8 points. Adjusting a side point would let you adjust a window's width or height without affecting the other. Anyway, this sort of approach has the advantage of being backward compatible: if you don't hit the right mouse button while sizing, it's just the same as now. It also has the advantage of being simple for novices (they just use the current system), but fast for experts (individually place each corner of a window in one operation). Comments? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
ralph@atrp.mit.edu (Ralph L. Vinciguerra) (10/20/89)
A greate idea was mentioned. The ability to change the images and locations of gadgets on windows and screen in preferences. I like it. Why not also allow the user to change the mapping of mouse clicks. Case in point: Consider (when using the workbench) what you do most of the time. That right, you double click nearly everything. Open this, start that, etc.. Thus, this operation would be nice to map to a single click. Reserve double click for more arcane stuff. Now I know that most folks would say "Hey, that's incompatible!", but this is where configurability comes in. I should have the option to do it that way. Just think of this idea as a visual equivalent to the command line oriented "alias" concept. Thus I can "alias" visual features as I'd like them to be. I think X-window offers this kind of ability.
jac@muslix.llnl.gov (James Crotinger) (10/21/89)
pds@quintus.UUCP (Peter Schachte) writes: > The twm approach >(after selecting the gadget, the next corner of the window which the >mouse leaves becomes the one which is sized) is too confusing for >novices. I guess I don't see why people (others have mentioned this also) think the twm resizing technique is unintuitive. Once the cursor changes shape, you move to the edge/corner you want to resize. When you get to the border, it sticks to the cursor, and you resize as appropriate. I have to admit that it took a few tries to get used to, but that's only because I was so used to the Amiga/Mac way of resizing. BTW, I think the most intuitive method is having a resizable border all the way around the window, but this border *has* to be big, else it is too hard to grab. And on the Amiga's small screen I'm certainly not willing to give up the space! (The biggest trouble that twm has cause me is its iconification gadget. On more than one occaision I've accidently quit amiga applications by trying to iconify their windows 8-( ) Jim
FelineGrace@cup.portal.com (Dana B Bourgeois) (10/21/89)
[line eater food] My $.02: I don't use the front-back-front gadgets much so I can live with whatever is decided and put into 1.4. I use DMouse and would like to see the equivalent DMouse functions in 1.4 - that would please me more. I like the idea of a sizing gadget that allows the side(corner) crossed by the mouse to move. That strikes me as very intuitive and easy to get used to. What are the problems with that system? After reading the comments to date, it seems clear to me that most people want the sizing gadget changed so that the window doesn't have to be moved to resize (which is the current way things work). One suggestion was for preferences hold options for gadgets and graphics of the gadgets. While I am attracted to the idea(so I can have it *MY* way), I think it is important that system gadgets be all the same. One of the strengths of Macintosh software is that it all tends to look the same and users (the guys who pay for all the software) like it that way. Makes it easy for the casual user. (like my boss who can't quit raving about his Mac.) Dana Bourgeois @ cup.portal.com Please excuse my use of the 'M' word, OK?
davewt@NCoast.ORG (David Wright) (10/21/89)
About your beef, I prefer another fix. Do what Mach II does and let you use the Amiga-M key to flip through all the screens, not just between WB and one other screen. Then you can always use Amiga-N to go to WB, and still cycle through the screens with AMiga-M, even if they don't have any screen depth gadgets. I also like MAch II's use of Amiga-J and Amiga-K to let you flip forward and backward through the windows on a screen, without having to use the mouse to select window depth gadgets. What I would like to see is the close, depth, and resize gadgets from the "newlook" program installed as standard features, and also revamp the absolutely horrible proportional gadget arrows. The present arrows look like a 1st grader drew them, while almost every other program has really nice arrows. Dave
peter@sugar.hackercorp.com (Peter da Silva) (10/21/89)
You apparently missed one point of my suggestion... that it be selectable by SIZEBTOP (a new flag), just as SIZEBRIGHT is selected today. In article <28268@shemp.CS.UCLA.EDU> michael@maui.UUCP (michael gersten) writes: > This will cause major problems if a window is resizable and not movable. Then don't set SIZEBTOP on non-draggable windows. Really, no matter what you do programmers will still make inconvenient design decisions. That a feature can be misused is no reason to prohibit it. If you're playing what if... what about resizable non-movable windows near the bottom of the screen right now? > It will also cause problems if you want to shrink a window. Right now I > place my text window where I want the top, put some garbage text in, > and then shrink it until there is no wasted space at the bottom. So don't use SIZEBTOP on your text windows. > Besides, any growth/shrinkage must now be followed with a window move. Why? > Please, keep the size gadget in the corner, and do proper clipping/scrolling > so that we can get a 23 by 79 window that only scrolls when data is put in > the bottom corner. I don't have any idea what you mean by the reference to clipping and scrolling. That's a function of console.device, not intuition. A 23 by 79 window might be enough for you, but I can make a 24 by 80 window if I can put the sizing gadget in the top. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
peter@sugar.hackercorp.com (Peter da Silva) (10/21/89)
In article <1275@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > bottom of the window), but when you press the right mouse button (while > still holding the left button), you can move the mouse without moving > the corner of the window. When you release the right button, the > pointer "snaps" to the nearest corner of the window, and you can > position that corner where you want it. Yes, I have a comment. *I LIKE IT* I forgot about this, but then I haven't touched a Star since 1982. Wonderful machine. If the Lisa people had more than half a day playing with one at NCC '81, we'd all be a LOT better off. (hell, if we still had NCC...) -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
pochron@gumby.cs.wisc.edu (David Pochron) (10/21/89)
One simple solution to just about all of the problems which have been
discussed so far on this subject would simply be to do the unthinkable...
modify the INTUITIONBASE struct and just put your own gadget structs with new
images, positions, etc.
I wrote a nifty little assembly language program which does this, and if I
ever get the incentive to write a .doc file for it, I'll post it. It basically
reads in a file from DEVS: called "intuition.config" and set up neat things
like a 3D alt-image'd close gadget.
Needless to say, probably won't work w/ 1.4, but works quite nicely w/
1.2 & 1.3.
-- David M. Pochron | "Life's a blit,
| and then you VBI."valentin@cbmvax.UUCP (Valentin Pepelea) (10/25/89)
In article <3397@puff.cs.wisc.edu> pochron@gumby.cs.wisc.edu (David Pochron) writes: >One simple solution to just about all of the problems which have been >discussed so far on this subject would simply be to do the unthinkable... >modify the INTUITIONBASE struct and just put your own gadget structs with new >images, positions, etc. > >I wrote a nifty little assembly language program which does this, and if I >ever get the incentive to write a .doc file for it, I'll post it. This is *guaranteed* not to work in future versions of the OS. In order to save potential users of your software the agonizing pain of discovering incompatibilities in their preferred utilities, I suggest you nicely write a complete .doc file, provide examples and tutorials, package the stuff nicely in a .zoo file, put it on a 100% certified error-free floppy, shrink-wrap the thing, and drop it into the garbage can! :-) Valentin -- "An operating system without Name: Valentin Pepelea virtual memory is an operating Phone: (215) 431-9100 system without virtue." Usenet: uunet!cbmvax!valentin Bitnet: cbmvax!valentin@uunet.uu.net - Ancient Inca Proverb Claimer: these aren't Commodore thoughts
pds@quintus.UUCP (Peter Schachte) (10/25/89)
In article <3987@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: >I think the answer is to have all of the gadgets and screen/window >layouts in preferences. Let me decide where I want the gadgets to be. This is a good idea, but it wouldn't go very far. I don't think, for example, that it could handle scroll bars, since there is no scrollbar gadget (I know there's a prop gadget, scrollbars usually have a prop gadget and a couple of boolean arrow gadgets). The current gadgets are at too low a level to meaningfully modify/customize/replace them. Maybe this will be better in 1.4? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (10/27/89)
This is in reply to a bunch of messages; I'm not going to quote what's
already been quoted to death.
Wherever the sizing gadget is, it would be nice to be able to size and move
the window within the same operation. Suppose the current sizing gadget is
augmented so that when BOTH buttons are pressed, it becomes a movement
gadget. While sizing the window you would be able to move it, using the
same gadget as a "handle", by holding down the right button. This would be
very convenient no matter where the sizing gadget was. I agree that the
current location of the sizing gadget is best for text windows, and see no
compelling reason to move it for other types of windows, PROVIDED that it
takes up no window space.
How can this be done? One way would be to use an additional small
layer/window for the sizing gadget, so that the entire window could be
rendered into. This leaves the problem of the gadget's area being obscured.
Suppose the gadget is not actually rendered except when it's being used. It
could be indicated by hash marks in the window border: | and rendered only
when the mouse was within the gadget and the left | button was pressed.
Unfortunately, this would probably be less than | intuitive. It would
also prevent mouse clicks from being transmitted : to the application
within the gadget's area. On the other hand, -------..+ it would remove the
need for a separate layer, which would probably be much better from a
performance standpoint. I suppose the gadget could also pass on a mouse
click if A) no sizing was actually done (the mouse didn't move while the
button was clicked) and possibly B) it was held down for a sufficiently
short time, probably the Preferences double-click time.
With this scheme it would be desirable for an application to be able to
specify whether the gadget should be rendered (and take up a row and a column
of the window) or not (and possibly confuse novice users) OR "no preference".
Most programs would use "no preference" -- especially since it'd be the
default, so all current programs would use it. An option would be added to
Preferences to let the user specify the default behavior.
I see no problem at all with a single front/back gadget. It will cause a
few extra mouse clicks here and there; will undoubtably save some there and
here; but that all comes out in the wash. It WILL be a lot easier to use.
I still screw up on which gadget to use, after 4 years.
I doubt any of this discussion has any bearing on what will actually happen
in 1.4 -- isn't a little bit late to be designing the system when it's
already in alpha-test?
Bela Lubkin * * // filbo@gorn.santa-cruz.ca.us CompuServe: 73047,1112
@ * * // ....ucbvax!ucscc!gorn!filbo ^^^-VERY slow [months]
R Pentomino * \X/ Filbo @ Pyrzqxgl +408-476-4633 & XBBS +408-476-4945filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (10/27/89)
In article <3397@puff.cs.wisc.edu> David Pochron writes: > One simple solution to just about all of the problems which have been > discussed so far on this subject would simply be to do the unthinkable... > modify the INTUITIONBASE struct and just put your own gadget structs with new > images, positions, etc. > Needless to say, probably won't work w/ 1.4, but works quite nicely w/ > 1.2 & 1.3. There are at least two PD programs that do this: NewLook and 3DLook. I have NewLook running in my system; I think it looks tons better than regular Intuition. I don't really give a hoot whether it'll work with 1.4 -- if not, I will just stop running it. It's not as if anything depends on it. I can't imagine there being any problems with it in current AmigaDOS versions: as far as I can tell, it just overwrites some bitmaps. Either it finds and correctly overwrites them, or the system dies. The system doesn't die, so it's working. What I >would< like is a version of NewLook that let you supply your own gadget images instead of living with what the author thought was nice. I haven't seen source to it anywhere...? Likewise I'd like to see source to KickFont -- I think Topaz-8 is atrocious, but the Pearl (?) font that is supplied in KickFont is considerably WORSE... Bela Lubkin * * // filbo@gorn.santa-cruz.ca.us CompuServe: 73047,1112 @ * * // ....ucbvax!ucscc!gorn!filbo ^^^-VERY slow [months] R Pentomino * \X/ Filbo @ Pyrzqxgl +408-476-4633 & XBBS +408-476-4945