Incorrect 'current profile' value during 'preswitch' script?

[noughtnaut]

Hello! First of all -- THANK YOU for maintaining this amazing project. You are an awesome human(?) being. As a scrum master and somewhat mobile developer, autorandr is truly making it a pleasure to move my laptop between desks and meeting rooms.

I am somewhat puzzled by the combination of preswitch script and the AUTORANDR_CURRENT_PROFILE variable. It seems logical that, before the switch, the 'current' profile would be whatever (if any) profile is active, but it seems the variable is reporting the 'destination' profile, the one to become active after the switch.

I realise that I could simply keep track of the 'source' state myself, but I am wondering whether this is worth adding to the application? If you do not think so, I urge you to at least amend the wording in the readme file so that this becomes more clear.

By the way, I have been tinkering with a similar utility (unashamedly simply triggered from postswitch) to adjust audio sources and sinks -- a neat trick to 'magically' connect meeting room speakers, desk headsets, etc.

[noughtnaut]

FYI, my tinkering is now online: https://github.com/Noughtnaut/noughty-autorandr This doesn't actually do the audio switching yet (although I have the code for it), but it does store/restore per-profile dconf configurations and adjusts the default printer.

[phillipberndt]

Hey, thanks, and also thanks for sharing your tool, that's an awesome extension! (Which we should link to from the readme.) I agree that this should be improved, and with your expectation.

[noughtnaut]

Thank you for your kind words. I am humbled.

But which is the correct understanding of AUTORANDR_CURRENT_PROFILE?

• That it should retain its value throughout the preswitch stage, and then change before entering the postswitch stage; or
• that it should reflect the 'incoming' profile, while the 'outgoing' profile might be tracked by a separate variable?

I suppose the former is the cleanest in a semantic sense -- although altering its behaviour might be a breaking change for scripts such as mine. Perhaps better to choose the latter path, but introducing not one but two new variables, making use of terminology such as OLD/NEW or OUTGOING/INCOMING?

[phillipberndt]

I'm open to breaking backwards compatibility over such a detail - all we have to do is make sure this is properly documented.

I also agree though that a more self explanatory name, and another variable, would help a lot.

So how about adding new variables, and mark the old one as deprecated?

[noughtnaut]

I've given this some thought, and I don't see an ideal way to store the 'current' state, seeing as how it could easily be modified outside of autorandr. Ideally, I'd want to store simply the name of the last-switched-to profile in an environment variable, chiefly because it is somewhat persistent while still being reset by logout or reboot events.

I don't see you having used (long-lived) environment variables elsewhere, so I'm not sure if you're okay with that approach?