Resize multiple objects to same size

[thomaso]

1 minute ago, R C-R said:

I am using "generally" in the sense of usually, widely, without regard to particulars or exceptions; IOW, as the opposite of seldom. It was not meant to mean universally or without exception.

Thanks, I haven't considered this possible difference (the German "generell" wouldn't man something like "usual" but rather "always" (like a basic principle, 'irrevocably') - though people often use them both in both ways). By the way: in Affinity the contrast of the grays in the dark UI may be an example for an issue which can appear as bug but doesn't have to.

[P.N.]

11 hours ago, R C-R said:

Generally, the term "bug" refers to some feature that does not work as it was designed to work, like by not working at all, causing a crash, or producing unintended side effects. What we are discussing here is a feature that is totally absent from the apps.

We are getting into semantics here. But I would argue that a bug is where an application functions unpredictable, unexpectedly or illogical. 

The mentioned export example would be a bug in that case as it should be expected behavior. Going with the "we did not think of it so it it not a bug" is just an excuse for lazy design and development.  

So I would call the experience of selecting multiple shapes at the same time but only one transforms a bug as it is unexpected and illogical behavior. Especially when compared to the same behavior in other apps. Then it is also unpredictable behavior.  

9 hours ago, R C-R said:

So a missing feature -- one not implemented at all in the app -- can in general also be called a bug? Does that mean that every missing feature we have been requesting in the feature requests forum (many for years) can also generally be called a bug?

The unpredictable, unexpectedly or illogical filter would exclude a lot of items on the list from being bugs and therefore feature requests. 

[Old Bruce]

A bug is a piece of code that does not work the way the programmer expected it to work. Not us users, the people who write the code.

[R C-R]

9 minutes ago, Old Bruce said:

A bug is a piece of code that does not work the way the programmer expected it to work. Not us users, the people who write the code.

Exactly! This avoids the otherwise considerable confusion about the difference between a missing (IOW, a non-existent) feature & one that exists but does not work as the designer expected it to work. Otherwise, anything that does not work the way even just a few users thought it should work could be called a bug.

[Old Bruce]

12 minutes ago, anto said:

Could you explain how the developer expected that feature Transform Objects Separately work? 

Better you ask the developer. I don't even know who worked on that, or when, or how many people were involved.

Having said that here is my expectation: When I select multiple objects and enter some values into the transform panel I expect it to act on the whole selection, the entire area is moved to the x, y coordinates and the overall size is scaled to the H + W values.

[R C-R]

51 minutes ago, anto said:

Could you explain how the developer expected that feature Transform Objects Separately work?

My guess would be as it does now; IOW, each object transformed proportionally in place rather than as a group.

57 minutes ago, anto said:

How it should work?

Some users think it should transform using absolute H + W values, or at least have that as an option. Since it does not currently offer that, it is clearly a missing feature, not a bug.

[thomaso]

1 hour ago, Old Bruce said:

A bug is a piece of code that does not work the way the programmer expected it to work.

As definition this can result funny. Might it not mean if programmers always expect their code to work as it does  they never can create or experience a bug? With other words, if code does not work as expected for the users the coder may say "I did not expect it to work any different".

To avoid such a one-way argumentation there are two points of view to consider: the coder's view and a view from outside (may be a user or just the boss). Interesting that a site called "code simplicity" did post a "precise definition". https://www.codesimplicity.com/post/what-is-a-bug/

I still don't think that any missing feature in Affinity yet would clearly be a bug – but I am aware that the expectations how code should work (~ be written) does vary for different people, probably even for different coders, too. However, it appears that code which has not been written yet can't be a bug. Means for this topic we should know whether there is any code to enable the users to scale as wanted. I doubt there is, at least there is no according UI.

[thomaso]

1 minute ago, anto said:

If proportionally, as you say, that should be in %, but not in mm.

It's up to us users. We can enter both to make it work as it was coded.

[Old Bruce]

2 minutes ago, anto said:

I have 3 objects, for example, W: 55 mm, 40 mm, 45 mm.

I use function Transform Objects Separately and set W  20 mm.

What I get: W: 24,4 mm, 17,8 mm, 20 mm.

What means this data?

Do the arithmetic.

45 / x = 20

40 / x = 17,8

55 / x = 24,4

I will wager that x in each case will be the same.

[thomaso]

2 minutes ago, anto said:

Without % this does not have sense.

Reduce to 20 mm what means? What should i get?

You need to enter the unit if you want to use a different than the default unit for the according field (which varies with app prefs, document setup and panels), while % can be used 'as unit', too.

If you don't type a unit than the currently default gets used. So, for an object with W=40 mm H=50 mm entering a new W=20 with scaling proportionally will result in an object of 20 x 25 mm (= 50%). So, if you have selected several objects for this action than they all will get scaled by 50%. Alternatively you can type "50%" instead of just "20".

[Old Bruce]

x is the unknown. Basic algebra.

[thomaso]

16 minutes ago, anto said:

I have 3 objects, for example, W: 55 mm, 40 mm, 45 mm.

I use function Transform Objects Separately and set W  20 mm.

