Programming Task: Learn Clutter.

[los93sol]

I still stand by my opinion that while Clutter may be extremely powerful, it limits UI development to programmers only, and we need more people involved with the project.  The way XBMC implements their skinning engine is more along the lines of what I think we need.  Expecting a UI designer to implement their ideas in C++, or anything more complex than a few simple xml elements is just not a realistic approach.  I stress that we need the absolute most simplistic methods for creating/destroying screens and objects on each screen as well as placement of objects and controlling their interactions.  Having had a look at the clutter samples on their site, this option does not provide a simple means for these things.  Is the goal here to create some basic elements with clutter and expose them to the skinner in a way that it is simple to work with?

[totallymaxed]

I still stand by my opinion that while Clutter may be extremely powerful, it limits UI development to programmers only, and we need more people involved with the project.  The way XBMC implements their skinning engine is more along the lines of what I think we need.  Expecting a UI designer to implement their ideas in C++, or anything more complex than a few simple xml elements is just not a realistic approach.  I stress that we need the absolute most simplistic methods for creating/destroying screens and objects on each screen as well as placement of objects and controlling their interactions.  Having had a look at the clutter samples on their site, this option does not provide a simple means for these things.  Is the goal here to create some basic elements with clutter and expose them to the skinner in a way that it is simple to work with?

Well we definitely agree with you. We need to use powerful lib's like clutter but we feel what is needed is an interface that exposes high-level xml like UI definition that is accessible to non programmers and therefore opens up the UI to those amongst the community who cannot program in C++ but can 'design'.

Thats why at top of this thread I was pushing for a clean separation between the Orbiter code and the the code that provides the 'visual toolkit'. We need to architect the 'new' Orbiter such that we can easily target new hardware devices with potentially widely varying hardware and display capabilities... at the low end it might be small mono LCD panel and at the top end either a touch based display or on an MD a UI that fully exploits the 1080p format/screen real-estate etc. We need to make sure that the UI design process is really accessible to non-programmers. Our current UI tools and paradigm is just not good enough and makes it impossible for those with great UI design skills to get involved and it also makes it slow for new UI design ideas or any experimentation in our UI to appear.

We must not miss this opportunity to fix these very significant limitations in our software.

All the best


Andrew

[tschak909]

But realistically, we can't design such a system, until we start building small models.

Right now, this is what I hope to accomplish:

(1) Create one good on screen UI in clutter
(2) Create one good non on screen UI in clutter.
(3) find the intersections between them, to provide concrete abstraction points, instead of GUESSING where they might need to be.

So we need to get used to the toolkit, and see what we can come up with visually, FIRST.

Anything else is intellectual masturbation at this point.

-Thom

[George_Ts]

I do not know how useful this could be, but it may be a way for non-programmers to contribute

http://en.wikipedia.org/wiki/Clutter_(toolkit)#Interface_builder

gt

[totallymaxed]

I do not know how useful this could be, but it may be a way for non-programmers to contribute

http://en.wikipedia.org/wiki/Clutter_(toolkit)#Interface_builder

gt

Yes that approach using json/clutterscript is interesting but its clutter specific...and that locks us into clutter for all devices which we dont feel is a good idea. We need something like that but we need a neutral approach that abstracts the actual graphics lib etc being used and deals with higher level UI constructs/objects that are not tied to a specific implementation on a specific device.

Andrew

[tschak909]

We can do that, afterwards... believe it or not... what we want.. for each device, is something that looks native... this means...coding orbiters to their native toolkits....

so worrying about whether clutterscript would be tied into clutter isn't that big of a deal as it would only be used for the on-screen and a few off-screen displays.

-Thom

[George_Ts]

Andrew:

Quite right. I do agree with everything you said and I second it.
But, hard-coding the UI design in cpp, instead of using a JSON definition brings us no closer to a platform-independent UI.

Thom:
In my limited experience it is very hard to design platform/device/graphics-lib independent systems, unless development on those systems is progressing, to some extent, in parallel.
I do trust your judgment when you say it can be done  afterward as you know far more than I regarding this specific system.

I do realize we cannot spread a small community like this one too thin, but, If 1-2 people interested in another platform, Android for example, start putting a couple of screens together, in parallel with the clutter effort, it would probably be easier to avoid unintentional lock-ins. (I mention Android as it seems to be raining Android tablets)

I hope this post is not too off-subject. I'd hate to interrupt the clutter discussion. I really feel that clutter is a good call !

