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+unsubscr...@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

Reply via email to