Re: [libreoffice-design] Re: Home for the breeze icon theme
On 08/01/2016 08:47 PM, Adolfo Jayme Barrientos wrote: > 2016-07-31 13:04 GMT-05:00 kainz.a : > I think you could maintain your own, separate GitHub repo, Andreas. It > doesn’t need to be “officially sanctioned by LibreOffice” =) Whether or not Breeze should be hosted at the LibreOffice Github is discussed at another thread I wrote this weekend (libreoffice@). Andreas wants to make the Breeze icons as much public and open source as possible. The fact that Uri was able to abandon the repo is a good argument for this approach. Jay added here the idea to take care of other icon sets as well. -- 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
Re: [libreoffice-design] Re: Home for the breeze icon theme
2016-07-31 13:04 GMT-05:00 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. I think you could maintain your own, separate GitHub repo, Andreas. It doesn’t need to be “officially sanctioned by LibreOffice” =) -- 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: ODF spec for hiding a shape or group
On 08/01/2016 01:41 PM, Jos van den Oever wrote: Good morning, Quite a puzzle, this topic. Had to rewrite my reply as I caught on to the thoughts you already put into it. Yes this is definitely a very confusing topic. :D On Monday 01 August 2016 09:14:40 Yousuf 'Jay' Philips wrote: On 07/31/2016 11:11 PM, Jos van den Oever wrote: 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. I get that now. You could perhaps show the layer name in a (optional) column. With the limited space in the tree list, dedicating a column to show the layer name wouldnt be a wise use of space, especially when layer and shape names can be long. 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. Indeed, looking at rendering order, an draw:layer is a group and a a draw:group is a layer. I think layers is a useful concept, but it does require a separate list from the navigator. I kind of like the current tabs in LO that show the layers. Toggle buttons for protection and visibility could go on the tabs. ODF layers and groups are interesting as a concept but seem to make things more complicated than they should be. I can see the point of layers being presented in horizontal tabs, as that best symbolizes that they dont affect z-order, though i'm not so sure that toggle buttons on tabs would work. Regarding z-index, what does it mean to change the z-index on a group if the objects in the group also have a z-index? This is not defined in ODF. Presumably, objects inherit z-index from a group but can override it. ODF says: "The draw:z-index attribute defines a rendering order for shapes in a document instance. Shapes are rendered in the order in which they appear in the document in the absence of this attribute." With my limited knowledge of ODF, groups dont have z-index only shapes do, so though you can pretend to move a group's z-index, you are actually moving the z-index of the shapes. In CSS, each element has it's own stacking order. So, no interleaving is possible unless the elements are interleaved. SVG has no z-index at all, only document order. So it's normal that Inkscape is simpler/less powerful in this regard. Not sure why CSS would be an example of a drawing format, so maybe you can clarify that. With SVG defining that document order is equivalent to z-index, it doesnt have to define an actual z-index value. This is no different than pages in a book or slides in a presentation. CSS and SVG are conceptually nice and simple. In ODF, a separate z-index based array is necessary to do efficient drawing. I believe efficient drawing can be done with a document order type z-index, as i would assume photoshop's psd format and illustrator's ai format follow this simple ordering. Even ODF states "Shapes are rendered in the order in which they appear in the document in the absence of this attribute." I'm not sure how many documents we'd break if we'd go for a the simple CSS z- index model. If it's not too many, we could make the specification language more precise and the same as CSS. 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. What is that workaround? So lets say we have 2 layers called Mobile and Tablet and we have 3 objects on these two layers called iPhone, Nexus and iPad, with the below ODF structure. [Layer] Mobile [Object] iPhone (z-index: 1) [Object] Nexus (z-index: 3) [Layer] Tablet [Object] iPad (z-index: 2) This could be processed into the standard layering system like so. [Layer] Mobile1 [Object] iPhone (z-index: 1) [Layer] Tablet [Object] iPad (z-index: 2) [Layer] Mobile2 [Object] Nexus (z-index: 3) So basically it breaks up layers when objects of a z-index reside within the objects on the layer. 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 Awesome to see the report and the discussion on it already. Does your test suite have test documents for layers, groups, and stuff and it would be good to test to find out what else LO doesnt support correctly. Dont think that would help much, especially when you have a long lay
Re: [libreoffice-design] Re: Home for the breeze icon theme
I thought it was possible to discriminate the Windows version to present a distinct icon set per version. Since Tango doesn't look native to Windows I think using another icon set with a more native feel would fit better, even for previous versions of Windows. For example, Office 13 and 16 also adopt a different design language than Aero but they don't look out of place in Windows 7. And barely anyone is using previous versions of Wnidows to 7 after the end-of-life for XP. I also think that Sifr looks better on MacOS than Breeze. A lot of work was done in these icon sets that look native in these two OSes. It is a waste not to put them front and center to the LibreOffice users on those OSes. Much like Tango is perfect for Gnome and Breeze also for KDE. On Mon, Aug 1, 2016 at 12:14 PM, Yousuf 'Jay' Philips wrote: > Hi Pedro, > > There is a bug report requesting the same thing (tdf#90194) and its > possible that Breeze fits well for windows 10 theme, but there are more > users on other versions of windows than windows 10, so i wouldnt be in > favour of it. > > http://gs.statcounter.com/#desktop-os-ww-monthly-201506-201606 > > Looking back, i think it was a mistake to move to Breeze on MacOS, > especially just after moving to Sifr by default in the previous version > after a survey confirmed that half of Mac users were switching to it. Some > of the problems I see with Breeze on Mac is that it blends badly with the > gradient background of the toolbar, though users who get LO from the > appstore dont have this problem as the toolbar is has a white background. > > https://youtu.be/lBWjBRPFdz0?t=31s > > > http://a4.mzstatic.com/us/r30/Purple7/v4/b1/85/37/b1853762-fa00-72e4-f672-f2d12117211d/screen800x500.jpeg > > Another problem is that Macs are primarily HiDPI and we dont have SVG > icons support in yet. > > Yousuf > > > On 08/01/2016 01:03 PM, Pedro Rosmaninho wrote: > >> This may be a bit off-topic, but couldn't the Breeze theme become the >> default theme in Windows 10? >> It fits a lot better with the design language of W10 than Tango (as KDE >> usually fits better with Windows than Gnome). And Breeze is already the >> default on MacOS... >> >> -- 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
Re: [libreoffice-design] Re: Home for the breeze icon theme
Hi, about the HiDPI support what's happen with it? I already add 32px icons but you can't use them in any LO version. 2016-08-01 13:14 GMT+02:00 Yousuf 'Jay' Philips : > Hi Pedro, > > There is a bug report requesting the same thing (tdf#90194) and its > possible that Breeze fits well for windows 10 theme, but there are more > users on other versions of windows than windows 10, so i wouldnt be in > favour of it. > > http://gs.statcounter.com/#desktop-os-ww-monthly-201506-201606 > > Looking back, i think it was a mistake to move to Breeze on MacOS, > especially just after moving to Sifr by default in the previous version > after a survey confirmed that half of Mac users were switching to it. Some > of the problems I see with Breeze on Mac is that it blends badly with the > gradient background of the toolbar, though users who get LO from the > appstore dont have this problem as the toolbar is has a white background. > > https://youtu.be/lBWjBRPFdz0?t=31s > > > http://a4.mzstatic.com/us/r30/Purple7/v4/b1/85/37/b1853762-fa00-72e4-f672-f2d12117211d/screen800x500.jpeg > > Another problem is that Macs are primarily HiDPI and we dont have SVG > icons support in yet. > > Yousuf > > > On 08/01/2016 01:03 PM, Pedro Rosmaninho wrote: > >> This may be a bit off-topic, but couldn't the Breeze theme become the >> default theme in Windows 10? >> It fits a lot better with the design language of W10 than Tango (as KDE >> usually fits better with Windows than Gnome). And Breeze is already the >> default on MacOS... >> >> -- 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
Re: [libreoffice-design] Re: Home for the breeze icon theme
Hi Pedro, There is a bug report requesting the same thing (tdf#90194) and its possible that Breeze fits well for windows 10 theme, but there are more users on other versions of windows than windows 10, so i wouldnt be in favour of it. http://gs.statcounter.com/#desktop-os-ww-monthly-201506-201606 Looking back, i think it was a mistake to move to Breeze on MacOS, especially just after moving to Sifr by default in the previous version after a survey confirmed that half of Mac users were switching to it. Some of the problems I see with Breeze on Mac is that it blends badly with the gradient background of the toolbar, though users who get LO from the appstore dont have this problem as the toolbar is has a white background. https://youtu.be/lBWjBRPFdz0?t=31s http://a4.mzstatic.com/us/r30/Purple7/v4/b1/85/37/b1853762-fa00-72e4-f672-f2d12117211d/screen800x500.jpeg Another problem is that Macs are primarily HiDPI and we dont have SVG icons support in yet. Yousuf On 08/01/2016 01:03 PM, Pedro Rosmaninho wrote: This may be a bit off-topic, but couldn't the Breeze theme become the default theme in Windows 10? It fits a lot better with the design language of W10 than Tango (as KDE usually fits better with Windows than Gnome). And Breeze is already the default on MacOS... -- 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: ODF spec for hiding a shape or group
2016-08-01 11:41 GMT+02:00 Jos van den Oever : > Indeed, looking at rendering order, an draw:layer is a group and a a > draw:group is a layer. > I think layers is a useful concept, but it does require a separate list from > the navigator. I kind of like the current tabs in LO that show the layers. > Toggle buttons for protection and visibility could go on the tabs. Way too much information to catch up in detail right now. In short: Normal users likely understand the page > layer > group > object relation as a strict hierarchical organization (as you describe for xml highlighting). The z-and t-order is seen as independent and complementary. We should not split the visualization into two or more views in order to deal with the underlying structure. This idea was discussed and has been discarded. All the best, Heiko -- 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: ODF spec for hiding a shape or group
Good morning, Quite a puzzle, this topic. Had to rewrite my reply as I caught on to the thoughts you already put into it. On Monday 01 August 2016 09:14:40 Yousuf 'Jay' Philips wrote: > 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. I get that now. You could perhaps show the layer name in a (optional) column. > > 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. Indeed, looking at rendering order, an draw:layer is a group and a a draw:group is a layer. I think layers is a useful concept, but it does require a separate list from the navigator. I kind of like the current tabs in LO that show the layers. Toggle buttons for protection and visibility could go on the tabs. Regarding z-index, what does it mean to change the z-index on a group if the objects in the group also have a z-index? This is not defined in ODF. Presumably, objects inherit z-index from a group but can override it. ODF says: "The draw:z-index attribute defines a rendering order for shapes in a document instance. Shapes are rendered in the order in which they appear in the document in the absence of this attribute." In CSS, each element has it's own stacking order. So, no interleaving is possible unless the elements are interleaved. SVG has no z-index at all, only document order. So it's normal that Inkscape is simpler/less powerful in this regard. CSS and SVG are conceptually nice and simple. In ODF, a separate z-index based array is necessary to do efficient drawing. I'm not sure how many documents we'd break if we'd go for a the simple CSS z- index model. If it's not too many, we could make the specification language more precise and the same as CSS. > >>> 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. What is that workaround? > > 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 Awesome to see the report and the discussion on it already. > >>> 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
Re: [libreoffice-design] Re: Home for the breeze icon theme
This may be a bit off-topic, but couldn't the Breeze theme become the default theme in Windows 10? It fits a lot better with the design language of W10 than Tango (as KDE usually fits better with Windows than Gnome). And Breeze is already the default on MacOS... On Sun, Jul 31, 2016 at 7:04 PM, kainz.a wrote: > 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 > -- 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
