Chandler Styles and Appearance

The style project will enable both developers and designers to tweak visual elements of the UI more easily than is currently available in Chandler. The goal of the project is to both unify the definition of visual elements and to make adjusting those elements much easier for people who may not necessarily be coders.

Project Status

Currently the style project is being specced out so that we have an idea of how it will be implemented by the end of 0.7alpha2. Development should begin as part of 0.7alpha3. This document will describe the current plans for how styles and appearances will be implemented in Chandler.

Goals

There are two main goals that we hope to achieve through the styles project. The first is to achieve consistency throughout the application and on the different platforms. We hope to centralize the definition and ues of styles within Chandler so that they are not sprinkled throughout the app.

The second is that we want to make it much easier for designers and non-coders to tweak various elements of the UI to achieve the desired look for Chandler. Wherever possible we want to define easily modifiable styles that control as many visual parts of the application as possible. By separating styles and making the editing of them more accessible, we hope to make the turn around of tweaking the visual look of Chandler much faster and thus hope to improve the overall look of Chandler. A side benefit of more clearly defining what visual elements can and cannot be modified is that it will give the designers more knowledge of what they have control over. Hopefully this will improve communication and better focus us on what visual elements most need attention.

Design

The nature of what we are aiming for is something of a Pythonic version of CSS. We want to take a lot of the ideas of CSS, but keep the syntax more in line with the rest of Chandler and Python as a whole. The code for styles will be contained within their own style files. There will be a set of default Chandler styles included in a base style file, but each parcel can introduce their own styles (or override/inherit from existing styles) in a style file that will be packaged with the parcel.

One area where Chandler styles will diverge from CSS is that they will not use the cascading model of CSS. Instead, they will follow more of an inheritance structure. What is meant by this is that Chandler styles will be able to inherit from one another, borrowing some properties and overriding others. They will have an inheritance structure just like any other Python object. Blocks using those styles, however, will not use cascading to describe which style is being used by that block. While such a feature would have some uses (imagine a replacement detail view that wanted all of its items to use a similar background style), its inclusion would just complicate things for now.

Wherever possible we will try to stay true to the parcel model of Chandler. Style files will be loaded just like parcels, once loaded the information will be stored in the repository, and blocks will be able to define "default" styles. Future versions of the style project may include GUI editors for style, the ability to write out new style files, and more advanced layout controls, but nothing specific is currently planned for those.

Initial Styles

We are limited in what we can do with Chandler styles by what wxWidgets allows us to control. The first part of implementing the style project will be to make accessible those styles which are already easily editable in wxWidgets. That set of styles centers mainly around fonts and the out of the box wxWidgets styles. As wxWidgets currently stands we have a great deal of control over what fonts we use (some tweaking is required when dealing with different platforms as described below). All of the elements for those fonts (family, size, weight, etc) will be modifiable. Blocks will initially be restricted to adjusting the wxWidgets style flags. However, stage two of the style project will be to add new styles and new capabilities to how we can modify blocks.

Advanced Styles

Once there is a basic framework in place that allows us to modify the things which wxWidgets makes most easily accessible, we'll move on to changing wxWidgets so that we can control much more of the visual look of Chandler. This includes things like borders, spacing, and padding. Currently there are a lot of limitations in how we can change borders in wxWidgets. There are a set number of styles for borders (around 4 depending on the platform), but we want to have far greater flexibility to change the thickness, color, shading, etc of borders. We also want to be able to have borders on only some sides of the block (currently wxWidgets requires you have the same border on all sides of a widget). We want to add padding inside blocks and spacing around them. All of these abilities will require changes to wxWidgets. Hopefully once these changes have been made we'll be able to reintegrate them into the main wxWidgets project.

Platform Issues

One of the things that we continually bump into when dealing with styles is the differences across the platforms. Different point sizes render differently on each OS, the same border style will look different on each OS, etc. We will attempt, wherever possible, to unify styles across the different platforms. Bryan has already created a translation for point sizes that allows Mimi to define sizes according to the Mac and scale them appropriately so they match on Windows and Linux. We will attempt to do the same for things like border styles -- whenever we can create a one-to-one mapping we will do so. However, we also want to enable designers to specify different styles to be used on different platforms. They will be able to create a different definition of a single style for each platform. By default styles will be used across all platforms, but if a platform specific version of that style exists for the given platform it will gain priority.

Current Bugs

Contributors

• Jed Burgess
• Alec Flett
• Mimi Yin

Comments

MimiYin A couple of things that come to mind include:

• A bunch of stuff relating to the event lozenges
  • Background gradient colors
  • Background colors
  • Border colors
  • Font color
• Margins and Spacing (eg. Event lozenges, Minical, Calendar header area, App area icons)
• Drawing shapes (eg. Rounded selection bar in the mini-cal)
• Programmatic rollover and selection effects

Reid

• If you can, use type-based units like "em" and "ex". This allows the UI to scale naturally with the font size. This leads to resolution-independence. As screens approach 3kx2k, even those 2-pixel borders are hairline-thin.

JaredRhine Just brainstorming. Possible overlap with preferences system?

• Keyboard shortcuts?
• Presence or absence of icons? On the OQO small-form-factor computer, the icon bar at the top takes up a significant amount of vertical screen real estate.
• Default hours shown on calendar?
• Format of dates on week bar: "Mon 27 Tue 28" vs "27 Mon 28 Tue"?
• Icon bitmap/svg image to use?
  

Bryan

• I've got these bugs that relate to layout & sizing; can we consider whether these should be part of this effort?
  • Bug:5297 (detail view labels should re-width themselves based on text width): Currently, all the labels are manually set to a fixed width; this is inadequate for localization & developers who might want to use a wider label and have it line up with ours.
  • Bug:3222 (All-day checkbox should be left-aligned with date/time fields): A native-widget bug: Mac's checkbox has whitespace to its left that other platforms don't.
  • Bug:3626 (Pulldown fields in Detail view are misaligned in Linux) and Bug:4274 (Baseline of text is misaligned in the detail view): Lining up baselines of text labels with the text displayed in widgets isn't doable now (I don't know of a way to ask a widget how much space it adds around the text in it.)
  • Bug:4766 (Detail view single-line fields should become multiline to fit long text): Arguably outside the scope of this effort, but since this is basically automatic in HTML layout, I figured I'd bring it up.