LinuxMCE Forums

General => Feature requests & roadmap => Topic started by: los93sol on September 20, 2008, 07:35:57 pm

Title: GUI Improvements
Post by: los93sol on September 20, 2008, 07:35:57 pm
Is it just me that notices that nothing seems to work properly in the GUI?  Text does not fit on the buttons properly, most screens look like buttons are missing, when actually using LMCE it frequently allows you to realize that you are in fact using several different programs.  I know that is how it works, but the point is the GUI is incredibly sloppy.  I find it frustrating that the devs are apparently hell bent on keeping their obviously broken system for creating GUI's.  I would gladly help out if the current system was not so horribly difficult to use.  I've said it before and I'll say it again, look at XBMC's skinning engine to see how it is supposed to be done!  Look how many people are creating skins for their software, meanwhile LMCE cannot seem to get a single person to fix the obvious bugs with theirs that gives any demo the general impression the LMCE is clunky and sloppy at best.  Feel free to slam me and tell me how I am bitching and not contributing anything, but the fact is some serious changes need to happen to make LMCE usable and to get it to a stage where it can even be tested properly.  I've been following the project for about a year now and simply find it incredible that nobody is even concerned that their software looks so sloppy.  Sure, there was that whole UI3 "discussion", but what the hell happened to that?  Media organization is simply awful, and the devs concensus is they are doing it "the right way"...again...look at XBMC to see how it is supposed to be done.  For god's sake I even talked to the developer who does all the code on their skinning issue and he said he'd be willing to consult with you guys about the way your UI is created and possible improvements to it.  You know what happened there?  Absolutely nothing, because nobody contacted him from LMCE, they expected him to chase them down.  When you're seeking advice you go get it, you don't wait for it to come to you.  Oh well, I'm over it, perhaps in another year someone will have realized that the general consensus of the clunkiness and sloppiness of LMCE is to great to be ignored or brushed off as people bitching.  When you decide to take a sensible approach to the GUI let me know and I'll gladly contribute something, but until then good luck, I'll be watching.
Title: Re: GUI Improvements
Post by: Zaerc on September 20, 2008, 08:04:07 pm
Is it just me that notices that nothing seems to work properly in the GUI?  Text does not fit on the buttons properly, most screens look like buttons are missing, when actually using LMCE it frequently allows you to realize that you are in fact using several different programs.  I know that is how it works, but the point is the GUI is incredibly sloppy.  I find it frustrating that the devs are apparently hell bent on keeping their obviously broken system for creating GUI's.  I would gladly help out if the current system was not so horribly difficult to use.  I've said it before and I'll say it again, look at XBMC's skinning engine to see how it is supposed to be done!  Look how many people are creating skins for their software, meanwhile LMCE cannot seem to get a single person to fix the obvious bugs with theirs that gives any demo the general impression the LMCE is clunky and sloppy at best.  Feel free to slam me and tell me how I am bitching and not contributing anything, but the fact is some serious changes need to happen to make LMCE usable and to get it to a stage where it can even be tested properly.  I've been following the project for about a year now and simply find it incredible that nobody is even concerned that their software looks so sloppy.  Sure, there was that whole UI3 "discussion", but what the hell happened to that?  Media organization is simply awful, and the devs concensus is they are doing it "the right way"...again...look at XBMC to see how it is supposed to be done.  For god's sake I even talked to the developer who does all the code on their skinning issue and he said he'd be willing to consult with you guys about the way your UI is created and possible improvements to it.  You know what happened there?  Absolutely nothing, because nobody contacted him from LMCE, they expected him to chase them down.  When you're seeking advice you go get it, you don't wait for it to come to you.  Oh well, I'm over it, perhaps in another year someone will have realized that the general consensus of the clunkiness and sloppiness of LMCE is to great to be ignored or brushed off as people bitching.  When you decide to take a sensible approach to the GUI let me know and I'll gladly contribute something, but until then good luck, I'll be watching.

Sooo... why don't you and XBMC get a room then?
Title: Re: GUI Improvements
Post by: hari on September 20, 2008, 08:21:00 pm
given on how many platforms it runs, I think the UI is not all that bad..

but hey, did you even care to watch tschak's hadesigner screencasts?

best regards,
hari
Title: Re: GUI Improvements
Post by: tschak909 on September 20, 2008, 08:34:39 pm
Okay, damn it. Now the gloves come off.

First,

We are a community based project, who are trying to get their feet stable, especially since we are lessening our dependence on Pluto to handle infrastructure.
Our concerns first, are getting a builder running for the next release, and to fix as many critical bugs as on our list before the 0810 release. This means, not many new features, but a few.

Secondly,

Our UI approach _IS_ the right one considering the sheer number of display devices we need to target. I have said it once, and I will say it again:

LINUXMCE IS NOT A MEDIA CENTER. IT IS A SMART HOME PLATFORM. THIS IS ITS FIRST PRIORITY!

While Orbiter is not perfect, and it is a bit behind the curve, it is more than capable to build a beautiful looking UI that targets not one, but over 7 different display targets. We just haven't gotten there, yet. the Basic skin is just that.. Basic. It was designed by Pluto to test and make sure that Orbiter was working in the first place. As such, it doesn't focus on aesthetic, as much as functionality. I want to replace this, and am actively looking for help from other people who can follow my lead, and produce something aesthetically pleasing.

The second issue is of course, that we are using disparate system components linked together with a message buss. For some of these pieces, such as the Xine_Player, this is very smooth and well integrated. For other pieces, such as the MPlayer_Player, or the MythTV_Player, it isn't so well integrated. It is possible to tighten the integration between these pieces to smooth things out, but it takes man power, moreso than it does time. I want to be able to make it so that the MythTV screens are not used, instead, using the Orbiter UI, so that scheduling, etc.. can be done from any display surface in the house. Similar things need to be done to the web browser, and other smaller pieces.

We even have someone who is actively working on re-vamping the web admin.

If you obviously felt enough passion for this project, to scream at it from the top of your lungs, you need to ask yourself, what can you do to help? Furthermore, just do it.

Until then, you have NO RIGHT to bitch. Go home.

-Thom
Title: Re: GUI Improvements
Post by: hari on September 20, 2008, 08:37:56 pm
/me gets some popcorn
Title: Re: GUI Improvements
Post by: sadara on September 21, 2008, 12:44:38 pm
This is my first post on the forums.
I've been following the development of MythTV for years, and linuxmce since the beginning.

I mostly agree with los93sol, but don't share his attitude.
I believe that the UI does _really_ need improvement, (a bit of an understatement)
However, I am not going to complain about it, or DEMAND it be fixed RIGHT NOW.

WYSIWYG - This is open source software, and until someone finds the time to do something about it, nothing is going to happen. It sounds like the core developers have a fair few things higher on their TODO list atm.

If the UI bothers you that much, start a bounty for a new one, just don't be surprised by the amount you will need to raise to get a developer interested.

If you believe that the underlying API is fundamentally broken, either write a new one, or pay someone to do it for you.
When I get time, I may look at this (highly unlikely it will be anytime soon)

For the moment I will start a new thread with a bit of a more positive note, could someone pm me with the contact info for the XBMC developer so I can chase him down.
Title: Re: GUI Improvements
Post by: tschak909 on September 21, 2008, 04:43:46 pm
I want something to be crystal clear: We will not replace orbiter, unless we have a technology that can effectively target all of the devices that orbiter can currently target, as well as providing a paradigm that will allow for a UI designer to be able to design re-usable elements that can inherit, and create variations that are not only device divergent, but also skin divergent.

Guess what? Orbiter and Designer ALREADY DO THIS!

