NextPVR Forums
  • ______
  • Home
  • New Posts
  • Wiki
  • Members
  • Help
  • Search
  • Register
  • Login
  • Home
  • Wiki
  • Members
  • Help
  • Search
NextPVR Forums Public Developers v
« Previous 1 … 56 57 58 59 60 … 93 Next »
GBPVRSkinTools alpha

 
  • 0 Vote(s) - 0 Average
GBPVRSkinTools alpha
gruskada
Offline

Member

Posts: 121
Threads: 20
Joined: Dec 2005
#21
2006-01-26, 02:52 PM
McBainUK Wrote:Just a question, have you thought about <SpecialElements> in the skin files? These determine the location of elements (composite images). This could be a problem in previewing how the GBPVR screen/plugin will look because the code determines what elements are used. Only the plugin would know which images are used for a particluar specialelement. Also, list boxe elements are made up of multiple images!

Also the WYSIWYG preview would only be able to show all the comosite images, it wouldnt be able to simualte the running GBPVR, eg popup boxes showing and hiding, menus being scrolled, lists filled with data...
You could have an option to hide/show elements in the preview - abit like 'layers' in photoshop

Well, for filling lists with data, we could fill it with "greeked" text in the specified text style. For popup boxes - maybe we could have a little icons set at the bottom of the page that represents currently non-visible items, that you could then click on to see in the appropriate place?

The "plugin plugin" idea I touched on earlier could handle what elements are allowed and what is used where, and any other plugin-specific things. This could get complicated, though. I think we'll probably need to get release 1 out the door without support for additional plugins...

gruskada
McBainUK
Offline

Posting Freak

Posts: 4,711
Threads: 429
Joined: Sep 2005
#22
2006-01-26, 03:09 PM (This post was last modified: 2006-01-26, 03:18 PM by McBainUK.)
gruskada Wrote:Well, for filling lists with data, we could fill it with "greeked" text in the specified text style. For popup boxes - maybe we could have a little icons set at the bottom of the page that represents currently non-visible items, that you could then click on to see in the appropriate place?

The "plugin plugin" idea I touched on earlier could handle what elements are allowed and what is used where, and any other plugin-specific things. This could get complicated, though. I think we'll probably need to get release 1 out the door without support for additional plugins...
Agree. You seem to have a good idea of the program. I'm away for the weekend so take your time with the wireframe and send it to me sunday/monday if you like.

Going to work on GBPVR UI Elements tonight.
Wiki profile
My Projects
Programs Plugin [SIZE=2](retired)
| Volume OSD Plugin (retired) | Documentation Wiki (retired)
[/SIZE]
jam_zhou
Offline

Senior Member

Posts: 632
Threads: 179
Joined: Sep 2005
#23
2006-01-26, 09:15 PM
I think this would be a great idea, thanks for starting this. I have one opinion however. While I applaud your efforts to make it completely backwards compatible with existing skins, I don't think that is completely necessary.

If you take the basic functionality of how skins work then I think you've accomplished your goals. Trying to make it compatible with existing skins will almost be impossible seeing as each person has a different naming convention and heirarchy scheme.

I think being able to change the property of buttons is good enough in most cases. Case and point is the popularity of the ContourHC. No graphics, just a nice clean and very attractive interface.

After you've established a good skinning tool then others will hopefully adapt to its conventions as long as it's not too restricting - but you've already considered that. After that those who wish to can modify the code much more readily to add more advanced options.

Can't wait for this tool...it'll really take GBPVR to the next level!
gruskada
Offline

Member

Posts: 121
Threads: 20
Joined: Dec 2005
#24
2006-01-26, 09:52 PM
jam_zhou Wrote:I think being able to change the property of buttons is good enough in most cases. Case and point is the popularity of the ContourHC. No graphics, just a nice clean and very attractive interface.

Totally agree on this, but it would be nice to be able to support extra plugins (at least in a future release). I was thinking - perhaps we can support Appearance Manager's standards, and therefore any plugin that supports that (if it works out that way). If it's not that simple, I hope you're right that people will modify the code to add more advanced stuff. I think putting the project out on SourceForge would go along way to help that process...

gruskada
gruskada
Offline

Member

Posts: 121
Threads: 20
Joined: Dec 2005
#25
2006-01-27, 02:47 PM
I've been really thinking this through, looking through plugin source code and XML files, and I think concerning plugins, we really need to support an expandable interface out of the box.

Even the base plugins have a wide range of SpecialElements, and I don't want to have to totally hardcode how to handle all of them (and all future changes to them) into SkinTools.

All we should need is the folder name for the plugin, and an array of "Displayable Special Elements" that contains their name, location, and size. Location and size can be completely dynamic.

In pseudocode (example using "Main Menu" base plugin - Buttons special element), here's part of what I'm thinking, as far as the "plugin plugin" meta information dll:

Code:
[displayable special elements array - should be a multidimensional array to be able to combine all elements and their attributes?]
name = buttons;
loc = 50,72;
size = buttonSize();
custom = customCode();

int[] buttonSize() {
  if(SpecialElements.ButtonType == "Horizontal") {
    return NormalButtonImageSize.Height + spacing, (NormalButtonImageSize.Width * Buttons.Count) + spacing;
  } else {
    return (NormalButtonImageSize.Height * Buttons.Count) + spacing, NormalButtonImageSize.Height + spacing;
  }
}

