[06:10]  * OvenWerks is not sure if he will be there for meeting this week.
[06:11]  * cfhowlett knows he won't be there since y'all are meeting at 0400 local time  :(
[06:11] <OvenWerks> OWCH
[16:56] <OvenWerks> we have trouble in -controls land... there are some things that are system (must be changed as root) and some stuff that is userland (must be changed not just as the user, but as the user from the session) This means that the whole idea of pkexec ubuntustudio-controls is flawed and needs to be changed
[16:57] <OvenWerks> I found this out by doing a check if jack is running (it is in my session) and the result is "stopped"
[16:58] <OvenWerks> Which is correct because root is not running jack. If root does run jack, the user can't create clients that see root's jack anyway.
[16:58] <OvenWerks> krytarik: ^^^ this is likely the case for tablet setup as well.
[17:03] <OvenWerks> The current idea is that the user should know when they are changing system settings and those should be by password. I am not sure this is true. Adding a user to the audio group or activating the audiolimits file are not really a problem.
[17:03] <OvenWerks> Changing boost or cpu governor should not be a problem either.
[17:05] <OvenWerks> None of these things allow the user to input arbitrary text, rather they give the user a set of choices they can choose from.
[17:11] <OvenWerks> I am thinking to create another script in /usr/sbin that can be called to do system kinds of things. I can set it up in PK to just work with no password. It would be called with one parameter that could be a cpu governor name, boost_on/off or boot_gov/boot_boost. That leaves setting the group. I guess I could make it two parameters so we could do group user.
[17:12] <OvenWerks> if we wanted to keep the password part we could instead ask for the password when OK is selected.
[17:13] <krytarik> Pretty sure I want a password for that, yes.
[17:14] <OvenWerks> It would mean doing all changes at exit. This  could be ok... but it would be kind of nice to leave the utility open and switch back and forth between boost and not or performance and not rather than using a password each switch.
[17:14] <OvenWerks> krytarik: which parts do you want password protected?
[17:15] <krytarik> Well, all system-wide ones, of course.
[17:16] <krytarik> Otherwise, one could fiddle with the script and make it execute all sorts of things.
[17:16] <OvenWerks> krytarik: one has to have root acces to change the script
[17:16] <krytarik> True.
[17:17] <OvenWerks> all files in /usr are owned by root
[17:21] <OvenWerks> If we were allowing the user to type in anything at all... password required.
[17:22] <OvenWerks> but we don't for anythingn ayatem
[17:22]  * OvenWerks has bad typing this morning...
[17:25] <OvenWerks> Anyway, we have to run a separate process for system. We can do it two ways:
[17:25] <OvenWerks> 1) a script with parameters in the background
[17:26] <OvenWerks> 2) a second GUI based script run with a password.
[17:29] <OvenWerks> krytarik: option 1 is invisible to the user, option 2 means the user starts a second application for some things and closing the main window may not close the system... or the system window may make the main window inactive.
[18:24] <krytarik> OvenWerks: Or just use shell commands directly with pkexec?
[18:24] <OvenWerks> krytarik: that would mean putting a password in two or three times after clicking ok
[18:25] <OvenWerks> (4 times actually)
[18:28] <OvenWerks> krytarik: if you install one of the governor change applets (like the one Luke suggested) they do not ask you for a password ever to change governor. Why are we more sensitive?  Setting the group to audio and the limits file to enabled are just things that should have been done on install.
[18:30] <krytarik> OvenWerks: How does that do it then?
[18:30] <OvenWerks> My personal feeling is that the jackd install is broken in that it does not set rt availablility.
[18:31] <OvenWerks> probably with a line in policy kit
[18:34] <OvenWerks> see /usr/share/polkit-1/actions
[18:34] <OvenWerks> though it may be with a line in /etc/sudoers or a file in /etc/sudoers.d/
[18:36] <OvenWerks> krytarik: I would like to remove the availablility to choose a user(s) to set to audio group and just invisibly when run check if things are installed right and fix otherwise :)
[18:38] <OvenWerks> So make sure the file /etc/security/limits.d/audio.conf exists and drop the current user into the audio group... no questions asked. Maybe check if jack is installed first.
[18:39] <OvenWerks> If we want the user to know something is happening (I guess really we do) then make it one check box "[] fix this user to run jack properly".
[18:43] <OvenWerks> Make the checkbox grey out if the task is already done and if the user has not yet logged out and back in... have a line just below in bold red that says reboot required or some such.
[18:45] <OvenWerks> In fact I may be able to make the widget not visible unless it needs doing.
[18:45] <OvenWerks> I think I have figured it out.   ;)
[18:46] <OvenWerks> I wonder if we should check if a lowlatency kernel is installed... we can run without.
[18:53] <krytarik> Well, check is nice - but just display if it isn't, I guess.
[18:54] <krytarik> Similar to what you've just done.
[18:56] <krytarik> And I guess the external shell script option without requiring a password is the most sensible then.
[19:05] <OvenWerks> Right, in any case the GUI will change again