LinuxMCE is so much more than what's on the on-screen display, and before you scream that "well, people don't normally use all that stuff." Firstly, they should, the orbiter can be installed on a wide variety of devices, and secondly, we're going for a much larger use case than MythTV, XBMC, elisa, etc... so please.. keep that in mind. We are painting a much bigger picture than all of those projects combined.

Pluto has already done the hard work to make this possible, and quite frankly, I don't think any of you will do any better off the cuff.


If you're going to scream, and complain, why don't you actually dig into the code, and you'll see that we already have what we need, instead of whining and complaining that it doesn't fit your model of the universe.

-Thom
Title: Re: GUI Improvements
Post by: los93sol on September 21, 2008, 05:00:09 pm
A few things to note...

Yes I watched the screencasts and will not use the HADesigner under any circumstances, it is way too cumbersome and drastically overcomplicated.  I've said this before, but the guy who wrote HADesigner has even stated that it needs replaced and was a hack to get something usable out quickly.  It was NEVER intended to be used this long.  That said, why keep bothering defending it when the same guy has also stated that there are bugs with it that have not been fixed or even attempted to have been fixed since it was put out.

Dont worry about taking off the gloves, I obviously threw mine aside when I decided to make this thread.  You should however note that I did make the statement that when the standpoint of HADesigner changes and the devs and people who are able to fix that current problems do so that I'll gladly help and contribute.  You're beating a dead horse continuing to use the HADesigner, it is clearly broken.

Finally, call it screaming if you want, trust me, it is not.  It is unbelievable to me that when showing off this system to your friends/family that nobody is embarassed by the UI, even the "nice" UI looks awful, have noticable bugs from the time the system is booted.  Again, I'll gladly help once a reasonable system is in place, or at least considered.

BTW...XBMC's skinning engine could easily be adapted to handle all platforms with little effort in recreating the entire UI several times over. ...I loved the comment about getting a room with them, you must share my views and/or stance on the issues considering you normally fire right back.

Title: Re: GUI Improvements
Post by: tschak909 on September 21, 2008, 05:14:45 pm
you know what?

it's become very clear, that you are more intent on complaining, than actually doing anything at all.

I'm going to continue working, helping write the Designer replacement, and working on the replacement of Basic.

I find it deplorable that you are content to sit and watch from afar while we bust our ass trying to stand on our own two feet, and make the system our own. by our, i mean the community, yet from your virtual mount olympus you feel the need to rain down complaint upon us that are ACTUALLY DOING THE WORK. You sir, should be ashamed of yourself. If you want change, get in, and get your hands dirty, and make the change. You'll feel a lot more accomplished for it.


Are you going to defend your position to the point where you are willing to do something about it? something tangible? are you?

Probably not,
I'm going to continue hacking. Later.

-Thom
Title: Re: GUI Improvements
Post by: Zaerc on September 21, 2008, 05:49:59 pm
...
BTW...XBMC's skinning engine could easily be adapted to handle all platforms with little effort in recreating the entire UI several times over. ...I loved the comment about getting a room with them, you must share my views and/or stance on the issues considering you normally fire right back.



If that is so easy as you claim, then why haven't you done it yet?

And to clear that little misconception up, I just think it isn't worth discussing with some little troll who blatently chooses to ignore the underlying complexity (and everything else that doesn't fit his delusion).  So as far as I'm concerned both you and your views can fuck right off.
Title: Re: GUI Improvements
Post by: totallymaxed on September 21, 2008, 08:44:21 pm
A few things to note...

Yes I watched the screencasts and will not use the HADesigner under any circumstances, it is way too cumbersome and drastically overcomplicated.  I've said this before, but the guy who wrote HADesigner has even stated that it needs replaced and was a hack to get something usable out quickly.  It was NEVER intended to be used this long.  That said, why keep bothering defending it when the same guy has also stated that there are bugs with it that have not been fixed or even attempted to have been fixed since it was put out.

Dont worry about taking off the gloves, I obviously threw mine aside when I decided to make this thread.  You should however note that I did make the statement that when the standpoint of HADesigner changes and the devs and people who are able to fix that current problems do so that I'll gladly help and contribute.  You're beating a dead horse continuing to use the HADesigner, it is clearly broken.

Finally, call it screaming if you want, trust me, it is not.  It is unbelievable to me that when showing off this system to your friends/family that nobody is embarassed by the UI, even the "nice" UI looks awful, have noticable bugs from the time the system is booted.  Again, I'll gladly help once a reasonable system is in place, or at least considered.

BTW...XBMC's skinning engine could easily be adapted to handle all platforms with little effort in recreating the entire UI several times over. ...I loved the comment about getting a room with them, you must share my views and/or stance on the issues considering you normally fire right back.

Hmmm... look if you truly feel that XBMC's  skinning engine "could easily be adapted to handle all platforms with little effort" then lets see you prove that statement... "put up or shut up" is a phrase that comes to mind. As Sadara said here this is a community... get involved and prove what your saying is reality or fund someone else to do it. If its so easy it will not be a costly excercise... will it?

Thom & Zaerc are full engaged in this community... and have been for a considerable time...and by the way actually know what they are talking about funnily enough.

So I would suggest you get yourself engaged too and if you can - prove your point by 'doing' not just 'talking' ;-)

All the best

Andrew
Title: Re: GUI Improvements
Post by: hari on September 22, 2008, 12:54:48 pm
/me gets some popcorn
damn, the troll ate all my popcorn..

@'maxed: how true :-)
Title: Re: GUI Improvements
Post by: los93sol on September 22, 2008, 03:18:00 pm
You guys are all missing my point entirely, the fact is there is only a handful of people who know enough about the framework to make a change.  It's not as simple as just get in there and do it, it needs to be thought out thoroughly and discussed.  That is my whole problem with this project, nobody is willing to discuss or look at different options for systems that are obviously broken.  Sure, I could just start hacking away myself, but then you'd be no better off than you are currently, it would be just that, a hack.  At some point you have to stop putting new code in and start working towards cleaning up the existing stuff and making changes to fix architectural problems.  I want to clarify too I said XBMC's skinning engine could be easily adapted, I never said anything about implementing it.  That's where this needs to be discussed.  I realized that this isn't so much of an argument since nobody is denying that there are problems with HADesigner.
Title: Re: GUI Improvements
Post by: Zaerc on September 22, 2008, 03:46:30 pm
You guys are all missing my point entirely, the fact is there is only a handful of people who know enough about the framework to make a change.  It's not as simple as just get in there and do it, it needs to be thought out thoroughly and discussed.  That is my whole problem with this project, nobody is willing to discuss or look at different options for systems that are obviously broken.  Sure, I could just start hacking away myself, but then you'd be no better off than you are currently, it would be just that, a hack.  At some point you have to stop putting new code in and start working towards cleaning up the existing stuff and making changes to fix architectural problems.  I want to clarify too I said XBMC's skinning engine could be easily adapted, I never said anything about implementing it.  That's where this needs to be discussed.  I realized that this isn't so much of an argument since nobody is denying that there are problems with HADesigner.

I have only one question... do you want fries with your order?
Title: Re: GUI Improvements
Post by: tschak909 on September 22, 2008, 04:24:53 pm
No, you're missing the point.

You seem to be expecting everything to be laid out for you before you ever set foot on this project.

Sorry pal, we're not there, yet.

And yes, before you retort back, "Well how can I do this, only a few know how to?" .... We are not inaccessible. You can work with us on getting a proper development environment set up, and the things you need to do the work. Either here in the forums, or on the chat.

Also note, that even with the final infrastructure in place, UI developers will need to work with us to merge the changes into the system. This encourages a bit of team work. In the end, UI people will probably be paired off in twos or threes, with one person doing the UI work, and another helping to get it all checked in.

