Hi all,
Heiko Tietze schrieb am 09.04.2018 um 16:48:
On 09.04.2018 14:58, Regina Henschel wrote:
I have written a more detailed report on
https://wiki.documentfoundation.org/Hackfest/Hamburg2018/Make_drawing_layers_ODF_conform
#2,3: Why do you want to have layers in master? Complicates things only for no good reason.
That is not about "master view" vs "normal view", but about the elements
<style:master-page> and <draw:page>. Both of them can have a
<draw:layer-set> element in ODF. If such layer-set does not exist, the
default layer-set of the <office:master-styles> element is used.
Currently LibreOffice cannot handle layer-sets from <draw:page> or
<style:master-page>, so LibreOffice always uses the default layer-set.
Currently this looks for example like this:
<office:master-styles>
<draw:layer-set>
<draw:layer draw:name="layout"/>
<draw:layer draw:name="background"/>
<draw:layer draw:name="backgroundobjects"/>
<draw:layer draw:name="controls"/>
<draw:layer draw:name="measurelines"/>
<draw:layer draw:name="mylayer"/>
</draw:layer-set>
<style:master-page
style:name="myPink"
style:page-layout-name="PM0"
draw:style-name="Mdp1"/>
</office:master-styles>
In this example you see the currently automatically generated layers
"layout", "background", "backgroundobjects", "controls", "measurelines"
and a user generated layer "mylayer".
From point of UI in LibreOffice the layers "layout", "controls",
"measurelines" and "mylayer" belong to the normal-view, the layer
"backgroundobjects" belongs to the "master-view". The role of layer
"background" is not clear yet, Armin will investigate that.
From the point of file format, there is no difference between these
layers. Only LibreOffice makes a difference, depending on the name of
the layer and shows the layer in the tab bar or not. Currently the tab
of the layer "backgroundobjects" is hidden from the tab-bar in
"normal-view" and the other way round in "master-view".
If you add a layer in the "master-view" (that is possible, try it out!)
the behavior is odd.
#8: Discussion in extra thread
#9..#12: +1 to remove special layers (will put it on the agenda for Wednesday)
#13: Not clear to me how the z-Order works; design and view mode must not differ
A form control consists of two parts, one is e.g. a <form:button>
element, which describes the behavior of the button, and a
<draw:control> element, which describes the geometry of the element.
That is, where you will work on in design mode.
In design mode ON a form control behaves like a ordinary shape. But in
design mode OFF the form control is a window and not a shape. And being
a window it is always in front of ordinary shapes.
Your demand "design and view mode must not differ" is currently handled
in the way, that elements on the "controls" layer always have a z-order,
which brings them before other elements. That is regardless of being a
shape or a control.
I don't know, how difficult it is to distinguish a form control from a
shape in design mode ON state. If it is not hard, then it might be
possible to bind the special behavior to the kind of object instead
binding it to the name of the layer in case of form-controls. That way
form-controls could be always in front. But I need to ask Armin about
that. I have added a remark about this to the Wiki page.
#14: Disagree, and would ask for more opinions. My arguments are in
https://bugs.documentfoundation.org/show_bug.cgi?id=90320#c4, though Stuart's compromise is probably the best
solution (option "View single layer tabs", on by default).
Would be good to outline some use cases like
"Eve uses layers to have a fix background and several foreground that she switches on/off to address
different clients."
Use case: Benjamin wants to make a simple greeting card. He never heard
about layer because he normally works in Impress.
My suggestion is not hiding generally, but only if it has one tab.
I have added a note about the issue to the Wiki page.
(Or as a scenario with more text; when developing from top of the cathedral those use cases would
be taken into requirements, milestones (or MVP), and test cases. The latter are of particular
interest for the product, the other in respect to project/time management.)
We have drafted some in
https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/
Perhaps that makes some things clearer. Notice that the report has a lot of "Ask UX" items.
Do you prefer, that I write an issue for each of it? Or do you want to discuss it here on the list?
General discussion to the ML, everything else to BZ, which in general the better place as we have
more transparency there. You could take the existing issues or create meaningful buckets that can
be resolved individually.
OK.
Kind regards
Regina
--
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
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.