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


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.