Also, how can you have a discussion on something, when you don't know how it works? in this case, how can you begin to figure out how to IMPROVE a piece of software when you haven't used it with your own two hands?

Chew on that a bit.

-Thom
Title: Re: GUI Improvements
Post by: los93sol on September 22, 2008, 04:42:14 pm
I have used HADesigner, it's simply a wretched hack of a design.  If it is so great then fix the fucking home screen with it or let's start talking about the problems with it and coming up with a solution to implement.  I find it ironic that you put all this work into the MAME skin and making the screencasts to promote HADesigner, but haven't bothered to fix the most obvious and simple alignment issues.  That's pathetic!
Title: Re: GUI Improvements
Post by: tschak909 on September 22, 2008, 04:52:07 pm
Wow, testy, are we?

My god, bro. I'm trying to address your concerns, but it really seems to me that you're content on just yelling like a little baby until you get your way. This is not how things get done.

Why don't you help work on a new tool, then? Or are you too busy yelling at the top of your lungs?

Or wait, are you saying you can't 'fix' the home screen to your liking?

Do you not understand why I did those mame screens in the first place? the MAME Plugin/Player was my entry into how the system worked. I chose to do a media player/plugin pair because I wanted those media types, and they happened to be the most complex parts of the system. I needed a UI for them, so I needed to learn Designer. In the process, I studied Designer, it's code, and Orbiter, and its code, in great depth. I made the screencasts AS I was doing the work, So that OTHERS COULD BENEFIT FROM MY WORK, YOU TWAT! THE WORLD DOES NOT REVOLVE AROUND YOU, IF YOU WANT A BETTER MAIN SCREEN, HELP US FIX IT!

How long did you actually sit down and use Designer? It took me a few weeks to get the hang of it. I then did the screencasts immediately so that people could get over that hurdle more quickly.

What's wrong with HADesigner from your perspective? we all have our lists. And a new designer is being developed by Michael Wokoun (m1cha3l in IRC), in JAVA. It's proceeding at a slow pace because he's, well.. like the rest of us.. has a job, and a need to put bread on the table.

And I'm not PROMOTING HADesigner. I am showing the tools that we have, and how to get things done in them. The most difficult aspect of this is doing totally new layouts and design, which was the focus of those screencasts.

I stand firm on my own convictions of the system, because they are founded in the fact that I have dug my hands deep within the system, and learned precisely how it works. While I do have problems with implementation, the design is sound, and this extends to the concepts embodied in Designer and Orbiter....

Where are your facts to back up your assertions? Why don't you come to the table with some data?

Do that, then we'll talk.

-Thom
Title: Re: GUI Improvements
Post by: hari on September 22, 2008, 06:08:02 pm
los93sol, we all agree that many parts need improvements and a bit of fixing on the UI front.

But until you show up some ideas on how to link the XMBC skinning engine with our hierarchically UI concept, I see no point in further discussing that route. We've already been there with flash and some other guy..

Maybe you want to give a better explanation of what exactly you are thinking about. "Using the XMBC skin engine" is a bit short. It is not like we deny every alternative approach.

Maybe you want to do a small proof of concept and show some results?

best regards,
Hari

Title: Re: GUI Improvements
Post by: los93sol on September 22, 2008, 06:57:50 pm
I lost the thread where this came up with before and I explained a bit about how XBMC's skinning engine is designed with a fall-through system that could be applied for supporting multiple platforms.  The way their system works is you would have a folder structure like:

SkinName
-NTSC
--Any replacement skin files that won't scale properly
-PAL
--All main skin files here
-720p
--Any replacement skin files that won't scale properly
-1080i
--Any replacement skin files that won't scale properly
-Images
--Theme 1
---All images for theme 1 here
--Theme 2
---All images for theme 2 here

When a skin is loaded at PAL resolution, all the skin files are loaded from the PAL folder and used to display the skin.

When a skin is loaded for any other resolution for example, 720p, all skin files are grabbed from the PAL folder and any files that needed to be tweaked to scale properly to 720p are loaded from the 720p folder.  So if you have a home.xml file in the PAL folder and not one in the 720p folder then home.xml is used and scaled to 720p from the PAL folder.  If you have a system.xml file in both the PAL and the 720p folder then the one from the 720p folder is used.

This fall-through system could be used to support different or tweaked skins on different devices without the need to recreate the entire skin.  Obviously some things should be designed to display on a TV, some on web pads w/touch screens, and some on smaller handheld devices like PDA's.

They also have a "theming" system in place that allows you to use the same skin files, but load images from different folders.  What this means is you can have, for example, the same skin, but in different colors.  This way a skin can be revamped to match your room better fairly quickly and with minimal effort by simply changing some color pallettes in photoshop.

It also allows the skinner to declare variables and call them using different routines so you can create skin-specific settings as well.  When used properly a skinner has the option to let the user decide which screen they want to see.  These settings could also aid with supporting multiple devices since obviously some PDA devices are touch screen, some aren't, some phones have full qwerty keyboards and some do not.  There are several variables that can be accounted for using a system like this.

The architecture is what I feel really needs some discussion since I do not know everything about LMCE, but have been around and dug into XBMC code enough to know and understand how it works.  My understanding on LMCE is that everything is exposed through device codes, and the entire system is controllable through these device codes.  If that is correct then the XBMC skinning engine works quite similarly.  They expose control of their software through action codes.  So for example you could have an action code like mediaplayer.play or mediaplayer.skipforward.  Those are then applied to a button or any other control in the XBMC skinning engine.  I'd be interested to know more about what ideas you guys have as far as whether LMCE could be controlled in a similar manner.  Again, my understanding is that this is very close to how LMCE works already.

There is another piece of the XBMC skinning engine that is very interesting, and that is the animations that can be done, a skinner can create a flashlike animated menu with as little as 10 incredibly simple lines in an xml file.  Animations can be fades, slides, etc, and vectors can be applied to these animations for more advanced skinners.

They also expose a plethora of visibility conditions ranging from basic button.hasfocus() to any of the action codes available.  There is literally no end to the possible combinations that can be used.

That said, this is a very brief introduction to what can be done with their engine.  I personally would like to see some interest in integrating XBMC into LMCE and letting it handle media organization, playback, etc., but I realize that is likely a HUGE undertaking and one that would likely require a cooperative effort from several people.

I do agree that the current HADesigner is capable, but even with all the screencasts and the amount of work Thom has put in trying to help people understand it, the system is just too difficult for people to get their heads around.

Again, I did talk with JMarshall (wrote almost all of the skinning engine for XBMC), and he said if anyone from LMCE is interested to have them get ahold of him, he can be found on the boards at xbmc.org, or on #xbmc on EFNet.  I'd like to hear what ideas you guys have to apply the features of XBMC's skinning engine to LMCE.

Just one more thing I'd like to point out is there are literally dozens of people who have a sound understanding of the xml based skinning system from the old underground xbox scene, most of these guys are still around and actively creating skins, and new ones are popping up all the time.  Those users could very well show interest in applying their talents to LMCE as well if it were as simple as what they're used to.  I've seen at least 5 LMCE users skinning XBMC in recent months so they are out there.
Title: Re: GUI Improvements
Post by: tschak909 on September 22, 2008, 07:20:40 pm
Thank you for your explanation, and I feel that we could use a hybrid of this in the long run.

With that said, you also need to keep in mind that there are a wide variety of devices that we have to target to. You haven't addressed these at all.