customCode() {
  //also display the left and right OR up and down buttons
}

-----------

We'll have to code this stuff in one way or another - might as well make it flexable.

I'd really like to hear thoughts from plugin developers on this.

gruskada
McBainUK
Offline

Posting Freak

Posts: 4,711
Threads: 429
Joined: Sep 2005
#26
2006-01-27, 03:12 PM
What kind of data do you need returned?

A special element is really just a locator for a composite image. Lists complicate it tho by using multiple images.
Wiki profile
My Projects
Programs Plugin [SIZE=2](retired)
| Volume OSD Plugin (retired) | Documentation Wiki (retired)
[/SIZE]
McBainUK
Offline

Posting Freak

Posts: 4,711
Threads: 429
Joined: Sep 2005
#27
2006-01-27, 03:13 PM
gruskada Wrote:I don't want to have to totally hardcode how to handle all of them.

All we should need is the folder name for the plugin, and an array of "Displayable Special Elements" that contains their name, location, and size. Location and size can be completely dynamic.
What is this data used for?
Wiki profile
My Projects
Programs Plugin [SIZE=2](retired)
| Volume OSD Plugin (retired) | Documentation Wiki (retired)
[/SIZE]
gruskada
Offline

Member

Posts: 121
Threads: 20
Joined: Dec 2005
#28
2006-01-27, 03:44 PM (This post was last modified: 2006-01-27, 03:52 PM by gruskada.)
McBainUK Wrote:What kind of data do you need returned?

A special element is really just a locator for a composite image. Lists complicate it tho by using multiple images.

In the case of the Buttons special element, it gives instructions on how exactly to display the buttons (i.e. horizontal/vertical, spacing between buttons). We can't just let skin developers put buttons anywhere they want (I don't think). It also needs to know where to display the left and right or up and down arrows. And it needs to know how to pull in and process other tags, like <SpecialElement name="MenuType" type="GBPVR.HorizontalMenuTask" />. So it's a locator, but it does a bit more that relates to the display.

I've really just looked at Main Menu in depth so far, though. Perhaps this is a rare special case?

gruskada
gruskada
Offline

Member

Posts: 121
Threads: 20
Joined: Dec 2005
#29
2006-01-27, 03:49 PM (This post was last modified: 2006-01-27, 04:33 PM by gruskada.)
McBainUK Wrote:What is this data used for?

It would be parsed to display special elements that don't have a size and/or location that's derived from code rather than explicitly set. For example, the "Buttons" special element doesn't have a size - it's determined by figuring out the size of the buttons with spacing included.

Then you've got things like these that we need to know how to handle:

(from "Recordings"):
Code:
<!-- the following are used by the recording details popup -->
<SpecialElement name="ManualRecordingControls" loc="65,150" size="120,40" spacing="10" />

SkinTools needs to know not to display all of these at once, and needs to know what to group it with. There's nothing in the XML file that says specifically how to handle these except for the comment. So this is really another issue that needs to be in the plugin meta information. I'm not really sure how to handle this - perhaps have a "group" and "group type" setting, where you can define what tags go with what groups. "Group type" would be something like "Popup" or "Alternate View"?

Actually, I wonder if it would be possible to just drop the plugin's .dll file in SkinTools, limit the plugin's functionality to just displaying things, and just catch exceptions that we can't handle (i.e. when the plugin actually tries to do something...)?

gruskada
McBainUK
Offline

Posting Freak

Posts: 4,711
Threads: 429
Joined: Sep 2005
#30
2006-01-27, 04:28 PM
The main menu I think might be a special case.

Skins talking to plugins and visa versa is always problematic. Maybe skintools could concentrate on manageging the creation of a skin, and leave the preview to using gbpvr itsleft. You could always have a preview of each composite image?
Wiki profile
My Projects
Programs Plugin [SIZE=2](retired)
| Volume OSD Plugin (retired) | Documentation Wiki (retired)
[/SIZE]
« Next Oldest | Next Newest »

Users browsing this thread: 1 Guest(s)

Pages (5): « Previous 1 2 3 4 5 Next »


Possibly Related Threads…
Thread Author Replies Views Last Post
  GBPVRUiElement loose its alpha herrmannj 3 1,561 2008-11-11, 05:13 PM
Last Post: sub
  Color Alpha / Transparency JoeGuy22 4 1,669 2006-12-22, 07:52 PM
Last Post: JoeGuy22
  Wanted: Comskip alpha tester in USA/Canada erik 1 1,221 2005-09-01, 03:49 PM
Last Post: GoodGuys
  My Pictures 3 alpha reven 110 24,463 2005-08-21, 12:46 PM
Last Post: tieke
  New Plugin: Email Reader (Alpha preview) Remco 36 10,572 2005-04-21, 09:30 PM
Last Post: joecru
  New weather plugin alpha CodeMonkey 59 17,957 2004-04-16, 09:45 AM
Last Post: CodeMonkey

  • View a Printable Version
  • Subscribe to this thread
Forum Jump:

© Designed by D&D, modified by NextPVR - Powered by MyBB

Linear Mode
Threaded Mode