I'm in hearty agreement.
keeping around the current UI paradigms is an option. Fixing these
issues, streamlining ui creation, making use of decorators (i.e.
rethinking of SC's UI patterns.
use cases, too. For example - you need to create six sliders to
control six parameters, based on six control busses. Each has an
associated spec. Their layout, markings, color, and labeling needs
can be incorporated into other UI later. They need to be properly
updated. Despite the fact that this is maybe the #1 most common UI
them their own extensive paradigms and specific uses.
make it cleaner, easier, more flexible, and prettier on both sides.
Post by Sc iss
sorry to disagree once more with you, felix. but the mere solution
of saying well you can create a log background and place it under
the view, you can create a ticks view and place it next to the
slider, and an led-like button and place it above the level meter,
will recreate exactly the mess that the current GUI is suffering
from : everyone is doing this themselves by hand, counting pixels,
and so forth. and then, one day, when a slider as pixel or or less
on any side, the pretty layout is gone. or change a font size, and
then redo all the work.
separation of objects, yes, but we need semantic grouping of
objects. and getting rid of pixel bounds (at least make them
optional). why not add a tick decorator to the slider, a grid
decorator to area filling objects, and so on. the layout algorithm
will take care that they get properly aligned, but you will still
be able to exchange the decorators.
one thing they did right in java's swing, although a little bit
late in the history, is baseline alignments, as an example. you
have a layout and you tell it two components match in their
baselines. doesn't matter where exactly vertically a text appears
in a button, the layout takes care that the button text and a
neighbouring label's text look fine together.
nothing against DIY gui fabrication and manual pixel tuning, but i
think a little bit more autonomous decisions from the GUI systems
don't do any harm.
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
(+) I think it is rather essential to be able to change the
background to a lighter/darker color, yet it should not destroy the
overall look and feel.
since the edges are a hue-less shading effect, that just gets
overlayed on whatever color is used. so I think it should work fine.
the one limitation would be if your background was black, then the
shading would not be visible.
I'd love to see this sort of mockup. IMHO, there should also be a
recognizable difference between a view's background color
(especially in the textview) and the window's background color.
I think he chose nice shades, nicer then the current SC defaults.
but in any case all backgrounds and colors are customizable when
you use the views.
nothing is changing compared to current guis : of course you can set the colors.
IMO the default shades that he chose aren't worth much debate since
they are customizable anyway. they look great and he chose them
because his designer eye liked it, so we should leave it that way.
change it in your own code to anything you like.
(+) Are these GUI objects scaleable?
nothing is changing compared to the current gui system. it is the
same Button and same args. the same SC code would work.
this is just a design for how the edges, handles and shapes
look.there will be new views in the future and we would hope to
implement them using the same style.
I.e. is there also a big Knob?
if you make it big it will be big.
(+) I'd like to see log-grids accompanying the wonderful idea of a
linear grid as proposed.
right, I also posted saying that various grids can be done.
perhaps the background would always be clear. then a slider/env/
range etc. can be created along with a container view behind it and
any then the background view can be anything you
want.LogGridBackground, GridBackground, PianoKeysBackground,
LOLCatsBackground etcput a sample view behind it so that you scale
your envelope directly over the sample.sound file view so you scale
your automation envelopes over the track.
(+) Adding the possibility to show values (i.e. numbers) on sliders/
2dsliders/knobs, etc would be great. This would need some space for
the values, though.
or you could put the scaling on a background and make the slider
slightly transparent (with harder edges) and you can see the
numbers through the "glass"
you can also create a view that shows numbered ticks and place it
directly beside the slider.
all of this is usage and does not and should not IMO be put into
the slider/knob itself. its the same as putting a label on a
fader. the fader doesn't implement the label, its just paired with
it in a composite view.
keep objects separate, reusable, combinable, throw-away-able,
(+) Optinal axis description (i.e. numbers) around 2D-sliders,
multisliderviews and envelopeviews would be great to have.
of course you could do all of this today, right now
(+) The levelmeter IMHO should have the possibility to indicate clipping
place a single LED above the fader.maybe you want a text up there
to show how much it clicked by.maybe click on it to reset it.
this is all usage, not part of the basic gui style design.
(+) I'd like to see an actual ContainerView implemented that can
have a colored outline (and optionally also a descriptive text) 
yes, that would be a useful general element ! (+) Please, some Radiobuttons.
true, more specifically a single round button in order to build radio buttons.
(+) A native plot window a la plot2 would be neat, also a scope
view and a freqview are IMHO needed.
those already exist. all current sc views exist.the current design
is just a rectangle with no edge styling.
as I said in another mail: maybe a raised item to contrast the
sunken item.raised has the drop shadow outside (this means scaling
the rectangle down by the size of the shadow). same light source
and angle as the sunken.
(btw. we should ask him what the angle is so we can recreate it for any future views)
with sunken and raised edge designs then many variations can be made.
a scope could appear raised, or it could be a light background color and sunken.
this would be a useful option for all/many widgets: no border /
simple curved edge / sunken / raised
a static text label could be raised giving a nice focus for that element.
a slider could use simple-curved edge, and next to it one using sunken.
--- original message end ----
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml