WANTED FEATURES FOR BERLIN
Wanted features for Berlin and the Warsaw and Moscow APIs
This feature list is intended for discussion on
design@berlin-consortium.org.
- 1) A "switch to standard" key (perhaps somthing odd like
Ctrl-Alt-SysReq), so I can switch to the standard Berlin configuration
when I temporaryly use another PC. If I press it again everything is
switched back to that computer's/user's normal fancy UI.
(Florian Laws)
- 2) The The BeOS font-dialogbox is very cool.
It allows a font to be both scaled, rotated and italicized in realtime - all
at the same time. This gives realtime feedback on how the selected font will
look without any effort from the user.
(ANOQ of the Sun)
- 3) It is good when popupmenus and dialogboxes always popup at the location of
the mouse pointer. This saves the effort of having to move the mouse to make a
menuselection or to answer a question in a dialogbox. Many GUIs
always display dialogboxes in the center of the screen which seems completely
crazy to me.
(ANOQ of the Sun)
- 4) In some cases it would be good to have the menubars of an application
right justified. For instance in a wordprocessor application the text
is usually left justified. If the menubar was right justified in
this case, the menus would cover up less of the text which is important.
(ANOQ of the Sun)
- 5) I like when all GUI-Controls are highlighted as the mouse travels over
them. Notice that when highligting for instance a listbox
there should be both a highlighted item and a selected item. It is not always
desirable if the mouse just selects what it is dragged over. This can be very annoying
when moving the selection with the keyboard while scrolling the list with the mouse.
(ANOQ of the Sun)
- 6) I like radial popupmenus a lot. I have only seen them used in a 3D modelling
application called
PowerAnimator from Alias|Wavefront.
Here are 2 hand drawn images of radial menus
with an Alias|Wavefront like L&F:
Radial menus popup at the location of the mousepointer, where the mousepointer
starts in the centre of the menu. This means that the mouse will only
have to be moved a very short distance to make a selection. This makes radial
menus very efficient, easy and fast to operate. It is even possible to make
hierarchial menus by popping op new radial menus when submenus are selected.
Here is an alternative look for radial menus:
(ANOQ of the Sun)
- 7) A cool idea for fast and easy operation of a radiogroup, would be
to allow the user to hold down the mousebutton and drag up and down to
change the selected radiobutton in realtime. If the selections also have
realtime feedback, this will make it
faster and easier to try out all selections in a radiogroup.
This is an alternative of having to click on each radiobutton
to see the effect of that option, which is the only thing possible in all GUIs that
I have ever seen.
(ANOQ of the Sun)
- 8) It would be good if the user could modify and customize hotkeys in
applications. This will allow users to choose their favorite hotkeys
for features that are often used.
(ANOQ of the Sun)
- 9) It would be cool to have some standard "menugroups" as part of a L&F.
Examples of menugroups could be: An "edit" group
for "cut", "copy" and "paste", a "selection" group for "select all" and
"select none", a "file I/O" group for "load", "save", "save as" and maybe "new (file/project)".
By making this an integrated part of the L&F it would be possible to have more consistent
menulayouts across multiple applications. If the user could also specify
hotkeys for those standard menu groups, there would also be a more consistent
use of hotkeys across multiple applications.
(ANOQ of the Sun)
- 10) It would be cool to merge the features of icon palettes, menuitems and tearoff
menus. It could be done if all menuitems could be dragged into toolshelves for
customization of the GUI, and if tearoff menus would be the same as a
predefined toolshelf. It could be made possible to put toolshelves/torn off menus
into other toolshelves for hierarchial organization of toolshelves.
The layout of menuitems and items in toolshelves could be toggled between icon-only,
text-only and icon+text modes. It could be cool if toolshelves/torn off menus could be
attached both to the outside of a windowframe and to the inside of a windowframe. It
should also be possible to detach it, so that it will be floating around independently.
(ANOQ of the Sun)
- 11) Let's support undo operations by default, and always by default
let's warn if the operation can't be undone. This warning should
of course be possible to turn off systemwide by the user. Berlin
should support unlimited undos/redos with a settable undo limit.
(Massimiliano Mantione, ANOQ of the Sun)
- 12) How about 3d sound? Here's how it might work: "sound object"
is created in a certain 3d location. The Berlin Sound Server (BSS?)
then "renders" it to the speakers in stereo, surround sound, or whatever.
(David A Feuer)
- 13) Compositor (should we trademark this? :) This is
the feature that lets you include documents into documents. Say a
tetris game in a text-document. The tetris game component is
responsible for displaying and otherwise handling ("editing"?)
the tetris game. We should possibly look at OpenDoc here, at
least for inspiration. When a Compositor component is included in
a document there should also be a URL, where the component
can be downloaded from, in case the document has to be shown on
a Berlin system where the Compositor component does not exist.
Sometimes you will not be able to do this automatically
as in the case of commercial components costing money.
Ideally there should also be a simple backup Compositor
component (such as an image supprted by all Berlin systems
or some OpenGL code), for a simple substitution of the component,
when the real component is not available.
(David A Feuer and many others)
- 14) Type Recognition (should we trademark this?) Berlin will
have standard components for recognizing the type of a file. The
type is described as a MIME-like string (such as "image/pcx" or
"image/jpeg"). When we have this, we can determine which applications
are able to open which files.
(Andrew Apted, ANOQ of the Sun)
- 15) Type Conversion (should we trademark this?) Standard components
convert files from one format to another. The files are recognized by
the Type Recognition system described above. Conversion managers can
be used to calculate conversion paths for files from one format to
another, when no direct conversion component exists.
(David A Feuer, ANOQ of the Sun)
- 16) Data Interfaces (should we trademark this?) This is standardized
interfaces for images, sounds, textdocuments (here we already have DOM).
The interfaces are used for accessing the actual data (like the pixels
of an image or the sample points of a sound). These interfaces can
be used both for I/O of images, sounds etc., when applications want
to support all fileformats installed as Data Interface components
in Berlin. The Image Data Interface should be defined by looking
at (at least) GGI and the GIMP plugin API. (ANOQ of the Sun)
- 17) Speech recognition. We should have a standard IDL interface
for writing speech-recognition components, so that these can be used
by all Berlin-applications.
(David A Feuer, Eric Johansson)
- 18) There should be a serialization interface. Better yet: Something
similar to properties in Delphi would be good. We can use CORBA attribtutes.
I don't know if the Interface Repository in CORBA will do this trick,
but we need some way of saying: "These attributes defines the state of this
component". That way all the state-attributes, can be stored/retrieved
(persistence), cloned, copied/pasted/DnDed, edited in a GUI builder etc.
(ANOQ of the Sun)
- 19) A filebrowsing API for listing the files in a directory. This
is necessary for making Warsaw/Berlin crossplatform in this respect.
(ANOQ of the Sun)
- 20) Builtin Color Management System which is important for
professional Imaging and DTP. We should exploit whatever features
GGI supports with this respect. There are even efforts for WWW Color
Management so it will even become an issue for people who aren't into print
business. For theory, see
http://icc.fogra.org/Dienstleistung/ICC-ProfileOffset/CM-theory-e.html.
The specs for ICC profiles and some thoughts about Web-CMS are at
http://www.color.org.
I think it is pretty high-level for now but it will become important later.
(Florian Laws)
- 21) Builtin print support. GGI handles the driver issues here.
(Massimiliano Mantione, ANOQ of the Sun, and many others)
- 22) All widgets should ideally be split into a Model part and a
View-Controller part as in the Swing API. Hopefully the performance of a
CORBA ORB will allow us to do this. For more information about this kind
of design, read this document about GUI-design.
(Massimiliano Mantione, ANOQ of the Sun)