If you use the option "Transform Objects Separately" then all selected objects are selected but 1 looks visually "more selected" than the others, this is the one in focus. This object will get the "20" you type. All others will get scaled according to the percentage scale of this specific object. Means if the 20 have been 40 before scaling then all objects will get scaled by 50 %.

[R C-R]

2 minutes ago, anto said:

But what means X.

It is the denominator of the fraction, also know as the divisor.

[Old Bruce]

2 minutes ago, anto said:

Thanks and I hope that the developers will correct the bug or will add new function. With Transform Objects Separately something went wrong.

Add a new function, I am happy with the way it works now. However, I do see the need for something that will give you what you have asked for and I hope it does occur sooner rather than later.

[Old Bruce]

1 minute ago, anto said:

You are happy because you do not use this feature (Resize multiple objects to same size) at all, or use it very rarely.

I am happy with the way it works now because the way it works now is what I use quite often. As I said in that post you have quoted I would also like to see added functionality to give you your needed and requested method of working.

[R C-R]

38 minutes ago, anto said:

Thanks and I hope that the developers will correct the bug...

It isn't a bug. It works the way it was designed to work, according to very simple & straightforward math. Like @Old Bruce said, what is missing is an additional function that works the way you & many others want it to.

[P.N.]

1 hour ago, R C-R said:

It isn't a bug. It works the way it was designed to work, according to very simple & straightforward math. Like @Old Bruce said, what is missing is an additional function that works the way you & many others want it to.

I do agree with the definitions posted by @thomaso . In that definition it would definitely be a bug. I refuse to believe that it works as intentionally designed. Perhaps just badly designed and sort of an accidental design flaw. Proof of my statement is the following.

• Selecting multiple shapes (i.e. an instant grouping) transforms everything in scale. - This is logical. You could create a group and transform but this is faster.
• Selecting multiple shapes and selecting "Transform separately" implies a equal transformation (either relative or absolute) for all selected items. Just transforming 1 item out of the larger selection makes no sense as you could just select one item to have the same effect. So why design this function to work in this way. 
• Selecting multiple text fields and changing the font size results in all text field changing the font size. Not just one. also does it not do a relative font size change. So the application has different behavior in comparable use cases. 
• In most Mac applications resizing multiple (non grouped) objects with entering a new absolute size results in all objects getting that size. So this is de expected behavior. 

I can think of no reason of why it should work the way it does. If only developers can decide of something is a bug then nothing would be a bug. In my many years in software this is also very uncommon practice.  

[R C-R]

3 minutes ago, P.N. said:

I can think of no reason of why it should work the way it does.

If for no other reason, it works that way because it is the way @Old Bruce just said is how he often uses it.

[thomaso]

1 hour ago, P.N. said:

In that definition it would definitely be a bug.

Why "definitely"? - By mentioning "reasonable user expectations" without defining what "reasonable" is and whether "user" is singular or plural, this definition expresses that it is an individual judgement, decision or even emotional impression. In short, it depends. – Actually it doesn't matter how this issue gets named, we users want it to get fixed and Serif will make their decision, regardless of its label 'bug' or 'missing feature'. (Yes, there also are bugs since years, though they got classified as bugs by Serif several app versions ago)

The current feature "Transform Objects Separately" has the advantage that the transformed objects stay each at its position. This becomes a lot more obvious when you rotate several selected objects, regardless of numerical via panel or by dragging. Then using this feature has a very different result than rotation without "Transform Objects Separately".

–>

With "Transform Objects Separately":

–>

[R C-R]

11 minutes ago, thomaso said:

The current feature "Transform Objects Separately" has the advantage that the transformed objects stay each at its position. This becomes a lot more obvious when you rotate several selected objects, regardless of numerical via pane or by dragging.

IIRC, 'rotate in place' is one of the specific uses that a number of users were asking for that Transform Objects Separately was designed to allow, along with resizing each selected object proportionally without changing their positions relative to each other. The request for the "absolute" resize all to the same size function came later.

[Ferdinando Traversa]

+1, this feature would be so useful!

[Wayne Burrows]

Hello All,

After reading everything within this thread, I am under the assumption that there is still no way to resize multiple different-sized layers all at once. Do I have that correct or does an available feature exist now? Just to make sure that I am on the same page with the topic of this post, I included a short video to show what I am trying to accomplish.

Thanks!

WB

[carl123]

See if this new feature (v2.4) does what you want...

 

[Wayne Burrows]

39 minutes ago, carl123 said:

See if this new feature (v2.4) does what you want...

No luck Carl. Take a look. I don't know if it is doing what it's supposed to do (which I doubt) or my Affinity is glitching or maybe there are too many layers for it to work properly. It's actually making it worse.

[Hangman]

Hi @Wayne Burrows,

From your screen recording it certainly doesn't look as though all groups end up the same height, though they are quite possibly the same width...

After selecting all the groups and then making them all the same width, if you also align all the groups left, are they then all the same width? If you repeat for height, i.e., after making all groups the same height, when aligned top do you see a mix of heights or are they all the same?

If they're not all the same width and/or height, are you able to upload the file in question so we can take a closer look...