All of these devices have at their core vastly different CPU configurations of different speeds, as well as differing rendering architectures for graphics. For this reason, Orbiter was designed to be a lowest common denominator approach...Everything is designed around simple bitmaps, and simple actions, sending messages to various devices (usually the negative numbered virtual devices from Orbiter's standpoint.)

We have animations too, in the form of MNG. We don't have anything more capable, because again, we are trying to provide a base-line for all output devices in the system. This is not likely to change. I will not sacrifice support of one or more devices, just to make the TV screen more capable.

I suggest you spend some serious time looking at the code, to see why things were done the way they were.

-Thom
Title: Re: GUI Improvements
Post by: los93sol on September 22, 2008, 08:33:08 pm
I might be misunderstanding something here, but doesn't the fallthrough system address the multiple devices by allowing you to render different graphics, layouts, even actions per screen and per device?  That system can be utilized to load up lower quality images, the defacto standard for XBMC is to use .png format, but it will also accept lower quality bitmaps, jpegs, etc.

Unfortunately, I'm not so good at code, I learned just enough c++ to get my hands a little dirty with XBMC, and was able to implement some things after much explanation from the developers there and countless hours for each small change.  I will attempt to read through it and understand what's happening, but can you point me to some good starting points, what files in the source and any specific functions or classes I should be looking for.
Title: Re: GUI Improvements
Post by: tschak909 on September 22, 2008, 09:20:25 pm
All of the source for LinuxMCE proper is under src/, and you can snag a copy of the code at http://svn.charonmedia.org/svn/trunk/

Orbiters at their core deal with DesignObjs, which may or may not contain other child designObjs. A design obj that contains everything on a screen will most likely be attached to a screen.

These relationships start at the database, so it's important that you figure out what's going on there.

We use a home grown utility to create C++ access classes from the database, called sql2cpp. It is described in the wiki here: http://wiki.linuxmce.org/index.php/Sql2cpp

sql2cpp is run on the build version of the database (you should never run it on your own local copy, because certain things are stripped out from a packaged release that are only used when building the release, but they are necessary to be in the resulting sql2cpp library.) to create the libraries pluto_main, pluto_media, pluto_telecom, etc. These libraries are used ALL over the system, and especially in Orbiter, to abstract access to the database. If you look inside pluto_main/ , you will find a whole set of Define_xxxxxxx.h files. These are constants defined from the individual Define columns in each part of the database. This is used to distinctly reference a database element inside the code, and is used quite a bit. DESIGNOBJTYPE_Web_Browser_CONST for example, would be referring to the row in the database that contains the Description Web Browser. Use this to trace the relationships between the code and the database.

Orbiter/ itself, is where you'll be spending most of your time. It is a beast. well over 200,000 lines of code. The vast majority of it is screen logic, with rendering parts pushed out to sub-classes. The majority of the stuff that makes orbiter work is in Orbiter.cpp. Here you'll find the different designobj types, what they can do, as well as variable substitutions, etc. All of the different devices use the same code. The orbiter itself comes in two main flavors, a fat client, which pushes the graphics to the target device, and orbiter itself runs on the target device, sending DCE messages back, and a proxy client, which is how the Cisco 7970, Web Orbiter, and Mobile Phone orbiters work. These work by assembling things together just like the fat clients, but instead render out a flattened image, which is then pushed to the clients, which accept the image, and merely transmit back "button presses".. regardless of this, the same code is used, just a different rendering subclass.

It must be noted that since Orbiter depends heavily on the database, and we have a shared database infrastructure in place, building a theme packet format is not practical. Instead, theme developers should work in a small grouping of teams, one of them having a username to our sqlcvs repository, and submitting stuff for it as needed, as well as providing the necessary skin directory so that a package can be made. This ultimately means, that new skins become available to everyone as they update their database, and they can be selected as needed, with the system downloading the skin package as needed. Once a skin has been installed, a renegeration is needed, and the skin will be used from that point on.


Anything done in designer, has to be generated. This entails pre-rendering output versions of graphics, so that they can be used by orbiter. OrbiterGen does this. OrbiterGen takes the database definitions, and tries to figure out the largest pieces of a designobj to render into one graphic (it tries to reduce to as few rendered graphics as possible, so if you have a static screen that doesn't change, it will render all of the pieces on it as a single graphic.) This not only includes statically placed designobjs, but also designobjs of type Array (when you see a row of buttons such as the scenario buttons? those are button arrays), which are replicated and then rendered.

It's worth noting that we use PNGs and MNGs exclusively, alpha channels can be used, and are used quite a bit. Depending on the orbiter implementation, a background color may or may not be rendered (in UI1, all transparent pixels take on the background image.).

In the spirit of pre-rendering the images, any MNG graphics are ALSO pre-rendered. That is, each and every frame is output, and composited together with its underlying exposed pieces. This also means, that if you have potentially any overlapping animation, interesting artifacts may result due to OrbiterGen not able to resolve the fact that a completely independent state of frames needs to be rendered.

-Thom
Title: Re: GUI Improvements
Post by: totallymaxed on September 22, 2008, 09:47:38 pm
Hey los93sol... Welcome ;-)

Andrew
Title: Re: GUI Improvements
Post by: HorstJ on September 23, 2008, 08:39:58 am
I don't want to get kicked  ;) too by joining this discussion, but wouldn't it be possible to do a "quick" (without the need of a to detailed view of the lmce code) demo XBMC orbiter? Just as a prove of concept...

Something like:
- add new regular orbiter for the same system as the XBMC orbiter stays on
- use a smb dir on core for skin and xml files
- write a small app able to capture/send messages (with regular orbiters device id created before) and use XBMC as skinning engine


Title: Re: GUI Improvements
Post by: tschak909 on September 23, 2008, 03:26:02 pm
Go for it. The new device needs to be an Orbiter, and must implement all the commands in the Orbiter command group.

-Thom
Title: Re: GUI Improvements
Post by: colinjones on September 24, 2008, 01:14:17 am
I don't want to get kicked  ;) too by joining this discussion, but wouldn't it be possible to do a "quick" (without the need of a to detailed view of the lmce code) demo XBMC orbiter? Just as a prove of concept...

Something like:
- add new regular orbiter for the same system as the XBMC orbiter stays on
- use a smb dir on core for skin and xml files
- write a small app able to capture/send messages (with regular orbiters device id created before) and use XBMC as skinning engine




I don't see how it could prove the concept unless it was a replacement of the on screen orbiter. That would mean completely unthreading the existing on screen orbiter device so that the POC orbiter could overlay itself on top of xine/pss/etc. And it would then need to handle all the functionality of the existing orbiter, which even without having read the code myself, would be a massive undertaking as I assume that the current orbiter is doing far more than just displaying screens, capturing clicks and sending/receiving a few DCE messages.... what about all the interfacing with the SQL database to determine command paths down pipes, getting media lists, etc....

It would be nice to see a POC, I just don't see any way of doing this "quick"ly :) I think if you want to know what it could look like, look at XBMC, the question really is more about how much work is involved in overlaying the UI part on top of all the other orbiter functionality and also making the UI able to scale and target different devices - and the answer to that seems to be "lots"! I don't think anybody is saying that another UI engine can't be used, the issue is that the orbiter is much more than a UI engine....
Title: Re: GUI Improvements
Post by: los93sol on September 26, 2008, 01:12:04 am
Okay, I've been thinking more about this and I would like to see what your thoughts are on this as a proof of concept.  It is apparent that to do this properly it would require a serious amount of work, but I think I know how to do this in such a way that it could be done quickly.  XBMC supports python scripting that can be run from within the skin in numerous ways.  Since LMCE is designed so that its functions can be called from various devices I would assume that means a python script could be written to act as a liason so LMCE would effectively be run in the background of XBMC, but it would demonstrate what can be done for LMCE skinning through their engine.
Title: Re: GUI Improvements
Post by: tschak909 on September 26, 2008, 01:33:00 am
I think you need to do some serious studying of the Orbiter source code.

The Orbiter takes care of a great many functions:

* Data Grid rendering
* text display and layout with variable substitution
* screen handling (mapping screens to designobjs and maintaining queues)
* connecting to player devices to get status information

and a lot more.

There's about 200,000 lines of code in Orbiter, before you even get to the rendering subclasses (Which are comparitively small.)

-Thom
Title: Re: GUI Improvements
Post by: tschak909 on September 26, 2008, 03:04:33 am
also, my question is.. how are you going to deal with all the disparate devices? mobile phones for example?

-Thom
Title: Re: GUI Improvements
Post by: colinjones on September 26, 2008, 03:20:34 am
Thom

Am I correct in thinking that the fundamental issue here is being able to have multiple UI engines using the same definition files for rendering screens? Meaning that you design a screen once, then the UI engine for UI1, UI2, UI2+AB, JavaMO UI, Win32, etc all need to use the exact same design files, but render them in different ways using their own engine. The point being that any new/modified screens are only done once, and you can guarantee that all the different UI engines will be able to render the same screen on any device, albeit that they will obviously look different.
Title: Re: GUI Improvements
Post by: tschak909 on September 26, 2008, 03:38:21 am
no, not correct.

One size DOES NOT FIT ALL.

With Designer, you design a designobj, to have common properties, any properties, and then you have variations which inherit from them. The changes include not only the properties of that designobj, but also the placement and display properties of its children.

-Thom
Title: Re: GUI Improvements
Post by: colinjones on September 26, 2008, 03:45:32 am
Understood - but once that set of "design files" are created by HAD they are the same set used for all UIs and all devices, right? Understanding that not all the devices or UIs use the same parts of the design files, they switch and select based on the designobjs and the variations that inherit from them, specific to the particular requirements of the device and UI in question.

Is that more true?
Title: Re: GUI Improvements
Post by: tschak909 on September 26, 2008, 03:58:31 am
correct, again... before you go any further.. you need to watch my HADesigner screencasts and actually use the program. Please.

I know los93sol has been screaming at the top of his lungs that he won't use the program, the important thing is that the functionality in this program must be duplicated, no buts.

I will not answer any more on this subject until the parties involved use the tools we have, and dig into them. There is no point in discussing further.

-Thom
Title: Re: GUI Improvements
Post by: los93sol on September 27, 2008, 04:34:09 pm
....grumble....grumble....orbi...grumble...fu..biter...grumble grumble.

Alright I'll try HADesigner, I'm going to be getting an environment setup, is it possible to use it local on the LMCE box?  If I remember correctly it is only a windows executable...still think that hardly makes sense, but maybe I'm missing something
Title: Re: GUI Improvements
Post by: tschak909 on September 27, 2008, 04:45:01 pm
you can. I had tried to make Designer run under Mono, and it almost does... there just are some implementation details in system.data.odbc that i never got around to finding and fixing....

what I do is run HADesigner in a vmware installation on my primary workstation, and set up mysql to connect to it remotely. I have detailed this on the wiki page for Installing HADesigner.

-Thom
Title: Re: GUI Improvements
Post by: Marie.O on September 27, 2008, 04:55:52 pm
Alright I'll try HADesigner, I'm going to be getting an environment setup, is it possible to use it local on the LMCE box?

Otherwise, you might want to watch Tschaks screencasts, and use the QuickDesigner (look at the wiki for details). That works under Java, allthough you need lots of screen real estate to use it.

rgds
Oliver
Title: Re: GUI Improvements
Post by: los93sol on October 06, 2008, 04:52:20 pm
@Thom

I have been setting up a dev environment to start working on the GUI.  We haven't exactly seen eye to eye on things and I'd like to put that behind us and move forward.  The next few weeks are very busy for me so I will be putting time into this whenever I can, but you'll likely start seeing me in the channel more and more in the coming weeks.  So far I have HADesigner running and connected to my LMCE box, now I'll learning how to make this all work and going through your screencasts again.
Title: Re: GUI Improvements
Post by: tschak909 on October 06, 2008, 05:08:01 pm
cool :) We're always in channel, so we'll try to help.

