"Chris Griffiths" wrote:
> I was able to draw directly to the screen with a blank screen as the
> canvas but I thought it'd be cool for it to be customizable - and I
> wasn't sure how resizing/scaling would work if I created the screen this
> way.
You get the x0,y0,x1,y1 values when you draw. You need to resize
yourself.
> For example, the forecast that mythweather uses is a 5 day forecast, but
> only 3 days are shown - if it was skinnable you could pick and choose
> (not to mention use matching fonts etc).
>
> In an ideal world, the weather plugin would present itself as type
> "weather" and give the skin with a list of info, i.e.
> Current Temp
> Windchill Temp
> Windspeed
> Wind direction
> ...
> ...
> Forecast Day 1 ...
> Dopler map url
>
> and then the skin would contain a definition <weather></weather> which
> held screen layouts and what to show (and what to ignore).
>
> It seems that all this is possible, but a fair ammount of code changes
> have to be made before declaring a plugin as skin type "weather" and the
> weather definition in the xml skin file can associate with one another.
>
> Is there a reason why all the code is required - it seems an ideal
> situation would be to declare the requested skin type and that would be
> the end of it.
Welcome to a plugin limitation ;-)
All who know the skin code, please read so I can fix it without
overlooking a bug in my idea.
To include a <weather> tag, we would have two major problems. First of
all, our fxd files don't contain a <weather> tag. Let's say we don't
include your plugin in Freevo and it is an external plugin (this is
the most difficult case, we should discuss it for future plugins).
Freevo doesn't know about the external plugin, so our skins won't
contain a <weather> tag. Other external skins may do that. So you need
to provide a part of a fxd file which will be added to each
skin. E.g. you include a fxd with the <weather> tag and the needed
areas, font definitions, etc. to share/skins/addons/ (main/plugins
maybe).
So the skin would load a) everything in addons b) the selected skin
and it's deps c) local_skin.fxd.
That was the easy part. If you look into the skin code, "menu",
"player" and "tv" are hardcoded. You can't add a new type like
"weather". How should the skin know which areas "weather" needs?
So a plugin has to register a new type with a list of areas. To make
it more complicated, a plugin may use two areas: an area for a small
menu and a area with some content. To avoid rewriting stuff, the
author want's to use the current ListingArea code. The other area is
personal, the plugin needs to register an area object the skin uses.
Example:
class MyArea(plugin.Area):
...
skin.register('weather', ('listing', MyArea()))
So a string means an area the skin code knows about (listing), an
object means this object. Maybe a handler object to parse the drawing
item is also needed, I don't know yet.
So what to do now? First, I would like to remove the 'player' and 'tv'
specific stuff from the skin code (only the 'if's) and let the two
types register themself.
skin.register('player', ('info', 'image', 'title'))
skin.register('tv', ('info', 'title', 'subtitle',
('tvlisting_area', 'TVListing_Area')))
The last tuple means: take TVListing_Area from from your skin module
tvlisting_area.
After that, I would like to add the fxd part with an example plugin
that uses a listing area and something on it's own. This could take
same time until it's finished.
Comments? Did I miss something? Does it makes sense?
Dischi
--
A tree never hits an automobile except in self-defence.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
