Thank you Ian for your answer. A more elaborate one later.
Just a quick note.

The class MenuIcons has a method category 'import/export'.  When you
do the export you see all the icons in your Squeak directory. So
changing them is easy. That could be a field for immediate action -
providing icon sets.

Hannes

On 4/25/10, Ian Trudel <ian.trudel at gmail.com> wrote:
> Hi Hannes and Steve,
>
> Thanks for your feedback guys. I particularly appreciate your input,
> Hannes. By the way, Steve, I am a big fan of your Laser Game tutorial.
> It's great! Have you considered having your tutorial in Squeak
> HelpSystem? :)
>
> I absolutely think we should focus only on a simple one page
> requirements at the moment, based on feedback from our community and
> conversations with Andreas. Let's build a relationship with graphic
> communities. We are likely to spend time on refining our knowledge,
> documentation and UI as time goes by. Realistically, if only we get a
> bunch of icons within the first 6 months, that would be really great.
>
> The facelift Squeak has experienced is good and an improvement over
> what we previously had. The main issue is pertaining to the fact that
> the facelift is bringing Newspeak look-and-feel into Squeak. As far as
> visual identity is concerned: it looks like Newspeak, then it is
> Newspeak. This facelift buys us some time but we're going to lose our
> identity overnight (at least in term of branding).
>
> Your comment about Personas for Firefox is interesting because it
> reminds me that Squeak is the Smalltalk for multimedia. Ironically,
> perhaps, I am not sure graphic designers will be thrilled to use
> Squeak. On the long run, we may have to provide some kind of Smalltalk
> Starter Guide for Graphics. If they manage to use it and like it, then
> we get more users and more graphics.
>
>> 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.
>
> Extra > Standard Graphics Library contains some. The resources are
> often encoded into methods but sometimes into dictionaries I think.
> There is a resource manager but I am not sure how it works nor if it
> is used at all. I know where some resources are but nowhere enough to
> make a list. Besides, I have to work on my relationship with Morphic.
> We need gurus to give us feedback.
>
> Would Creative Common an acceptable license? Which other licenses
> would be acceptable? (Board members, what do you think?)
>
>> Yes, a list of priorities is an immediate need.
>
> We should first consider what kind of priority facelifting should have
> among the current priorities Squeak has (e.g. 4.2 roadmap). As I
> wrote, the Newspeak look-and-feel buys us some time. At least time to
> build a relationship with the graphic communities.
>
>> myGreatTheme-backarrow.png   (this name consists of the theme name
>> together with the resource name - just a start not something really
>> worked out)
>
> A small standard guide would be much needed, indeed. Provided that a
> resource manager would handle resources, importing and exporting, that
> could make it much easier.
>
>
>> I think some more research has to be done to find out and document in
>> a summary view what is already in the system.
>
> Documentation is a major task by all means. I would rather favour
> building a relationship with graphic designers. My understanding is
> that beautiful concepts don't get far in our community if they are not
> practical enough.
>
>> 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.
>
> Would you care to elaborate? I would rather hope graphic designers
> tell us about our shortcomings. Some of them are fine UI designers.
>
>> 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)
>
> What would be our immediate gain in doing this? I suspect it won't
> give us much. It also remains a documentation task. My point being we
> should not burden ourselves in order to ensure the success of this
> idea. However, we can provide new documentation based on our
> requirements to be integrated. Digging is the work of archaeologists
> and historians. It's long and boring and this won't get many of us
> motivated.
>
>> - 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
>
> I like that. Morphic is very confusing at times.
>
>> - 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')
>
> By the way, would Toolbuilder be skinnable?
>
>
>> There are several reasons I have not continued to keep the Skins project
>> up
>> to date:
>>  1.  I actually like the existing look and feel.
>>  2.  It surprises me there is core demand for this capability.  I have
>> always thought of it as a "goodie" and more of a personal fun indulgance.
>> I
>> may be wrong about this impression, of course.
>>  3.  Bringing the Skins project up to date usually took about a weekend to
>> do because the base Squeak design kept changing so much.  So the project
>> would drift away with other personal Squeak projects taking priority -
>> including a Laser Game tutorial rewrite I keep promising to complete.
>>
>> Mostly, I haven't kept Skins current because I like the existing look.  :)
>
> Steve, I think it's the reason why Squeak has very slowly evolved
> graphically. Many old timers were used to the look and like it,
> perhaps ignoring a bit its flaws. It took a long time to get the
> facelift we have now. In the spirit of rejuvenating the community with
> new members, the look matters. Besides, in term of deployment,
> skinning is a great feature — otherwise forever stuck to write custom
> UI components.
>
> JavaFX is an interesting case study because it understands building
> UIs require different people (programmers, graphic designers, etc).
> Business logic can be implemented in Java. JavaFX has a declarative
> language for its UI, UI builder, and other support for graphic
> designers. It's fairly easy to build good looking apps.
> http://javafx.com/samples/
>
> All the best,
> Ian.
> --
> http://mecenia.blogspot.com/
>
>