Thread: Android-ish Theme Request

Media player can be controlled from any screen wit the media buttons (it's just a function of the layout of the screen)

I'm still learning what OM can do If you can't control media player from home then leave that off. The other ideas sound good o me also.

The question is more almost, what can't it do? If you haven't programmed in the environments then it can be tricky, but as a programmer, with full access to the .NET environment, plus all built in functions and controls in the OM framework, it's just a matter of using the right code. Plus wrapped opengl functions (I think opentk it resembles) - man, I wish knew opengl/graphics .

I ask because, like Android, that media box can be a "widget" that is updatable by the media player plugin. However, updatable (live) menu items is not something OM can do right now.

I don't want to overstep or sound arrogant here, but why not? Can the main menu not perform the same mediafunctions (mediastates? can't remember exactly) that the default ui.dll had in them. States that update via song change, play, etc? If it can, just update the right labels on the main menu?

So I would think (for now) we can leave that off the menu pages, scroll "now playing" stuff in the top bar , and when top bar is swiped down you get the media player page.

As said before, the top bar looks small. I did find gesture code in the ui stuff, but haven't really looked at it yet. Will there be enough room to swipe inside the top bar? Or are you implying if you only start the swipe in the top bar?

Andrew's idea of the volume knob in the bottom corner with the behavior you mention works for me. A couple media buttons on the bottom bar (prev/next, play/pause) or, like the default skin, press a single button to bring up media controls. Maybe, as long as there is media playing, the bottom bar shows media buttons?

I'll plan a horizontal sliding volume bar (basically horizontal design of the default vertical one for now) for testing. It can always be changed later. As for media controls, is there enough incentive to offer the full range of them? IE) ff,rw,stop? There might be enough room on the bottom bar to fit prev/play(pause)/next buttons since those are prob the most use. The other media buttons could be used in the media screen? Is this an ok idea?

Sounds good to me I'm not that picky on the fine details. Just let me know if you need any new images for the home screen.

Originally Posted by detlion1643

The question is more almost, what can't it do? If you haven't programmed in the environments then it can be tricky, but as a programmer, with full access to the .NET environment, plus all built in functions and controls in the OM framework, it's just a matter of using the right code. Plus wrapped opengl functions (I think opentk it resembles) - man, I wish knew opengl/graphics .


I don't want to overstep or sound arrogant here, but why not? Can the main menu not perform the same mediafunctions (mediastates? can't remember exactly) that the default ui.dll had in them. States that update via song change, play, etc? If it can, just update the right labels on the main menu?

I have every faith that it could be programmed as part of the Main Menu plugin. You would have to account for the placement of menu items sort of auto-wrapping around it. I don't know if you are familiar with Android so excuse me if this is obvious (I also am not trying to sound superior in any way) but when the user picks what apps (plugins) to add to the home screen (main menu), the main menu needs to arrange them, including the widgets (the media box) no?

What I am thinking is the idea of 'widgets' for the media box that Andrew proposed. A widget is user place-able. Almost a stand-alone mini application that can be placed on any of the main menu pages. As most know, I'm not a great OM plugin programmer :O but when I think out the way these things would work, it would mean a whole new category of plugin and the way the Main Menu behaves. I was just not sure it was doable at this point. But if you're confident that it can be done, by all means go nuts it would be an excellent feature.

Originally Posted by detlion1643

As said before, the top bar looks small. I did find gesture code in the ui stuff, but haven't really looked at it yet. Will there be enough room to swipe inside the top bar? Or are you implying if you only start the swipe in the top bar?

I was thinking if the gesture started in the top bar (again, like Android behavior) like you are dragging down the top bar like a drawer.

Originally Posted by detlion1643

I'll plan a horizontal sliding volume bar (basically horizontal design of the default vertical one for now) for testing. It can always be changed later. As for media controls, is there enough incentive to offer the full range of them? IE) ff,rw,stop? There might be enough room on the bottom bar to fit prev/play(pause)/next buttons since those are prob the most use. The other media buttons could be used in the media screen? Is this an ok idea?

I have no preference to vertical or horizontal volume. I do like the +/- being available when the volume is tucked away. But that's just my preference. I have the CharacterLCD plugin with Matrix Orbital and I assign volume buttons to that so makes it always available as well.

My personal thought on the basics you mention (prev/play(pause)/next) are all that are needed on a regular basis. At least from a driver point of view. If you are on the main menu you are likely trying to get to a different app (nav?) otherwise you may well leave the full media screen visible. I'm not sure how crowded the bottom bar will get :S.

On a side note, I know it's media player related, but I like the behavior of "Previous" to first jump to the begining of the current track, then, if a second press occurs within a second or two, it will jump to the previous track. That way, if I wish to hear the current song again, I can. Current behavior (while in shuffle mode) jumps to a random track (not the previous track) so I cannot easily navigate back to the same song

