Make Templates. Make Items. Make Views. Make Property Pages.
Don't make applications.
This shell is different from what you're used to. While many elements will be familiar, they may work differently from how they do on other systems. Most graphical shells on Linux can be called thin shells; they strongly resemble the underlying system. This shell is a thick shell. The default is to portray what a casual user expects, which may be different from the underlying system. This kind of abstraction is already familiar if you consider that a text shell in a terminal doesn't tell you anything about the semiconductors in the underlying hardware.
Parts of the Shell
The principle abstraction of this shell is the item. Items come in a variety of types and new types can be easily created. Items are parts of the user's model of the system.
Items
The shell provides a graphical user interface to a variety of items. Items are the objects of the graphical user interface. They may correspond to programmatic objects, but they may also be abstractions that unite various parts of the operating system. Every item has metadata. Item metadata includes the item's name, its icon, its media types, screen locations for its views, the files it represents, and more.
Some items are containers of other items. More on those later.
Items are distinct from other objects because they are part of the user's model of the system.
An item is an abstract concept. The shell represents items graphically in views, which allow items to be manipulated and changed.
Views
Each of the various graphical representations of an item is a view. The item icon is the simplest view. The item property panel is another. Every item has these two views. Most items have more views. Some items may have surprising views. For example, an OpenDocument file has its default view in an office program, but it also has a folder view because its contents are a zipped archive of other files.
Do not be confused by the term "View". As used here, a view is an interface to an object and facilitates changing the object in various ways. In terms of the model-view-controller paradigm, this shell's view is both a view and a controller.
On other systems, a view might be considered the main interface of an application.
A few of the shell graphics are not views of items, but are overlays on the screen.
Overlays
Overlays can be regarded as peripheral devices that extend onto the screen. The most obvious of these is the menu bar, which is usually present at the top of the screen. The menu bar also contains some system status indicators. Notifications will also appear in overlays.
Services
Services are common procedural elements that are available to all views. The dictionary service, for example, is available to provide spelling corrections, definitions, et al.
Items
For every kind of item on the system, there is also a template.
Templates
Templates are a special kind of item. When you drag and drop from a template icon, you get a new item of a kind specified by the template. For example, there is a folder template. Dragging and dropping from this template creates a new folder. There's a template for almost every kind of item you can create. One exception is a template itself; there's no template template. Templates can be created from existing items by dragging their icons into the template folder.
Templates can have content. If you create a template from a word processor document, then new items made from that template will have the same content as the document did when the template was created. This is an easy way to make form letters, for example. If a folder with content is turned into a template, all of the folder's contents will be reproduced by dragging from that template.
Some items contain other items. The most basic container is a folder.
Folders
Folders are items that contain other items, much like a directory contains files. Simple folders are just graphical representations of directories. More complicated types of folders exist.
Workspaces
A workspace is a special kind of folder. A simple workspace may represent a filesystem directory, but it also has information about the state of items inside it. The views of items in a workspace folder are connected to the folder view of the workspace. If the folder view closes, the item views close too. When the folder view is opened, the previously open items in the workspace reopen. It's a simple form of session management.
Desktops
Desktops are special workspaces. When a desktop is opened, its folder view becomes the background of the shell. Signing on to the system is really just opening your primary desktop, and signing out is closing it. Because the desktop is a workspace, any items that were open when it was last closed will be opened again when it's reopened.
Views
Every item has at least two views: its icon and its property panel.
Icons
Every item has an icon view. It is, as the name implies, an icon. The icon view may have indicators of the item's status, such as hatch marks indicating another item view is open, or badges denoting some status.
Don't confuse an icon with a decal or a badge. An icon represents an item and can be moved around. A decal takes the place of or augments some text on a control, like a button. Decals are stuck to their controls. A badge indicates some status information about an item and is usually found stuck to the item's icon.
Property Panels
Every item has a property panel which allows viewing and editing some of the item's metadata. Panels are divided into pages. The "General" page applies to all items as it shows the item icon and name. Additional pages depend on the type of item being viewed.
When an item as additional views, one of them is designated the main view.
Overlays
The Sign-On Screen
The sign-on screen shows icon views of the users' primary desktops.
The Menu Bar
The shell has one menu bar at the top of the screen. The menu bar changes according to which view is active. Users should be able to do their work without using the menu bar, but it's there for less frequent commands. It also provides a space for some system status information.
If every view had its own menu bar, it would seem that menus are really important. They would take up a lot of screen real estate.
The menu bar is at the top of the screen where it can be easily reached and easily seen, but stays out of the way.
Zoom Out
The zoom out overlay brings all open views onto the screen.
Notifications
Some notifications may briefly appear in small overlays.
Status Center
The status center shows a log of recent notifications, as well as a calendar and some other controls.
Services
Clipboard History
Dictionary
Calculator
Macro Recorder
The icon view of the primary desktop is on the sign-on screen.
The first thing you see on the screen after signing on, aside from the menu bar overlay, is the main view of the primary desktop. It's a folder that forms the background of the screen. The starting desktop contains a few items: a trash can, something something, and a templates folder.
Items, Views, Overlays, Services, Icons, Property Panels, Folders, Workspaces, Desktops, Templates: Those are the basis of the entire system.
- Items
- Simple types
- Container Types
- Folders
- Workspaces
- Desktops
- Templates
- Views
- Icons
- Property Panels
- Other
- Overlays
- Sign-on Screen
- Menu Bar
- Zoom Out
- Notifications
- Status Center
- Services
- Clipboard History
- Dictionary
- Calculator
- Macro Recorder
Permanence
Items have permanence, and so do their views. Icons on the desktop don't move around or disappear unless the user moves or removes them. Where a property panel first opens is arbitrary, but when it opens a subsequent time, it appears where it was when it was closed the previous time. All the views of an item reappear where they disappeared.
Views appear from somewhere and disappear to somewhere. Icons, which have fixed places in their folders, are an exception to this. If the item's icon view is on the screen, the other views of an item appear from it and disappear to it. If the item's icon view is not on the screen, then the other views of the item appear from and disappear to the nearest containing folder's icon view.
Workspaces go a step further. They keep track of their open items so they can reopen them when they are reopened.
Differences from Other GUIs
Some differences from other graphical user interfaces, especially those on Linux, should already be apparent.
There are three applications on Linux that are reimagined in this shell: the window manager, the file manager, and the session manager.
The Window Manager
The window manager does very little in the normal order of things.
- It keeps overlays, including the menu bar, on top.
- It keeps desktops on the bottom.
- It provides switching between desktops and keyboard-based switching between windows.
- It does not draw window frames, but it may provide effects like shadows.
- It does not reparent windows.
- It may provide a virtual desktop which is larger than the screen.
- It provides the zoom out overlay.
- In the event of a window being closed, it ensures the right window has keyboard focus.
- It may restrict the movement and placement of windows, but it mostly respects what clients give it. (The constraints on movements should suffice to constrain placement, because windows will only ask to be placed where they were before.)
Mouse-based focus is managed by the windows themselves using the globally active input model of the ICCCM. Window stacking order has some contraints, to keep overlays and desktops right, but clients are expected to raise their windows appropriately. This means that if a client receives input focus on a window, it should raise that window and any of its transients to the top of the stack, calling XRaiseWindow. If the focused window is a transient for another client window, i.e. a dialog for a parent window, then both windows should be raised and stacked transient over parent.
The ICCCM states that,
In general, the object of the X Version 11 design is that clients should, as far as possible, do exactly what they would do in the absence of a window manager, except for the following:
- Hinting to the window manager about the resources they would like to obtain
- Cooperating with the window manager by accepting the resources they are allocated even if they are not those requested
- Being prepared for resource allocations to change at any time
Despite this, it has often been assumed that focus and stacking should be left entirely to the window manager. The same has been assumed for what are often called "decorations", though the ICCCM does later state that window managers should display window titles. Those "decorations" are, in fact, controls, and clients can be expected to provide such controls themselves.
The File Manager
The file manager is mostly replaced by folders. Browsing the file system, as with most modern file managers, is relegated to a utility which most users won't need. The user model of items and folders is preferred by the GUI over the programmer's model of files and directories.
Users are free to arrange for a file browser to be the default view for any folder.
The system as a whole is an item manager. Items may be files, and they may also be database objects. For example, an address book can be a directory full of vCards or a database of contacts.
The Session Manager
The session manager is replaced by workspace folders. The principle user session is tied to the user's primary desktop, which is a workspace folder. Subsessions are created when other workspace folders, including other desktops, are opened.
In reality, every folder is a session manager. The difference for workspace folders is group control.
Notes on Folders
Folders should tend to be shallow. They're for the user's work, not for viewing the entirety of a unix filesystem. Some of the natural depth should be swept into projects which open into project views instead of folder views.
Folders should tend to be small. Folders containing lots of similar items should probably have another view which manages the size of folder.
When folders get large or deep, there may be a need for a new kind of view.
A deep folder suggests a need for project management. For example, source code should by default open in an IDE.
A large folder suggests a need for catalogue management. For example, the special containers described elsewhere.
Developers should look for opportunities to manage folder depth and size. Users should complain when things get out of hand. A dialog between users and developers should help the system grow.
Folders provide screen positions for both icons and views to opening views. These positions are shared with the window manager which may then animate the transition from an icon to another view. If the folder for an item is closed when the non-icon view is still visible, then the animation closing the open view will show it going to the containing folder's icon. If that icon is not visible, it will go to the next containing folder's icon, and so forth down to an icon on the desktop. (How?)
A workspace item combines file and session management functions. As a file manager, it displays icons for its contents. As a session manager, it keeps track of other views of its contents.
Expectations of Views
- Registration
- Views must register
(Where?) to handle item types.
- Views must register
- Opening
- Will receive timestamp
- Will receive icon position
- Will receive session manager data
- Communicate with session manager
- Communicate with window manager. Icon position should be provided before mapping.
- Request focus using timestamp. Focus is not guaranteed.
- Presenting
- Raise window if focused and show and raise secondary windows as needed.
- Move and resize or tell WM to move and resize?
- Draw controls to match state. Background window controls should be disabled if they do not process the click that grants focus.
- Update view geometry metadata.
- Closing
- Update view geometry metadata.
- Communicate with session manager.
Views are responsible for communicating with the window manager and their session manager. To present a window, a view must communicate to the window manager the position information it receives when opened. This information includes icon positions in container windows between the view and the desktop. The view will also receive a timestamp corresponding to the event which opened the view and must use this timestamp to set focus when its window is mapped. Focus is not guaranteed! If another view has received focus in between the opening event and the mapping of the window, then it will not receive focus. If and when the window does receive focus, it should ask to be raised.
A view must communicate updates to its window position to the session manager. (The session manager will set metadata accordingly, probably by communicating with the file manager.)
If a view contains items which may be opened in other windows, it should act as a folder or workspace.
A view may use alerts, dialogs, palettes, panels, or other transient windows. They should be marked as such for the window manager.
Folder views must provide to . . .
If a view contains items, it should accept template drops to create new items.
Some Implementation Thoughts
One View, One Process?
I suspect each view will be its own process.
Folders
I'll probably implement folders in a small app called folder. The app will do a bit of desktop integration and then use a library called libfolder which provides most of the code for the field of icons view. I imagine there will be one folder process for each folder view. Workspaces and desktops will do much the same using libfolder, but they need more code to do session management. The main argument to folder is a URL for something which can be viewed as a folder. If the URL is for anything other than a simple directory, it will probably be handled by another program instead. A program called archive, for example, might handle gzipped directories. This program will also use libfolder, so the archive will act like a folder.
OS/2 had the System Object Model which allowed for extensibility like with archive and folder. I don't know that anything that complicated is really necessary. There might be a better way now with something like DBus or flatpak portals.
With each folder being a separate process, inter-process communication is obviously going to be very important.
Property Panels
The trickiest thing may be the property panels. Every view of an item may need to add or add to a property panel page.
Again, I expect the panel to be another program, properties. It will have to load modules for non-standard pages.
Context menus
Closely related to panel extensibility is context menu extensibility. (Do we View as . . . or Open as . . .?) It may be useful to add menu items in addition to those on the View as . . . submenu.
Does dbusmenu (whatever it's called) actually work for our menu bar?
Positioning Views
Positioning views on X is easy, but Wayland doesn't allow client-dictated absolute positioning. There might be a way to have window manager/compositor-dictated positioning that preserves view positions. The views would have to advertise themselves as displaying a URI as a particular type of view. The wm/compositor would use that information to retrieve item metadata from somewhere and store it to somewhere.
My original thought was that position metadata would be stored either in special files or in extended attributes (EA). Clients would look up their own info and request their positions. It might be possible to have the wm/compositor maintain, or at least use, some database of URI, view type, and view position data. For local views, this can still be done in special files or EAs.
Not having the position data in EAs seems a good way to lose it, in the event that a file is moved. There would have to be some system level control of files that updates the position database.
Another problem with the window manager looking up position data is that it will be complicated for remote clients.
Special Programs
A few programs are themselves items.
Calculator
The calculator is a simple calculator.
Terminal
The terminal program is a general purpose view of character data. It is available as an execution parameter for shells, scripts, etc. All of the text shell templates produce files which will open in a terminal.
Web Browser
What can be said about this? It's essential, but its contents aren't really part of the shell. Bookmarks, on the other hand, can be filed away; they can be items.
Help Browser
The help browser is available from the menu bar.
File Browser
The file browser is what's usually called the file manager in other shells. It exists for GUI access to parts of the system which are not represented in the shell.
Special Containers
A few containers are special in that they tend to be large and unique. They may also be used by many programs.
Address Book
The address book is a container for contacts, and contacts may be used in many different ways. An item's metadata may indicate a contact as the author or sender of the item. Contacts should be available for email and also for event planning.
Every contact should appear in the main address book. The contact template should make sure this happens.
Bibliography
The bibliography is a container for references which may be used for citations. References include not only citation information, but also user's notes and possibly copies of the referenced material.
Calendar
The calendar is a container for events, and events happen all the time. something something integrated activity journal
As with the address book, all events should appear on the main calendar. Same problems here.
Feeds
Mail Boxes
The mail boxes are containers for messages. ???
Music Library
Photo Gallery
Containers and Items
Folders, Workspaces, Desktops
Archives
An archive is a kind of folder.
Connections
There's a remote desktop application, but you never run the application. Instead, you double-click the icon representing an RDP connection. To create a new RDP connection, you drag an icon off the RDP connection template and drop it somewhere. By default, this opens the property panel for the connection. From then on, you just double-click the icon to open the connection. You can shift-double-click to open the property panel again. or you can configure it in the connection's window, using the menu bar.
Terminals and Shells
Address Books and Contacts (vCards)
Calenders and Events
Bibliographies and References (Citations)
Feeds
Binders and Formatted Text
Presentations and Slides
Spreadsheets
Albums and Photographs
Slideshows and Photographs
Albums and Music
Playlists and Music
Stations and Music
Notebooks and Notes
Notebooks and Computations
Outlines
Bookmarks
Documentation
Ledgers and Transactions
Programs
Projects and Solutions
The default view of a project or a solution is an IDE.
Portfolios
Libraries and their contents
Raster and Vector Images
Database Queries
Other Media Types
But I'm a developer!
If you use an IDE, not much changes. An IDE is a view of an item called a project. Your project is likely to be a bunch of files in a directory. That's fine. The shell will recognize the directory as a project and, by default, open it in your IDE. If you need to manipulate the contents of the directory outside of the IDE, you can view the project as a folder. Of course, you can always use a text shell in a terminal too.
If you don't use an IDE, the shell can be like an IDE for you. Again, you are working with a bunch of files in a directory, so you can view that as a folder. More importantly, you can set that folder as a workspace. When you open the workspace, your previously opened views will open again. With not much work, you can make sure that all the tools you use are ready for you.
What about git?
It should be possible to make a view for a git repository that recognizes its complexity. Since a repository usually contains a project, an IDE may be the view of choice for working with that repository.
However git is integrated with the shell, it is likely that "git repository" will be a new kind of item. A project is a git repository is a folder is an item.
The problem with git for the shell is that file metadata may be easily lost, no matter how it's stored. I have no solution for that at this time. It will likely require a special file in the directory containing metadata for a particular version.
I need a terminal.
There are templates for text shells and they use the terminal program to show the text shells. Once you've created a text shell item, by dragging and dropping from the template, you can configure it to your liking through the property panel. You can change the terminal program used as well as the text shell used in the terminal program. You can set environment variable, initialization files, etc. You can even run non-shell programs in the terminal.
But I like applications!
In that case, I strongly recommend you use a Mac. It provides the best application-oriented experience by far.
Common Scenarios
Signing On
The sign-on screen presents desktop folder icons for users. Double-clicking one opens a password dialog. An animation shows the password dialog emerging from the icon. If the entered password is incorrect, the dialog shakes
Signing Off
The system menu, in the top left corner, presents the command to sign off.
There should not be any need for any sort of dialog in response to this command. The state of everything at sign off should be restored at sign on.
Finding an Item
Use the search item on the menu bar.
Starting Something New
How many steps does it take to start something new, once you are signed on? One thing needs to be visible: a folder. The desktop folder will do. Exposing part of the desktop may add a step.
If a folder is visible, a new item can be created by right-clicking the folder, selecting New from the pop-up menu, and selecting a type from the list of types in the New submenu. The new item will be created in the folder and its name will have keyboard focus. The name can be changed by typing and accepted by either pressing Enter or clicking anywhere else on the screen. This way of creating a new item is familar from Microsoft Windows.
If a template is visible, a new item can be created by dragging from the template to the desired destination. Again, the new item will be created with its name having keyboard focus.
The File→New menu item should only be used by programs that contain multiple items to add an item among the others. A simple text editor should not have a File→New menu item. (Or should it? Just to copy everyone else?)
Creating a Project in an IDE or Similar Environment
Open the Templates folder on the desktop. Drag from the project's template type to any folder to create a new project in that folder. Double-click the new project's icon to open the IDE.
Creating a Project as a Workspace
Open the Templates folder on the deskstop. Drag from the workspace folder template to any folder to create a workspace folder. Double-click the folder's icon to open the workspace folder. Use other templates to add files to the project.
An existing folder can be turned into a project by checking the Workspace option in the folder's property panel.
Resuming Work on a Project
To resume work on a project, the project's icon must be found. It may be on the desktop, in a folder on the desktop, or in a folder in a folder on the desktop. If the project is buried deeper than that, the reason should be explored.
Once the icon is found, the user double-clicks on the icon.
If the project has been developed in an IDE, that IDE should be seen to emerge from the project icon. If the project has been developed as a workspace, then the workspace folder should be seen to emerge from the project icon and any previously visible items in the folder should emerge from their icons.
Saving Something
This doesn't happen. All work is saved as it is done.
Really?
That's the plan.
Moving or Copying an Item
Most items can be moved or copied by simple drag and drop. In keeping with the convention on other systems
Templates are the exception. The default when dragging from a template is to create a new copy of the template contents.
Dragging an item from a background window does not bring the window to the foreground.
Moving of Copying Multiple Items
If a group of items is already selected, it can be moved by simple drag and drop. As long as the selection is not entirely templates, any selected templates will be moved or copied as the other items are. A selection of only templates follows the rules for moving or copying a single template.
Dragging a selection from a background window does not bring the window to the foreground.
Renaming an Item
Clicking the name of a selected item put it into an edit mode. There must be enough time between a selection click and a name click to distinguish it from a double-click.
Keyboards, Mice, Pads, Touchscreens, Pens, etc.
Almost everything should be doable with a keyboard and a single-button mouse. A long first button press can be interpreted as a second button press.
Holding down a key should present alternative characters, rather than repeating the key.
Accessibility
I hope that the system will be accessible by default. That is to say that I hope the design decisions I'm making will have immediate benefits for accessibility. I believe the light and dark control styles I have chosen also suffice as high-contrast styles. I have not chosen a widget toolkit, but I will be chosing one, or creating one, to work with assistive technologies. I'm barely approaching writing code, so I'm far from any sort of release. This system must be accessible from day zero. I expect to solicit accessibility input as soon as I'm satisfied that my design documents make a modicum of sense.