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
--- Day changed Mon Aug 31 2009 06:29 -!- JonCruz [[email protected]] has joined #create 08:39 -!- JonCruz [[email protected]] has quit [Remote closed the connection] 17:21 -!- Enselic [[email protected]] has joined #create 18:05 -!- houz [[email protected]] has joined #create 18:05 -!- houz [[email protected]] has quit [Read error: 104 (Connection reset by peer)] 19:24 -!- maxy [[email protected]] has joined #create 20:05 -!- portnov [[email protected]] has joined #create 20:06 -!- a_l_e [[email protected]] 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 [[email protected]] 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 [[email protected]] has quit [Remote closed the connection] 22:42 -!- portnov [[email protected]] has quit [Read error: 110 (Connection timed out)] 22:51 -!- Enselic [[email protected]] 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 [[email protected]] has joined #create 04:31 -!- mrscribe [[email protected]] has quit [Read error: 110 (Connection timed out)] 07:12 -!- portnov [[email protected]] has joined #create 08:50 < CyrilleB> christoph_s: what kind of smartish ? 08:50 * CyrilleB wonders what VIPS is ? 08:52 -!- a_l_e [[email protected]] 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 [[email protected]] has quit [Read error: 104 (Connection reset by peer)] 10:24 -!- portnov [[email protected]] has joined #create 10:43 -!- portnov [[email protected]] has quit [Read error: 148 (No route to host)] 11:23 -!- JonCruz [[email protected]] 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 [[email protected]] has joined #create 14:43 -!- portnov [[email protected]] has quit [Read error: 60 (Operation timed out)] 15:05 -!- portnov [[email protected]] has joined #create 17:50 -!- a_l_e [[email protected]] has quit [Read error: 110 (Connection timed out)] 18:34 -!- Enselic [[email protected]] has joined #create 20:14 -!- portnov [[email protected]] has quit [Read error: 113 (No route to host)] 22:44 -!- Enselic [[email protected]] has quit [Read error: 54 (Connection reset by peer)]
_______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