Okay, I fear I have rambled enough

Cheers,
John

Originally Posted by andrewfblack

Sounds good to me I'm not that picky on the fine details. Just let me know if you need any new images for the home screen.

Oh, I am sure as this moves along, you will get a few requests for more images! Especially for "icons" for main menu for other plugins. I'll need one for Arduino. I "want" to flesh out the guts for some OBDII plugin, just the basics. We'll see how far I get once I grab an ELM327 interface. An ambitious little project for me, but what the heck.

John

With everything that is being discussed - I'm gonna say the bottom bar is too crowded.. I say this because if we talk about volume/play/next/prev that's already 4 less places for buttons to be configured to go to plugins. If we add the +/- to volume as well, I think it starts taking up too much room.

For swiping the top bar, at this time to me it's a little small - If we want to up the height/pixels from the current to maybe about 70 or so, it will just be that much more manageable. Then we could keep the volume stuff in the top bar. But that's probably gonna negate the reason to swipe in the top bar..

On a side note, I know it's media player related, but I like the behavior of "Previous" to first jump to the begining of the current track, then, if a second press occurs within a second or two, it will jump to the previous track. That way, if I wish to hear the current song again, I can. Current behavior (while in shuffle mode) jumps to a random track (not the previous track) so I cannot easily navigate back to the same song

Easy enough to do!

I don't know if you are familiar with Android so excuse me if this is obvious (I also am not trying to sound superior in any way) but when the user picks what apps (plugins) to add to the home screen (main menu), the main menu needs to arrange them, including the widgets (the media box) no?

I have no clue how Android works. I've seen it, but never used it myself. I do know that if you add an app, the main screen can grow so that you can scroll up/down to see them all. Do we want the main menu screen to house the apps as well? If not, maybe I can build a horizontal scrolling control (think the lists but with horizontal flick movement) that sits on the ui level. The one that doesn't scroll is the home button - all others are listed too scroll, so you can just 'scroll' to the plugin you would like... I'm just throwing out ideas, as I said I have no idea how Android works, but if we are just trying to keep plugin buttons available from anywhere....

I'm actually going to stop suggesting ideas at this time... You know Android better than me, the more I suggest, the less Android it's probably gonna resemble.

Oh boy! I seem to be rambling now

I hate to double post, but I don't feel this is just edit worthy...

I did a quick look into Android 4.0 (heh, though they were still on 2.x if that shows you how I don't know much about it). They came a long way from what I used to know.

Looks like they now have a 'bottom' bar that includes common apps to be launched. We can make something like user configurable common plugins. They can choose like 3-4 and those chosen can be included on the bottom bar. Maybe all other plugins would be vertically scrolled like Android's main home screen?

Looks like the top bar in Android is just notification stuff.

Widgets placeable/sizeable on the main menu. The main menu, as it might house other apps, could be split into 2 sections. Widget section and app section. Think like left 1/2 of the screen could house configurable widgets, and right 1/2 of screen could house the scrollable apps?

Other than these 3 things - Most changes are under the hood or things that I am not programming for. Camera's, editing photo's/videos, network control, multitasking...

Wait, multitasking? New to me on a phone anyways. Is there enough to warrant coding multitasking. It would be a huge pain keeping track of everything panel wise from plugin-to-plugin, but it could be done with enough time. Default OM can be used like 80% multitasking, it only screws up when using multiple panels in a plugin, otherwise the original panel state stays as it was. I don't see a need for multitasking-switching plugins, but others might...


This still brings about the volume/media button problem of before, where to put these? The left side of the bottom bar is probably the best place (since right side could house the common plugins)?

Alright, this time for real, you guys tell me how this skin should work with resemblance to Android. All I have is viewing of screenshots/info from Androids website...

Originally Posted by jmullan99

Oh, I am sure as this moves along, you will get a few requests for more images! Especially for "icons" for main menu for other plugins. I'll need one for Arduino.John

Icons can be generated on the fly from font's in OM or assigned a picture. There is a special attribute for this if you look at the top of each plugin code you'll see it. This is how the icons for the main menu is assigned now.

Originally Posted by detlion1643

Wait, multitasking? New to me on a phone anyways. Is there enough to warrant coding multitasking. It would be a huge pain keeping track of everything panel wise from plugin-to-plugin, but it could be done with enough time. Default OM can be used like 80% multitasking, it only screws up when using multiple panels in a plugin, otherwise the original panel state stays as it was. I don't see a need for multitasking-switching plugins, but others might...

OM already multitasks... It's a question about how your plugin is designed. If you reset everything each time the panel is shown then it will not multitask, if you keep your own thread running and don't reset anything then it will multitask. OM does not shutdown or kill any plugins unless the plugin crashes or OM is closing.