-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Per-layout command / more flexible commands #15
Comments
Hi @michaelcadilhac! Thank you for your feedback. Just another option how you can solve your issue. As far as I understand, the issue is in quotes surround You can introduce an argument to the In this case, no overloading will be introduced and it will work without modification of config files for all current users. I'm not sure that adding overloading won't require config files modification. |
Hello and thanks for the prompt reply! I believe that if we do want to make the interface more flexible, keeping the divide
I understand you are preoccupied by backward compatibility; we can just add an optional argument for |
The initial idea why What about flexibility. I agree it is a very important part of this widget and I definitely agree with your arguments, but I don't want to break backward compatibility and force users to write full command. I think it might be inconvenient. If we speak about adding optional argument to I see several possible options:
Thank you for this good feedback. I'll be glad to see such flexibility improvements in the widget. |
My use case is that I alternate between US and US Dvorak. For both, I have a
setxkbmap
option and I then reload~/.xmodmaprc
. I use this rather unfortunate line:This is to "hack" into the
os.execute
that is done by the code.A much more elegant solution would be to have a
add_primary_layout
with named argumentsname
,icon
,full_command
,cmd_argument
, with the last two optional, although one of the two should be there. For instance:Alternatively, we could specify the command when creating
kbdcfg
as:… but this does not provide the same flexibility.
The text was updated successfully, but these errors were encountered: