User Interface - Ideas for Google Summer of Code





User Interface

  • Separating GUI from Windowing/Events and Graphics

    Overview: We would like to separate the GUI engine from both the graphics engine and from the platform-specific Windowing and Events handling, as part of splitting the Ecere library into multiple modules.

    Anything to do with top-level windows management and relaying events would become part of a separate 'Windowing' module and could be handled by a number of backends, including other cross-platform toolkits.

    As part of this task, an interface API would be defined that could connect any Windowing implementation with:

    All existing interface drivers would be moved to this new Windowing module, with each driver in an individual library with its own dependencies. They would be reworked to implement that interface.

    In addition to our own platform implementations, implementations could also be developed for other cross-platform toolkits, including:
    • GLFW (highest priority)
    • SDL
    • Qt
    The Windowing module would provide a uniform API to handle cross-platform events and top-level window interaction, while making it easy to integrate either or both the GUI and Graphics engine.

    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)
    Other relevant/useful skills:
    • Familiarity with programming user interfaces
    Expected results: Removing all platform depencies from the GUI toolkit and making it possible to easily use our GUI toolkit and/or Graphics engine within a window of other cross-platform toolkits (e.g. GLFW, SDL, Qt) which may provide better support for a particular platform.

    Difficulty: Easy

    Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
    Additional Mentor: Réjean Loyer <redj@ecere.com>

  • 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" };
       };
    }
    

    and this style sheet

    { [
       { "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 }
    ] };
    

    would generate this layout:

    [auto layout screenshot]

    See also this initial implementation built on top of our current GUI system.

    The finalized GUI system should feature:
    • 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
    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)
    Other relevant/useful skills:
    • Familiarity programming user interfaces
    • Experience with CSS and building Web-based user interfaces
    Expected results: A GUI that can automatically adapt to any resolution or styling changes. A way to easily build user-interfaces without having to explicitly specify anchors for each control, and without negatively affecting performance. A working foundation GUI system to which all our common controls, dialogs and applications can be ported to.

    Difficulty: Hard

    Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
    Additional Mentor: Réjean Loyer <redj@ecere.com>

  • 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)
    Other relevant/useful skills:
    • Familiarity with programming user interfaces
    Expected results: A panel docking system built into the new GUI toolkit, easy to integrate in applications.

    Difficulty: Medium

    Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
    Additional Mentor: Réjean Loyer <redj@ecere.com>

  • 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)
    Other relevant/useful skills:
    • Familiarity with NCurses
    • Familiarity with Windows text console API
    • Familiarity with programming user interfaces
    Expected results: Restoring full usability of GUI applications in text mode, based on new auto-layout system. At minimum the Ecere IDE should be fully usable from a terminal.

    Difficulty: Easy

    Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
    Additional Mentor: Réjean Loyer <redj@ecere.com>

  • 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)
    Other relevant/useful skills:
    • Familiarity with programming user interfaces
    • Experience with CSS and building Web-based user interfaces
    Expected results: A way to style user interfaces separately from the code e.g. by an expert designer, making it much easier to achieve a modern look and feel when building user interfaces.

    Difficulty: Hard

    Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
    Additional Mentor: Réjean Loyer <redj@ecere.com>

  • 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)
    Other relevant/useful skills:
    • Familiarity with programming user interfaces, common controls
    Expected results: All common controls and dialogs in current Ecere GUI system working in new GUI auto-layout system, and adapted to reflect new styling & auto-layout design.

    Difficulty: Medium

    Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
    Additional Mentor: Réjean Loyer <redj@ecere.com>

  • 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)
    Other relevant/useful skills:
    • Familiarity with CSS and CSS editors
    Expected results: Being able to edit cascading styling rules visually from the IDE, with an intuitive interface for choosing selectors and applying styles.

    Difficulty: Easy

    Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
    Additional Mentor: Réjean Loyer <redj@ecere.com>



Copyright © 2017 Ecere Corporation. All rights reserved. | Design by FreeCSSTemplates.org.