Le 08/04/2023 à 22:31, Quentin Barnes a écrit :
On Sat, Apr 08, 2023 at 07:09:54PM +0200, Maxime Soulé wrote:

Le 08/04/2023 à 18:03, Quentin Barnes a écrit :
I created a commit with my changes for comment here:
(If you try out the change yourself, be sure to pick up the earlier
commit 1240941 that adds the function RLayoutGetNameIndex().)


Good idea, I just commented your last commit.
Thank you!

In the macro that is "MONITOR__<name>", it's got the double-underbar
to prevent a possible name collision with "MONITOR_<number>".  If
there is absolutely no chance a device ever being a simple integer
now or in the future, then the extra underbar can be removed.

I think there is no chance a collision occurs, as Xrandr should take care of
How does xrandr take care of that? Does it have naming device
requirements that preclude digit only naming?

The names have always been prefixed with an alpha characters and not
a simple digit string as far as I know, but I didn't know if that
was just a convention or a requirement.

I misread, I thought you spoke about monitor names collision :)

That said, I don't think a monitor name can begin with a digit. Names are built using the corresponding connector name as found in the driver, like here:

What do people think of this change overall?  Was what it something
that makes sense and might be useful to others?  Is there a better
or different way to do what I need to do instead?

Out of curiosity, do you have some examples of use of these new macros?

Sure!  I can provide the examples of what I had previously mention > [snip]

Thanks, it's interesting!

Another thing that comes in mind: don't forget that these new macros are bound to Xrandr initial detection. If the layout has later been overridden using MonitorLayout config variable, the macros won't reflect the user layout.

Perhaps XRANDR_ (or XRR_) prefix could eliminate a possible confusion? I don't use MonitorLayout myself, but for those using it, it could be misleading.



Reply via email to