incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matevz Bradac <mate...@gmail.com>
Subject Re: #217 - Make Bloodhound's layout responsive
Date Thu, 20 Dec 2012 20:00:26 GMT
On Wed, Dec 19, 2012 at 10:50 PM, Olemis Lang <olemis@gmail.com> wrote:
> On 12/19/12, Matevz Bradac <matevzb@gmail.com> 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 .
>
Good catch, I missed this one. Are there any special considerations within
post_process_request(), before or after switching the template?

>> 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 .
>
I was also thinking about 2., but at that time it seemed there are
more structural
differences between the current layout and the mockup for this to work. It would
be much easier to have single templates and just switch CSS classes though,
so I'll recheck if the template code could be unified to a greater extent.

>> 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 .
I'll first prepare a proposal/patch and attach it to the ticket if that's okay.
This way others can also check if I'm barking up the wrong tree, and correct
me accordingly. =)

>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
Thanks for all the suggestions!

--
matevz

Mime
View raw message