-Thom
Title: Re: GUI Improvements
Post by: los93sol on October 08, 2008, 05:28:51 pm
Thom,

I've been reviewing your screencasts in my downtime to get my head around HADesigner a little better.  It does seem a bit cumbersome to use, but maybe that will change once I'm more familiar with it.  I might not have gotten far enough into the screencasts, I'm about 70% through them now, but I have a few quick questions.  I do not have all of the devices that need to be designed, I do not have a Symbian phone, or a PDA so testing on those devices is not possible for me.  Is there some way to emulate the UI running on the hardware within HADesigner so it can be simulated as close as possible?
Title: Re: GUI Improvements
Post by: tschak909 on October 08, 2008, 07:49:27 pm
currently no. it's one of the reasons  I have one of each type of device. But you can do it right, so long as you understand what needs to be present on each device type... For example, the Symbian variation should have Button definitions in each child designobj for any keys you want to press. Often there is no graphic in that case (Symbian does not inherit from the standard variation, so any actions like onload etc, have to be duplicated in the cell phone variation)....

-Thom
Title: Re: GUI Improvements
Post by: Marie.O on October 08, 2008, 08:24:27 pm
[..]I do not have all of the devices that need to be designed, I do not have a Symbian phone, or a PDA so testing on those devices is not possible for me. 

Also keep in mind, that you don't NEED to build for all UIs. Start with a UI as a UI1 replacement for example, and build it. After re-building all the screens for a new design, you WILL have such a good understanding on how things work, that adding support for the other devices will be trivial for you.

rgds
Oliver
Title: Re: GUI Improvements
Post by: los93sol on October 08, 2008, 09:13:36 pm
@posde
Absolutely, that's my plan.  The more I'm using LMCE the more it occurs to me that UI2 is fine, I don't need to re-invent the wheel, but it needs a LOT of polish, I'm going to start with the home screen first to start learning.

@Thom
I have two more quick questions...the screencasts make more sense this time through and I am confident that when I get back to my dev environment at home I'll be able to accomplish some things this time around.
1. How can I submit my changes for review to be included in the trunk?  I understand obviously that access to the trunk is something I must earn and prove a thorough understanding before any such access is given, but I'd like to be able to submit my changes to you before posting as a patch for critiquing (sp?) since you're the resident HADesigner expert.  :)
2. I see in HADesigner the IsTabShow help boxes for the design object, I also see in the screencasts the D and R next to two of the four boxes there, am I correct in thinking this serves as an onup, ondown, onleft, and onright directive for navigating with keyboard arrows or arrows on a remote for instance?  If not, is this a feature of HADesigner and is it covered in the screencasts as I haven't gotten all the way through yet, just thinking as I go.
Title: Re: GUI Improvements
Post by: tschak909 on October 08, 2008, 09:29:43 pm
Some things to note:

PLEASE PLEASE PLEASE PLEASE PLEASE do all your work in a top level category folder, create a new one "MySkin" .... Do not modify Basic in any way.

With Skins, any designobj can serve as the basis for a skin variation, so there is no reason to modify basic, let's keep that clean for now. Take a look at the SmallUI category, those are variations for the Cisco 7970 skin. Note that under this folder are categories much like the top level folder.. they don't have to be the same, but it's that way to make things more consistent.

create a shell script, I call mine designer-checkin.sh with the following lines:

Code: [Select]
/usr/pluto/bin/sqlCVS -U anonymous~nopass -H sqlcvs.charonmedia.org -R 3999 -e -c "Change This Comment" -r designer

This should be sufficient to get an sqlCVS menu.

