Upcoming UI changes for UNR: Customizing Yelp's Home Page

[Kyle Nitzsche]

Just pointing out that coupling the content with the (yelp) viewer 
imposes real restrictions. For example, how can karmic UNR fork yelp to 
point to UNR Help Center when that same yelp is used in karmic to point 
(hard coded) to Ubuntu Help Center (unless changes are made to read the 
target from gconf or somewhere).

Given the increasing numbers of distros/images/flavors that consume help 
content, I think it makes sense to consider a model like this:
 * single-sourced content that supports inclusion methods (like xinclude 
and Mallard)
 * converted into multiple delivery formats (x/html, pdf, etc.) (at 
build time... ?)
 * displayed by arbitrary viewers

I think it makes sense to start considering completely uncoupling 
content from the viewer. Otherwise it is too monolithic.

Cheers,
Kyle

Shaun McCance wrote:
> On Wed, 2009-09-16 at 15:22 +0100, Phil Bull wrote:
>   
>> Hi Shaun,
>>
>> On Tue, 2009-09-15 at 18:01 -0500, Shaun McCance wrote:
>>     
>>> The single most compelling feature of Mallard is that you can
>>> drop pages into a document and have links to them appear from
>>> other pages in the document.  I don't see how we can possibly
>>> do this without any run-time processing.
>>>       
>> This can't be done at build time, but it could be done at install time
>> if pages are only expected to be changed/added when packages are
>> installed or updated. The package manager could just call a handler
>> which rebuilds the relevant part of the HTML cache once it's finished
>> installing packages.
>>
>> Otherwise, something involving inotify could work.
>>     
>
> It's possible.  You don't want the HTML files to be shipped
> by (and thus owned by) any package, since rewriting a file
> belonging to a package is bad news.  So this would be some
> sort of post-install hook to generate an HTML cache.
>
> This really does limit my ability to improve things in Yelp,
> since rendering changes would then have to be done in the
> pregeneration tool, and that would have to be run against
> all installed documents.  And it makes it considerably more
> difficult for us to pick up locally overridden files in
> XDG_DATA_HOME, e.g. in response to web updates.
>
> (Yes, I'm talking about features we don't have yet.  But
> these are features the documentation team has been talking
> about for years, and I designed Mallard to support them.)
>
>   
>>> The performance issues in Yelp are, by and large, not a result
>>> of the XSLT.  They're mostly a result of excessive or poorly
>>> executed disk access.  If anybody wants to talk about this,
>>> the correct place to do it would be upstream.
>>>       
>> It would be good to take a look at this. Should we discuss on
>> gnome-doc-list?
>>     
>
> Technical nitty-gritty should go on gnome-doc-devel-list.
> I don't use it much these days, because I'm the only one
> hacking on things right now, and I don't like talking to
> myself. ;-)
>
> --
> Shaun
>
>
>