[mythtv] Seeking comments on new method of customizing Myth menus

[Joseph A. Caputo]

On Fri, 8 Oct 2004 13:52:30 -0400
Isaac Richards <ijr at po.cwru.edu> wrote:

> On Friday 08 October 2004 01:05 pm, Joseph A. Caputo wrote:
> > I haven't addressed the technical details here, just giving the
> > basic idea to see if this is a modification that would be accepted
> > (Isaac?). Note that the existing menu structure wouldn't need to be
> > changed, with the exception that a unique name attribute must be
> > given to each existing button.
> 
> Sounds like it'd work well, to me.

Great.

So now I'm looking at performance vs. memory usage.  Right now, if I
read things correctly, the XML file for a menu is re-read each time the
menu is encountered, whether the user is descending into or escaping out
of the menu tree.  This probably works OK for the case we have now where
1 menu == exactly one XML file.  Under the proposed scheme, it could
quickly become inefficient to locate and parse an arbitrary number of
individual XML files in addition to the menu's 'main' file.  However, it
also probably doesn't make sense to eat up memory by keeping every menu
in memory.  Here's what I've thought up; please let me know if this idea
makes sense:

- the supplemental menu control files will be parsed the first time a
menu is loaded (usually at startup).  Controls will be placed into a
resident QMap with the control name as the key.  Subsequently, each
time a menu is loaded we need only check the timestamp on the file(s) to
see if the control files need to be reloaded, or if any control files
were added/deleted.

- the main menu XML files will be parsed when first encountered and
maintained in a QCache with a relatively low maxCost (like 3 or 4, or
even 2).  After the menu is parsed, the QMap of controls will be
searched for additions/deletions/overrides.  Each subsequent time the
menu is encountered, if it is still in the cache we need only check the
timestamp on its file; otherwise we read it in again just as before.

I see this as a middle-of-the-road approach.  I could make it lean one
way or another -- either keep everything memory resident (faster?), or
don't keep anything in memory and find/read all the necessary files each
time a menu is requested, as we do now.

The reason I choose here to have the individually-specified controls
remain resident is because there may be any number of controls specified
in this manner, all of which must be parsed to determine if they apply
to the current menu, even though none of them may be relevant.  Keeping
a QMap in memory seemed like a decent way to avoid lots of redundant
file I/O and XML parsing.

Any preferences/comments?

-JAC