[libreoffice-design] Re: ODF spec for hiding a shape or group

[Yousuf 'Jay' Philips]

On 07/31/2016 11:11 PM, Jos van den Oever wrote:

On Sunday 31 July 2016 18:47:22 Yousuf 'Jay' Philips wrote:

On 07/31/2016 03:23 PM, Jos van den Oever wrote:

Hello Yousuf,


Hi Jos,


I read your document. You say

 "ODF ...handles layers differently from other tools."

and give Inkscape as an example. Inkscape does not have layers, just
.

ODF defines the word layer to mean one thing, while other apps define it
to mean something different. That is what is intended to get across. For
example, GIMP has layers for text and bitmap, while ODF would calls
these objects and not layers.


The distinction between layer and group is something a user has to learn. It
helps if the application behaviour is close the file format. That saves on
translation between internal model and file format.


The concept of what ODF defines as a layer or group isnt something most 
users will comprehend as its a foreign concept that no other app 
implements and a concept not possible to conveniently show in a layering 
tree.


> If all ODF supporting

applications do this, it also makes behavior more similar.


If ODF supporting apps have to support both what ODF defines as a layer 
and group and what other formats define them as, unfortunately these 
apps will likely stick with what the other formats define, which is what 
karbon and flow have done. I would assume the best way to deal with this 
complication is for ODF supporting software to have two layering modes 
that handle specific formats, as the standard layering concept can be 
saved to ODF, but ODF layering cant be saved back.



You discuss Krita. For vector graphics, you can also look at Karbon which
can open and save odg files. Unfortunately, I just saw a bug there:
Karbon does not respect the z-index when objects are in layers.
https://bugs.kde.org/show_bug.cgi?id=366297


Krita wasnt discussed, just screenshots were taken from it. Yes heiko
and i tried out calligra karbon today and i tried out calligra flow
yesterday. Both apps do the same with objects being limited to a maximum
z-index defined by the layering of the layers.


I'd say that that is a bug and I've reported it as such. Currently when
loading/saving an LO file with Karbon would lose information.


Yes i guessed that any app using the standard layering would have the 
same problem of loading ODF layering, but there is a workaround that 
could be done to still maintain the correct layering to some degree, 
though it wouldnt work for groups across layers.



BTW similarly a file with layers in created in Karbon is not read properly by
LO Draw: the layers are discarded.


Yes i've reported the issue as i noticed the same and it comes down to 
LO not supporting  as a child element of .


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


Karbon has a convenient layer view where you can toggle visibility and
editability of layers.


We will be implementing the visibility and editability toggles as well
with our redesign.


Cool. That will fix most UI issues I'm sure.


Layers do not influence the z-index. This gives flexibility. A UI might
still offer to increase or decrease the z-index for all objects in a
layer.

There isnt a convenient means that i can think of that can show a
stackable tree view if object z-orders can cross layer boundaries. This
is something we've been wrangling with for a few weeks when discussing
the proposal and likely why karbon and flow have decided to limit users
ability to have objects cross z-orders of other layer objects.


3D view would help but it's quite some work to implement. Mozilla has a 3d
view for web pages.
What might help is the give objects that belong to a layer a shine when you
hover the layer in the layer list.


Dont think that would help much, especially when you have a long layer 
list. We've gone with the idea to include the layer name after the shape 
name and/or in a tooltip.



But you can have a tree from the layer into the objects and allow changing the
z-index for the groups and the objects in the groups.


Likely this view is fine for advanced users who specifically want to use 
ODF's layering concept, but not something that the average user will.



The idea you have to let go is to enable z-index buttons for the layers. That
does not fit with the file format.


That is true, which is why our proposal is to hide layers in easy mode 
so regular users dont get confused by the concept.



You can have the hierarcy of Page/Slide > Layer > Group* > Object in the
navigator.


Unfortunately you cant as group isnt limited to a layer, so its possible 
to have a group with two objects from two different layers. It would be 
great if there was some text or mockup from ODF of a hierarchical view 
to demonstrate how it could look.



Why do you want to hide individual groups or shapes?


Because its a feature that individuals will use, i know i would, as i
use it all the time in gimp, photoshop and inkscape. Karbon and flow
have the same feature and 

[libreoffice-design] Improving Navigator in Draw proposal published

[Yousuf 'Jay' Philips]

Hi All,

For those who may not hear this from elsewhere, the proposal of 
reworking Navigator in Draw has been published on the design blog.


https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/

Enjoy the reading and please do comment. :D

Yousuf

--
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Re: Home for the breeze icon theme

[kainz.a]

Hi,

For your information uri inform me before he closed the repository and the
kde stuff on github wasn't up to date.

But yes in general the png files isn't useful for new contributions and the
origin file is the important stuff. You wouldn't save exe files. The cpp
files are the needed.

Thanks for upload the files.
Andreas kainz

Am 31.07.2016 15:09 schrieb "Yousuf 'Jay' Philips" :

> Hi all,
>
> Andreas informed me that the github repo that was hosting LO's breeze icon
> theme, as well as all the breeze icons for kde, has been removed and he
> asked where can the breeze svgs be hosted. I've uploaded the SVGs to the
> core repo under /icon-themes/breeze/svg/.
>
> https://gerrit.libreoffice.org/27750
>
> This incident has gotten me thinking of how secure are we with our sifr
> and tango icon themes on github.
>
> https://github.com/libodesign/icons
>
> Yousuf
>

-- 
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Home for the breeze icon theme

[Yousuf 'Jay' Philips]

Hi all,

Andreas informed me that the github repo that was hosting LO's breeze 
icon theme, as well as all the breeze icons for kde, has been removed 
and he asked where can the breeze svgs be hosted. I've uploaded the SVGs 
to the core repo under /icon-themes/breeze/svg/.


https://gerrit.libreoffice.org/27750

This incident has gotten me thinking of how secure are we with our sifr 
and tango icon themes on github.


https://github.com/libodesign/icons

Yousuf

--
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted