Smm Panel Free Script
Baudilio Eliason
I was initially creating the panel under a MarginContainer, also created through code.
It turns out this MarginContainer also had a size of Vector2(0, 0) as default.
Therefore no matter what I set as the size of the panel, it would not be rendered.
Specifying the size of the MarginContainer first results in the panel being scaled to be the size of the MarginContainer.
Again, thank you for contributing your questions and concerns during registration. I have taken the most often-cited questions and will be posing them to our panelists. [Questions curated for each panelist and build off of each other].
KRISTIN ARNOLD, MBA, CSP, CPF Master, professional panel moderator, and high stakes meeting facilitator is on a quest to make all panel discussions lively and informative. Check out her free 7 -part video series on how to moderate a panel and other resources to help you organize, moderate, or be a panel member.
I run three PC's through one monitor via a KVM, I recently changed my mouse and when I come back onto my linux PC (SolydX64 bit) (say from my windows PC) the mouse scroll speed is way to fast, so I have a little bash script that I run manually, now I would like to run the script from an icon on my 2nd desktop panel which would be a lot quicker than opening a terminal and running the script manually.
I have made a .desktop file and added it to .local/share/application/ folder but I guess I have something wrong as when I click on the icon, something does happen but the mouse scroll speed is unchanged. Can somebody tell me the correct procedure for getting a bash script to run from a panel icon please.
Working with array values is tougher because I don't think xfconf allows you to manipulate individual elements of the array. And since creating a new panel or a launcher requires array manipulation, it may not be possible. You might be able to create a wrapper function to read, store and re-write the array values (as a complete set), but I've never tested this.
As I explained earlier, it won't be easy (impossible?) because you need to manipulate array values (see panel-1/plugin-ids) and as far as I know, xfconf-query can't manipulate individual elements of an array (I might be wrong, but I can't find any info on how to do this). Thinking out loud, you may be able to create a wrapper function to read, store and re-write the array as a complete set, but these are uncharted waters (don't know if its possible).
It's not a "command line" solution, but can't you just find the app you want in your desktop menu, drag (a representation of) it from there to the desktop, and then on to the panel you wish to place the launcher on?
DISCLAIMER: Be very careful with this code. If possible, test on spare system or in a vm. This works on my test system (in this case fedora), but I can't vouch for others. You have been warned.
If you want to develop a shell script to set up your Xfce panels, then you will obviously have to understand how you can access the Xfce configuration from the command line. In this post, I will explain what I learned in order to write such a script.
As an example, you may decide that you want to modify the size of your first panel (i.e., for a horizontal panel, its height, or, for a vertical panel, its width). First, you may want to find out what its current size is:
The panel plugins are listed in an array, of which each element identifies a plugin. Each individual plugin is represented by a three-element array, in which the first element specifies the plugin name, the second element is an indicator of the plugin type, and the third element identifies a further variable that, depending on the plugin type, will be either an array or a string.
A plugin property is represented by a three-element array that specifies the property name, the property type, and the property value; if the value is the empty string, then the property will remain unset (i.e., its default will be used).
The script is meant to be run on a Debian system, and begins by testing if the computer is running Debian, and if the desktop environment is Xfce. To my knowledge, however, the script does not use any Debian-specific features, and it should be perfectly safe to remove the test for the system distribution name (or to make it test for a different distribution). I haven't tested it on any system except Debian, though.
One of my major goals in developing this script was avoiding the need to manually keep track of panel ids and plugin ids. Thus, if you want to adapt the script to your own preference, you can simply list the panels that you wish to have it create for you, and the plugins that you want it to add to each panel, without worrying about their ids. The script will automatically assign the appropriate ids to the panels and plugins.
Option "-brief" is unknown, try "ip -help".
./panel2: line 436: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
./panel2: line 437: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
./panel2: line 438: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
./panel2: line 439: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
./panel2: line 440: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
./panel2: line 441: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
./panel2: line 442: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
./panel2: line 443: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
./panel2: line 444: declare: -n: invalid option
declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...]
Your first error, "Option "-brief" is unknown, try "ip -help"", indicates that you are not using a compatible version of the program "ip". It is used in the line, "ip -brief link". Try running that at the command line. I get:
If you get something different (like your error message), you are going to have to figure out how to do something comparable on your distro. Likewise "-n" is a perfectly legal option in the version of bash I am running:
The -brief arguement is showing not found. This Chromebook is running the latest version of Ubuntu ARM. So first it looks like I need to get ip link figured out, and than look into the version of bash that is running on ARM.
The "-brief" option on the ip command isn't really essential, but if you leave it out, then you will have to rework the sed command that extracts the network interface names from the output. In fact, that is how I initially considered doing this, but then I discovered the "-brief" option, which made it a whole lot easier.
Also, if you won't be using the Network Manager plugin anyway, you can simply leave the IP_LINKS variable blank. Alternatively, if all your computers use the same names for their network interfaces, you could even hard-code them.
The "-n" option on the declare or local command, on the other hand, is a pretty important feature, since the operation of the script is centered around the idea that the value of one variable can be interpreted as the name of another variable that you want to address (somewhat similar to references or pointers in typical programming languages, I guess). Without this feature, the dynamic nature of the script falls apart.
As a historical note the "-n" argument for the declare bash builtin first shows up in documentation (but not in the changelogs) of bash 4.3. The current is bash 4.4 so you are almost certainly running an older version of bash.
The declare -n syntax, as best I can tell, makes the variable a synonym for another variable. Since the use in the script is all very readonly, it looks to me like you could just explicitly spell out each array, e.g. change:
I don't really believe that will solve the problem. Yes, you do eliminate the indirection to the LAUNCHER_PROPERTIES_UNSET variable, but now you're left with indirections to each of the individual *_UNSET variables--which you would have to further expand. You may arrive at a workable solution if you do it intelligently, but it's not immediately clear to me how it would be done.
If you really cannot get access to the 'declare -n' feature, then you will likely be better off hard-coding the panel and plugin parameters (which is exactly what I tried to avoid, since I didn't want to manually have to keep track of panel ids and plugin ids). While this may make the script look more staightforward, it will certainly get far more painful to maintain. Another option, of course, may be to recode it in, say, Perl or Python (which I had also considered, but given that the process really just consists of a sequence of, mainly "xfconf-query", commands, I preferred a shell solution instead).
Forgive my lack of knowledge, but it looks to me like if the only problem were the handful of "declare -nr" statements, the solution I suggested would work ok. But I think you are suggesting that even though the error messages posted did not show them, there will be similar problems with "local -n" statements used in function calls. Is that what you are saying?
c80f0f1006