Programming Task: Learn Clutter.

[tschak909]

Clutter is being chosen as the animation and canvas management library upon which to build the replacement for Orbiter.

Please, study this system, and start doing small snippets of code to get used to it...

We will probably be using cluttermm to provide a C++ binding.

Links:
http://clutter-project.org/
http://www.openismus.com/documents/cluttermm_tutorial/0.9/docs/tutorial/html/index.html

-Thom

[MANDINGO]

 

On it

[totallymaxed]

Clutter is being chosen as the animation and canvas management library upon which to build the replacement for Orbiter.

Please, study this system, and start doing small snippets of code to get used to it...

We will probably be using cluttermm to provide a C++ binding.

Links:
http://clutter-project.org/
http://www.openismus.com/documents/cluttermm_tutorial/0.9/docs/tutorial/html/index.html

-Thom

Lets make sure that we architect any Orbiter implementation such that we can make sure that there is no lockin to the clutter libs and that we can easily build Orbiters for other devices/OS's etc. We must separate the graphical implementation so that we can implement Orbiter even on devices with very basic display capabilities even ie we'd like to be able implement new Orbiters even on devices with simple text only displays. Lets make ssure there is a clean separation between representation layer and the underlying Orbiter Core code...lets not make any hardcoded assumptions about what display/resolution etc capabilities a specific Orbiter hardware platform has. Lets make it easy to take the Orbiter anywhere we like in the future.

Andrew

[tschak909]

The point here is to start trying out UI concepts.

-Thom

[totallymaxed]

The point here is to start trying out UI concepts.

-Thom

Yes I understand that...and am excited by what may emerge....but lets not forget to make sure that UI concepts scale correctly and are cleanly separated from the Orbiters core code...lets not assume that all devices will always have the same display capabilities and lets make sure we do not intermix specific UI concepts/implementations and hardcode those assumptions into the underlying low level Orbiter code.

I'd like us to be able to build 'full on' Orbiters that exploit all of the richness in for example clutter but I also want us to be able to easily build Orbiters that dont depend on clutter or specific display features/capabilities. Lets keep these properly separated and not re-invent the current Orbiter mess where we have a monolithing big 'hunk' of code that is incredibly complex and difficult to scale to different devices.

All the best


Andrew

[uplink]

I made something silly that you can get from here: http://dianemo.com/clutter-orbiter-sample.tar.gz. It should NOT be used as a base (I mean, just look at the sloppy coding style). Just build it and enjoy the simple effects when you click the buttons

[tschak909]

we'll be able to scale and abstract...but right now, we need to narrow down a set of capabilities that we know we want to expose.

The simple truth about Orbiter in relation to the rest of the system is that:

* it needs to be a DCE device. the from device is massively important to the rest of the system
* it needs to register to the orbiter plugin so that follow me, binding, switching of rooms/EAs, etc, work
* delineations of functionality happen as "screens"

everything else is relative, precisely BECAUSE orbiter is so bottom heavy.

Any orbiter simply needs to understand the division of screens. Let's keep this in mind, so that we do not try to over-abstract and fall into second-system syndrome that Orbiter had.

The reference orbiter, will be written in Clutter, and this will become the TV UX. With a touchpad UX, etc..etc.. . (UX == user experience)... we'll have more user experiences as time goes on..but the sheer size of orbiter...can basically be ignored, because we're starting over.

SO LONG AS THE DATA PRESENTATION LAYER IS KEPT IN A SEPARATE CLASS, WE'LL BE ABLE TO MATE IT AND CHANGE IT AS TIME GOES ON. THERE IS A TEMPTATION TO SIMPLY GLOB EVERYTHING TOGETHER DUE TO THE WAY DCEGEN WORKS, DO NOT FALL PREY TO THIS. WHEN IN DOUBT, THE COMMAND DEFINITIONS IN ORBITER SHOULD BRANCH OUTWARD INTO OTHER CLASSES.

some of the things we need to figure out:

* alpha composited clutter stage
* blurring the stage so that windows behind the stage appear blurred (think the currently playing media)

 -Thom

[uplink]

Check out Moovida. You may find some of this stuff in there, even if it's not written in C++.

[jimbodude]

Lets make sure that we architect any Orbiter implementation such that we can make sure that there is no lockin to the clutter libs and that we can easily build Orbiters for other devices/OS's etc. We must separate the graphical implementation so that we can implement Orbiter even on devices with very basic display capabilities even ie we'd like to be able implement new Orbiters even on devices with simple text only displays.

I second this.  This issue is of key concern when redesigning the Orbiter.

