UI values – 1 for more than 1

[thomaso]

For various selected objects AfPub always reports only 1 specific value per property.

That value is sometimes - but not always - just taken of the first selected item, in case of cmd-a it isn't.

That way AfPub gives definitely wrong information for some objects. font size, ... or color.

Examples:

2 objects, 2 fills  > 1 color – version A + B:

 

Text size – version A & B:

 

Text – color & size & tracking:

 

 

Last but not least,
Text size – image frame:

[garrettm30]

Someone else brought this up recently, and I do think it would be better to either show nothing as the value, or some sort of indication like "mixed." I don't think it is a necessarily a bug, but it is not the ideal design in my opinion.

Can anyone suggestion why the current implementation is better than simply showing "mixed" or something similar?

[thomaso]

On 5/31/2019 at 3:51 PM, garrettm30 said:

I don't think it is a necessarily a bug

If a software reports 1 wrong value for 2 (or more) selected items then it is a bug - what else?
An unnecessary bug if you are aware that for identical situations it does not appear at other spots in the UI already.

Obviously the developers have an idea already how to visualize such conflicting input/output: Compare in Character Panel the font name and style text field: it simply shows NO value in case of conflicting inputs. Also the value in brackets (...) [...] and the  greyed out value  is used already in the UI in various panels to show that value as not to be real true so-to-say. – Or compare font size in character panel (< one value) vs. main menu bar (< no value).

In this way showing  no value  does appear more true than showing 1 wrong value.
Even 1 specific value but in (brackets) or  Gray  would be less wrong or confusing than the momentary solution.

[Gabe]

Hi both,

Sorry for the delayed reply. 

I've logged one as an improvement (having 2 colours selected) and one as a bug (not having the size blank - This only seems to affect Mac and not Windows)

Thanks,

Gabe. 

[Patrick Connor]

We believe the character panel issue has been fixed in 1.8.0  [Publisher beta currently available, others to follow]. The object selection issue currently remains unresolved.

[garrettm30]

56 minutes ago, Patrick Connor said:

We believe the character panel issue has been fixed in 1.8.0

From what I can tell, this is fixed for the font size attribute only, but other attributes still show the value of the first character in mixed selections. For example, all of the values in the "Position and Transform" section of the character panel continue to show the value of the first character even if other characters in the same selection have different values.

What @thomaso was showing (correct me if I am mistaken) was just a few examples of a problem all over the interface when a selection has mixed attributes.

[Patrick Connor]

@Gabe

Please validate AFB-2273 on whatever macOS @garrettm30 has, thank you.

[garrettm30]

Just now, Patrick Connor said:

whatever macOS @garrettm30

10.14.6

[Gabe]

I logged this as a separate issue, as the Position and Transform panel was not mentioned in the original report. 

[garrettm30]

5 hours ago, Gabe said:

I logged this as a separate issue, as the Position and Transform panel was not mentioned in the original report. 

Thanks for doing that, but this is a common issue across the interface, of which we have only given a few examples. Should we hunt down all places where this occurs?

[Gabe]

I spotted a few other places while logging this and made a note on the ticket

[uneMule]

Bonjour à tous.
Je ne suis pas le lapin de Alice, mais je suis toujours en retard !
En suivant le lien de  @thomaso, il semble que cette discussion soit toujours active.

*****

Hello everyone.
I'm not the Alice Bunny, but I'm always late!
Following  @thomaso's link, it seems that this discussion is still active.