Calling all UI Designers for new Basic Skin

[los93sol]

Unfortunately I don't use Gimp, how difficult would it be to put the replacement button textures you created in a .png format?

[tschak909]

so go download a copy. ;-) It's free.  http://www.gimp.org/

-Thom

[los93sol]

Thom,

As I understand it is not currently possible to integrate MythTV's UI into LMCE, are there plans for this in the future?  As I see it almost all of the MythTV UI can be ditched since LMCE handles everything the MythTV would already except for viewing TV.  I really have a hangup on the duct tape feeling I get when I see the MythTV UI pop up.

[tschak909]

Orbiter can take over all of the functionality that MythUI is doing, we just use mythtv to enable viewing instead of mythfrontend.

We'll need to expose a LOT more data via the MythTV_Plugin... This will take the longest, because we have to replicate what mythfrontend is doing for these database queries.

Once this is done, data grids can be attached, and Orbiter can fully assume the role that mythfrontend was previously doing.

-Thom

[aussie]

How can i help out???  not very good at programming but have a various knowledge in photshop???

[tschak909]

First, install HADesigner, make sure you have a working LinuxMCE core you can connect to

Second, watch my screencasts.

-Thom

[los93sol]

...Just to add to that, once you have an idea how HADesigner works and what is possible it would be nice to put together some mockups, or build on some of the ones already posted in this thread.

[digilifellc]

How about a pie menu that starts, and is based in a corner instead of centrally on the screen? It would be more consistent with the pie menu idea, keep the media-up-front concept, take up less space, and would be easier (of sorts) to navigate because the boundaries of the viewable screen are clearly and consistently defined (the edges of the screen). Also, being that every screen on the planet has four corners, this could give way to specific button arrays the perform specific functions, such as top left = media, top right = automation, bottom left = computing and internet, bottom left = technical. You could even use compass directions to get more use out of the screen (top, left, right, bottom). The only issue is that a pie menu doesn't give much room for text, and would be very icon-heavy to be useful.

To think of it, another perk could be the ability to call up these menus without a touchscreen, such as a phone using its dial pad to navigate. The same numbers could be reused for successive sub-menus because each menu layer would function as its own ?entity? (I don't know how to fully describe that one... please forgive me). It would function much like dialing a normal phone number. In order to go back to a parent sub-menu, a 'back' protocol can be used ('Last' or 'Back' or even '8' on a remote control or phone, left arrow on a keyboard, right click on a gyro mouse, etc. TPs would be able to initialize parent menus from sub-menus directly because they would still be visible.)

For OSDs that use gyro mouse functions, when you hover over a function, its text description can show in a status display, as well as its corresponding dial-in number for use with a remote of cellphone.

I may be barking up the wrong tree, but I was just thinking over the pie menu idea and was inspired by the application's screenshot. I do think it can work, but there would need to be some rules in place for it to be practical.

I'll be posting some graphics on what I have in mind in a few hours, don't worry.

[krys]

a picture is worth a thousand words   

[jimmejames]

I would guess he's talking about something like this:
http://circledock.wdfiles.com/local--files/start/CircleDockLeft.JPG

or this:
http://www.gadgetell.com/images/032006/origamikeybus.jpg

[tschak909]

Please guys, let's be realistic.

We need something approachable that most people can use.

And unlike most of you, I actually have experience with pie menus, and given the scope of what this system needs to do, the number of usable spots is not enough to carry even the most basic functional scope.

-Thom

[krys]

I would also be concerned that the buttons would not be large enough when you are 10-15 feet away watching tv.

[digilifellc]

@krys: Good catch. That could be a problem if the icons aren't big enough. In the same breath, if they are big enough, successions will only be able to go so deep before the screen boundaries are hit.

@jimmejames: That's exactly what I envision for touchpanels. Something a little different for OSDs.

@tschak909: You don't think this interface is usable? Why isn't it (more than "I don't like it")?

[krys]

Thom stated earlier that the number of usable spots wouldn't be enough for all of the buttons that we would need, but I am sure he can expand for you.

[digilifellc]

Then wouldn't that require a bit of planning of which buttons would be placed where on the interface? Buttons that are close to the edges would fan out inwardly. Buttons aimed at the center of the screen would fan out evenly. If a sub-menu would take up more space than there were spaces available, then I would get worried.

Is there a sub-menu that would take up more than, say 8 spaces?

Even if that were the case, couldn't the sub-menu be broken up into smaller pieces by anchor (corner or compass direction) or even sub-menu A and B?

I'm not trying to refute the answers given, I'm just trying to exhaust all possibilities. Just don't flame me.