[Cuis] Better Themes

Fri May 18 21:15:00 CDT 2012

Hi Folks,

(I added the Cuis list back, Casey, Hope you don't mind.)

In general I fully agree with every comment Casey made, so I'll only 
comment where I might add new info.

Casey ransberger wrote:
> Inline.
>
> On May 18, 2012, at 2:56 PM, "Phil (list)" <pbpublist at gmail.com> wrote:
>
>   
>> Casey,
>>
>> Since you mention it... :-)
>>
>> My Smalltalk projects right now are focussed on using Android (Cuis on CodDroid which is a lightly modified CogVM).  Part of that effort is going to include creating at least a basic mobile theme in which everything needs to be larger to accommodate the touch-based nature of mobile devices (i.e. larger images/text to support larger hit areas.)  
>>     
>
> This is a passion of mine as well; the small footprint and fast(er) Morphic make Cuis ideal for applications on small devices.
>
> The Tango icons are available as PNG in several sizes derived from SVG master images. You can scale them to whatever size you like and export PNG that ContentPack can bring in.
>
>   

I think that apparent size on Display and Themes are rather orthogonal. 
Any theme should be zoomeable! Evaluate 'Preferences hugeFonts' (and 
reopen any windows!). This preference makes everything huge, including 
mouse pointer. Icons are not resized, though. It shouldn't be hard to 
resize them like we do with the window controls (close, etc).

