Pioof
-
Posts
22 -
Joined
-
Last visited
Posts posted by Pioof
-
-
29 minutes ago, Old Bruce said:
No it hasn't lead to any inconsistency.
Yes it has. It slightly edited your file. Click on the object I called A, select same transparency, do whatever you like with the resultant selection : move it around, scale it, change fill color... whatever crosses your mind. It will affect object B (among others).
Undo, deselect everything and click on object B. Select same transparency, do whatever you like with the resultant selection : move it around, scale it, change fill color... It won't affect object A.
transparency of A = transparency of B, but transparency of B ≠ transparency of A.
Didn't I already write this somewhere? -
36 minutes ago, walt.farrell said:
That is not how it works today.
Yes, I know, I was explaining how my "solution 2" quoted by Old Bruce would work. Sorry for the present tense, it does not belong to a current reality.
-
2 hours ago, Old Bruce said:
Set the Layer (container) opacity to 40%, that makes the rectangles have 40% opacity. Remove one of the rectangles from the Layer. Is the 40% opacity still applied to that rectangle?
If you drop it to a Layer with 70% opacity it'll have that 70%. If you drop it to the background (which as far as I understand behaves like a layer with 100% opacity, it has 100% opacity.
2 hours ago, Old Bruce said:Put a rectangle with 60% opacity into that Layer. Is it now 40% of 60% or just 40%? What happens to Rectangles at 50% opacity being placed into a layer with 90% opacity?
You can't put a rectangle with 60% opacity into a Layer with 40%. It inherits its opacity from the Layer so its value can't be chosen independently. If you want to achieve a different perceptual effect you work with fill/stroke opacity, or you move it to a Layer with 24% opacity.
2 hours ago, Old Bruce said:As it is now Rectangles have their opacity and Layers have their opacity. The Layer's opacity is then applied to the Rectangles' opacity. This is consistent.
It's a choice that has lead to an inconsistent behavior of "same transparency". As I said, there are several ways around that issue. The last solution I outlined is my preferred right now but I understand that the constraint it creates (all objects in the transparent layer have the same "layer transparency" --unless that layer transparency is 100%) may not please everybody.
-
7 hours ago, MEB said:
Layer structure/content sets the context for some of the behaviours/funcionality implemented in the app.
That is very well, but does it relate to the action of selecting objects? You show that a given effect applied to a layer or to an object give different results. I can see that this can be exploited in smart ways. Now if I select an object, apply "select same whatever" and do not get a collection of objects but a heterogeneous set of objects and layers, then every function I'll apply of this heterogeneous selection will have different effects on the visible objects, whether they're affected as individual objects, or whether they're affected as constituents of a selected layer (I initially thought it could make no difference, but you pointed me to one it makes --thank you for that). So this way of selecting "same transparency" does not seem any smarter, on the contrary.
And I hate to repeat myself but apparently this is something that does not shock you, guys: if you select an object A and ask "select the same transparency" and the result of that is A and B, every normal human being expects that to be symmetrical: select B, ask "select same transparency" and you should get A. AD does not do that. You don't seem to believe me, it's funny, so try it on MEB's file above (select_same_transpaqrency_2.afdesign
Click on the top left square, apply "select the same transparency", get the middle one selected. Deselect everything, click on the middle square, apply "select the same transparency", you won't get the top left one selected but still another square selected. The operation is not symmetrical. Not. It may be "by design", I don't care, I feel, and trust that 99% people would feel the same, that it should not behave this way.
Why do we see this asymmetry? AD does this because it treats separate opacity parameters, object opacity and layer opacity, the same (whereas they're not and they interact), but nevertheless only object opacity, when an object is selected, is considered as the key value to be matched (so, irrespective of the opacity of the container layer). In contrast, a consistent way of programming would be to consider as key value the product of the layer and object opacities. To be anal, that would not be always the apparent object opacity either since this perceptual opacity is affected by fill and stroke opacities, on top of that. The product of layer and object opacities would be some half-evident transparency property, at best. But at least this way of doing things would give a symmetrical behavior. Select an 50% opaque object in a 100% opaque layer, and you'll get all 100% opaque objects in a 50% opaque layer (and all 62.5% opaque objects in a 80% opaque layer etc). Select any one of these latter objects, choose "select same transparency" and you'll get all of them again. "Same" finally meaning same.
Obviously another way to do it is to make opacity a heritable property of a layer, whenever layer opacity is not 100%. Objects would inherit their non-100% opacity from their container layer. That would also allow symmetrical behavior, and you could always play with fill/stroke opacity if ever you wanted an object with a different perceptual opacity inside that non-opaque layer. Actually I much prefer this second version. It makes the concept of transparency sounder, and does not multiply redundant parameters.
In both cases the resultant selection would be a homogenous collection of objects, so whatever you decide to do on them would have consistent effects.
Sure, you could still find some other mechanism. I don't really care. As long as "same" means "same".
-
2 hours ago, walt.farrell said:
It is an important concept to understand, and makes a difference in practice.
As far as I can see, it doesn't make any difference in practice. Please give me an example of a difference between the selection of a layer and the selection of all its constituents, apart from what is displayed in the inspector window.
Anyway, that is not the key problem of this thread. The key problem is that "same" is supposed to be a symmetrical concept. If A is the same as B, then B should be the same as A. In the current implementation, it is not. I'm not asking why it is not, I think I begin to understand why AD works in that convoluted way, I'm just saying this is a stupid choice and a stupid implementation that breaks one the most basic assumptions a standard user holds. When your software does not behave as 99% people instinctively believes it should, you are obviously free to go on thinking they are uneducated and need to read the doc. Or you can change that behavior to make it intuitive. As far as I'm concerned, I see no value in the current implementation of "same transparency" and would never use it, if ever I adopted AD as a professional tool.
-
6 hours ago, walt.farrell said:
It may appear (in the workspace where you see the bounding box) that it is selecting the middle rectangle, but it is not. It is selecting the Layer that contains the middle rectangle. They happen to have coincident bounding boxes, but they are different objects.
No. If you move around this selection, the middle object moves around. If you change the fill color to green, the middle object turns green. I don't care whether in theory the layer is selected and the object inside it is not: everything is consistent with a selection of the object.
-
Sorry for the delay in the response.
I must be thick but for me there "layer opacity" cannot mean both "the opacity of a layer" and "the opacity of an object inside that layer". As far as I understand, but correct me if I'm wrong (at least that's how I would expect things to function), we should have, in hierarchical order:
layer opacity > object opacity > (fill color opacity, stroke color opacity)
and all contribute to the perceptual opacity of the object.But that's just semantics. Now take your example file. Select the top left object and use "select same transparency": you'll get the top middle object selected. Now select that top middle object and apply "select same transparency". You will not get the top left object selected. In other words, A = B but B ≠ A. The problem is that both in mathematics and in common sense, "same" is symmetrical. So if it works fine by design, then your design is completely broken.
-
Well, JimmyJack, I did that just to prove something to Alfred. Initially, my layer2 had 45% opacity (see my 3rd screenshot) and everything was selected all the same. In short, whatever opacity setting you vary, fill, stroke, layer, everything is selected, which makes no sense to me. Besides, IMHO the only sensible thing would be to select the same perceptual transparency, whether it results from a fill choice or a layer choice (but we may disagree and that).
The file is attached if you want to have fun.
-
So in short, it looks like a bug. Is there a formal way to file it or this thread enough? (to recap, it is AD 1.10.4 on macOS 10.14.6)
-
No, it still does. But with an added box around the purple object that correlates with the (new) selection of layer2 in the layer panel.
-
Nope, the selected object (green disc) belongs to a layer with 100% opacity; layer 2 has opacity 45% and its object is selected too.
-
Hello all.
Whenever I select an object of a given transparency (as shown in the upper right Color panel, green disc on first image), and chose Select->select same ->transparency, I get all the objects in my drawing, as shown on the last image (AD 1.10.4). Either something is not intuitive or there is a bug (functionally, it is a bug). Note that in my 2nd and 3rd screenshots fill is in fact 100% opaque but the brown object sits in a 100% opaque layer whereas the third purple object is in a layer only 45% opaque -- neither correspond to the object and layer opacity of the green disc. It is not a question of fill vs. stroke transparency either, because both are different between my objects (not shown). So if it's neither fill, stroke or layer transparency, what transparency is AD considering then?
-
I attached the file (spectacular from an artistic point of view as you'll see).
This is something that I cannot reproduce from scratch, so it is linked to the file history. -
I've switched to AD since it now allows "select same...".
When I started evaluating v.1 10.4 a while ago, I created a simple test document with several layers, one of which has transparency set to < 100%. I recently noticed a weird behavior. When I drop an object from another layer to that layer in the layer panel, transparency applies. Great. Now if I select this object on the canvas and moves it around, it jumps to the base layer (not called Layer 1 but something like "crop area", for whatever reason that I can't remember) and transparency obviously does not apply anymore. Redropping the object to the partially transparent layer gets me to the initial state, and this bug can be repeated on and on...
-
On 1/10/2019 at 3:54 PM, MEB said:
Some features depend or are tied to other work/parts of the software that may still need to be finished or that aren't yet working as we hoped for. Some may require some research or rewriting a large part of the code or may even en up not working/performing well enough and must be postponed for some reason
Hi. Back on this thread for a check, I found MEB's above 'explanation'. Thanks for that. It seem to vindicate my earlier hypothesis that devs initially chose a data structure that makes selection by attributes very impractical (thus very slow). Sorting this mess out would mean rewriting most of the code, a formidable task that would not offer clear benefits to the existing users of AD (compared to adding fancy 'creative' features). So my hunch is that AD 1.x will never have selection by attributes. And it's not even obvious whether AD 2.x will have the different internals that could allow it.
All in all, I won't waste my time any more with AD. Too bad, on paper, it seemed cool.
-
On 11/10/2018 at 3:46 PM, madtho said:
I'd love to see how other folks are working around it.
Same as B4ttleCat, by using Adobe Illustrator.
There's no workaround to this feature.
You'll have to love manually selecting a zillion of objects without mistake (an interesting psychometric task, sure).Funny I haven't totaly given up on AD and still checking this forum every 6 months or so. Seeing for how long the issue has been around, I suggest that the moderators should write a sticky post "Tomorrow, AD gets the oft-requested selection by attribute". This would save them some time (ok, not that we get feedback on the issue very often).
-
I'm coming back to see if there had been any progress on this issue. But no.
You have limited resources, right, but also wrong priorities I'm afraid. This is perplexing to me. You are probably catering to your existing user base, but you should understand that adding basic functionality would expand that user base significantly.
Anyway, still on AI CS6.
-
On 03/04/2018 at 7:05 PM, dominik said:
can you please name examples of 'some fancy woo woo' that was introduced lately thay you think is not essential to AD's functionality?
I'm not davision, but I'd say that the ability to rotate the canvas (rather than the object after you've created it) is not an essential functionality. Similarly, adding and editing a pressure profile curve along any path is certainly nice to have, may speed up certain effects, but its absence won't block you from using the app.
The inability to do multiple selections based on color/weight/appearance/... is a showstopper for anybody working with complex documents, especially when editing these documents, not creating them. Right now AD is ok for simple layouts like web site graphics, or for some illustration projects. It's completely inadequate for even moderately technical projects, which I believe is the most frequent use of AI. They'd get more long-term customers and revenue from this population of users with a few features crucial for power users than with new brushes or texture effects.
Right now I don't mind, I'm still working fine with AI CS6. When it'll stop working completely because of OS change, I'll go back to Affinity to see what they've been up to in the meantime. See, I'm even checking right now out of pure curiosity...
- Krustysimplex, furtonb and B4ttleCat
-
3
-
From the AD team response, I suspect that they initially botched up by not thinking a minute about this feature and decided on a data structure that makes this kind of automated selection impractical to code or horribly slow to run. Now they have either to recode vast portions of the program or set up a dual, redundant data structure to handle this (fast but memory-hungry).
Of course that's just speculation. But otherwise I don't see why after four years they still haven't implemented this obviously essential and much requested feature.
-
"Select same...."
The missing function.And if you have spare time, align on click-selected object, à la Illustrator. Much more powerful than align on first/last.
-
I'm trying an evaluation version of AD, as a possible replacement of AI. The lack of smart selection is a deal-breaker for me. How many times did I select strokes of a given weight, or changed colors for a specific combination of weight & color... I'm usually editing EPS output from other programs that can happily spit out thousands of strokes in complex graphs. No way I'll be selecting them by hand!
You may dream of a neater, grander way to implement criterion-based selection than AI's, but if it's taking too much time then in the meantime please ape their elementary solution... it's really not rocket science.
- furtonb, QuietDesign and Krustysimplex
-
3
Set Units to MM (millimeters) application wide
in Feedback for Affinity Designer V1 on Desktop
Posted
Three years on and an AD2 out, nothing has changed and AD/Serif still doesn't understand that units of measure are a choice of the user, not a property of the document, and should be set somewhere in the global properties of the application.
My "poor workflow" is like JCD's, it requires me to use physical units of measure. Always. Whatever document I open with AD. It shouldn't be complicated to understand. The piece of software has to do the computations for you, it's first grade mathematics.
I don't earn a living using AD (otherwise I'd probably use something else). But years of not addressing elementary requests... I find it fascinating to set and run a feedback forum, and not use it as a way to improve your product.