Evolve auto-layout prototype into working UI system

Overview: We are building a new UI system with automatic layout, making it easier to add and modify elements to user interfaces, as well as to customize their look or support multiple resolutions.

At the moment, the Ecere GUI features very limited automatic layout, controls must be positioned with an anchor to an edge, or a Stacker must be used to stack controls with limited flexibility.

We have a basic design for this new auto-layout GUI system, which is fundamentally similar to web <div> and CSS positioning (elements with either vertical or horizontal flow), and will also feature some kind of box model for margins and padding, but taking a simpler approach and not suffering from what we see as limitations and over-complexity in CSS, especially regarding distributing available space.

We also hope for the core UI element to be lighter than our current Window class which provides everything from top-level form support, to a document model while also being the core element for all common controls. This would greatly encourage building more complex controls from core elements and also facilitate styling, while maintaining a low memory footprint.

With the current draft design, the following code

class Elemental : Col
{
   Bar r1
   {
      Element b0 { caption = "<<" };
      Bar s1 { };
      Element b1 { caption = "The" };
      Element b2 { caption = "Quick" };
      Element b3 { caption = "Brown" };
      Bar s2 { };
   };
   Bar r2
   {
      Element b4 { caption = "Fox." };
      Element b5 { };
      Element b6 { };
   };
   Bar r3
   {
      Element b7 { caption = "Left" };
      Element b8 { caption = "Address Bar" };
      Element b9 { caption = "Right" };
   };
}

{ [
   { "class == Elemental", bgColor = ivory },
   { "id == Elemental::r1", bgColor = gray, maxSize = { 100%, 100 } },
   { "id == Elemental::b0", fgColor = white, bgColor = navy },
   { "id == Elemental::b1", bgColor = red },
   { "id == Elemental::b2", bgColor = blue, fgColor = white },

   { "id == Elemental::r2", bgColor = lightGray, maxSize = { 100%, 150 } },
   { "id == Elemental::b4", bgColor = yellow },
   { "id == Elemental::b5", bgColor = aquamarine, maxSize = { 25%, 50 } },
   { "id == Elemental::b6", bgColor = tomato, maxSize = { 50%, 50 } },

   { "id == Elemental::r3", bgColor = lightGray, maxSize = { 100%, 0 } },
   { "id == Elemental::b7", bgColor = skyBlue },
   { "id == Elemental::b8", bgColor = teal, maxSize.w = 100% },
   { "id == Elemental::b9", bgColor = maroon }
] };

• Rendering using graphical elements from the new state-based vector graphics engine, including text
• Full box model support (margin, border, padding, contents)
• A scrolling system for GUI elements whose contents is larger than allocated space and configurable scrollbar options
• Support for wrapping elements onto multiple lines
• A special class for top-level windows (regrouping functionaliy specific to these) from which common controls would not inherit to lighten the footprint of GUI elements
• Information about whether the pointer intersects graphical elements marked as input-related in event handlers

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity programming user interfaces
• Experience with CSS and building Web-based user interfaces

Implement dockable panels on top of new GUI system

Overview: We would like the new GUI toolkit to feature a built-in docking layout system. This would follow the typical model where utility panels can be snapped to any edge of the main frame, while the main content (called the 'active client' window in the current GUI system) occupies the middle.

When docking to an edge already docking a panel, the panel would stack/dock next to that panel. If snapping to an edge while the surrounding edges already docks a panel, then this docking would not affect the space occupied by those surrounding panels. For example if panels are first docked to the top and bottom edges, and one docks another panel to the right, then the right panel would only use the space in between those already docked top and bottom panels; while if the right panel was docked first, then panels docked to the top and/or bottom panels would not affect the panel docked to the right which would keep using the entire height. It should also be possible undock panels and have them float.

For the docking to work nicely with the auto-layout system, the docking interface would simply set properties/styles defining the selected layout and space distribution would go through the same path and function the same as for non-docking windows.

See also the task of integrating this functionality in the IDE.

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with programming user interfaces

Make text mode GUI functional again

Overview: The Ecere GUI has historically supported a text mode, which can conveniently run in a terminal (using the NCurses library) or in a Windows console. This is particularly useful for running a GUI application you would normally run in full graphics, but for which sometimes the graphical environment is not available (e.g. through a shell, for an OS installation before the graphical environment is set up, in a non-GUI runlevel). It can also be used to build a console application but using a GUI style program flow, avoiding the clunky input entry and validation often seen in console applications.

Although the text GUI functionality is still working to a certain extent, the many changes that have occurred in the GUI toolkit combined with the little use the text GUI has received has rendered it mostly unusable. The major problem has been dealing with the difference of scales of GUI elements between text and graphical interfaces, a problem which is essentially the same as handling multiple DPI resolutions. We thus have good hope that the new auto-layout system will work wonders for maintaining a great text GUI with little effort, and it would in a sense validate a good auto-layout design.

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with NCurses
• Familiarity with Windows text console API
• Familiarity with programming user interfaces

Cascading Styles GUI Engine

Overview: Reorganizing the GUI common controls to facilitate styling. This would include reviewing styles inheritance from parent elements, specifying background, foreground and border graphics in a uniform manner. It would also include support for various types of selectors, including mouse over, some runtime properties, and at least planned support for smooth transitions between styles.

It should also be decided how styles applied to GUI elements will propagage to state-based graphical elements (from the graphics subsystem).

The relationship between properties, styles and selectors should be figured out. All styles will likely be properties, but properties would cover runtime aspects (e.g. whether a button is pressed, a checkbox is pressed, a control is active) which will rather act as selectors. It should also be decided which styles/properties will be common to all elements, and which styles/properties will be specific to some controls.

Styles would be loaded and applied from embedded JSON style sheets.

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with programming user interfaces
• Experience with CSS and building Web-based user interfaces

Reimplement common control and dialogs on top of new GUI system

Overview: All common controls and dialogs would need to be adapted to the new GUI system. Most immediate mode drawing should be replaced by a combination of state-based graphical elements and core UI elements with standardized styling properties (e.g. font, colors, borders, backgrounds). This will also follow style inheritance, and make it easier to style controls.

Event handling for controls will need to be revisited with the new GUI system passing information relating to the pointer intersecting with graphical elements.

It may be desirable to split the currently small number of common control classes into more specific control classes. For example the Button class could be split into CheckBox, PushButton, RadioButton, to reduce circumstances where some properties have no effect because of a particular configuration. It would also better reflect the range of functionality provided by the toolkit and make it easier for new users to find such controls.

Special consideration should be brought to data controls (e.g. ListBox) as to enhance the flexibility and styling of individual data rows and fields based on the new layout and styling system.

Event handling for controls will need to be revisited in connection with how each element will take care of its own events to support various scales and styles.

Functionality currently provided by the Window class should be organized elsewhere in a separate class (for example the document model, facilitating loading, saving and monitoring file changes).

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with programming user interfaces, common controls

GUI Style Designer

Overview: Support for editing the new GUI styling rules should be integrated within the GUI Designer and IDE.

A new rule editor should be developed, showing a list of all rules where inheritance and overriden styles are highlighted, in addition to the property sheet we already have, which would keep showing realized values.

The view on a particular rule feature should allow selection of selectors, such as the control's class and identifier (which would match to the 'name' in the current GUI system), whether the pointer is over the control, and other properties of the control (checked status, pressed, active...), the full list of which to be determined as part of the styling system task.

The styling rule editor should be integrated with the existing form designer, selecting controls on the designer bringing up existing rules or initiating the creation of new rules and selector, and highlighting in some way multiple controls affected by a rule being edited.

It should be possible to save and load styles separately in style sheets (using either eCON or JSON) (e.g. embedded in a project resources) or embed styles directly within the form and controls code.

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with CSS and CSS editors