You can do a
'diff' ... to see the differences between your stuff, and the central server. You can also revert some or all of your changes here.
'update' ... DO THIS FIRST before doing any designer work, so that your local database is up to date.
'checkin' to check in your changes.

You should come by the chat room to work with us the first run through, and please chat with us to let us know what you're up to. We all use this database, so we need to know if major changes are going to happen, so we can brace for them.

also this first pass, you should mysqldump your pluto_main database and keep a copy, in case something buggy happens.

To answer your second question:

the tab boxes U D L R, are interesting... normally, if Is Tab Stop is selected, Orbiter will order the tab stops automatically, pressing right will go to the closest object to the right, to the left, etc.

but you can specify a designobj # here to say, when you tab left from this object, go to desigobj 5678, instead. This should be used when the normal percieved eye flow for direction keys needs to be interrupted for some reason.
 
-Thom
Title: Re: GUI Improvements
Post by: los93sol on October 08, 2008, 10:31:03 pm
Cool, I was curious about this as I navigate with the keys on my keyboard and found several buttons that don't navigate logically as represented on the screen.  I'll have to play with this as I have some ideas to change the layout to improve the navigation.  I'm interested to see, since I'm using a designobj # in those fields, and a designobj can be a single or group of objects/buttons, will it remember which specific button had focus last and return to that button when navigating back to that designobj.  What I mean is you have two columns of buttons for example.

DesignObj 1          DesignObj 2

Button 1
Button 2              Button 4
Button 3

Logically you want the buttons in DesignObj 1 to be a 'group' so that if you navigate between columns starting with button 3 to button 4 then back you should focus where you left off at button 3.  Likewise if you navigate from button 1 to button 4 then back it should return focus to button 1.  I'm thinking this is not how it works though based on some of the navigation behavior I've seen in LMCE, but hopefully I'm wrong...I'll find out soon enough!
Title: Re: GUI Improvements
Post by: los93sol on October 13, 2008, 05:52:22 pm
I finally got my development environment running and have started making a few changes to UI2 already.  I don't really have anything impressive at this point, but I'd like to start a discussion on the boards about my approach and what I'm planning on doing.  Please realize I do not currently have a full blown system and am working toward building a more complete system.  If I am misunderstanding something or not accounting for something let's start discussing how to properly address the problem and come up with a solution.

I am working from UI2, I understand there are multiple devices that will run the UI and that it needs to be designed as such that a user navigating with a Fiire remote, arrow keys, or touch screen can easily make there way around the system. 

1. The thing I don't like about the current UI when run on a TV is that it appears to have been designed for navigation with any of the three in mind, and it can safely be changed to not include the touch screen navigation. 

2. The cursor on screen I do not quite understand as if things were laid out right, you could do away with it completely and navigate just fine with a gyration based remote or arrow keys.  Perhaps someone can shed a little more light on this for me.

These seem to be the obstacles the design needs to overcome to have a beautifully designed UI in both function and form.  It is my understanding that there are some limitations in HADesigner and LinuxMCE that require point 1.  Thom, can you verify I'm understanding this correctly?  My information is coming from my limited experience with HADesigner and from my interpretation of your screencasts.  I think it is because anything in the Standard layout is duplicated across any other layout.

My plan is to not take away any functionality from the current UI, but to modify it in such a way that a box connected to a TV feels more like a media center that just happens to be capable of communicating and controlling your entire house, and to make things like touchpads, PDA's, etc. feel like a remote that is in sync with, and capable of controlling your entire house.  The main difference I think in my plan and the current implementation is that the difference between a device connected to a TV and a touchpad is somewhat fuzzy from what I've seen.  It is possible I'm missing something entirely though, is it possible to select what layout your device uses?  And if not, how does LinuxMCE decide which layout to use?
Title: Re: GUI Improvements
Post by: tschak909 on October 13, 2008, 06:27:26 pm
UI2 does not function well with a touch screen, primarily because it lacks methods for bringing the menu up simply by touching the screen.

As for the cursor, you can replace the cursor with a transparent cursor (in the skins folder) to see what the effect is... the issue is however:

* while you do have an effective trail on the main screen, the other gyro screens such as the TV guide, the volume/lighting, the chapter selection, and the jog shuttle do require some effective feedback. This is why the large mouse cursor is used, and why it changes from a 4-way, to various 2-way cursors to indicate the allowed mouse direction.

and yes, correct. Anything in the Standard Variation is inherited to the other variations. The exception to this is of course the Symbian (Cell phone) layout, which has its variation explicitly set to not inherit from the standard variation.

Play around a bit more. :)

-Thom
Title: Re: GUI Improvements
Post by: Marie.O on October 13, 2008, 09:23:53 pm
Tschak,

do you have to run regen for the orbiter, if you change the mouse cursor?

rgds
Oliver
Title: Re: GUI Improvements
Post by: tschak909 on October 13, 2008, 09:32:00 pm
Good question!

will have to look into that.

-Thom
Title: Re: GUI Improvements
Post by: Marie.O on October 13, 2008, 10:24:24 pm
I can do that myself. Thanks Thom :)
Title: Re: GUI Improvements
Post by: los93sol on October 14, 2008, 12:19:38 am
Hey guys I'm having a problem in HADesigner tonight, not sure what changed or how, but now in my "designer window" I cannot get to all of the settings since I cannot make the window large enough to view the ones all the way at the bottom, any ideas?
Title: Re: GUI Improvements
Post by: tschak909 on October 14, 2008, 12:24:39 am
you should have a minimum size of 1280x1024. With that said, if the display isn't big enough, a scroll bar will appear in the rightmost extreme of the window (but only if it's not maximized), you can use this to scroll up and down as needed.

-Thom
Title: Re: GUI Improvements
Post by: los93sol on October 14, 2008, 04:30:30 pm
yep, absolutely what the issue was, I didn't think changing my screen res would have effected it though as it was still pretty high...those are some steep requirements :)

Title: Re: GUI Improvements
Post by: tschak909 on October 14, 2008, 04:45:58 pm
I understand. It is important to note however that you're working with images that are sized for 2844x1600, before sizing down to their target orbiter size.

btw, if you're interested, come over to: 

http://forum2.linuxmce.org/index.php?topic=6381.msg38881#new

-Thom
Title: Re: GUI Improvements
Post by: krys on November 11, 2008, 03:37:34 pm
what happened to this thread? did it get moved or did progress stop?
Title: Re: GUI Improvements
Post by: tschak909 on November 11, 2008, 03:40:04 pm
I am still offering support for anyone interested in learning and doing UI work.

-Thom
Title: Re: GUI Improvements
Post by: chriss on November 11, 2008, 03:47:22 pm
Thom, I'm still messing around with HADesigner to make some first sketches for calendar functionality. Currently I am watching your screencast again because I have several problems, but I will come back to them in the dev thread.

Cheers
/Chriss
Title: Re: GUI Improvements
Post by: krys on November 12, 2008, 10:34:44 pm
I am very interested in helping out in this area as it is something that I am more familiar with. I have made it through most of your screencasts and will start messing around with HADesigner soon. I only wish that there was a way to bring all of the data to my work PC as this is where I tend to have a lot of downtime. From my understanding the PC running HADesigner needs to be on the cores network to send/recieve all of the data.
Title: Re: GUI Improvements
Post by: tschak909 on November 12, 2008, 11:18:28 pm
that's correct.

-thom
Title: Re: GUI Improvements
Post by: chriss on November 13, 2008, 07:44:28 am
krys,
you can install a local  mysql server and copy the pluto_main database and the skins directory to you work PC and you won't need the connection to the core anymore. This should be enough for playing around with HADesigner. You could even sync your changes to the master repository with sqlCVS...

/Chriss
Title: Re: GUI Improvements
Post by: tschak909 on November 13, 2008, 01:45:30 pm
no, don't do that..... you won't be able to test your changes.
Title: Re: GUI Improvements
Post by: krys on November 13, 2008, 05:16:24 pm
I actually think that for now I am going to mess with some of the images just to make it a little more slick... I think that the UI is great functionally (there are a few things that I would change) but it mainly just needs to be sexier. I have done graphic design work in the past for web sites and this is pretty much just the same thing. Basically I will be just making a new skin for now as opposed to adding buttons and moving menu's etc. Once I get a really good feel for each menu and how it relates to my setup I will start messing with layout, plus I dont want to do anything major until 8.10 comes out. Speaking of 8.10 should we expect this as an early X-mas present or will it be more like a Happy Easter timeline?
Title: Re: GUI Improvements
Post by: tschak909 on November 13, 2008, 05:23:43 pm
We're working as hard as we can on the 8.10 release. We just built alpha's last night that a few of us are testing.

As for skin modification, cool. Yes, it is basically just changing bitmaps. Any designobjs that do not have matching bitmaps in their respective skin folders will fall back to Basic.

As a start I typically copy the Basic folder to my new Skin folder, and work from there.

I would suggest at least installing the Orbiter software on a windows machine, to test the UI1 variations. You should do all the variations, even if you don't use them, because others will.

-Thom
Title: Re: GUI Improvements
Post by: krys on November 13, 2008, 11:03:28 pm
I started laying down some graphics for the Game remote that was in the screencasts, luckily I have Photoshop at work so I can do all the graphic design in my downtime and just ftp it home so all I have to do at home is just substitute. Its looking pretty sweet, I just need to make sure that it works the way I envision it, I might post some teaser shots when I get a little further along.
Title: Re: GUI Improvements
Post by: tschak909 on November 13, 2008, 11:07:29 pm
awesome

Title: Re: GUI Improvements
Post by: krys on November 14, 2008, 09:46:32 pm
jeez this thing is looking sweet, hopefully I will have time over the weekend to get this first remote functional in HAD, I decided to make a remote for the MAMe player that you used in the screencasts. 8)
Title: Re: GUI Improvements
Post by: tschak909 on November 14, 2008, 09:49:13 pm
Cool? got a screenshot? I can help guide you as to what is possible.

-Thom
Title: Re: GUI Improvements
Post by: tschak909 on November 15, 2008, 11:01:14 pm
I have posted a thread showing off original Pluto 1 skins, so that you guys can see.

http://forum.linuxmce.org/index.php?topic=6650.0
Title: Re: GUI Improvements
Post by: krys on November 16, 2008, 04:25:41 am
Thom,

I cant seem to figure out the install instructions for the HAD, How do I set up the Grant?

USE mysql;
GRANT ALL PRIVILEGES ON pluto_main.* TO odbcuser@192.168.80.xxx IDENTIFIED BY 'odbcpassword';
FLUSH PRIVILEGES;

am I supposed to set this up from the core, or from the machine that will be running HAD? Is this a command I type in somewhere or do I actually use mysql? Sorry but this just isnt making sense right now.
Thanks,
Krys
Title: Re: GUI Improvements
Post by: tschak909 on November 16, 2008, 05:22:10 am
You type this in mysql on the core. Open a shell to start mysql with:

Code: [Select]
mysql pluto_main -uroot

-Thom
Title: Re: GUI Improvements
Post by: krys on November 16, 2008, 09:19:49 pm
Thanks for stickin with me, I opened a shell, started mysql (on the core) got the command prompt

mysql>

I typed in the commands as specified and all that happened was it dropped down a line and indented with a "->" symbol
Is this all that was supposed to happen? I got no confirmation that anything actually happened, and when I try to create the system DSN i get a SQL_ERROR cant connect to mysql server on local host.

Thanks,
Krys
Title: Re: GUI Improvements
Post by: tschak909 on November 16, 2008, 09:42:13 pm
the command must end with a semicolon. It gave you a -> prompt because it thought you wanted to type something in addition to what you already typed.

-Thom
Title: Re: GUI Improvements
Post by: krys on November 16, 2008, 10:44:51 pm
Should I be putting something in the server blank when setting up the DSN? I still cant connect at this point. I believe that I got the core setup correctly, but when I click on test I still get the error

[MySQL][ODBC 3.51 Driver]Can't connect to MySQL server on 'localhost' (10061)

Title: Re: GUI Improvements
Post by: tschak909 on November 16, 2008, 11:07:10 pm
Dude. Please read the instructions. It tells you to put the address of your core (192.168.80.1) in the server field.

-Thom
Title: Re: GUI Improvements
Post by: krys on November 17, 2008, 03:46:02 pm
Thom,
Sorry for wearing down your patience, I just looked again at the wiki and didn't see anywhere where it tells you to put the core's IP in the server blank. Thanks for the heads up though I will try that when I get home.
Thanks,
Krys
Title: Re: GUI Improvements
Post by: hari on November 17, 2008, 04:39:34 pm
krys: can't await your mockup :-)
Title: Re: GUI Improvements
Post by: tschak909 on November 17, 2008, 04:47:40 pm
Yes, Likewise. Please show us what you've been doing, especially right now, so we can help guide it.

-Thom
Title: Re: GUI Improvements
Post by: krys on November 17, 2008, 05:14:04 pm
well here is what I have so far, notice I still have not placed volume or light controls. The blank on the left will be for the playlist, and I still need to locate the currently playing info. All that is easy enough, I am just hoping to get this HADesigner installed tonight.

