[Cuis] Better Themes

[Phil (list)]

Juan & Casey,

On May 18, 2012, at 10:15 PM, Juan Vuletich wrote:

> 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've got the Tango icons but haven't seen the exact icons used in Cuis windows (no biggie... I was able to replicate them without too much trouble in Inkscape)

>>  
> 
> 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!)
> 

I wasn't aware of these options... good to know.

>>> 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.
>> 

Agreed... I only mentioned Android so you understood what my objectives were.  While the VM and plugin work (i.e. the native views thread) I am doing is Android specific (as it would be for any other platform... though it will hopefully be pretty easy to adapt for other platforms), the goal is to keep the image work as platform-agnostic as possible.
 
>>  
>>> 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.
> 

I'm on-board with that.

>> 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)
> 

Right now, I'm not thinking too much about this re: Smalltalk as I'm still working through this in my native mobile apps.  When/if I figure it out there I'll probably have some ideas re: Smalltalk. :-)

> 
>> 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...

<pitch>While there's nothing wrong with iOS technically (I used to be an iOS user myself), I'd encourage anyone interested in Smalltalk to consider Android for their next device since it's a platform where we're all *welcome* and *encouraged* from a policy standpoint.</pitch>

That said, even if you stick with iOS or something else, hopefully some/most of what I'm working on should still be useful on your mobile device.

> 
>>> 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.
> 

Agreed.  One of the reasons I chose Cuis is that it made (for me) the best tradeoffs re: functionality vs. simplicity.  No need to apologize for getting it right.  Incomplete is fine... I'm just trying to understand where you were going (or planning on going).

As for what I tried, I created a directory called MobileContent with my icon art and then called mycontentpack path: 'MobileContent'.  That seemed to work but nothing displayed for the icons I modified (window close/minimize/maximize) when I opened a new window.  However, this was shortly before things started getting weird in the UI and I took a break from it.

>> 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...
> 

I'll take a look at that and see if I can make it work.

>> 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...
> 

Cuis has been relatively kinder when I've blown up the UI where Squeak was pretty unforgiving for me.  I'll take a look at where the code for this and the recommendation above leads.  This should at least get me going re: what I need to be looking at.

>>> 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...
> 

Not another pitch for Android so much as suggesting that you take a look at how they've somewhat addressed the issue re: having to support multiple screen sizes/resolutions with a common/consistent UI.  See http://developer.android.com/guide/practices/screens_support.html they also have a pretty good design site that discusses things like scaling a UI from a tablet to a phone @ http://developer.android.com/design/index.html

An example of what I was really trying to get at was how would a future Cuis deal with say a Retina display Mac where potentially either the UI is 1/4 its current size or everything is pixel scaled up and looks blurry/ugly?

>>> 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


Thank you guys for helping me to think a little crazy,
Phil