Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of matevzb@gmail.com designates
 74.125.83.52 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: #217 - Make Bloodhound's layout responsive
From: =?utf-8?Q?Matev=C5=BE_Brada=C4=8D?= <matevzb@gmail.com>
In-Reply-To: 
 <CA+DjKZc5yxu=SuGEzMORWGo3meMKqy+fN+2yxKhfN3ccQhxQnw@mail.gmail.com>
Date: Mon, 4 Feb 2013 16:30:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4160653D-E7FD-4074-881B-3D64F9A71F7A@gmail.com>
References: 
 <CA+DjKZdPyC641u0FeRXFw-ff2XJ4hsPMDKVTwweHor2yrGT70Q@mail.gmail.com>
 <CAKoya92Q14eTRbTapK8KKH8gae-gqrndbevSp8jXUe1t4JQTQQ@mail.gmail.com>
 <CA+DjKZfur1qbiwHcw6Bib1kx4XeNkNP7M1=PqD0AWab=iUZQ6A@mail.gmail.com>
 <CA+DjKZc5yxu=SuGEzMORWGo3meMKqy+fN+2yxKhfN3ccQhxQnw@mail.gmail.com>
To: bloodhound-dev@incubator.apache.org

Hi,

I attached a new patch to the ticket, synced with the latest trunk =
changes (mostly
with regards to in-place ticket editing). The changes are still a bit =
rough around
the edges (especially the phone layout), those will be dealt with in the =
near future.
Please review the patch, and if there are no major issues found, I'll =
commit the changes
in a day or two.

Once the changes are committed, I think we should first focus on fixing =
the ticket UI
by continuing the discussions in other threads (Andrej, Tom) and =
consolidate the proposals.

--
matevz


On 29. Dec, 2012, at 22:04, Matevz Bradac wrote:

> Hi,
>=20
> 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:
>  [bloodhound]
>  responsive_layout =3D 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.).
>=20
> Additionally the patch also contains the small html5 doctype fix for
> trac, which was posted on the
> devlist a while back.
>=20
> And last but not least, happy holidays to everyone. =3D)
>=20
> --
> matevz
>=20
>=20
> On Thu, Dec 20, 2012 at 9:20 PM, Matevz Bradac <matevzb@gmail.com> =
wrote:
>> On Thu, Dec 20, 2012 at 4:12 PM, Joachim Dreimann
>> <joachim.dreimann@wandisco.com> wrote:
>>> *Regarding point 1:* Bootstrap is making responsive styles =
non-optional in
>>> the next release:
>>>=20
>>> "*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."
>>> https://github.com/twitter/bootstrap/pull/6342
>>>=20
>>> 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=3D"viewport" content=3D"width=3Ddevice-width,
>>> initial-scale=3D1.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.
>>=20
>>>=20
>>> *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.
>>=20
>> Thanks,
>> --
>> matevz
>>=20
>>>=20
>>> Cheers,
>>> Joe
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 19 December 2012 19:59, Matevz Bradac <matevzb@gmail.com> wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> 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:
>>>>=20
>>>> 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?
>>>>=20
>>>> 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?)
>>>>=20
>>>> Cheers,
>>>> matevz
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Joe Dreimann
>>> UX Designer | WANdisco <http://www.wandisco.com/>
>>> *
>>> *
>>> *Transform your software development department. Register for a free =
SVN
>>> HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *