Dime Project Meetig 2001-12-01

Dime Meeting

Date: 2001-12-01

IRC Log

Summary by zzorn.

Attending

nikal
Tim
AlistairD
zzorn

How do you guys feel about us doing our own GUI library?

Problems with ParaGui

Young and buggy (as our own library would be too, of course)
No layout manegement
C-like event system and callbacks that is integral to the system, so it is hard to rewrite
Requires rewrite of size handling, component containment, etc to implement layout management
Different themes for different parts of an application not possible?

So what we would be able to reuse would be the drawing code, some of the theming code, and possibly some of the code for different widgets (with some rewriting).

So it seems the best way would be to write our own GUI library, and reuse useful parts of ParaGui, LibUta or other GPL window systems where possible.

In the end we agreed with the decision to create our own GUI (on top of SDL). It should be something that works for it's intended purpose (creating nice looking and usable GUI system for Dime), and is not overly generalized.

GUI Library name

We settled for just Meadow instead of MeadowGui.

Where not clear from the context, Meadow GUI, or The Meadow GUI Toolkit can be used.

Event handling mechanism

A mouse and keyboard event listener system, using the Observer pattern, and a Singleton event source that wraps SDL.
Button presses and such can be connected to some actions in three ways:
1. Assign one or more listeners that listen to action events sent by a specific widget, such as a button. (Observer pattern).
2. Inherit an Action class, and add it to a button, menu, hotkey, etc, through some setAction() method. The Action contains getName, getIcon, isEnabled, and similar methods, as well as an execute method. The button/menuitem/etc uses the getName and similar methods to get text for the button caption / menu item. (Command pattern). Some listening system could be used to listen to changes in the enabled state, so that the button can set itself to disabled when not in use.
3. Subclass a Component class, to create an own custom widget, override onMouseDown, onMouseMove, onKeyDown, etc, or just onMouseClick. Perhaps also register as a listener for mouse events, so that we avoid calling onMouseMove unneccessarily. Return true if the event was processed and consumed, falso otherwise (or the other way around). (Chain of Command Pattern).

Creating a Dime Christmas Demo

We should focus on getting a solid base of the events, and theme, classes and interaction with a few basic widgets to test it out.

Just displays a static map, not even loaded from a file. Optionally scrolling around on it could be implemented.

[Okay, getting it ready for Christmas can be a bit ambitious, as we only have some twenty days for that :) Anyway, we can aim to have at least something that compiles and shows something on the screen for then. --zzorn, editing the summary]

Single or multithreaded GUI toolkit?

We discussed wether to run event actions in separate threads from the main GUI thread.

PRO: The gui won't freeze on accidental long operations.
CON: Syncronization problematic when operating on shared data structures.

Solutions:

Have a flag for each possible event action, of wether to run it in a separate thread.
PRO: Built in, easy for user.
CON: Could result in a lot of duplicated functionality in many different events.
Provide an easy to use class that can run an event action / command in a separate thread.
PRO: The threading is well separated into an independent class.
It is clear when a new thread is used. CON: Slightly more work for framework users.

It seems that the second solution alternative would be the best one, as it allows us to not worry about multithreading in the implementation of the GUI framework, but instead encapsulate it in a separate class, that users can use in cases where they want to start longer calculations or separame processes.

Deadlines

AlistairD suggested that we may want to set some dates for near term battleplan items. It works rather well for some projects, such as the mozilla project.

What benefits do we get from deadlines? And what drawbacks do they have? Something to think about for the next meeting.

Themes

We discussed how themes should work in some detail.

Theme Properties

zzorn:

There's colors, transparency, font, optionally drawing style (add, colorize, darken, lighten, etc, depending on what SDL supports, if any) etc. Then there's possible bitmaps.. For rectangles, we have tile/stretch in X/Y direction, left/center/right align edge, top/middle/bottom align edge, and a set of tiles to use, with probabilities for each (good looking non-repetitive tiling).
Then there's more complex shapes, such as borders, scrollbars, etc. For borders we may want corner bitmaps, and then endponin, middle, and filler bitmaps for the edges. For scrollbars we want endpoint middle and filler bitmaps too, probably. These more complex shapes could simple consist of many small rectangle areas that have the normal rectangle properties, for the corners, endpoints, etc.

Theme Rectangle and Edge Renderers

zzorn:

I think it could be useful to create three kind of themedRectangles or something. One for a regular flat area, such as a button or panel bg. One for a horizontal or vertical edge, with endpoints, middle, and filler. And one for a frame, that consist of two vertical and two horizontal edges, plus four corners.. These themed rectange, or perhaps (Themed)RectanglePainter classes are then used in the default scrollbar etc repaint method, to do the repainting. They would also be given a settings file, and perhaps some prefix to append to it, to search out the bitmaps and/or color setting, translucency, etc from a given property file.. We'll also need some bitmap cacher and loader singleton that they can request bitmaps form by filename (/id?)

Applying a Theme

We could store theme data in property files (one for each widget type), that are loaded into Property classes, that are queried for string contents based on a string Id. The settings for a parent widget class are used as defaults, unless overridden in a property file for a specific widget.

Setting a theme would go something like this:

A new theme is loaded. Theme *t = new Theme(); t->load( "halloween" );
The new theme is applied to the application ( myMeadowApplication->setTheme( t ) ), or to a part of the application ( myLoginDialog->setTheme( t ) ).
The application root component, or the component that the theme was applied to, sets it's theme variable to point to the theme, queues a redraw request, and goes through all it's children and applies the theme to them.
The setTheme methods calls some initThemeProperties method, that gets the current text color, bg color, and myScrollBarBgRectanglePaintor.topEdgeBitmap, etc. by querying the Theme class properties.
The redraw operation of different widgets call the ThemeRectanglePainter etc classes, as well as drawText( buttonCaption ) etc.

We could store the needed RectanglePainter objects locally in each widget, along with variables for font color etc, then we have those instantly available as local vaiables when we paint the component, and there's no need to do string lookups for each widget on redraw.

Internationalization

novalis pointed out that Internationalization should be a toolkit function. We could also use an existing library such as GNU gettext for it. It also tends to be one of those things that is a major pain to integrate later, if not included from the start. This is something we can think about when we have the basic Meadow system working.

Updated and New Documents

Nikal has written a great concept document, it seems like it will make it to this months Chopping Block. :-)

zzorn created a new page for the Meadow GUI Toolkit in the library section, and also summarized a prioritized feature list for it.

zzorn also updated the Dime Architecture document to reflect the latest plans, and wrote better descriptions of the roles of the different libs.

Next Meeting

The next project meeting will be Saturday, 2001-12-08, at 15:30 GMT.