There are other similar preferences that are not so extreme. Play a bit 
with them. There is also 'Preferences verySmallFonts' (and friends), 
that are very useful for displays with low dpi. (For example 800x600 on 
a 24" Display. Sometimes I need to use this mode!)

>> While my effort is focussed on Android, I would hope that at least some of it (esp. themes) would be applicable to other mobile platforms such as iOS and WinMo (or whatever they're calling it this week.)  
>>     
>
> Totally. I would encourage that you avoid working about matching the Android look and focus on usability, but that's my two cents.
>
>   
>> The short term goal is to make everything bigger in a static way (i.e. everything is just a larger fixed size) but the longer term desire would be to support some sort of scalable theme approach where the user could decide how large/small to scale the UI.  
>>     
>
> Yes and sort of. Making everything bigger in a static way is the current best way forward IMHO, for the short term. Part of the reason I stopped walking down this path, however, is Morphic 3, which will (as I presently understand it) make heavy use of SVG, giving us some zooming for "free" (really, Juan's blood, sweat, and tears, to make use of an English expression.)
>   

:) Yes, that's the idea.

> There's another issue in mobile-land, though, which is that we haven't really addressed life without a mouse. While I understand that multiple Hands have been supported since time immemorial, relating that to a multitouch as opposed to a multi-mouse interface will be real work.
>
>   

Indeed. If I wanted to bring a Android app to the market, this is where 
I'd focus the effort. The existing evens are for keyboard and mouse. We 
need something better. We need to handle the situation where there won't 
be any mouse events, but touch events. These should be something 
different, and the system should work with any of them. Additionally, 
keeping big multiuser multitouch tables in mind when doing this is also 
needed. (This involves several fingers, and some fingers belong to the 
same hand/user; etc)

> At one point I actually had the code that Bert wrote to make Etoys work on iPad working in Cuis, but it got broken badly around 3.0 in a way that was frustrating to debug (bug only manifested on the device, and created a zillion debuggers.) It would be cool to revisit that and figure out what was going wrong at some point.
>
>   

Too bad you didn't tell me about that Casey! I'd help with that.

> Good work with getting Cuis up on and Android system, that's FREAKING AWESOME. I wish I had one to help, but all I've got is iCrap:(
>
>   

Now I'm starting to want an Android device myself...

>> I  literally just started to look at creating a custom theme by creating a Theme subclass and got a few icons loaded via ContentPack (not sure if I did it the 'correct' way since the comments seem acknowledge that the correct way is currently undocumented :-)  
>>     
>
> If it worked, you're probably doing it right. Can you describe what you did? I can probably help more with context. Unfortunately I'm having to run around a lot and just have a phone, so I can't quite browse code most of the time. But no worries! Catch-22 is just a bootstrapping problem:)
>
> ContentPack was something I threw together to actually fix a problem once that I accidentally introduced after bringing the new icons in initially (they weren't in the update stream, breaking it badly.) My original plan was to unload it after I had fixed the mess I'd made, that it would be a one-off, but Juan really liked the idea so we kept it around and explored hypothetically using it to accomplish similar things with content other than just icons. Juan saw a general idea there. All I saw when I wrote it was IconPack. Sadly, I can't remember how it works without looking at the code again. What I can offer is my promise that I'll do that, get back to the list, and we'll clarify any confusion in the class comment after discussion.
>
>   

Hey Casey, don't be modest. ContentPack is GREAT! It is not obvious, so 
a little docs would be great...

The idea is to let collaborators of art resources (graphics and sound 
designers) use whatever tool they prefer. For them, the resources are 
PNG or WAV. But we need to get them in source code, to load them as 
updates. ContentPack takes those external files and turns them into code 
(that creates live instances). Then the change set is included in the 
update stream. As we have the live objects, a later updates removes all 
that code. And we are done. Later, if we want to do another run of 
edition with external tools, ContentPack lets us export the resources as 
files, so our artist updates them. Then the process is repeated.

The following is copied from the release notes of Cuis 3.3:

ContentPack - A clean solution for a problem Squeak had for over a 
decade! (by Casey Ransberger)
    - Manages internal/external resources
    - Allows import / export to enable use of use existing stuff and 
external tools
    - Does not depend on external files for image update
    - Updates done with code (enabling change sets of Monticello packages)
    - Avoids cruft accumulation, code for resources is removed after update

All these properties are important, and ContentPack solves the issue 
really well.

> As far as Theme is concerned, I'm going to write a post today that will hopefully explain how it works pretty well. But that's a whole other post. Thanks for indulging me, Phil!
>
>   
>> Of course then I ran into the issue of the visual layout code appearing to be relatively hardcoded for a UI of a fixed size, started poking around at what I thought I needed to change and managed to crash the UI a few times before taking a break.
>>     
>
> Here's where we run into the limitations of Theme. I haven't attacked the sizing issue yet, as it currently hits me an non-trivial without Morphic 3. 

For the time being, I think that the best would be to do it through the 
Preferences in 'bigger and smaller GUI' category. Some details, like the 
size of the close button, is derived from font size. Other details that 
are missing should be handled in some reasonable way...

> Might not even really be trivial *with* Morphic 3. I am, however, deeply interested in what you run into while trying.
>   

Well, it is one of the main objectives of Morphic 3, so no matter if 
trivial or not, it should be there :)

> I there is a way to switch to large fonts though, and it's in the old Squeak 3 preference system if I remember right. I used that outright when I first started playing around with Cuis on the iPad. Might be #bigFonts on Preferences, but I can't know for sure without a computer that I can run Cuis on in front of me. Remind me to get back to you on this.
>
> FWIW, modifying anything about the UI in a living system is perilous because every frame of animation depends on that code. Be prepared for every change you make to be met with a thousand debuggers or a total hang.
>
> Getting Theme done, I ran into problems like that so often that I had to make a mantra of "file it out, save the image, try it to see if it works (by swizzling,) then send it to Juan for review."
>
> When you're hacking on the UI, it's important to be prepared for a hosed image when one makes a mistake.
>
>   

Right. In any case a nice detail of Cuis is the Transcript. It is 
different from the other Smalltalks. You can call transcript from a 
#drawOn: method, even from low level display damage repair code. If 
there are no walkbacks, the GUI will not freeze. So Transcript is a very 
useful debug tool here...

>> Any pointers re: how Theme and ContentPack are intended to be used would be helpful.  What I got from reading some of the code comments was that the final approach hasn't solidified yet, so simply having the code and image assets for one of the built-in themes as files on disk (rather than pre-baked into the image) along with docs on how to add it to the image would probably do the trick.  Also, any pointers on code considerations for scaling up the UI in size for this effort are greatly appreciated.
>>     
>
> Yep, my docs suck. Thank you for suggesting ways to improve them. I'll broadly explain Theme shortly, but ContentPack is going to take me a bit more time as I don't keep that code in my head.
>
>   
>> Finally, have you guys started thinking about the implications of multiple display densities as it relates to the UI and themes? (i.e. l/m/h/xh(dpi) on Android or 'retina' on iOS and sounds like it's coming soon on Macs)
>>     
>
> I have a feeling that "we" (read: Juan) have (read: Juan has.) At least a bit.
>
> CC Juan, because I feel like some of your questions regarding size of display and such might be more readily by someone who understands graphics and signal processing better than I do.
>
>   

I have thought a bit on this. Sometimes, besides size, another parameter 
of GUI complexity could be useful. This would simplify icons, reduce the 
number of widgets (leaving just the most important ones). The idea here 
would be (for example) that a GUI that runs in 800x480 can have many 
widgets drawn at low resolution (for example on a PC with a big display) 
or very few widgets at high resolution (for example on a phone)... I 
guess that would come after Morphic 3 vector graphics...

>> Thanks,
>> Phil
>>     
>
> No way, man! Thanks for giving it a shot. I'm going start scribbling down some notes on Theme to get started and hopefully get those sent off to the list tonight, though I won't be able to reach a ST VM until tomorrow.
>
> (what follows is my original post in this thread, supplied for context.)
>
>   

Agreed. Thanks, Phil, for bringing all this up.

Cheers,
Juan Vuletich

>> On May 18, 2012, at 5:19 PM, Casey ransberger wrote:
>>
>>     
>>> Hello all,
>>>
>>> Juan and I did what we could to make the look of Cuis fluid to the industrious user. Since we're all talking about Cuis on this list now, I thought I'd say: those themes aren't set in stone, and I'm not totally thrilled with most of them. I think the best we have is the one Juan did, which is the current default.
>>>
>>> The default is (I hope!) entirely represented by class Theme in Cuis. All other themes are subclasses of Theme (IIRC) but there are some other things which are possible. Nothing stops you from subclassing a subclass of Theme, and on and on. I was also able to do some really wild stuff with DNU hacks! But alas, we don't like those much in the core of the system:) so we didn't use that (though there's nothing stopping an external package from doing so.)
>>>
>>> Theme is (as has been pointed out) more limited than what Polymorph did. Polymorph, though, is huuuuuge and not in the spirit of Cuis, which is why I got the idea to write Theme in the first place. OTOH, Theme is *one class.* Given that it affects the whole UI in pretty deep ways, though, I think it's okay for it to be a largish class, as long as we are vigilant about protocoling our methods responsibly.
>>>
>>> Here's where I'm going. If you do play around with the skinning system, please let the list know when you find something you wish it did but doesn't currently. I can help with that, Juan can help with that, and if you can help with that: thank you!
>>>
>>> Most of the current non-default themes have been provided as examples of how to do it. I don't love them: we should make them awesome better.
>>>
>>> We're small, but we're damned good-looking, and looking better all the time.
>>>
>>> --C
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>       