[mythtv-commits] Ticket #4264: MythContext restructure

[MythTV]

#4264: MythContext restructure
--------------------+-------------------------------------------------------
 Reporter:  nigel   |        Owner:  nigel
     Type:  task    |       Status:  new  
 Priority:  minor   |    Milestone:  0.21 
Component:  mythtv  |      Version:  head 
 Severity:  medium  |   Resolution:       
  Mlocked:  0       |  
--------------------+-------------------------------------------------------

Old description:

> Some packagers are having problems building MythTV now that there is
> another circular dependency in the libraries. libmyth uses libmythupnp,
> which in turn depends on libmyth.
>
> There are some hacks to get past this, but the long-term solution is to
> remove this dependency (and the one between libmyth and libmythui).
>
> My current proposal is to put some of the gnarlier MythContextPrivate
> stuff into another myth library (''e.g.'' mythbase). This would pull in
> the MythContext code and the UPnP stuff, and be called from (linked
> against) the myth programs.

New description:

 Some packagers are having problems building MythTV now that there is
 another circular dependency in the libraries. libmyth uses libmythupnp,
 which in turn depends on libmyth.

 There are some hacks to get past this, but the long-term solution is to
 remove this dependency (and the one between libmyth and libmythui).

 My current proposal is to put some of the gnarlier !MythContextPrivate
 stuff into another myth library (''e.g.'' mythbase). This would pull in
 the !MythContext code and the UPnP stuff, and be called from (linked
 against) the myth programs.

--

Comment(by nigel):

 The circular dependencies have hopefully been worked around in [15478] and
 [15481]. That will give me more time to develop this some more (maybe add
 soon after 0.21). I am currently not happy with:
  1. !MythContext becoming an un-usable class (due to some pure virtual
 methods). It is unlikely that anyone would want to instantiate a
 !MythContext and then set the database stuff manually, but for a quick
 test program, it is feasible.
  2. The structure. Having it in libmythtv means that '''''everything'''''
 now depends on libmythtv instead of libmyth. That is maybe an unavoidable
 cost of having UPnP magic, and a UI for choosing a backend or editing the
 DB parameters, but there is maybe a better compromise?
  3. I could (should?) move all the GUI stuff into the sub-classes. A text
 program will never need to lookup the window size, so why should it be in
 the base !MythContext class?
  4. The initial bootstrapping UI could/should use libmythui.

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/4264#comment:8>
MythTV <http://svn.mythtv.org/trac>
MythTV