Thom, I understand you're mainly looking at UI concepts right now, but it is worth considering even as you make silly sample programs.  If this separation is incorporated in sample programs, the code produced for prototypes will be more useful down the road, which will limit the amount of time spent re-developing things that already work for one application.

[tschak909]

hmm. Guys...

You can't design a retargetable UI TO A BLANK PIECE OF PAPER.

Take as an example from another problem space, the Linux Kernel...

The Linux kernel was designed for one CPU. The Intel 80386. This vastly simplified the program's overall design. However, Linus made some basic assumptions about memory architecture, and tried to make an API to suit them, but these things happened _AFTER_ the initial design. Had he made the decisions BEFORE the completion of the first iteration of the design, things would have turned out very differently for Linux and its design... The results of his initial quick solidification of assumptions have proven to be scalable over time, as Linux runs on every CPU architecture with SOME form of memory management (and even some without..)

Remember, DCE is a messaging infrastructure. You all are placing too much creedence on Orbiter's importance. Even as it is right now, as long as the replacement is a DCE device, data grids can be pulled for dynamic information, scenarios can be queried for scenario data, and as long as there is a functioning DCE device at the Orbiter end, then the Orbiter Plugin can figure out where to send things.

So trying to think of everything to be overly abstracted and perfect...be careful...remember, right now, everything IS highly abstracted, and Pluto was able to make orbiters for TiVO and Moxi and Hillcrest, which use drastically different UIs.

-Thom

[jimbodude]

Assumptions are not the same as coupling.  I'm talking about decoupling your UI elements from your UI design/layout, and your UI design/layout from the underlying logic code.  We already know that DCE has taken care of a lot of the abstraction already - but I'm not talking about that layer; I'm talking about the actual program that is running on the devices - the one that talks to that DCE layer.  That code needs to be highly retargetable so it can run on all these cool new devices, as you know.

For instance - as you tinker, think of ways to make the results of the tinkering useful in other places immediately.  If you make a neat slider or button, take the extra 10% and make it reusable.  If you make a neat screen, take the extra 10% and make it flexible for other tasks.  As the design becomes more defined, think of ways to abstract it from the UI while still handling all the usual Orbiter logic.

I'm not saying that I think you have chosen any incorrect path, nor am I saying that you haven't thought of this on your own already - I think it's quite the opposite, actually.  But there are some key limitations that can be avoided by designing the application part of the Orbiter effectively, and everyone involved in the implementation should be aware of that so they can look out for issues on their own.

[tschak909]

Although it may seem like it, there isn't an argument here.. I understand your concerns...and I am telling you that it is way too early to make them... I can guide the systems design of any UI designs to show proper abstraction, WHEN the time is right... it's not now.

The point i am trying to make here, is that we should first concentrate on one GOOD SOLID UI, then build the next target...then another... to try and see what differences we need to encapsulate...

I suspect:

* clutter can be used for most orbiter implementations, as a plain DCE device. The native orbiter should be with Clutter...with a hope that I can target MeeGo and its UX'es as a final target. This would be
** The Media Directors
** native touch screens running MeeGo
** native handsets running MeeGo

* for anything else, we provide a simple proxy, similar to the Proxy Orbiter so that orbiters can be done in other toolkits to match the native widgeting of the target device. This would be _android_ _iPhone_ etc. The difference is, with the proxy orbiter, we DO NOT ENFORCE A UI, and instead just deal with signaling and data acquisition.

Trying to build the one size fits all cram everything into a database and encapsulate skinning proved to be a massive failure. Yes, it worked as designed, however, it was simply too impractical to maintain beyond the vertical confines of Pluto....and thinking about THEMING at this point would be foolhardy. Let's nail down our basic concepts first, and get them right...then we can go forward.

-Thom

[jimbodude]

There is no doubt that there is not an argument, and I know you've thought of all of this before, Thom.  The goal of my comment was to make these points clear to others who have maybe not thought it all the way through and perhaps gain some interest from others who could pitch in.

Your plan is sound, I look forward to the results.

[tschak909]

For those who can't compile Radu's demo for some reason, I have shot a quick video of it...

http://www.youtube.com/watch?v=Hm2RC-m-3D0

-Thom

[totallymaxed]

To compile the Uplink's demo just download it, uncompress the archive somewhere using;

tar zxf clutter-orbiter-sample.tar.gz<return>

Now you need the clutter lib;

apt-get install libclutter-1.0-dev<return>

So now you have the clutter lib installed. Now from a terminal just cd into the directory that you uncompressed the tar.gz archive into and do;

make<return>

After a few seconds you'll get the prompt back and there will be a new executable call 'orbiter' in the directory. Now you can run Uplinks demo by just typing;

./orbiter<return>

Enjoy!

All the best