19 Sep
2016
19 Sep
'16
3:57 p.m.
Will Godfrey wrote:
As I've said elsewhere, another thing that puts me
off is this obsession
with shades of ... black!
This design choice was influenced by the feedback that the user survey
provided.
65.2% of users expressed a preference for dark backgrounds, 19.6% for
light backgrounds and 15.2% for some other combination (generally
no-preference or requesting multiple themes).
Future releases will likely include an easy means of retheming, though
it doesn't look like that functionality will be available in a user
friendly way for the initial 3.0.0 release.
David Jones wrote:
And I hope the controls within it will similarly be
freed of their pixel
constraints.
I can't think of a single component that has a fixed overall height or
width.
There's a small number of widgets which make use of a fixed padding (in
addition to a linearly scaled padding term), but otherwise very little is
specified in terms of pixels within the codebase.
Basically as long as large changes in the aspect ratio aren't made
everything rescales very nicely (IMO).
jonetsu wrote:
Was the GUI layer created from scratch or is it an
existing toolkit ?
It's a completely new toolkit.
Work on this project initially started with a Qt project back in 2014,
but using an existing toolkit didn't benefit things substantially given
the overall requirements.
The new toolkit is called "mruby-zest" (or just zest).
It uses an embeddable ruby interpreter, mruby, to power the overall app
and it uses nanovg to render all graphics via opengl.
Overall the custom code for the new toolkit and the new UI amounts to
around 22,000 lines of code, so it's not tiny, but I get the feeling
that if it was implemented in another toolkit that number would be
larger still.
Most of this code is in a pseudo-qml like format, so at least that
notation was borrowed from Qt.
--Mark