LinuxMCE Forums
General => Developers => Topic started by: tschak909 on May 07, 2010, 12:52:10 am
-
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
-
;D
On it
-
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
-
The point here is to start trying out UI concepts.
-Thom
-
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
-
I made something silly that you can get from here: http://dianemo.com/clutter-orbiter-sample.tar.gz (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 :)
-
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
-
Check out Moovida. You may find some of this stuff in there, even if it's not written in C++.
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
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
-
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?
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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).
-
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
-
Yeah, the whole point here is to come to grips with some different tech, so we can make concrete decisions.
-Thom
-
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.
-
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
-
Just my immediate prediction...
The entire Orbiter codebase will be dropped, and rewritten from scratch.
-Thom
-
Just my immediate prediction...
The entire Orbiter codebase will be dropped, and rewritten from scratch.
-Thom
Nice prediction. Quoting from the past :)
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
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?
-
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
-
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 :D
-
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 :D
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.
-
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?
-
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
-
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
-
Has anyone tried to make a transparent stage? (remember, you need working composite manager for it to completely work.)
-Thom
-
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?
-
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?
You're doing it right, except that the package libclutter-1.0-dev was first introduced in Ubuntu Karmic. You'll have to either run Ubuntu 9.10 or 10.04, or backport the package.
-
If i change the code to use the 0.8 version which is available on kubuntu will it still work or do i need to setup a Ubuntu environment just to learn clutter?
-
If i change the code to use the 0.8 version which is available on kubuntu will it still work or do i need to setup a Ubuntu environment just to learn clutter?
I'm not sure what differences there are between the libclutter version in 0810 and the 910/1004 version...give it a try
Andrew
-
There is a toolkit for Clutter called mx, which is being used for Moblin/MeeGo currently:
A description of it is here:
http://blogs.gnome.org/thos/2009/11/18/a-new-clutter-widget-toolkit/
a git repository of the toolkit is here:
http://git.moblin.org/cgit.cgi/mx/
-Thom
-
Meanwhile, over on the qt side of things
http://labs.trolltech.com/blogs/category/labs/graphics/kinetic/declarative_ui/
Qt is a very compelling option. We'll just have to enable STL compatibility to work with our existing C++ code.
Quick is definitely something to look into, as the entire UI can be defined in Javascript, and style like languages.
an example walkthrough of some Qt Quick stuff:
http://meego.com/community/events/presentations/rapid-development-meego-using-qt-quick
-Thom