srp@modcomp.UUCP (Steve Pietrowicz) (11/06/89)
I've been having a discussion with someone for the past couple of days, and I think we've probably reached a point where it's probably best to agree that we disagree. :-) I was wondering what folks here think. There are some utilities around that let you bring windows to the front when you click on them. Should the window be brought to the front if the window flags for that window don't have Front/Back gadgets? I think that it is desirable to be able to do this. After all, there are some programs that don't give you any way to get back to the CLI if they open a window on you that has no FRONT/BACK gadgets. Here's an example of something the will screw up: One full screen sized window has several gadgets on it (no BACK/FRONT gadgets, though). When one of the selection gadgets is clicked, a new window, which can't be moved and has no BACK/FRONT gadgets, comes up. The second window covers all the gadgets on the first window. Being able to click the back window and have it come to the front makes the second window disappear, and all the gadgets on the first window are back, which may really screw up the program. Should utilities with this window clicking ability have that function turned off as default, or should the option be left on as default? I think the option should be left off, but can be turned on by the user if he makes the decision to do so. It would be safer for new users who might get tripped up by not realizing what the function means. Perhaps the real question here is this: Is using windows to cover up portions of a screen a "correct" thing to do, or should this be avoided? Is there a better overall way to handle the problem? What do you think? srp -- SR Pietrowicz UUCP: ...!uunet!modcomp!srp CIS: 73047,2313
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (11/06/89)
In article <186@modcomp.UUCP>, srp@modcomp.UUCP (Steve Pietrowicz) asks how
depth arranging of windows without front-to-back gadgets should work.
Particularly, should such windows automatically move to the front when they
are selected?
That's why we have the ability to include depth arrangement gadgets.
It gives the programmer control over how the windows will behave. It also
lets the user know what has been decided. Trying to achieve that
flexibility without depth arrangement gadgets opens a real can of worms.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (11/11/89)
From article <788@jc3b21.UUCP>, by fgd3@jc3b21.UUCP (Fabbian G. Dufoe): > That's why we have the ability to include depth arrangement gadgets. > It gives the programmer control over how the windows will behave. It also > lets the user know what has been decided. Trying to achieve that > flexibility without depth arrangement gadgets opens a real can of worms. On a multitasking computer, making the assumption that you, as the programmer of an application, know which window/screen I as the user want to use next is WRONG! The whole purpose of being able to run multiple processes/tasks is to allow me to integrate several tasks. I don't think that utilities such as DMOUSE should need to exist. The fact that they do, in such wide spread usage, says something about the users opinion of the current interface, and choice of a useable interface. ***Hoisting myself to the top of the soapbox*** If there are patent problems with choosing to use something that looks like an existing interface that works/feels good, the rights should be purchased. We seem to be spending a lot of time trying to get features similar in capabilities to some that already exist, but the APPLE vs MS war seems to have blinded us of the fact that a legal solution is painless. The UN*X band wagon provides some interesting insight in that UN*X solves a lot of problems and provides access to many applications that are good for software development and multiuser tasks. If I were the CEO of a computer company targeting any market, I would be very interested in knowing how I could sell computers without have to spend money writing software. By providing a development environment that is complimentary to the usage of the developed software, you can't help but win. Most companies are choosing to buy commercial resale rights to UN*X or a derivative to eliminate the startup overhead of designing a multiuser OS. Commodores current direction with Amiga Dos worries me because they are attempting to reproduce everything that already exists in UN*X. It seems much more attractive financially to take UN*X my the reins, and just port the graphics support to that platform. I have heard rummors of SYSVR4 appearing down the road for the Amiga. I have yet to see anything official (other than the boot screen on my 2500). Everybody that I have talked computer purchasing with as of late wants UN*X, or at least UN*X compatibility. Most are buying 386 machines because they want it now. Okay, I am stepping down now... -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (11/14/89)
In article <4679@cbnewsc.ATT.COM>, gregg@cbnewsc.ATT.COM (gregg.g.wonderly)
suggests Commodore should replace AmigaDOS with Unix.
Unix is a fine operating system but it requires more resources than
AmigaDOS and it isn't as fast. I've been very impressed with the things
AmigaDOS can do. An operating system that lets a product like CrossDOS
work is well-designed indeed.
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...uunet!pdn!jc3b21!fgd3shf@well.UUCP (Stuart H. Ferguson) (11/27/89)
+-- srp@modcomp.UUCP (Steve Pietrowicz) writes: [ example of program using overlapping immobile windows to control user input state machine ] | Perhaps the real question here is this: Is using windows to cover up portions | of a screen a "correct" thing to do, or should this be avoided? Is there | a better overall way to handle the problem? My personal opinion is that controling the user's control sequence in this way is a bad practice. Not just because click-to-front utilities will screw it up, but also on general principles. "Modeless" is a big buzzword in User Interface circles these days, and for good reason. A "Mode-full" interface is one like the one described, where the user has to follow some sequence of steps to get through the control process. A modeless interface can accomplish the same input tasks, but allowing the user to do it in his own order. Typically, the same design process that leads to a modeless interface leads to a more flexible one as well. Just my two cents. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (ferguson@metaphor.com)