Submitted by cronix on Mon, 05/10/2010 - 21:06
Posted in
The icons that are designed for the user interface have long, human readable, filenames. The problem is that the current TouchShield Slide only supports these great DOS 8.3 filenames.
I feel (have) a need for short generic filenames or at least a very clear naming convention that can be used for icons on the TouchShield Slide too. I think we will have new/other images in the future that can easily be tried in the several interfaces that use them (TouchShield, Processing and others...) I see several options:
- Change all current names to 8.3 filenames. That makes them less human understandable.
- Create some sort of rename script which holds some 8.3 naming conventions. This script can rename the filenames to short names that can be used on the TouchShield Slide.
What do you guys think? I have a preference for option 2 because thats easier for me :-). A copy scripts needs attention too and can have it's own bugs.
I'm starting to consider the
I'm starting to consider the possibility that the touchshield is a 'target' for images, and so is the processing GUI.
Consider a full-blown GUI for using on a netbook or PC. Users would want to take advantage of the larger screen size. While I don't necessarily think all of that screen should be taken up with moco controls - there are use-cases that simply wouldn't be obvious to me at this stage. (naturally =)
I wonder if, instead, we could simply have a set of images as the core set - some larger than what's needed for the touchshield (for scaling up), and others that simply aren't used.
One could then use make to call imagemagick or some other easily-scriptable application to build a set of the right size files. The makefile could also result in a re-naming script to be run, based on a map of the given target. Then, we could have our cake and eat it too - as make and makefiles are designed to be easy to maintain and be portable. =)
FWIW, I'm not necessarily hung on those filenames either. It was just easier to progress in that way, nothing that grep and sed can't fix in some code *g*
!c