Programming Task: Learn Clutter.

[jimbodude]

I thought the point of this thread was for clutter discussion specifically, not orbiter design discussion... but ok.

Thom, it might even be easier that way, since the "old Orbiter" could still exist as the "new Orbiter" is developed.  People could choose which to use - stability or new functionality - on a per-device basis if it were set up that way.

The key points I'm interested in (no design stuff in the database, re-design-ability without any code changes, and platform portability) have been addressed, and I'm very happy with that direction so far.

There are a few other items I'm interested in - the ability to create your own custom screen(s) on a per-installation or per-device basis, better media sorting, and user management.

For example - having the "climate" and "security" rows are useless to me.  I would rather make a screen with a clock, some media shortcuts, and controls to set lighting levels as the home screen.  The design I would want to do would be selecting what I want, and where to put it on the screen - the complex stuff like picking icons and colors should be handled by the orbiter.  This way if you change the "theme", or whatever you want to call it, my custom screen will still match everything else.  Maybe this complete customization is only available for 1 or 2 screens, where the rest are dictated by the design that is shared by all users.

For another example - say I have a device that doesn't quite fit the mold of any other - maybe it's a cable box that has arrows and select buttons and stuff, maybe it's a PS3 which has 51 (I think) buttons on the remote (many of which have nothing to do with media and will exist on no other device), or maybe it's some completely different device that has nothing to do with anything.  It would be great if part of the device template could describe what buttons should be on the remote and have the orbiter pull the proper things together automatically.  Think of a generic remote template - where buttons or groups of buttons appear, disappear, or reorganize themselves based on the device's capabilities.  Of course, part of the UI design will describe how to lay out the buttons and what icons to associate with them - the template only knows what buttons are important.  Maybe there is a priority scale for selecting which buttons to leave out if the screen is too small.

For media sorting, this should be completely customizable.  The user should be able to make up hierarchies - like Author, Album, Title or Title, Season, Episode - and attach those to buttons on the orbiter.  The same should be true of any sort of search - for instance "TV Shows", "Action Movies", "James Bond Movies", "TV Shows recorded in the last week", "Unwatched Videos", "Recently watched videos", "Videos partially watched", etc.  Maybe even shortcuts to specific playlists.  The user can select which ones are important or make up their own, and they appear on the orbiter.  I know exactly what I usually search for - there are only 3-4 searches that I do - so I should be able to make shortcuts to those searches so I don't have to wait for the datagrid, select the search buttons, run the search, browse through the results because the search is only close to what I wanted, and finally make a selection.

Media sorting should also be configurable for any search.  For instance, it's easier to look a James Bond movies by release date, videos should be sorted alphabetically (leaving out the "The", as I've stated before...), and recorded TV should be sorted newest-first with new episodes (this week's new stuff) highlighted.  These are my preferences - other people will want other sorting, I'm sure.

The thought behind these ideas is that no one likes the same things, and no one has the same technology implemented, so why should everyone use the same exact interface?  Slight customization in some key places can bring the UI to a whole new level very quickly.

I've also been wondering for a while if there is a better way to handle the current user of an orbiter in the case where no one is using it.  Currently, someone is always the user of an orbiter, but as new technology comes about where we can figure out who is in a room and react to it - that assumption stops making sense.  This brings up the case where no one is in a room, and the case where more than one person is in the room.  Orbiter can't handle either of those, currently.

These are probably much further down the road, but something to think about, if you haven't already.

[totallymaxed]

I thought the point of this thread was for clutter discussion specifically, not orbiter design discussion... but ok.

Thom, it might even be easier that way, since the "old Orbiter" could still exist as the "new Orbiter" is developed.  People could choose which to use - stability or new functionality - on a per-device basis if it were set up that way.

The key points I'm interested in (no design stuff in the database, re-design-ability without any code changes, and platform portability) have been addressed, and I'm very happy with that direction so far.

There are a few other items I'm interested in - the ability to create your own custom screen(s) on a per-installation or per-device basis, better media sorting, and user management.

For example - having the "climate" and "security" rows are useless to me.  I would rather make a screen with a clock, some media shortcuts, and controls to set lighting levels as the home screen.  The design I would want to do would be selecting what I want, and where to put it on the screen - the complex stuff like picking icons and colors should be handled by the orbiter.  This way if you change the "theme", or whatever you want to call it, my custom screen will still match everything else.  Maybe this complete customization is only available for 1 or 2 screens, where the rest are dictated by the design that is shared by all users.

For another example - say I have a device that doesn't quite fit the mold of any other - maybe it's a cable box that has arrows and select buttons and stuff, maybe it's a PS3 which has 51 (I think) buttons on the remote (many of which have nothing to do with media and will exist on no other device), or maybe it's some completely different device that has nothing to do with anything.  It would be great if part of the device template could describe what buttons should be on the remote and have the orbiter pull the proper things together automatically.  Think of a generic remote template - where buttons or groups of buttons appear, disappear, or reorganize themselves based on the device's capabilities.  Of course, part of the UI design will describe how to lay out the buttons and what icons to associate with them - the template only knows what buttons are important.  Maybe there is a priority scale for selecting which buttons to leave out if the screen is too small.

For media sorting, this should be completely customizable.  The user should be able to make up hierarchies - like Author, Album, Title or Title, Season, Episode - and attach those to buttons on the orbiter.  The same should be true of any sort of search - for instance "TV Shows", "Action Movies", "James Bond Movies", "TV Shows recorded in the last week", "Unwatched Videos", "Recently watched videos", "Videos partially watched", etc.  Maybe even shortcuts to specific playlists.  The user can select which ones are important or make up their own, and they appear on the orbiter.  I know exactly what I usually search for - there are only 3-4 searches that I do - so I should be able to make shortcuts to those searches so I don't have to wait for the datagrid, select the search buttons, run the search, browse through the results because the search is only close to what I wanted, and finally make a selection.

Media sorting should also be configurable for any search.  For instance, it's easier to look a James Bond movies by release date, videos should be sorted alphabetically (leaving out the "The", as I've stated before...), and recorded TV should be sorted newest-first with new episodes (this week's new stuff) highlighted.  These are my preferences - other people will want other sorting, I'm sure.

The thought behind these ideas is that no one likes the same things, and no one has the same technology implemented, so why should everyone use the same exact interface?  Slight customization in some key places can bring the UI to a whole new level very quickly.

I've also been wondering for a while if there is a better way to handle the current user of an orbiter in the case where no one is using it.  Currently, someone is always the user of an orbiter, but as new technology comes about where we can figure out who is in a room and react to it - that assumption stops making sense.  This brings up the case where no one is in a room, and the case where more than one person is in the room.  Orbiter can't handle either of those, currently.

These are probably much further down the road, but something to think about, if you haven't already.

All of the above are not really anything to do with what we are currently discussing here. What your discussing above is about implementing changes to the LinuxMCE UI. What we are discussing here is re-designing how 'under the hood' the Orbiter & UI is built and managed - ie the basic building blocks/tools that you build a UI from - any UI not just the current one. What your talking about is what a UI implementation, built with the 'new' Orbiter and associated tools, might have in it in your opinion - all of which I am in no way disagreeing or agreeing with you on (your points  do seem reasonable and valid).

Once we have some prototypical components of the 'new' orbiter & tools ready - ie the Orbiter & the spec for the UI definition format/markup, then you and many others can go and build any UI you like and test all of your ideas out. But first we need to re-engineer the tools for you to be able to do that. Once we are at that point then you might ask 'I would like to be able to this in my UI...how do i go about it?' ...we will either say use this or that existing markup definition or in some cases we're going to say 'great idea!....we need to extend the markup to allow for that'. We're not even at the early stage of being able to do that yet.

All the best


Andrew

[jimbodude]

I'm talking about a level of flexibility that will have effects on how the system is designed as a whole.  The specific features are beyond what is going on here, yes.  Think of the specific features as examples or use cases for how these new "building blocks" would be used.  For instance, replacing a screen based on some settings or generating screens programatically - these are interior features that will expose themselves to UI designers, but the root of their implementation is under-the-hood stuff.

I think I may have focused on the design features more than the underlying support for them, which made my statements misleading and long-winded.

[tschak909]

It's really very simple, guys...

either:

* I find some people willing to do the low level work, that I can work with, guide, shape as needed, to build the architecture we need,

OR

* Everyone waits a couple of years, while I build the new orbiter, ALL the tools, and then HOPE people use them.

I for one, am tired of doing huge chunks of the recent work, while others basically lurk.

-Thom

[jimbodude]

I'm fine with that statement.  I think you will have more people interested in helping if you document your goals and your planned approach, as stated earlier.  Even if it's all "subject to change" - people need direction, and they need something to get excited about.

[totallymaxed]

I'm talking about a level of flexibility that will have effects on how the system is designed as a whole.  The specific features are beyond what is going on here, yes.  Think of the specific features as examples or use cases for how these new "building blocks" would be used.  For instance, replacing a screen based on some settings or generating screens programatically - these are interior features that will expose themselves to UI designers, but the root of their implementation is under-the-hood stuff.

I think I may have focused on the design features more than the underlying support for them, which made my statements misleading and long-winded.

But right now is too early for this type of input. Nothing we're doing or discussing here currently will pre-empt any of the mechanisms you mention...but what your wanting to discuss is way further down the line - your trying to 'plan a city' when we're still trying to decide how to best to 'fire the bricks'.

All the best

Andrew

[davegravy]

I'm fine with that statement.  I think you will have more people interested in helping if you document your goals and your planned approach, as stated earlier.  Even if it's all "subject to change" - people need direction, and they need something to get excited about.

Thom has vision which in my experience he isn't very open-minded about shifting or opening up to public debate. That being said, his vision  usually satisfies most people's best interests whether they know it or not. I.e he's usually right about shit. The problem is the people who -don't- know it: it is difficult to get them on board to contribute to something they percieve as against their intersts. I think if someone can find a way to organize something like what you propose it would help bring in more resources. Perhaps if Thom doesn't want to compose such a thing, someone can pick his brain and derive something for his review and comment?

[totallymaxed]

I'm fine with that statement.  I think you will have more people interested in helping if you document your goals and your planned approach, as stated earlier.  Even if it's all "subject to change" - people need direction, and they need something to get excited about.

Thom has vision which in my experience he isn't very open-minded about shifting or opening up to public debate. That being said, his vision  usually satisfies most people's best interests whether they know it or not. I.e he's usually right about shit. The problem is the people who -don't- know it: it is difficult to get them on board to contribute to something they percieve as against their intersts. I think if someone can find a way to organize something like what you propose it would help bring in more resources. Perhaps if Thom doesn't want to compose such a thing, someone can pick his brain and derive something for his review and comment?

Well we're already committed to working on this - as you can see by the 'demonstrator' code Uplink posted here a few days back. We plan to continue to post code samples around clutter and to show our ideas for UI markup (again see the earlier post from Uplink on this). We hope that posting real source here (the demonstrator is just that - a way to show what can be done with clutter) that some of you will join in and help. Apart from wanting to make sure we have a markup driven UI rather than one that needs special tools or to be programmed directly in C++ I think we can include everyone in the discussions and be open minded about any other aspect of the Re-engineered Orbiter. We also hope that our next demonstrator with UI markup will allow some of you to get enthusiastic about building UI's that way - or at least wet your appetite for doing so...and that you'll post your efforts here too.

All the best


Andrew

[uplink]

A warning: be prepared to scrap all the code we write at this stage, several times over, until we get a grip on it. That can look like duplication of work, but to me that's experience. When we get to a "Wow, we all like it" moment, we'll be ready to start the real work

[Kezza]

A warning: be prepared to scrap all the code we write at this stage, several times over, until we get a grip on it. That can look like duplication of work, but to me that's experience. When we get to a "Wow, we all like it" moment, we'll be ready to start the real work

I agree it's not duplication but very important for investigation and experience. Once I have some free time (core died last night) I will be looking into the examples that come out since as I feel it's a great way to help learn how the code works and if I'm really lucky i might learn enough to have a go at it!

Look forward to hearing how this progresses.

[los93sol]

I'm all in for helping create a really nice UI, but I'm completely missing a few of the skills required.  As Thom has said we all need to get involved here where our particular skills shine.

Areas I'm not much help with:
-Understanding how to pipe the lower level clutter code into a higher level language like xml.  I understand our goal is to get something solid and really nice, and firmly believe that we need someone to volunteer to work with the higher level stuff and someone to assist with providing the tools needed by the skinners working with those higher level tools.
-Creating textures/graphics

Where I do have LOTS of experience and can carve out enough time is working with higher level languages and partnering with both someone with an idea who can create the necessary textures, and someone piping out the lower level clutter code into a higher level language as needed.  This is how I've done it in the past working with JMarshall and Blackbolt.

I agree, it's all talk until we break ground, so is anyone interested in working it this way to get started?

[tschak909]

los93sol,

Just look at the clutter C tutorials, and start messing around.

GUYS, RIGHT NOW, A FEW OF US NEED TO LEARN.

I am learning too.

-Thom

[totallymaxed]

I'm all in for helping create a really nice UI, but I'm completely missing a few of the skills required.  As Thom has said we all need to get involved here where our particular skills shine.

Areas I'm not much help with:
-Understanding how to pipe the lower level clutter code into a higher level language like xml.  I understand our goal is to get something solid and really nice, and firmly believe that we need someone to volunteer to work with the higher level stuff and someone to assist with providing the tools needed by the skinners working with those higher level tools.
-Creating textures/graphics

Where I do have LOTS of experience and can carve out enough time is working with higher level languages and partnering with both someone with an idea who can create the necessary textures, and someone piping out the lower level clutter code into a higher level language as needed.  This is how I've done it in the past working with JMarshall and Blackbolt.

I agree, it's all talk until we break ground, so is anyone interested in working it this way to get started?

As Thom says above just break out the clutter docs and experiment with the lib...look over clutterscript and see how that works. We're all learning here.

As Uplink has already said above we're all going to iterate over all of this for a long time yet...and lots of code will be junked in the process...but thats ok...Just dig in an learn the parts that interest you and become a 'expert' in that area. Someone else will fill in the other missing knowlwdge. Look at Uplinks demonstrator...extend it, make it do some new tricks, break it, play with it...post it all back here for us all to see & learn from. Dont worry about a 'soup to nuts' understanding of everything...if we all take that approach we'll never even get started ;-)

All the best


Andrew

[tschak909]

Has anyone tried to make a transparent stage? (remember, you need working composite manager for it to completely work.)

-Thom

[dcubox1]

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>

Im trying to learn clutter at present, ive been throught the tutorials and now I wanted to build the example, i have the example downloaded and can see the cpp code etc, however when i try to do the install libclutter-1.0-dev it says it cannot find the package?? am i doing someting wrong?