GUI designs

[neowert]

Do you plan on doing a GUI for your OS? If so, post a drawing of them. 800x600 preferable. Maybe a brief statement of how it works.

[Candy]

Is it just me or is a gui design no more than a skin? Imho you could better ask people for new paradigms for use in their (or others) guis etc.

You can find numerous skins on lots of skin sites.

[BI lazy]

"... if so, post a drawing of them ..." what for a nice form of imperative, buck. And No, you won't get any from me.

[neowert]

I see the spirit of sharing is with us all. I may post mine when its done. It was inspired by palm OS, the CLI, and the game Uplink.

[neowert]

Here is my general GUI idea. Be warned, my image editor is horrible, and doesnt not let me edit text once typed. What you will read is what I typed on my first try. The white texts are explanations, not part of the GUI. The explanations are mostly notes to myself. No guarantee you will understand them. Having said that, here it is:
http://homepage.mac.com/neowert/gui.jpg

It would seem my idea is similar to Pype's. I figured my idea was not original.

[Tim]

I think if a GUI needs this much text to explain it (even if it is just a mock-up) then it needs a lot of design work. The best system (not just software) is one which doesn't need a manual. Read Donald Norman's books (not software books, but it all applies to software) for more.

[neowert]

Well, using it is fairly simple. Just connect the needed components. It is just unfamiliar. There was probably more written about what we know as GUIs now when the CLI was big. Plus the CLI needs a lot of explanation. It mostly comes down to audience. My intended audience is me, and whoever else likes the design. But if I get any better ideas I will use them. Unfortunatly, that is the best I have right now.

[Pype.Clicker]

i have a few things :
the 'search tool' in action: http://clicker.sourceforge.net/ideas/search_pannel.html

the 'shell': http://clicker.sourceforge.net/pixs/futureshell.png

the 'desktop': http://clicker.sourceforge.net/pixs/c32desktop.png

the 'shell viewing a C file': http://clicker.sourceforge.net/pixs/futureshell2.png

Note that all these things are just sketches of what could be done and are more some kind of 'eye-candy marketting' than result of existing code (i do not have a mouse driver nor a video driver yet

[Pype.Clicker]

It would seem my idea is similar to Pype's. I figured my idea was not original.

Indeed, our design are quite close to each other ... However, one thing i'm unsure about is whether you plan to have those multiple separate box while the application is running or just when you're editting the application (i.e. adding the packet viewer, for instance)

[neowert]

Well, I have not decided. Each box is a stand alone app too. I am toying with the idea of being able to hide them all. The problem with that is some apps would need input from text fields, so hiding would not work. My idea around this is customizeable windows. That is where you drag any text fields or other components to a blank window. You could then hide all the intermediate apps, and just work with one window. So it would be like creating custom apps without any skills at all.

[mystran]

I've been thinking about merging the idea of terminal, "screen" program, and graphical applications somehow.

Basicly I've considered the idea that a "window" is not owned by an application, but is a distict entity which can instead hold applications within itself. I think Plan9 used to have something similar, but basicly, the idea is that you have something like a terminal emulator, which can display both regular text-stuff, like shells (possibly with similar features to pypes design) and graphical components, including any applications that'd normally have their own windows..

Add tabs or something like that to the mix.. add a screen-like location transparent detach/attach functionality, allow stuff to be moved from window to another, allow app-components to show other components (like any component arch should allow anyway) and allow creation/reconfiguration of windows easily, and you have my vision.

Technically the vision is basicly that a window is nothing but a component, which serves as a viewport which other components can use. These components don't have too much control of the window though, unless they create their own (which is useful in some cases). Then a shell could add tabbed-viewports and putting the command prompt into one..

[proxy]

mystran's idea is actually suprisingly similar to the "kparts" structure of KDE's konqueror. basically, you by using this system you can embed any compliant application into the view pane of konqueror, be it vi, a terminal, a text viewer, etc, anything which is built with kparts API. you just seem to be taking it a step further, namely making it a basic part of the GUI and also making all apps in your GUI implicitly compliant.

I think it's a very cool way to do things, but unfortunately, I beleive it has some usability issues. Personally I love the kparts system, but I could easily see my parents getting very confused because of menu's constantly changing there layout and other part of the main view pane chaning purpose all the time.

However, once you understand it, it's wonderful

proxy

[Pype.Clicker]

... but I could easily see my parents getting very confused because of menu's constantly changing there layout and other part of the main view pane chaning purpose all the time.

Well, actually, Mac OS is known to be one of the easiest-to-use system and it does have a single menubar which content changes according to the currently selected application ...

[Tim]

The Mac menu bar is generally considered 'better' than the multiple menu bars of other systems, since you always know where it is, and it's always easily accessible at the top of the screen. And if Mac developers design their user interfaces according to the Apple standards, the top-level items don't change that much between applications.