My GUI design

[Tux]

Closing windows shouldn't be the kernel's job, anyway. A click on the close button should just send a message to the application -- no kernel involved.

Well, that is why people have to use the task manager. The goal of HALfix is to make a system that actually works. Why do you put the X button? To kill the app. Now, if the app is frozen, then how will the app close itself? That is the bug in Windows or should I call it a design failure?

In a true system, the X button should always close the app.

By close program I mean the "end process" button.

[Tim]

Well, hopefully you will never need to kill a process. Is the close button there only to kill crashed apps?

[Tux]

I can't speak actuallity right now. The project's leader ain't here for a long time. And I lost my version which was able to execute plugins. So it is a hard blow.

[Curufir]

There is of course another way around it.

Have the X button simply store application state onto disk and destroy the running copy.

Then next time the user starts the application instead of starting normally it starts with the saved state.

So X in this environment would actually mean "I'm done with this application for now, but I'm coming back later". An menu item would be what you use to exit by signalling the application, and killing crashed apps would come via a task manager or some sort of right click/kill mechanism on a task bar. In this scenario the program is unaware of the status, or presence, of the X button. It's only aware of the quit item on the menu should it choose to place one there.

This fulfils Tim's requirement of a false action being recoverable. If they close the window by mistake then simply restarting the application will restore the previous state and their work. The state saving mechanism could be made available to the program as well. So let's say they quit (Via the menu) their editing program without saving, instead of an alert the program can be smart and just store the current state. Next time they load the program the chances are they'll either continue working on the same file, or immediately close the file to start work on another, in which case the application itself can alert them to the fact that the file is unsaved before closing the file.

This leans towards the design of my own OS which is aiming for a fully persistent state, which is actually trickier to pull off than you might imagine.

[Tuxaroo]

Genius!

But how about games who have 64 MB slots?

My solution would be to do this.

Use a bit in the program header, so some apps have the feature or not.

Actually 2 bits,

bit 0: Backup Ram?
bit 1: Confirm close?

[Robert Lee]

But what if the process's state is dependant on its envirnment. Examples:

ProcessA is transfering data to ProcessB. Can ProcessB's state really be restored once saved/killed? Assume ProcessA is on another machine connected over tcp/ip.

ProcessA has hooked into several system events such as onScreenResolutionChanged. You save/kill the process's state. Change the screen resolution and restore ProcessA.

Another way to impliment this solution would be to allow applications to save thier state cooperatively, possibly using system functions for assistance. Before the OS kills an application, send it a StateRequest. The same system can be used for systemwide autorecovery if you can configure the OS to send StateRequests to each process every 5 minutes. Then leave it up to the OS to keep track of states. If a process has saved states next time it runs, the OS can send the application a StateRestore signal, the application can use to resume where it left off.

-Robert

[Tuxaroo]

My best solution would to have the kernel ping the app. If it is frozen, the X button does an XKill, if it is running, the program sends a wrap it up message.

[Solar]

2) Take into consideration that there are a significant number of people with either red/green colour blindness, so using those for important things in your default look is probably not a great idea.

Ah, but he is emphasizing information that uses a different channel... as opposed to the MacOS which (last time I looked) uses only color (and position, granted) to convey information, his buttons have color, position, and imagery. I'd say: Well done!

3) Human awareness goes top-left, bottom-right, top-right, bottom-left.

...unless you are of Asian or Arab origin, because this awareness pattern (for which I would like to see some sources!) probably comes from the way we write / read.

I mention this because it might be a good idea to shift the time etc over to the left side of the screen to stop it catching the eye so often.

I remember several systems of the 80'ies (like AmigaOS, RiscOS and some others) that had status information (time, RAM usage, CPU usage) along the top screen border, and "other" icons (like drives, program start icons etc.) top-left. That's in-line with the way we (western countries) read and write. Think a corporate letter, which usually has status information at the top-right.

However, since the appearance of that UI nightmare called Windows, users have come to expect the time to be bottom-right. (Dunno if Microsoft is really to blame, since I saw CDE doing it in 1993 already.) Even Linux follows that metaphor, however broken it may be.

So you have to chose between the "right" metaphor and the one people got used to...

4) DO NOT put minimise and maximise buttons next to the close button.

Copy that. Don't put the close button near anything else. (Another thing the Amiga Workbench did quite nicely.)

Looks good aside from those gripes, and..err..US date format (Yuck ).

There's an international standard for date formatting now (ISO 8601), which is yyyy-mm-dd. That's easily sortable, and unambigious as far as the field ordering is concerned. (05/04/2003 could mean April 5th or May 4th, depending on which culture you come from.)

[Tux]

I am using a diff. method for awareness. The human brain can be trained to follow patterns. I remember working perfectly on a windows. After I had to type something on a MAC, I had trouble for some like 10/12 minutes. Then I got used to it. About the human awareness pattern, do they forget left handed people? Diff. people have diff. orientation needs.

[mystran]

I've been thinking of a system where application is not an important concept. You work with documents instead. When you close a window, you close the document. Whatever it was, it will be the next time you open it, but you open the document, not the program.

So, say, you can have two text documents, and when you open one, you get an editor that remembers what the document looked like when you last closed it. This means that you also need to have persistent undo and probably some means of versioning, but personally, I don't see a reason why user should bother to save the document.

If it's not expected in the first place, and you provide means for versioning (to recall later versions when you want to discard changes) you can autosave as often as you want, which also means that user can expect to have the document almost up to date even on an unexpected system crash.

I like to think about documents as objects and programs as classes. You have objects, which you can manipulate with the methods implemented by the class. If all the state belongs to the object, it enough to save the object. The class can be loaded easily as long as the object (or the system storing the object) knows what class is needed.

[Curufir]

But what if the process's state is dependant on its envirnment. Examples:

ProcessA is transfering data to ProcessB. Can ProcessB's state really be restored once saved/killed? Assume ProcessA is on another machine connected over tcp/ip.

Ok, strictly speaking this is well off-topic, but I'll address it anyhow. Kindly bear in mind this is only relevant to my own OS design and likely to be different to anyone else's take on the situation.

There are three stages in completing any given task with a computer.

• The Input Phase
• The Calculation Phase
• The Results Phase

During the input phase information is fed into the program, during the calculation phase that information is manipulated in some fashion, and during the output phase that information is returned to the user.

I presume that all programs that will ever run on my system are deterministic in nature. Meaning that providing the same inputs to the program the same result will be produced no matter how many times the program is run.

The big problem with storing a program's state is, as you have pointed out, a problem of missing inputs.

The instinctive means of storing program state is to store the result phase, and the current state of the calculation phase making the tacit assumption that the input phase is over, or can be resumed without considering prior inputs. This works well for something like a text editor when the inputs are user driven, generally not related, and happen sequentially. However for other applications, such as your tcp/ip example, it isn't very helpful.

Now what I am proposing is that instead of storing the results/calculation phase state the only thing that needs to be tracked is the input phase. Any result phase can be reconstructed from the relevant input phase simply by running the task against the stored inputs. This provides total rollback capability to every single application running on the system. Any application can rollback to any previous state at will.

That's the principle anyhow. In practise things get a little more complicated. The scheme I'm working on involves determining states of rest for a program, ie those points at which it has completed a results phase and is waiting for a new input phase. At this point the entirety of the old input phase is stored and a new input phase record begun. I'm trying to work out a decent balance between maximising rollback (Ie number of input phase records stored) and minimising the space taken. The mechanism I'm currently toying with is to store the calculation/results phase every X input phases and removing the stored input phase records up to that point. This is purely down to the amount of space keeping permanent track of input phases would take, and the amount of time it would take to reproduce the current result phase from the zeroth input phase when the application resumes. The other problem is, of course, figuring out which inputs should register as a new input phase. Eg You don't want every single mouse movement being a new input phase for the desktop, rolling back mouse position is fairly irrelevant.

So how does this affect your tcp/ip problem?

Let's say, as an example, it's a web browser:
The browser got closed halfway through a transfer, so it lost half a page. Now the rollback mechanism allows the application to simply rewind the application to the start of the transfer (The "GET yadadada" operation) and continue where it left off. Whereas if I were simply stored the calculation/result phases I wouldn't know where this transfer began and the last one finished.

Or let's say it's a web server that got closed:
The server got shutdown halfway through a transfer to someone else. Now on resumption of the web server it rolls back to the input phase preceding that transfer request, a state in which it is waiting for requests. The user requesting the transfer has lost data, but the server has resumed in a viable state.

Sorry if that explanation isn't really great, I'm still working through the principles of this on paper and it confuses me as well sometimes.

[Pype.Clicker]

figure from looking at your virtual snapshot (which imho lacks some additionnal hints on how the things will *behave*) seems to suggest that those small squares at the window corner are meant for window resizing, right ?

i consider it's auwfully hard to resize stuff that way (which may explain why soo much people just make everything screen-wide ) ... moreover, it means that if you want to take advantage of available free desktop space *above* your window, you'll have to
1. drag&drop the window's titlebar to move the whole window higher
2. go back to the window's border (crossing the whole window) and click on that 5-pixels bar (or even smaller if the theme dezigner never resize windows) to actually expand the window...

I would suggest that alternatively, you dedicate a modifier key to send events to the window manager rather than to the window's application.
This is almost perfect in www.enlightenment.org (imho), except you don't have a visual confirmation of what's going to happen (i.e. changing the mouse cursor to a hand when the modifier key is pressed could have been nice, as you can expect to use hands to stretch/move stuffs ...)

For instance :
[*] ALT+Left-click drag&drop moves the window along the screen
[*] ALT+middle-click drag&drop resizes the window as if you clicked the corner of that window's quadrant... it makes it a bit discouraging when you click the middle area, so i would suggest the middle area of the window to act as a "centered-zoom" stretcher".
[*] ALT+right-click pops up the window manager menu (close, iconify, anihilate, remember state, stick, roll, group, select border and stacking order and much more)

all i think it lacks is a "proportionnal resize" method, which could be handy when displaying pictures, etc.

[Tim]

What's wrong with having a resizable border all around the window, like in Windows? That way you can resize a window in any direction without any modifier keys, by dragging on the border, or move it, by dragging on the caption.

[Pype.Clicker]

just the fact that borders are usually very smalls (and smaller when you have high-res screens) and hard to reach with devices like touchpad or small-red-device, or a low-battery mouse.

I don't mean there should be no borders, just that i can work about 10 times faster when i can use an alternate way ...

[Candy]

on that subject, if you use the newer windows design pattern (hate to say it but they did get it right...) and use a title bar for the upper left corner positioning, and a big surface for resizing the lower right corner (relative to the upper left one). If you make the surface large enough the user will use it.