[CREATE] OpenRaster layer attributes: lock and visibility

Wed Dec 2 12:33:51 PST 2009

We've discussed visibility shortly a while back on #create. Attaching the
log. Mega-short summary:
- For MyPaint a boolean "visible=true,false" would do the trick just fine.
- However, SVG uses visibility=
13:22 < pippin> visible | hidden | collapse | inherit <- are the SVG values
13:22 < pippin> and it is combined with the display attribute which has:
inline | block | list-item |
13:22 < pippin> run-in | compact | marker |
13:22 < pippin> as values
13:22 < pippin> table | inline-table | table-row-group | table-header-group
|
13:22 < pippin> table-footer-group | table-row | table-column-group |
table-column |
13:22 < pippin> table-cell | table-caption | none | inherit
- Consensus that we should follow SVG where natural

So, how much of this makes sense for OpenRaster? Do we want collapse and/or
inherit? Any of the additional attributes?

Some way of marking a layer as locked (ie: uneditable) is also needed. Any
input on this?

-- 
Regards Jon Nordby - www.jonnor.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/create/attachments/20091202/9fdaf4bf/attachment.html 
-------------- next part --------------
--- Day changed Mon Aug 31 2009
06:29 -!- JonCruz [n=joncruz at adsl-75-51-188-197.dsl.lsan03.sbcglobal.net] has joined #create
08:39 -!- JonCruz [n=joncruz at adsl-75-51-188-197.dsl.lsan03.sbcglobal.net] has quit [Remote closed the connection]
17:21 -!- Enselic [n=martin at c-267871d5.017-113-6c756e10.cust.bredbandsbolaget.se] has joined #create
18:05 -!- houz [n=houz at pD954CDAA.dip0.t-ipconnect.de] has joined #create
18:05 -!- houz [n=houz at pD954CDAA.dip0.t-ipconnect.de] has quit [Read error: 104 (Connection reset by peer)]
19:24 -!- maxy [n=maxy at 84-73-221-119.dclient.hispeed.ch] has joined #create
20:05 -!- portnov [n=portnov at v-20678-unlim.vpn.mgn.ru] has joined #create
20:06 -!- a_l_e [n=quassel at 60-229.60-188.cust.bluewin.ch] has joined #create
20:11 < portnov> hello. We are working on better layers support for MyPaint now. One point should be to save layers visibility in OpenRaster. AFAIK, there is no corresponding attribute in ORA specification right now. Our suggestion is to use "visible" attribute of <layer> tag in stack.xml. Is it OK?
20:16 -!- Irssi: #create: Total of 11 nicks [0 ops, 0 halfops, 0 voices, 11 normal]
20:16 < jonnor> CyrilleB: pippin: ^ :)
20:18  * CyrilleB is trying to think what would be the alternative
20:19 < jonnor> one could imagine the reverse; having a "hidden" tag
20:19 < CyrilleB> what would be the difference ?
20:21 < jonnor> if visible = True, the layer would be visible. If hidden = True, the layer would be not visible?
20:23 < maxy> I guess it only makes a difference if some application already uses one or the other
20:24 < portnov> As I see, Krita does not save this information at all currently.
20:24 < jonnor> "visible" seems to me to be a bit more precise
20:25 < CyrilleB> yes, and I tend to prefer "positive" tag naming
20:27 < portnov> and one small point is how to interpret layers without this attribute. I think, we should by default let visible=True ?
20:27 < maxy> certainly; doing otherwise breaks compatibility with all existing apps
20:27 < CyrilleB> yes, by default visibility=true
20:28 < CyrilleB> and visible should be optional, I think
20:28 < portnov> I think so too.
20:34 < jonnor> if there are no immediate objections I suggest that we go for that, updating the specs and sending a notification on the ML
20:41 < CyrilleB> I'd like pippin's opinion as well
20:51 -!- maxy [n=maxy at 84-73-221-119.dclient.hispeed.ch] has quit []
21:56 < christoph_s> http://blogs.adobe.com/jnack/2009/08/fixing_adobes_customer_service.html
21:56 < mrscribe> Title: John Nack on Adobe: Fixing Adobe's broken customer service (at blogs.adobe.com)
21:58  * CyrilleB loves the first comment :)
22:02  * christoph_s thinks most FLOSS projects offer much better support ...
22:40 -!- a_l_e [n=quassel at 60-229.60-188.cust.bluewin.ch] has quit [Remote closed the connection]
22:42 -!- portnov [n=portnov at v-20678-unlim.vpn.mgn.ru] has quit [Read error: 110 (Connection timed out)]
22:51 -!- Enselic [n=martin at c-267871d5.017-113-6c756e10.cust.bredbandsbolaget.se] has quit [Remote closed the connection]
23:23 < christoph_s> CyrilleB: Is there anything smartish in Krita's imaging technology that I should/could mention in article together with GEGL/BABL and VIPS?
--- Day changed Tue Sep 01 2009
04:21 -!- JonCruz [n=joncruz at 75.51.188.197] has joined #create
04:31 -!- mrscribe [n=supybot at 213.225.74.238] has quit [Read error: 110 (Connection timed out)]
07:12 -!- portnov [n=portnov at v-20678-unlim.vpn.mgn.ru] has joined #create
08:50 < CyrilleB> christoph_s: what kind of smartish ?
08:50  * CyrilleB wonders what VIPS is ?
08:52 -!- a_l_e [n=ale at box.ditoy.com] has joined #create
08:52 < CyrilleB> christoph_s: google helped me, is it about memory management ?
09:20 < christoph_s> bonjour CyrilleB. anything that's innovative :)
09:28 < CyrilleB> now that's a good question :) I don't see much innovative in gegl/babl nor VIPS :/
09:29 < CyrilleB> which means, I don't see much innovation in Krita either
09:31 < portnov> kubelka-munk seems to be such an innovation ?
09:33 < CyrilleB> we are speaking of core libraries, I think
10:16 -!- portnov [n=portnov at v-20678-unlim.vpn.mgn.ru] has quit [Read error: 104 (Connection reset by peer)]
10:24 -!- portnov [n=portnov at 79.134.14.200] has joined #create
10:43 -!- portnov [n=portnov at 79.134.14.200] has quit [Read error: 148 (No route to host)]
11:23 -!- JonCruz [n=joncruz at 75.51.188.197] has quit [Remote closed the connection]
11:36 < pippin> CyrilleB: I will not mind a visible=TRUE (or perhaps visibility=foo) attribute, please check with some native english speaker for what word would be appropriate though.
11:40 < CyrilleB> any native speakers around :)
11:42 < pippin> personally I'd like the second opinion because I find visibility odd and cumbersome :d
11:57 < CyrilleB> visibility is odd, but I find "visible" ok
11:57 < CyrilleB> I wonder if such information is stored in svg, and how
12:00 < pippin> http://www.w3.org/TR/SVG/painting.html#VisibilityControl
12:51 < jonnor> the argument in #mypaint regarding this was that "visibility" didn't sound like a boolean
12:57 < CyrilleB> I would for visibility then, to follow svg
12:58 < CyrilleB> but I am not sure if visibility should be made non-inheritable like in SVG
12:58 < CyrilleB> sounds strange  to me to have an hidden group with a visible layer
13:19 < pippin> CyrilleB: visibility as per SVG is _not_ a boolean
13:19 < CyrilleB> pippin: is that a problem ?
13:19 < pippin> if we make it a boolean yea, then we get the worst of both worlds
13:19 < pippin> a icky name, and inconsistency with SVG
13:20 < CyrilleB> right
13:21 < CyrilleB> but I mean visibility='visible' visibility='hidden' is fine for me
13:21 < pippin> uh?
13:21 < CyrilleB> that's what svg has, right ?
13:21 < jonnor> is it a scalar in SVG?
13:22 < pippin>  visible | hidden | collapse |  inherit <- are the SVG values
13:22 < pippin> and it is combined with the display attribute which has:  	inline | block | list-item |
13:22 < pippin> run-in | compact | marker |
13:22 < pippin> as values
13:22 < pippin> table | inline-table | table-row-group | table-header-group |
13:22 < pippin> table-footer-group | table-row | table-column-group | table-column |
13:22 < pippin> table-cell | table-caption | none | inherit
13:22 < pippin> for our purposes we very well might want to use it for making a filter a nop as well
13:23 < CyrilleB> yes
13:23 < pippin> (in my world view, an over-op is just another filter, that takes the compositing branch as an argument)
13:25 < CyrilleB> that's the svg view as well, but I don't share it for imaging
13:27 < pippin> CyrilleB: ?
13:29 < CyrilleB> hum ?
13:29 < pippin> what is your view then? I do not immediately see it; and throw an exception trying to integrate that statement with the rest of my understanding of your pov
13:31 < CyrilleB> I think <filter compositeop="over"> <layer/> <filter compositeop="somethingelse"> <layer/> ... is very complicated
13:31 < CyrilleB> the only "advantage" would be to "easilly" allow parameters for the composite op
13:32 < pippin> yep, and this is the reason you've managed to con me into accepting the current bastardized way of doing things in OpenRaster
13:32 < pippin> I much prefer how I'm doing it in native GEGL land / oxide ;)
13:33  * pippin minimizes his irc client and returns to work
13:35 < CyrilleB> well nothing is decided wrt to composite op...
13:40 < pippin> CyrilleB: my stance originally was (and I still prefer it) that all of filter / stack / layer / render (/... etc) all _should_ have been one single type of element, it is more flexible and simpler
13:41  * CyrilleB wonders why pippin doesn't use one single word of vocabulary ;)
13:42 < CyrilleB> but the vocabulary things is unrelated to "visibility" and/or "composite/ops"
13:43 < pippin> in my opinion it is related
13:44 < pippin> since all these elements are elements that would need a visible / enabled attribute
13:44 < pippin> in the same way that all of them need to support fallbacks
13:44 < pippin> they are indeed all the same; and at least for GEGL the parsing serialization is only complicated by treating them as different things
13:45 < CyrilleB> ??
13:45 < CyrilleB> you can have a parseCommonAttribute function, no ?
13:46 < pippin> not relevant
13:46 < pippin> I have a tree of nodes, all the same
13:46 < pippin> but I have to use different element names depending on the role of the node
13:46 < pippin> this name can be fully inferred by the position of the node in the tree
13:46 < CyrilleB> well of course, how do you differentiate a filter from a layer, then ?
13:47 < pippin> based on it's type
13:47 < CyrilleB> how do you know the type ?
13:47 < pippin> 'gaussian-blur' ?
13:48 < CyrilleB> well you can ignore the tag, if you don't want to use it...
13:49 < pippin> I cannot,.. lets just hope that I do not find the time and motivation to make a proper native GEGL based graphics tool / motion animation package etc.
13:49 < pippin> if I do,. OpenRaster will only be capable of expressing a small subset of what the much simpler format can do.
13:52 < pippin> but to return to the issue at hand,. perhaps "enabled" is a good name to add to "node"
13:52 < CyrilleB> well I understand why you can't... and I hope you will find time for that tool, I would be interested to see it :)
13:52 < CyrilleB> hum, enabled, to control visibility ? or locking ?
13:53 < pippin> CyrilleB: to control whether the "node" is enabled, or simply passes the data through
13:53 < pippin> CyrilleB: so yes, to control visibility; locking is orthogonal.
13:54 < pippin> CyrilleB: saying wheter a filter is enabled or not feels slightly better than stating if it is visible or not
13:54  * pippin thinks of invisible gaussian blurs
13:56 < CyrilleB> yes indeed
13:56 < pippin> CyrilleB: btw, I do have ~10000 line long oxide compositions with animations lying around
13:56 < pippin> oxide as you probably recall being the precursor to the format used in GEGL http://pippin.gimp.org/oxide/
14:30 -!- portnov [n=portnov at v-20678-unlim.vpn.mgn.ru] has joined #create
14:43 -!- portnov [n=portnov at v-20678-unlim.vpn.mgn.ru] has quit [Read error: 60 (Operation timed out)]
15:05 -!- portnov [n=portnov at v-20678-unlim.vpn.mgn.ru] has joined #create
17:50 -!- a_l_e [n=ale at box.ditoy.com] has quit [Read error: 110 (Connection timed out)]
18:34 -!- Enselic [n=martin at c-267871d5.017-113-6c756e10.cust.bredbandsbolaget.se] has joined #create
20:14 -!- portnov [n=portnov at v-20678-unlim.vpn.mgn.ru] has quit [Read error: 113 (No route to host)]
22:44 -!- Enselic [n=martin at c-267871d5.017-113-6c756e10.cust.bredbandsbolaget.se] has quit [Read error: 54 (Connection reset by peer)]