Hi Cedric,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 14, 2012 at 10:44 AM, Cedric Bosdonnat <span dir="ltr"><<a href="mailto:cbosdonnat@suse.com" target="_blank">cbosdonnat@suse.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Mirek, Olivier,<br>
<div class="im"><br>
On Thu, 2012-12-13 at 18:40 +0100, Mirek M. wrote:<br>
> The original idea was to not have a static size for the overlay, but<br>
> rather have its size detemined by its contents, in the same way it<br>
> works on Android (and as was designed for our Android port), and<br>
> similar also to iOS/new Mac OS X behavior.<br>
<br>
</div>Doh! I broke it completely ;) The is no overlay anymore. Honestly, this<br>
wouldn't fit most templates repositories (starting with<br>
<a href="http://templates.libreoffice.org" target="_blank">templates.libreoffice.org</a>) which have pyramidal folders structure.<br>
<br>
Of course I implemented the path idea as well. The other good thing for<br>
me is that it's way easier not to paint the overlay with shadow,<br>
transparency and so on.<br></blockquote><div><br></div><div>A border would have sufficed, no transparency needed, really. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im"><br>
> Again, here the idea was to be consistent with the Android port.<br>
> It was imagined that there would only be one level of hierarchy (as is<br>
> standard on Android and iOS), as it makes browsing templates much<br>
> simpler and will be necessary if/when there is sync functionality<br>
> between Android and desktop LibreOffice.<br>
><br>
><br>
> Thus, a path bar would be largely unnecessary, as it would only show a<br>
> single item. Also, there would no longer be an easy way to rename a<br>
> folder (at least, if it acted like a traditional path bar).<br>
<br>
</div>I'm about to change the whole implementation to have it support several<br>
levels. The restriction for the templates storage is on the templates<br>
management class from LibreOffice (already there before), but at least<br>
we'll be able to handle all remote repositories without problem.<br>
<div class="im"><br>
> (In general, if in doubt, look at the Android 3.0+ implementation, or<br>
> at least Apple's Document Library implementation [1].)<br>
<br>
</div>As I already told you... we still have a huge amount of desktop users to<br>
take care of.<br></blockquote><div><br></div><div>As I keep reiterating, the proposed UI is desktop-oriented.</div><div>Apple's Document Library is also desktop-oriented (in fact, it's desktop-only), and it has similar characteristics. Have you at least read the link [1] I posted?</div>
<div><br></div><div>Anyway, I can't say I'm happy about the changes, but I can understand how it is tricky to create a good folder overlay implementation and how a single-level hierarchy might conflict with what we have now (though I'm still convinced it will need to change if we want a good UX).</div>
<div><br></div><div>[1] <a href="http://informationarchitects.net/blog/mountain-lions-new-file-system/">http://informationarchitects.net/blog/mountain-lions-new-file-system/</a></div></div></div>