incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: #217 - Make Bloodhound's layout responsive
Date Wed, 19 Dec 2012 21:50:23 GMT
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 .

> 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:

Mime
View raw message