bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matevz Bradac <>
Subject Re: #217 - Make Bloodhound's layout responsive
Date Sat, 29 Dec 2012 21:04:40 GMT

I created the initial patch for responsive layout in the ticket view
and attached it to ticket #217.
The changes to the main template were kept to a minimum to not disrupt
other views, so there is no
need for switching to another template. There are still a couple of
things that need improvement in
the mobile views (e.g. the navbar, better positioning of some elements
etc.), those will be fixed
once the major changes have been integrated onto trunk. It also
contains a couple of small hacks
(activity feed title hiding, sticky shadow) which will be addressed as
soon as possible.
It's possible to "disable" the responsive layout by a setting in trac.ini:
  responsive_layout = false
Note that this only removes the viewport meta tag from the template,
as per Joe's suggestion.
The patch was tested in Chrome, FF and IE (all Windows), Safari (OS
X), iPad/iOS6 (multiple browsers)
and on an Android 4.0 phone. Hopefully I've covered most of the use
cases (logged in/out, admin etc.).

Additionally the patch also contains the small html5 doctype fix for
trac, which was posted on the
devlist a while back.

And last but not least, happy holidays to everyone. =)


On Thu, Dec 20, 2012 at 9:20 PM, Matevz Bradac <> wrote:
> On Thu, Dec 20, 2012 at 4:12 PM, Joachim Dreimann
> <> wrote:
>> *Regarding point 1:* Bootstrap is making responsive styles non-optional in
>> the next release:
>> "*Responsive CSS is no longer separate.* All responsive features are now
>> compiled into the core bootstrap.cssfile. Separate files are no longer
>> required, and have thus been removed."
>> There may be a very easy solution though: If viewport meta tag is missing,
>> at least iOS with retina screens (I tested this with an iPhone 4S, iOS 5 +
>> 6) shows the standard layout of pages and doesn't apply responsive css.
>> The tag is: <meta name="viewport" content="width=device-width,
>> initial-scale=1.0">
>> If this is also true for Android, we could just not add the meta tag to
>> pages to stop them from applying the responsive layout for smaller screens.
>> It's not pretty but it may work.
> My main concern was the difference in layout between the current template and
> the mockup. If the layout can be made generic enough, then this is definitely
> something to consider.
>> *Regarding point 2:* Yes, I can see that this may be an issue in the
>> future, but I can see other solutions for the specific case you raised. The
>> header of the activity macro that appears inside the sticky panel is
>> actually just the name at this point. What's in the right panel may be
>> different in other views too, such as the Wiki, Source or Custom Query
>> views. We need to come up with a way to refer to the name of that object in
>> the right panel as part of our documentation for 'Bloodhound-ready widgets'
>> anyway.
> Agreed. For this specific widget we could do a workaround for now, and
> perhaps extend the widgets in general should the need arise.
> Thanks,
> --
> matevz
>> Cheers,
>> Joe
>> On 19 December 2012 19:59, Matevz Bradac <> 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:
>>> 1. In the ticket there's a proposal for being able to turn this feature
>>> on/off,
>>> as it will impose significant changes on the layout, so some things may
>>> not work
>>> as expected right from the start. 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.
>>> 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?
>>> 2. Handling of widget macros: when using widget macros, each widget is a
>>> more or
>>> less self-contained entity. 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?)
>>> Cheers,
>>> matevz
>> --
>> Joe Dreimann
>> UX Designer | WANdisco <>
>> *
>> *
>> *Transform your software development department. Register for a free SVN
>> HealthCheck <> *

View raw message