Date: prev next · Thread: first prev next last
April 2015 Archives by date, by thread · List index


https://bugs.documentfoundation.org/show_bug.cgi?id=90374

--- Comment #8 from Jay Philips <philipz85@hotmail.com> ---
Created attachment 115094
  --> https://bugs.documentfoundation.org/attachment.cgi?id=115094&action=edit
sidebar tabs cropped

(In reply to V Stuart Foote from comment #7)
Created attachment 115092 [details]
indicator when drag resizing Deck is about to collapse closed

Behavior now is that while we drag the Deck's width narrower at a point the
GUI switches to a close action for the Deck--a Right pointing arrow
appears--and release of the drag colapses the deck.

That behaviour doesnt happen for the Properties or Manage Changes tabs.

This complements action of a click on the current Tabbar button which
collapses the deck for the current content panel(s), or if a different
Tabbar button will toggle the Deck to that tab's content panels(s).

Dont forget the 'X' button in the title bar. :D

The full collapse of the Deck with a click on its Tabbar button seems
correct UI/UX.

A drag resize to minimum size -> then collapse (looks to transition when
last widget of the specific content panel(s) open has been obscured) also
seems correct -- reopening of deck to that same content panel opens it to a
"minimum width", for that content panel. And changing the Deck to one of the
other Content panel(s) with a Tabbar click retains the prior "minimum width".

Is there a point to be able to shrinking down the width of a tab so that the
controls start to disappear, similar to the attached image.

The Navigator and Manage Changes content panels seem to incorrectly not
allow resize of the deck to point of colapse, but they do honor the "minimum
width" if set from another content panel active in the Deck.

I was able to resize Navigator to the point of collapse. I find the resize of
the deck to point of collapse to be quite useless. Other office suites that
implement sidebars dont have such functionality (calligra, iworks,
wps/kingsoft).

All that being said, the current configuration of allowing both a "minimum
width" (e.g. last fully exposed widget) prior to collapse of the Deck, and a
"maximum width" independently for each Content panel continues to make
sense. Especially if we are able to improve function of the Sidebar with
per-user customization of bug 67770, and the other issues of comment 1.

So NO, would not agree to a single minimum width applied to Decks of "all"
content panels--but that said, there is room to improve how each decks
minimum width (prior to collapse) is determined.

So you wouldnt agree to a single minimum width for all but you'd agree to
having independent minimum widths per deck, right?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.