(http://wiki.linuxmce.org/images/3/38/Remote_layout.png)

Here is the link to the full res image

http://wiki.linuxmce.org/images/3/38/Remote_layout.png
Title: Re: GUI Improvements
Post by: los93sol on November 17, 2008, 07:21:55 pm
I have noticed that the textures are duplicated over and over and over again for no apparent reason, is there some logic behind this?  For example UI2 on the home screen the same textures are duplicated over and over for each "menu" even though the textures are identical in pixels and in name, just stored in different folders.  Wouldn't it be simpler to customize and manage by pointing these buttons at a single texture?
Title: Re: GUI Improvements
Post by: tschak909 on November 17, 2008, 07:22:57 pm
What do you mean by texture? can you give specific examples?

-Thom
Title: Re: GUI Improvements
Post by: los93sol on November 17, 2008, 09:05:38 pm
The most specific I can get right now is the graphic used to the buttons on each of the main menu's, for example the Telecom menu and the Media menus in UI2.  They have the same graphic when the buttons are not highlighted, but they are both pointing to different paths for the same graphic.  I hope that makes sense...

I don't have my environment near me so for the sake of explanation let's say it uses the graphic ButtonNoFocus.bmp.

The Telecom menu would point to
MainMenu/Telecom/ButtonNoFocus.bmp

And the Media menu would point to
MainMenu/Media/ButtonNoFocus.bmp

Also if I recall correctly, by the above scenario which should be fairly accurate to what is actually being used there is also an existing, but unused MainMenu/ButtonNoFocus.bmp.  I was just trying to swap some bitmaps to quickly change the appearance and quickly realized that it meant digging through and creating the same image over and over again. 
Title: Re: GUI Improvements
Post by: tschak909 on November 17, 2008, 09:07:57 pm
Oh! I can explain that.

It's a vestige left over from the ORIGINAL Basic skin in Pluto 1. (look at the other thread where i posted the screenies)

if you'll notice each category had a different colored button..hence the different graphic files.. they found it easier just to copy over than to replace all the paths. :)

-Thom


Title: Re: GUI Improvements
Post by: los93sol on November 17, 2008, 09:37:46 pm
Gotcha!  It kind of makes sense and I'm not sure how orbitergen works under the hood, but I'd imagine that is slowing down the generation quite a bit if it's grabbing and rendering seperate images all over the place when it could just grab one and render it where it needs.  At the very least once the orbiter screens are generated it would seem like it would take a performance hit from it.
Title: Re: GUI Improvements
Post by: tschak909 on November 17, 2008, 09:48:51 pm
actually, it wouldn't make that big of a performance hit, because that's not where OrbiterGen spends most of its time.

OrbiterGen has two discrete passes:

In pass 1, it builds a rendering tree from the information in the database, joining together all the information between the various tables, to provide what is essentially a scene graph.

The goal in pass 1, is to create tree branches with as few nodes as possible, because in a screen if nothing changes, a single graphic for the top level designobj is rendered. Otherwise, each time there is a potential child designobj within a designobj that changes, OrbiterGen must render each potential change as a separate graphic, thereby increasing orbiter generation time. This is why Pluto decided later in the game to not use discrete state changes in the Basic skin, and opted to dynamically draw rectangles for selected states, etc. They wanted to cut down on Orbitergen's rendering time.

Now this also implies, that if MNG animations are used, that EACH AND EVERY FRAME for a given region must be rendered separately! (this is actually what happens)

In Pass 2, the rendering trees are used, to direct an image compositor to combine all the requisite images for a given area into a flattened png, and scale them down to the target size dictated by an orbiter's PK_Size.

I hope this explanation makes things a bit more clear.

-Thom
Title: Re: GUI Improvements
Post by: los93sol on November 17, 2008, 09:59:11 pm
Thom...jesus man...you are a freakin genious to have figured all of this out.  Thanks for breaking it down for me...I'm trying very hard not to be "thick" about my views on HADesigner and reading over this thread, I think it will be helpful for many others to understand why it is a better system than the others I was originally suggesting.  +1 Karma for you for sure!  I assure you I have been working with the system and don't quite have anything impressive to show off, but I have been able to change things around a bit now after your screencasts and explanations of the system.  You are an asset to the development team
Title: Re: GUI Improvements
Post by: tschak909 on November 17, 2008, 10:05:15 pm
Thank you, but I cannot take all the credit.

A good portion of this came together, after a lengthy phone conference discussion with Aaron.b while verifying my own forensic research with Designer and Orbiter.

-Thom
Title: Re: GUI Improvements
Post by: krys on November 17, 2008, 11:11:58 pm
Thom,
What are your impressions of my layout? I should be able to finally get going in HAD tonight to see if I can make it work out on the system like I have it planned in my head.
Thanks,
Krys
Title: Re: GUI Improvements
Post by: tschak909 on November 18, 2008, 12:19:40 am
it may have problems scaling down cleanly, also you need to be sure that your hotspots can cleanly be bound in square regions.

-Thom
Title: Re: GUI Improvements
Post by: krys on November 18, 2008, 04:48:08 pm
I actually have all of my hotspots in photoshop as 266x266 squares like the video mentioned, the Circle in the middle is actually the same dimensions as your game controller in the video (just imagine the circle tightly fitted into a square) 3 buttons high x 3 buttons wide.
Also I finished my HADesigner setup last night but didnt get started doing anything because we had some guests over. Tonight I should be able to make some progress.
Title: Re: GUI Improvements
Post by: tschak909 on November 18, 2008, 04:53:37 pm
groovy, okay :)

-Thom
Title: Re: GUI Improvements
Post by: krys on November 24, 2008, 05:24:04 pm
I am currently still setting up some features and hardware that are taking up most of my spare time. As soon as I tackle some issues (mainly my most important MD will still not net boot, very frustrating  ???) I will focus on some more designing. I have a USB-UIRT in the mail along with a Wintv-150 tv tuner, I would really like to get the system functional before I dedicate my time making it purty. What is really going to suck is I am sure the very day that I finally get this kernel panic from my NIC fixed will be the day that LMCE 8.10 will be released and it will prob be automatically recognized....
Title: Re: GUI Improvements
Post by: los93sol on December 03, 2008, 05:01:50 pm
I know how to modify screens now, but how in HADesigner do I start a new skin with it's own directory and file structure from scratch?  I've gotten familiar with using MySQL Query Browser and the other tools to find my way around a skin, but I don't understand how to just start from scratch in a folder other than Basic.
Title: Re: GUI Improvements
Post by: tschak909 on December 03, 2008, 05:06:14 pm
Well, I go over this a bit in my first skin screencast, but basically:

* Copy the Basic folder to a new folder, any name.. doesn't matter
* Create a new entry in Skin with your skin's name, and directory, at the very least. Pattern the row after Basic.
* Create any designobj screen overrides you need in Screen_DesignObj, taking into account your new PK_Skin number.

-Thom
Title: Re: GUI Improvements
Post by: los93sol on January 30, 2009, 05:40:37 pm
I hate to beat a dead horse with a stick, but I really think two skins need to be created that match, one for orbiter devices optimized for touch screen devices, and one for media directors optimized for remote, keyboard, and gyro navigation.  It seems silly to have overly huge buttons and fonts on my media director when surely nobody has or is using their TV as a touch screen, getting up to walk to the tv to change the volume, etc.  Am I misunderstanding something or has this just not been completed yet.  I understand the fallthrough system for different devices in HAD and agree that it should be used when dealing with touch screens, but don't understand why the media directors don't have their own UI to opimize them.
Title: Re: GUI Improvements
Post by: tschak909 on January 30, 2009, 05:50:01 pm
Not going to repeat myself. :)

You've already answered this question in your post.

-Thom
Title: Re: GUI Improvements
Post by: totallymaxed on February 01, 2009, 09:49:51 am
I hate to beat a dead horse with a stick, but I really think two skins need to be created that match, one for orbiter devices optimized for touch screen devices, and one for media directors optimized for remote, keyboard, and gyro navigation.  It seems silly to have overly huge buttons and fonts on my media director when surely nobody has or is using their TV as a touch screen, getting up to walk to the tv to change the volume, etc.  Am I misunderstanding something or has this just not been completed yet.  I understand the fallthrough system for different devices in HAD and agree that it should be used when dealing with touch screens, but don't understand why the media directors don't have their own UI to opimize them.


We use ASUS Eee Top's in UI1 as 'kitchen top' or wall mounted touchscreens - everyone I have shown one of these too loves them. Using the UI1 Orbiter like this on a touchscreen makes you realise how good this UI really is... the touchscreen is what it was made for. Same goes for Tschak's WebDT Orbiter to of course....

Andrew
Title: Re: GUI Improvements
Post by: colinjones on February 12, 2009, 02:18:56 am
I hate to beat a dead horse with a stick, but I really think two skins need to be created that match, one for orbiter devices optimized for touch screen devices, and one for media directors optimized for remote, keyboard, and gyro navigation.  It seems silly to have overly huge buttons and fonts on my media director when surely nobody has or is using their TV as a touch screen, getting up to walk to the tv to change the volume, etc.  Am I misunderstanding something or has this just not been completed yet.  I understand the fallthrough system for different devices in HAD and agree that it should be used when dealing with touch screens, but don't understand why the media directors don't have their own UI to opimize them.


We use ASUS Eee Top's in UI1 as 'kitchen top' or wall mounted touchscreens - everyone I have shown one of these too loves them. Using the UI1 Orbiter like this on a touchscreen makes you realise how good this UI really is... the touchscreen is what it was made for. Same goes for Tschak's WebDT Orbiter to of course....

Andrew

Andrew - what kind of price do you pay for them (or rather resell them for)? Trying to see what is a reasonable price locally in Aus...