[squeak-dev] Re: looks evolution

Hannes Hirzel hannes.hirzel at gmail.com
Sat Apr 24 07:47:02 UTC 2010

And there is the entry

NEW Skins support for Squeak 3.4/3.5/3.6/3.7


Steve writes that he has successfully imported imported and tested 35
themes at that time (June 2004) From:

Skins [ENH]
13-Jul-2004 tested in Squeak 3.7beta update #5878
13-Apr-2003 tested in Squeak 3.4, 3.5, 3.6 alpha

NEW Skins support for Squeak 3.4/3.5/3.6/3.7
In early February 2003 someone wrote to me again asking if I would
please port the old skins code over to Squeak version 3. Fact of the
matter is, I did not want to port the old skins code because of a
number of outstanding issues. However, I did start working on a
re-write a few weekends ago and this is a PRELIMINARY result.

This new model attempts to accomplish a couple of goals that I saw as
defects in the original skins model:
# Use "standard" theme files from the open source Linux world.
# Replace existing morphic components in the skinned window by finding
them dynamically and not requiring special subclassed window code.
# Provide a way to delete a theme and restore the window to it's original state.

I've accomplished those goals. Also, the framework can be extended to
support other imported theme files. At this time the skins framework
will import the "Ice Window Manager" themes directly as can be found
at a site like http://themes.freshmeat.net. I have successfuly
imported and tested 35 themes from that site in Squeak with this new
skins code. No special handling of the theme files is required. Just
uncompress them and tell Squeak where to find them. More about the
actual skins theme process later... The nice part about this approach
is that I don't have to concern myself with distibution of themes and
art work. Lots of existing themes already exist and are being added
regularly. The Ice Window Manager themes were selected as my first
importer because they seemed to be the easiest to understand and seem
to be standard forms based theme designs. At this time window title
bar, title bar buttons and window borders are imported and managed by
the skins framework.

On 4/24/10, Hannes Hirzel <hannes.hirzel at gmail.com> wrote:
> Hi Ian
> Thank you for keeping on pressing on this issue.
> On 4/24/10, Ian Trudel <ian.trudel at gmail.com> wrote:
>> Nobody is interested to collaborate? I'd hate to see a good idea die
>> alone in the dark.
> It will not.
> I think people _are_ interested in working on this.
> The challenge is to put mechanisms in place which makes it easy for
> people to contribute.
> More see below.
> It would be great to know what kind of graphic
>> resources is needed to have a fully functional UI and I'd expect
>> Squeak UI guru(s) to give us some feedback. An estimation in numbers
>> of number of images required would be a plus.
> Yes, we need to know where the graphic resources (images, icons, color
> definitions, border with definition etc) are located. Currently I have
> no idea where to look for this.
>> A requirement sheet could further include:
>>    * A comprehensive list of our most important points in term of
>> visual style (and usability?)
>>    * A comprehensive list of graphic resources required (icons, menu
>> and window decorations, buttons, splash screen, etc)
>>    * Visual effects and transitions, if any
>>    * Files and images formats, if any specific ones are required
>>    * Accepted License(s) for contributions
> YES, the license is important.
> And we could have different loadable libraries with graphics.
> Currently we deal mainly with bitmap graphics. But the source file
> should be vector graphics wherever possible
> http://en.wikipedia.org/wiki/Open_Clip_Art_Library
> http://planet.openclipart.org/
> There is the Tango Icon library we could put to immediate use to
> replace the 'cartoon' arrows.
> **)
> The have as well started a table giving a list of visual metaphors
> http://tango.freedesktop.org/Icon_Metaphors
>> We could also stipulate our preferred visual style(s) but it should
>> remain open.
> Yes
>> We should focus on the most important elements (e.g.
>> related to usability, such as colours that can be looked at for hours
>> and hours without bursting any people's eyes).
> Yes, a list of priorities is an immediate need. However as this is
> open-source development this list is just a list of suggestions and
> people may pick to work on something what they feel comfortable with
> or what they have fun with.
> So far we have a solution for changing the background (a few hours
> old, see another thread).
> As the next item I would see the replacement of the navigation arrows and
> then
> the implementation of a chooser for color themes (I think there are
> mechanisms in place - we just have to make use of them - i.e. polish
> and enhance them)
>>Graphic designers need
>> to be inspired and have some freedom for their creativity, especially
>> when it comes to contribution given with their heart. :)
> Yes.
>> I believe Polymorph is currently not loadable in 4.1 and our UI is not
>> really skinable. We should put in place a small plan to make it easy
>> for graphic designers to test their graphics in Squeak, if possible.
> This is linked to your remark above where you say that we need a list
> of graphical elements (including a description how they are supposed
> to be named) to make it easy for non-programmers to come up with
> another set.
> I.e. something like
> myGreatTheme-backarrow.png   (this name consists of the theme name
> together with the resource name - just a start not something really
> worked out)
>> This will increase the number of contributions.
> Indeed. See the 'personas' movement of Firefox 3.6. You may choose
> among 10 thousands of 'personas'.
>> A simple one page requirements sheet would be more than enough.
> For the start yes, but I bet you'll see that it will develop quickly .....
>> Anything else should be on?
> I think some more research has to be done to find out and document in
> a summary view what is already in the system.
> I think there are graphic themes. Let's give it a try and do some more
> to find out what is lacking with the current schemes.
> I we should work on a list of action points
> - background chooser (done by Steve Wessels)
> - inventory of graphics
> - dig out things from the past and summarize what is useful for the
> future (entry point for example http://wiki.squeak.org/squeak/1114,
> Appearance / Themes / Skins - October 2006)
> - evaluation of current situation - what does the 'theme' mechanism in
> the preferences browser deliver? (see screenshot)
> - naming scheme for graphical elements of the user interface
> - polishing the preferences browser
> - loader for UI-elements ('personas' idea from Firefox; maybe it is
> possible to tap into that - i.e. just use the 'personas')
> - list of further actions
> - .......
> Hannes
> **) I do not dislike the cartoon icons as such but for a more general
> audience I think we should have something more neutral.  The
> 'industrial', slightly 'retro' look we now have is quite OK for the
> time being I think. In the end we should have  different well worked
> out skins and themes people can choose from. One reason for this is
> that people may adapt Squeak for their specific application needs. Or
> a game programmer might want to have something particular.
> P.S. I am 'out of Squeak office' for the next 3 hours.....

More information about the Squeak-dev mailing list