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.