bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Making Bloodhound's layout responsive [ticket #217]
Date Thu, 04 Oct 2012 17:29:45 GMT
On 10/4/12, Gary Martin <> wrote:
> On 03/10/12 19:06, Olemis Lang wrote:
>> On 10/3/12, Joachim Dreimann <> wrote:
>>> My suggestion is to enable it using an opt-in mechanism in the Admin
>>> settings of any Bloodhound deployment, showing a clear 'Responsive
>>> layout
>>> beta' banner at the top of pages where the responsive stylesheet is in
>>> use.
>> There's a suggestion about how this could be done ... **IF** a generic
>> translation is possible at stream filters level .
> If we are trying to get to something close to the wide view in the
> pre-responsive layout considerations, I am not sure that we need much
> extra at the stream filters level. For the purposes of responsiveness
> (that is dynamically responding to changes in width), would it be better
> for this to be handled in js and css? I could of course be
> misunderstanding your point.

I don't know whether there's a misunderstanding . I was thinking of
using fluid layout (rather than current fixed layout) if responsive
features are enabled . That's what stream filter would be for. Besides
it could help with including responsive CSS classes in elements
initially found in non-responsive layout. Of course we could write
different Genshi templates for responsive layouts

> I wonder how much of a need there will be for opt-in and beta banners
> for this as well but I look forward to finding out.

IMO it's ok as long as we dedicate some effort to improve significant
features we decide to incorporate .

GMail is a beta release ... so ...

>>> Responsive Ticket view
>>> mockup<>
> Is there a place for reply and edit buttons on comments (assuming that
> these are still required).

afaicr they should be hidden by default . Nonetheless I've been
thinking about this and the classes used in the patch submitted for
#182 only consider screen size . Nonetheless touchscreen devices
having big dimensions exist . In those cases the same problem will
happen and it will be hard (impossible?) to see reply/edit buttons .

> I can imagine that some kind of click event
> could bring up a small context menu for these if space is at a premium
> but I am not sure that would work well on touch screen devices.

something like a dropdown ? e.g.

Actions ↓
| Edit      |
| Reply     |



Blog ES:
Blog EN:

Featured article:

View raw message