Future plans

#1

I mentioned elsewhere that I had some thoughts for the way look-and-feel should be done, so here’s a quick synopsis of the way I want to drive the juce UI in the near future. Comments more than welcome!

I’m finding that the UI is starting to look a bit old-fashioned, and writing look-and-feel code is a pain even if you’re experienced at it, so I have a cunning plan that might make it all considerably easier.

Now, I’ve not entirely thought this through, and it may turn out to be fatally flawed, but the general idea is this:

  • Take the drawable classes, and make them properly serialisable, so they can be stored in a compact binary format.
  • Add functionality to Drawables to allow more complex ways of positioning their points. This could be done by introducing vertical/horizontal guide markers for points to be positioned relative to. The markers could themselves be positioned relative to other markers, and could be placed proportionally or absolutely. This’d give quite powerful control, and would let you create objects that scale intelligently to the space that they’re being drawn into. E.g. the current TextButton design is hand-coded to scale its text and corners nicely when resized, but if drawables had these extra abilities, the entire button could have been designed visually as a single drawable, without writing any code at all.
  • The markers and drawable elements can be named, so they’re accessible from the code that’s using them.
  • The look and feel for each type of component will no longer be done with code, it’ll be made up of hopefully just one drawable, with some pre-determined properties. E.g. a slider can be designed as a drawable which is known to contain a guide marker called “thumb position”. The thumb graphics are drawn relative to this marker, and when the Slider component wants to move the thumb, it just changes the position of this guide marker and redraws the drawable. A TextButton component might expect that its drawable contains a DrawableText element called “buttontext”, so when it needs to change the button label, it just finds that element and changes it.
  • I’ll then build a new, more powerful version of the jucer that can edit drawables really easily - a bit like the way it currently lets you design your paint method, but with much more control.
  • This tool will save a set of drawables into a single CPP file, including any images they use. The CPP will actually store serialised versions of the drawables, but will expose a set of functions that simply return them as drawable objects.

So there might be a few cases where a little hand-coding is still needed, but my hope is that the tools would let you do at least 95% of the work involved in designing a look-and-feel entirely visually, and save it as a single CPP file.

#2

…And I just started to enjoy L&F.

After reading this, the first thing that popped into my mind was “Blend”, this is a Microsoft product that was released a couple of years ago, and I “had the pleasure” of working with it when it was in beta.

They have this concept of “Control Templates” which can be edited graphically. I haven’t used it for a long time, and just had to download the demo to refresh my mind.

Some screen shots…

Slider

Slider-ControlTemplate.png630x575

Check Box

CheckBox-ControlTemplate.png800x284

Cool stuff!

#3

I’ve done something very similar to what you describe: during last months I wrote a DrawableLookAndFeel class that can be feeded with SVGs to “learn” how to draw GUI elements.

For example, you can feed it with a SVG (it’s a Drawable, after all) describing a button, and all the buttons drawn by such look and feel will be drawn with that SVG as “template”.

Obviously, the Drawables given to the class should be properly formatted and are usually DrawableComposites with properly named children.

The button template, for example, is a DrawableComposite object whose children should be named “normal”, “down”, “over” etc., and they describe the graphic appearance of the button in each of those states.

Similarly, the rotary knob template is made up of a fixed part, a rotating part and a rotation center…

Some other (not all) GUI elements are implmented. If you are interested I may send some code to you.

#4

Ah, good to see I’m not the only one thinking along these lines!

[quote]
If you are interested I may send some code to you.[/quote]

At the moment I’m not too bothered about specifics, more just thinking about what kind of things I might need to bear in mind when designing it… Do’s and don’ts, etc.

#5

What I would like to see is a CSS like template to describe widgets
using class and widget name.
This is great in CSS to define standard LnF for global and specific widgets

It would allow to simply redefine colors, fonts, positions(fixed rectangle or relative size à la CSS), image strip or svg replacement for widget drawing for each state, and ice on the cake a little function to draw the widget if necessary just like the LnF callbacks but using a script (ie no need to compile)

