My GUI & OS Ideas
By Rob = Rob Alexander
Comments in [] are mine.
These questions were submitted to CSS on 9-9-98. Significant replies have been appended to them.
Ian = Ian Collier
Andrew = Andrew Halliwell
Orjan = Orjan Larsson
Luis = Luis Commins
Darren = Darren Salt
Chris = Chris Young
Mat = Mat Simpson
Joe = Joe Mackay
J'urgen = J'urgen Lerch
I've been thinking of ideas for the OS and GUI. I would ask your opinions on the following. Incidentally, there is a prize of nothing at all for the guy who spots the only two OSs that I've had significant exposure to.
1) Will we have memory protection?
2) What about allowing a program to have direct and exclusive access to some of the hardware? A game might want direct graphics (ie write to video memory) and sound - it would have to run full screen to do this.
Obviously only one program could do this at once, and could not usefully co-exist with other programs using the same hardware. Therefore all other tasks would be suspended when a program was working in direct mode. If there was a need to return to normal mode the direct mode program would automatically be suspended.
Andrew Never a good idea. All i/o operations should go through the OS. That way, it gets rid of the problem of incompatibility with later releases. Why is it needed? The OS is there to control who gets access to what and when. It's quite possible to tell the OS that until "whatever" operation is over to make all other tasks requesting the device to wait, but then, they could go on an do something more usefull instead, like store the info to be sent in a buffer and continue working.
Orjan We will be in the same situation as the Amiga, or even worse, the PC The day we want to make an HISPEC, we will have to make it compatible in hardware As a MacOS fanatic, I really love the idea of not being that darn compatible. Even the Mac Plus and Mac SE differs in hardware, but nothing differs in system to the programmers between these machines.
Luis That's where you begin to do the clever stuff with the underlying OS. The simple fact is true, only one thing is running at any one point, but there's so much power in the system that you don't notice (or shouldn't), there are a lot of processes going on and only one cpu. 'Direct mode' is a little misleading, games that use this are going deeper into the system, but what of the other processes that also run 'concurrently'? Sure, let the game have total control, but it also has to keep the score, monitor keyboard/joystick input, play the sound fx, calculate player position, missile trajectories, etc you'll only get faster graphics if that's what you dedicate the routines to, others may suffer. Not one process should dominate cpu time unless it is extremely specialised. Look at the old fractal renderers that locked up the keyboard and screen to compute the image. Only now that machines and algorithms are faster that the small percentage of time dedicated to keyboard scanning and screen updating is acceptable. There are some games that throw out the OS rather than go through it, but this seems to be less and less as deadlines for projects shorten and processors become faster. Remember, it's ONE cpu.
Chris Umm... bad for future compatibility. Although I doubt there will *be* a future machine based on this, so there's probably no problem.
3) Amiga style file and path names? e.g "poo:/lard/wib.htm" where the file "wib.htm" is in directory "lard" which is in the root directory of disk "poo".
Chris That's UNIX style. Amigas don't have the first slash after the colon (eg. "poo:lard/wib.htm") Ian] It most certainly is not. In Unix you don't have to know which disk a thing is on once the disk is mounted; everything is a plain file name. Of course removable media muddy the water a bit but you still treat them as file names. Solaris's volume manager gives you a /floppy/poo/lard/wib.htm as well as making /floppy/floppy0 point to /floppy/poo in case that's what you like. As with the Amiga, a disk can be referred to by its device name or the name of the disk inside it. (E.g. if disk "poo" was in zip drive "zip" then using "poo:" or "zip" in filename would do the same thing. The advantage of using "poo:" is that if "poo" was not in the drive (or any other drive) then the system could ask the user to insert it).
Chris Yes! Yes! Yes! I *hate* the way you can't access disks directly on M$ crap. It makes for a completely, well, un-floppy-friendly OS.
Ian Can't say I've ever wanted to access a disk by volume name. That might be because I've only ever used computers with one floppy disk drive, but when I stick the disk in I don't care what it's called I just want to get the files off it. Solaris automatically mounts floppies and CDs by volume name, and also supplies a symbolic link by device name. Any installation instructions you get with these media always use the device name, not the volume name, in the example commands.
Joe When I said all drives I meant all types - floppies, HDs, CDs, removable HDs etc. I can't say I find it useful for floppies but it's very useful for my SyQuest drive, where the system politely asks for the cart it wants when needed. And not like the Macintosh's "give me that disk or else" approach
4) Link files? Like Win95 shortcuts, but are physical links built into the file system (UNIX generally has these?). So they work from the CLI and _maybe_ are automatically updated when their target file is moved/renamed.
Andrew They're called "symbolic links", yes.
Orjan Have you checked up alias on MacOS? Works like you write there Even more fun, they ARE, not _maybe_ updated. And in latest beta of MacOS, can ask if they should be deleted, if the file they are pointing too also have been deleted BeOS have made it one step even better. Alas, it requires an file system coupled with an active database.
Chris Amiga also has these (see: MAKELINK command). UNIX and Win95 can do links to directories as well, which is nice. Amiga does support them, but not officially.
Darren Hmm. If you want automatic updating, then you'll want hard links and a Unix-like filing system. (Of course, hard links are limited to the same physical device.)
5) Right-click brings up context-sensitive menu (as in Win95)?
Darren No. The *middle* button should open a menu. And none of those stupid menu bars either.
Mat Oh dear. How many mouse buttons are we going to end up with? Why not just put a ball underneath the keyboard?
6) 'Live' desktop as in Win95. Initially blank, but you can then populate it by RClick to bring up a menu and selecting "Create Link", then creating links to all drives. (Or create a folder to put them in, and call it "My Computer")
Darren Stick the drives on an icon bar.
Chris Um.... I'd prefer the Amiga/Mac way of doing things: ie. inserted disks automatically appear, so you are accessing disks and not drives. Links can be created on the desktop, of course.
7) A GUI-lite mode where the OS and GUI stuff is available to programmers but no desktop or other fancy stuff is loaded. A CLI window appears by default. The Amiga does this if you feed it a bootable disk with nothing else on it.
8) Minimised windows (or all open windows) live in a taskbar at one edge of the screen.
Andrew Why? What's wrong with minimised windows as icons on the desktop?
Rob They get lost under a sea of windows. If you want to find a minimised window on a busy screen, you have to minimise a lot of other windows. Unless of course we arrange it so that the desktop can be brought to the front, but that would cause a whole load of new problems. Or, maybe we could have a easy-to-bring-up list of all windows, or all minimised windows. Or a task bar that can be popped up and down.
Ian But if you want to access an iconised window then doesn't it mean you have finished with your current window so you can iconise it and reveal all the icons? The point I was trying to make was that if all your windows are the full size of the screen then you can only look at one of them at once, so you might as well iconise your current window before trying to look for another one. Of course, as someone else suggested, you could merely send the current window to the back and all the icons will appear.
Chris Icons should *NOT* have depth. EVER. They should merely be attached to their window, even if that window happens to be the desktop. Because icons floating whereever they feel like it aren't icons at all. They're just badly misshaped windows.
Andrew They're called widgets, and in a client server system, like, for example X, they are quite efficient, take up minimal bandwidth, and not all that much memory... So what's wrong with having an icon in it's own personal window so that it can be raised above the other windows and selected? Almost everything in X is a widget in it's own right. Even scroll and menu bars. Remember, the whole point of this discussion is to take the best features from all OSs in an attempt to produce a hybrid with EVERY good feature.... Isn't it?
Chris I just don't like them. Those little minimised icons in Win3.1 are the same thing - they float over whatever you're doing when you don't really want them to. If you could push them to the back it would ok-ish. But you can't - you can only bring windows over the top.
Andrew There are different types of widget. Some widgets are the "children" of windows, and always appear with the window. Even a button in a dialogue box is a widget in it's own right, but it can't be moved around inside the dialogue box, or brought to the front without the dialogue box it's attached to.
Ian You can send icons to the back if you like in X (it helps if you have a RaiseLower key on the keyboard, but if not you still usually get an icon menu containing both Raise and Lower if you press the right mouse button on the icon).
Andrew Give them 2 depths (top and bottom) and you can call icons so they appear above ALL windows, or below ALL windows, and you solve the problem of not being able to find your icons...
Ian Well you can have that as well. In my window manager the middle button does it if pressed in the root window. In OS/2 there is a gadget in the toolbar at the top of the screen which contains a window list, and Ctrl-Esc also brings it up.
Darren Or as icons on the backdrop...
J'urgen Here on the Sun you can click the windows to the back - even _behind_ any _icons_ (that doesn't work for instance on the AMIGA). OTOH even on the AMIGA you can click a window behind any other window - minimized or not. And on a busy screen you might have problems finding any window (that's why I like AMIGA screens - now this opens a whole new can of worms ...)
9) Windows look like:
<Close> Title <Min> <Max>
Double-clicking on the
title brings the window to the front, but clicking in it once only gives it the
focus. If Min'd or Max'd, the appropriate button is replaced with
Darren No.
<back> <close> title <toggle size>
<vscroll>
<hscroll> <resize>
Chris Back gadget near close gadget. Not good.
Mat No reason why a minimised window *shouldn't have a title bar - the title bar stays visible when a window is minimised in MacOS, and that works very well, thank you.
Chris No. Add a depth gadget (first click to the front, if it's at the front, then it goes to the back). Or two depth gadgets, but that'll just clutter up the title bar.
Ian Have Front and Back buttons instead. Or make the right button bring up a menu when pressed on the frame which has these things on it. Of course, ideally there would be a "focus follows mouse" mode.
Rob If we have Min/Max/Front/Back/Close, that's quite a lot of buttons, especially for little windows.
Ian There is no real reason why windows should have a close gadget on them at all, really, since each application should have an "exit" button (or command) on it. For those stubborn apps you can have a close item in the frame menu.
Orjan If its an texteditor, and you want to close an textwindows, but not exit the application, what are you going to do when? Choose an menu item? An icon in the windows "somewhere" for closing an window ought to be there IMHO.
Darren Er, what are you on about? Some windows shouldn't, yes - dialogue boxes, in particular - but an editing window in a text editor should. And as for the 'quit' option, well that's on the menu which appears when you click Menu on the app's icon on the icon bar. Except in the rare occasions when the app doesn't install an icon there.
Darren The bar at the bottom of the screen, which M$ tried to copy for Wincrash 95. Typically, an application will create an icon on this bar, and must process clicks upon said icon; one standard is that when Menu is clicked on this icon, a menu will be opened containing at least 'Info' and 'Quit', and likely some way of easily accessing that app's global configuration window(s). Because most apps place an icon there, and that's where you access those apps' main menus. Any menu opened as a result of a Menu button click over a window is relevant only to that window; similarly any menu opened as a result of clicking on a menu icon (what would, under Windross, be the rightmost part of a laughably named "combo box").
Ian A text editor will have its own File menu with a Close in it so the one in the title bar isn't strictly needed.
Darren And would it close one window or all windows displaying views of the same file?
Ian The text editor will have a mechanism for saving and exiting files. If it is a menu based editor (xedit, axe) then there will be a menu option for "close file". If it's key based (emacs) then there will be a key for it. I'm not sure why you mentioned closing the file but not the application. Surely if you pressed the close button in the title bar it _would_ exit the application.
Chris What about directory windows? Anyway, it's far easier/quicker to click on a title bar close gadget than to hunt through menus. Closing apps/windows is quite a common activity, y'know :-)
Ian In my frame menu I have Iconise, Raise, Lower, Full screen and Delete (actually close) as well as the more obscure items Stick, Focus and Quit (that's a more violent form of close). You are welcome to stick all those in buttons on the title bar but it might get a bit crowded. A frame menu is a nice place to hide all the useful things you might need but which aren't important enough to have buttons of their own. Windows even has one (though you have to click on the button on the left instead of anywhere on the frame).
Chris You don't need all of them, though - close, a resizing gadget and a depth gadget. And possibly a maximise/minimise gadget. Of course, maximise/minimise can be the same gadget with different mouse clicks (or shift clicks or something) to maximise and minimise.
Ian Well RaiseLower can be a single button. Or you can put RaiseLower and Minimise on the keyboard instead of in the title bar. Or I might accept double-click on the title bar as a signal for Maximise (not that I often feel the need to maximise a window).
Chris Agreed. There should be some kind of misc icon/menu on all windows to do the really obscure stuff. But the question is... do you really *need* those obscure items in the first place?
Darren Full screen: doesn't exist. We have 'toggle size' instead, which will either expand the window such that its full logical work area is shown (actually, this is clipped to the screen size so that only part of its LWA may be shown) or reduce it to its previous size and location.
Ian The Full Screen option does toggle the size.
Darren Yes, but it's invariably to full screen or original size, not to a maximum sensible size for the window.
Ian Nope - X windows can have a maximum size and if they do then "Full Screen" won't make them any bigger than that. Quit: doesn't exist as a window tool, although apps which may run as transients (ie. only open one window and don't place an icon on the icon bar) will interpret the 'close' tool as 'quit'.
Iconise: Shift-Select on 'close'.
Ian Sounds a bit dangerous (and odd too). In order to prevent accidents, shouldn't Close be more difficult to press than Iconise? Like Tim Hartnell said when reviewing the Spectrum: you can easily type NEW by accident by pressing the A key, but the harmless STOP command needs two key presses.
Ian Windows even has one (though you have to click on the button on the left instead of anywhere on the frame).
Chris Not completely true. Click RMB on the title bar to bring it up - a right click on the left-hand icon brings up a different menu. Sometimes it is almost the same, but if you click like that on a directory window you get a, erm, "file menu from the parent window" or something.
Andrew Right... Little explaination time. In X, they use the terms Widget and Gadget to describe... Well... Tools. A widget is a tool that has a window attached to is, and it contains ALL the information concerned with that window, and any operations that the widget will perform. A Gadget is similar to a widget, only less memory hungry, because it's doesn't have a window of it's own. Both have their drawbacks. Widgets take up more memory due to the window. Gadgets use up more bandwidth, because widgets are held on the client, and gadgets must communicate with the server a lot more to tell their windows what to do. So. A widget can be anything in it's own window, from a button or menu bar, to a text editor. A Gadget can be something attached to a widgets window or an X window on the server used in a similar way...
10) Every object has an analogue of the "Properties" thing in Win95.
Darren Is this necessary? It seems like bloat to me...
Chris Well, obviously you need some kind of file information.
11) A single-tasking mode which works much like DOS. It provides a CLI and basic hardware support (e.g. file-system handling, console I/O).
Darren You should be able to access this and return to multitasking as and when required, without requiring to reset or restart the desktop.
Chris Together with hardware-direct mode.
12) Amiga-style aliases. E.g. you could tell the system to treat all references to "foopaint:/pics/" as "apps:/graphics/fp/pics/"
Darren Given the above, this looks too similar... I'd go for "foopaint:pics". This makes it clear which is the path reference and which is the device/disk reference.
Chris You're missing the point entirely. I fear I will have to explain the whole reason for Amiga ASSIGNs... Basically, the whole point is that they do look similar - if you have a program on a disk called "MyApp:", which expects to find its data files* on a disk called, er, "MyApp:", what happens if you copy the program over to hard disk? Or rename the disk? It can't find its data files, and will insist on asking you to "please insert volume MyApp in any drive".
The solution? ASSIGN MyApp: DH1:MyApp (or something)
Also, you can use ASSIGNs for splitting large directories over into two directories, two disks or whatever. Massive FONTS: directory? Just split it into two (let's say DH0:Fonts1 and DH0:Fonts2, for example) and...
ASSIGN FONTS: DH0:Fonts1
ASSIGN FONTS: DH0:Fonts2 ADD
Now, any reference to FONTS: will search DH0:Fonts1 first, and if it can't find what it wants in there, it will search DH0:Fonts2 They are also useful for shortening long path names, or as an easy reference for frequently accessed directories. Fed up of typing (OK, so nobody would have a path like this, but it's just an example) DH1:Apps/Paint_Packages/MyPaintProg/Pictures ? Just; ASSIGN Pics: DH1:Apps/Paint_Packages/MyPaintProg/Pictures Now any reference to Pics: will take you to the longer path name (which I refuse to type out again) Well, hope that's cleared that up.
* OK, so nothing should do this - as there is now a special PROGDIR: assign which returns the program's directory. But old stuff did.
13) Case-sensitive filenames?
Andrew Some people (QL users for example) prefer case insensitive, bacause you can type lrun boot, lrun Boot, lrun BOot or lrun bOOT and get the same file. And if you have a long enough filename (without the crappy dos or incredibly crappy win95 fix), it doesn't matter.
Other Comments
Ian Anyway I would have thought that most users on this group would be pushing for something like Sinclair BASIC, although I bet at least some of the Amiga and OS/2 users around here would agree that Rexx would be a nice choice.
Darren Maybe, though you should have a good look at BBC BASIC V and other current BASICs to find out what to do and how it should be done, and M$'s offerings for contrast.
Chris And I am one of which does agree. Rexx (or, more specifically, ARexx) is an EXCELLENT scripting language, which is ABSOLUTELY BRILLIANT at controlling AMAZING programs remotely. For automating tasks, or doing complicated things which the software doesn't directly allow etc. It would be nice if the OS had some kind of ARexx port built in to it*, so you can control all aspects of the OS/GUI through scripts, and interact with other programs. Completely superb.
* Of course, the Amiga's 'COMMAND' port allows you to do command line things, but to do anything other than running programs you need an extra library. What we need is a COMMAND type port, but also an OS port to directly call OS functions, like a compiled program would. And, of course, easy functions to send messages to other programs' ports directly from within a compiled program.
J'urgen As someone else already pointed out, we originally wanted something like a version of Sinclair BASIC as a general, inbuilt language. I think we could use this a scripting language, too. And an idea that I had already long ago for a Super Spectrum (or, a little later, AMIGA) is to have both compiler and interpreter for that language. They won't need to be seperate binaries but could use common pieces of code - parser or even the code generator (although the latter would probably produce only rather inefficient code).
Chris I think we should work out what they're called first - there's no problem with "icons", but "gadgets" have been referred to as "widgets" and even "window tools".
Andrew How about this? (Using X convention)
Widget: A Gadget that owns it's own window. (All data held on Client)
Gadget: A process that is owned by a window. (Window data is held on server and the gadget must communicate with the server whenever it wants to do anything.)
In other words, it's a toss-up between fast network and more memory use on client, or a slower, more congested network, and more free memory on the client. In non-client/server systems though, I imagine there wouldn't be much difference between a widget and a gadget, apart from the fact that a gadget doesn't own it's own window, whereas all widgets do. WIDGET = WIndow gaDGET...
Chris Maybe I'm just being thick, but what do you mean by "owning their own window". How can a gadget* own a window? Surely the OS or the application owns the window, and the window owns its gadgets?
Andrew With a widget, all window information relevant to it is on the Client side, and the Widget effectively "owns" the window, and can manipulate a lot of the data without having to contact the server. With a gadget, all the window data is stored on the server, and effectively, the gadget is "owned" by the window it's linked to. So it's got to communicate a lot more with the server. The OS runs everything, and allocates all resources. It's what the resources are allocated TO. A widget is allocated a window which is part of the widget. A window is allocated a gadget, which is part of the window...
Chris Yes. It's an X thing, where the terminals are merely display devices for the server (sorry, can't remember the actual name for this). Whereas I was thinking along the lines of "normal" (ie. single-user) systems, where there is only one computer running the place and there can't be two ways of doing things really.
