On 12/19/12, Matevz Bradac <[email protected]> wrote: > Hi, > :)
> I started implementing the responsive layout functionality, for which Joe > had > created a mockup in #240. There are a couple of issues to be resolved, any > suggestions are appreciated: > If you could share somehow what you've got , we could provide more concise feedback and suggestions ... these might be useful to hack, break and develop patches at will mercurial mirror @ bitbucket : https://bitbucket.org/olemis/bloodhound mercurial patch queue @ bitbucket : https://bitbucket.org/olemis/bloodhound-mq However I'll try to imagine what you did and reply accordingly , but beware of the fact that I might misunderstood something . [...] > > I've currently implemented this by having > two > types of templates (responsive- and old-style), and BloodhoundTheme's > __init__ > then checks for a specific trac.ini setting and switches to whatever is > set. If you are using options in trac.ini I suggest you to make that decision in theme's post_process_request instead because : 1. __init__ is invoked once @ component creation time 2. ... which means that even if trac.ini is edited the value will not be updated 3. that's what trac.config.Options descriptors are for : they transform values in config file into component's attribute and still watch for changes in trac.ini (... or alike ... ) to keep these up to date . > The problem I see here is that template content changes will have to be > synced > back and forth between both template types, i.e. any functional changes done > to > one template will have to be implemented in the other as well. I suppose > that > this is something we'd like to avoid, perhaps someone has a better > solution proposal? > well , the ways to go to avoid synching them both (i.e. no duplicated code) are : 1. to insert responsive CSS classes by filtering template streams . 2. to have a single template and use conditional statements (e.g. <py:if /> , <py:choose /> , <py:when /> , <py:strip /> , ${value1 if responsive else value2} ) checking for responsive var been set . > 2. Handling of widget macros: when using widget macros, each widget is a > more or > less self-contained entity. yes , they are by design ;) > Due to that certain layouts may be difficult to > implement without changing other functionality. For example in the mockup > ticket > view in #240, the ticket header and the activity header are both placed in > the > same sticky div. > But due to the activity feed being inserted as a > Timeline widget, > the separation of its header and data is not possible (without hacks). > (Or perhaps > I've interpreted the widget code incorrectly?) > yes , you are correct . This needs some improvements installed in widgets code . if you share your code @ bitbucket in a fork of olemis/bloodhound (in a new private branch referencing target ticket number , please) or as a patch in olemis/bloodhound-mq patch queue itself ( I'd grant you with appropriate permissions ;) I could work side-by side with you by reviewing everything in detail and improving timeline widget for all this transitions to happen smoothly . -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