Still I agree this is quite a bit of work :slight_smile:

#6

I think you might reuse the PositionedRectangle class to specify how single Drawables should be positioned relative to each other within the template for each control. If properly used, I think this is enough to achieve nice resizeability as you described.

In addition, consider the possibility to add a set of (string) properties to Drawables, the same way Components have. That will open the possibility for future extensions or parametrization of some aspects (radius of rounded corners of some borders, for example…)

#7

CSS is certainly something I’ve been thinking about in relation to this - but more in the sense that Drawables = CSS, and Components = HTML.

To make it more easily editable, it might actually be a good idea to store the drawables in a text format.

The positioned rectangle’s ok, but I’ve often hit things that it can’t do. I think having independent vertical and horizontal guide markers is good because multiple points or shapes can be made relative to a marker, and having markers-relative-to-other-markers gives you extremely flexible control.

They’ll definitely have a set of properties, but probably of predetermined types, like colour. Things like a corner radius could be done with a named marker. I’m sure there are some other vital elements I’ve not yet thought of, but which will become clear when I start actually trying to build things with it!

#8

I’m with using SVG for this! It’s basically an XML and it allows you to add custom nodes for your needs (properties and guides, for example). InkScape behaves exactly like that for adding guides and grids.

#9

SVG’s great, but it doesn’t give you the sort of layout control that I think you’d need for this. Sure, you could use SVG with proprietary additions, but that all starts to get a bit unwieldy.

The jucer would definitely let you import SVG to start from, though! (And maybe even save a drawable as SVG)

#10

Ok. That’d be fine, my goal was to keep the possibility to interchange graphic resources back and forth between software developers and graphic designers.

#11

In my vision of this, the jucer would be a good enough graphic editor that you’d actually let the artists use it too.

Part of my motivation is that I find inkscape really clunky to use - I’d really like to come up with something that lets you do basic drawing in a really slick way, even if it doesn’t have the more advanced features that inkscape does.

#12

I agree :slight_smile: I’m with you if you decide to extend jucer that way. I hope our designers will like it. Anyway, the import and export functions toward SVG format still look like key features to me.

#13

Well i can just add, that i use JUCER where i can and how i can. If all those feature were added to JUCER i think it would be an amazing RAD. Drawing would be great, manipulating images in more ways.

I think CSS/HTML is a bad idea, XML would be better. CSS and HTML contain so many bugs and gotchas it’s hard to do an implementation nowadays. I think that GTK uses some form of themes, it’s a set of images and a description file, also binary engines can be used to add new functionality to thhe theme engine.

#14

Don’t misunderstand - I’m not considering actually using CSS. I just meant that the relationship between CSS and HTML is analogous to that between Drawables and Components. Components provide the content, and Drawables provide the visual appearance.

#15

[quote=“jules”]This tool will save a set of drawables into a single CPP file, including any images they use. The CPP will actually store serialised versions of the drawables, but will expose a set of functions that simply return them as drawable objects.

So there might be a few cases where a little hand-coding is still needed, but my hope is that the tools would let you do at least 95% of the work involved in designing a look-and-feel entirely visually, and save it as a single CPP file.[/quote]

hi, when I first started using Juce I used the jucer a lot and it’s a really powerful tool, but it’s been 2 years that I’m not using it anymore because I needed more flexibility and I’ve never really felt comfortable with code generator tools. So despite the savings in time I find myself handcoding the widgets layout and look and feel most of the time.

Most of the UI work is mostly tedious data declaration with a little behaviour here and there. It really helps to have a clear separation between both.

I’m really curious to see if there’s an elegant way to support both data-driven and algorithmic UI with both statically compiled code and/or dynamically loaded assets (SVG, CSS, scripts…)

I’ve seen that QT supports the compiled approach by generating 2 classes: one for the UI layout and drawing code which is auto-generated and one that is meant to be modified by the end user. And of course they also have QTdesigner files and style sheets.

I’ve also seen recently that NUI is using CSS with custom extensions and widget decorators.

#16