thanks,
gt

[tschak909]

I agree.

The whole point of using Clutter was to provide a replacement for the on-screen display, for now. I want to produce one REALLY GOOD UI for it... this can be themed with clutterscript....

As for other targets, providing good DCE bindings with an improvement over the Datagrid plugin will be enough to start. (The XML Data Handler/Data Catalog Plugins that were started by Pluto were a good step in this direction, unfortunately, never completed.)

The code for the XML Data Handler plugin is in SVN however...

-Thom

[uplink]

My sample is hardcoded because it's just a first attempt to making something. I didn't have time to play enough with clutter to come up with a silly UI definition to go with it, but I may just as well do in the following days and post the new sample, with the UI definition taken out so people can move things about. Maybe I'll add a few transitions as well (2-3 screens you can bounce around).

[totallymaxed]

Andrew:

Quite right. I do agree with everything you said and I second it.
But, hard-coding the UI design in cpp, instead of using a JSON definition brings us no closer to a platform-independent UI.

As Uplink points out the the sample was hard coded just to show what could be done in clutter...it was a demonstrator...and was not meant as an example of how an actual Orbiter might be coded internally or how we might go about making it possible for non programmers to build UI's.

Andrew

[tschak909]

Yeah, the whole point here is to come to grips with some different tech, so we can make concrete decisions.

-Thom

[jimbodude]

Perhaps a separate "new orbiter design discussion" thread should be spun off so the work that has to happen to learn the UI library is not covered up with higher-level design talk.

It would be great if the people who have thought this through already could document their thoughts in a sort of "proposal" for the community to see.  Such a document would contain:
- a list of recognized problems with the current system that are being addressed with the new system
- broad goals for the new system
- a description of the scope of the work
- and any major design decisions made or yet-to-be-made.

The idea would be to:
- provide structure and concrete goals to the development timeline
- allow others insight into why things are being developed the way they are
- allow others to provide suggestions on alternate directions
- create interest in the orbiter redesign project to attract developers with the proper skill set
- and avoid wasting time re-explaining the design to each person who asks about it.

I'm fairly certain that you've thought of things that others have not, and I'm sure you have thought of things that you haven't mentioned in this thread or to anyone else.  It would be great to get some insight into where things are headed, and what sorts of people will be needed to help the effort.

[totallymaxed]

Perhaps a separate "new orbiter design discussion" thread should be spun off so the work that has to happen to learn the UI library is not covered up with higher-level design talk.

It would be great if the people who have thought this through already could document their thoughts in a sort of "proposal" for the community to see.  Such a document would contain:
- a list of recognized problems with the current system that are being addressed with the new system
- broad goals for the new system
- a description of the scope of the work
- and any major design decisions made or yet-to-be-made.

The idea would be to:
- provide structure and concrete goals to the development timeline
- allow others insight into why things are being developed the way they are
- allow others to provide suggestions on alternate directions
- create interest in the orbiter redesign project to attract developers with the proper skill set
- and avoid wasting time re-explaining the design to each person who asks about it.

I'm fairly certain that you've thought of things that others have not, and I'm sure you have thought of things that you haven't mentioned in this thread or to anyone else.  It would be great to get some insight into where things are headed, and what sorts of people will be needed to help the effort.

What your seeing here is an open discussion about this whole topic - Thom has some specific areas that he in particular is interested in exploring, we have some areas that we are interested in exploring. I think for the time discussing all of this here is probably the right thing to do.

Whats emerging here is the result of an ongoing discussion amongst Thom/Uplink & myself (and others in the past too to be sure!). The goals are to retain and extend the re-target-ability of the current Orbiter, separating the Orbiter logic from the visual theming, while at the same time making it possible to deliver modern UI effects/widgets and down to low spec text mode graphics, and a non-programmer orientated ability to create/modify Orbiter UI (some kind of xml like markup in a text file is what we're leaning towards).

Soon we should have some more accessible code with a sample UI definition format posted here in the thread. This should give people a good idea of what we're thinking and an ability to play with some limited UI definitions without having to get into any coding...while those that want to code can look at the actual code and extend or improve it.

After that we may want to separate this into more specific threads.

All the best

Andrew

[tschak909]

Just my immediate prediction...

The entire Orbiter codebase will be dropped, and rewritten from scratch.

-Thom

[uplink]

Just my immediate prediction...

The entire Orbiter codebase will be dropped, and rewritten from scratch.

-Thom

Nice prediction. Quoting from the past