I had a feeling it wasn't going to be easy ...

Your idea sounds good, although I dont know enough about the current
setup to offer anything constructive.

The main thing I guess is that there is no way to add a new "weather"
section without serious rework - it may get too complicated to have it
happen automagically as you've described, but even if the ammount of
changes to the core code could be minimized it would be a start.

I do like your idea of the 'tv' and 'player' just using generic
components - this makes is far easier to extend, allowing the reuse of
them very easily.

Thanks,
Chris


On Wed, 03 Dec 2003 11:05:10 +0100, "Dirk Meyer" <[EMAIL PROTECTED]> said:
> "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


-------------------------------------------------------
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

Reply via email to