You are not logged in.
for this current situation I am sure it is slightly overkill.
Since your requirements appear to be pretty simple, I agree it probably is.
Really all I want is one top panel that contains an Application Menu, shows currently opened programs, as well as workspaces, time, and battery level.
Seems simple enough. I would suggest you write out the xfconf-query commands that create these items; that should not be too hard to do. It's probably a good idea to delete the existing panels (as my script does), and create a new one, then add the required plugins to it.
Once you can do that, you can work from there, e.g., to adapt the Application Menu to your needs.
Offline
By the way, when I began to work on my script, my first approach was to create one big array that would hold the instructions (and their parameters) to create the panels and their plugins, and write some sort of "interpreter" that would walk through the array and execute the instructions.
Conceptually, the array would look something like:
BeginPanel
BeginPanelProperties
PanelProperty PROPERTY-NAME PROPERTY-TYPE PROPERTY-VALUE
...
EndPanelProperties
BeginPanelPlugins
BeginPanelPlugin
...
... (to be honest, I don't remember exactly how I was going to describe the plugin type and parameters)
...
EndPanelPlugin
BeginPanelPlugin
...
EndPanelPlugin
...
EndPanelPlugins
EndPanel
BeginPanel
...
EndPanel
...
However, when I realised that I would then have to keep the verbatim contents of the resource file (as required by certain plugins) directly in the array, I decided that the array definition would easily become awfully unwieldy in this way. I preferred to replace the contents of the resource file with the name of a variable (external to the array) into which I would then store the verbatim copy of the resource file. That was how the idea of using indirections came up, to create not a single huge array, but multiple smaller arrays instead (which would be linked together by name)... which eventually developed into the script as it stands.
Anyway, I'm not sure if these thoughts make sense, or appear helpful, to anyone, but I just thought I'd chime in with these ideas.
Offline
I had, a couple of weeks ago, completed something quite similar, but implemented with the power of a perl script. I had hesitated to post such a complex matter, but as a complement to the discussed shell script it now is interesting to give a short illustration of my alternative.
This script creates an entirely new xfce desktop environment from scratch (it throws away existing panels). Like the approach with the shell script, the desired configuration is defined by tables. This is best illustrated by a snippet from my scripts (including comments):
# List of plugin descriptors to be defined
# ----------------------------------------
# @arg_list defines the panels and the plugins to be generated. Each panel
# and each plugin is represented by a line (sequence of items):
#
# - items are separated by a series of whitespace characters that contains
# at least one tab character (hence: spaces alone are considered part
# of an item);
#
# - the leading item in each line defines the type of the plugin:
# * panel ... define a panel rather than a plugin; all subsequent
# plugins belong that panel - until another panel
# appears in the list,
# * orage ... short for xfce4-orageclock-plugin,
# * separator3 ... a sequence of 2 transparent and (in between) 1
# type-dots separator
# * partition ... a label item that displays the OS-partition
# * else ... the name of a plugin as used in xfconf;
#
# - the subsequent items specify properties of the panel or the plugin,
# their number (possibly 0) is imposed by the type; for details, refer
# to the comments on the "%plugin_specs" structure (module CommonData)
#
# - the first item in the argument list must be the begin of a panel
# definition.
#
# **<string> ... is a shortcut for $config_params{<string>}
#
# Comment lines ... the first non-blank character is a #
our @arg_list = split /\n/, <<'END';
panel 1 PANEL_VERTICAL **BAR_WIDTH 100
separator SEPARATOR_TRANSPARENT false
trash
separator3
launcher xkill.desktop
separator SEPARATOR_TRANSPARENT true
launcher drakconf.desktop
launcher xfce_settings.desktop
separator3
launcher konqueror_browser.desktop
launcher firefox.desktop
launcher thunderbird.desktop
launcher hexchat.desktop
separator SEPARATOR_SEPARATOR false
launcher konsole_remote.desktop
separator3
... snip ...
separator3
launcher man_viewer.desktop
separator SEPARATOR_TRANSPARENT false
partition
panel 2 PANEL_HORIZONTAL **BAR_HEIGHT 98
drawer Applications xfce/menus/application.png ''
drawer Help xfce/menus/help.png JH_Help.menu
drawer Communications xfce/menus/communications.png JH_Communications.menu
drawer Peripherals xfce/menus/peripherals.png JH_Peripherals.menu
drawer System Tools xfce/menus/system_tools.png JH_SystemTools.menu
drawer User Tools xfce/menus/user_tools.png JH_UserTools.menu
drawer Desktop xfce/menus/desktop.png JH_Desktop.menu
drawer Editors xfce/menus/editors.png JH_Editors.menu
drawer Info xfce/menus/info.png JH_Info.menu
pager 2
tasklist
separator SEPARATOR_TRANSPARENT true
cpugraph
xkb-plugin us,us,ch ,intl,fr 0 1
systray 18 false
orage
END
The leading item in each line determines the panel or panel-item to be configured - most of them can be understood intuitively, the arguments define parameters that specify the precise configuration of the panel item, resp. point to files in .local/share/applications and .config/menus.
This example illustrates the creation of 2 panels in an L-shaped layout:
the vertical (left) panel contains launcher items for frequently used applications,
the horizontal (bottom) contains
a series of application menu buttons (left part)
the common-use desktop action widgets (remainder)
Desktop properties and shortcuts are defined by a series of tables like
# Definition of keyboard shortcuts and plugin property lists
# ----------------------------------------------------------
# A property list contains 2 different types of items:
# single string items ... prefix string (will be applied to the property
# name of each subsequent property definition
# - the prefix string may be re-defined
# - the leading item must be such a string
#
# 2 tab-separated items (items may contains spaces) ...
# sub-item #0 = property name (with prefix)
# #1 = value of the property
#
# **<string> ... is a shortcut for $config_params{<string>}
#
# Comment lines ... the first non-blank character is a #
# Application shortcuts
our @application_shortcuts = split /\n/, <<'END';
xfconf-query -c xfce4-keyboard-shortcuts -p /commands/custom/
<Super>e emacs
<Super><Alt>e gksu emacs
<Super>t thunar
<Super><Alt>t gksu thunar
<Super>c gnome-terminal --profile=JH_app
<Super><Alt>c gnome-terminal --profile=JH_root -e su - bash
<Super>r gnome-terminal --profile=JH_remote
F12 ''
END
# Window shortcuts
our @window_shortcuts = split /\n/, <<'END';
xfconf-query -c xfce4-keyboard-shortcuts -p /xfwm4/custom/
<Control><Alt>Right next_workspace_key
<Control><Alt>Left prev_workspace_key
... snip ...
# Various properties
our @various_properties = split /\n/, <<'END';
xfconf-query -c keyboard -p /Default/
RestoreNumlock true
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/
lock-screen-suspend-hibernate false
xfconf-query -c xsettings -p /Net/
ThemeName Ia Ora Arctic
IconThemeName Oxygen
DoubleClickTime 270
xfconf-query -c xsettings -p /Gtk/
FontName Sans 10
xfconf-query -c xsettings -p /Xft/
DPI **SCREEN_DPI
END
# Bookmarks for Thunar sidebar
# $<symbol> will be converted to $ENV{'<ymbol>'}
our @thunar_places = split /\n/, <<'END';
$HOME/common/info Info
$HOME/common/info/Platforms/Mageia/6 Mageia-6
$HOME/.local/share/applications Applications
/common/usr/local/share/icons Icons
sftp://$ALT_HOST$HOME $ALT_HOST
END
(variables like SCREEN_DPI are perl constants defined at script initialisations, variables like $HOST_NAME or $HOST refer to shell variables)
Essentially, the script contains a wrapper that reads these definition lists and generates corresponding system calls. These calls use
xfconf-query as discussed here
dconf load <path> to import canned (created with dconf dump) definitions - in my case used for defining the properties of gnome-terminal along with profies (I use gnome-terminal because I want to have profiles)
Launching these system calls is done with the "DoCommand" utility procedure, as illustrated by a snippet from the end of the wrapper code
... snip ...
unless ( $global_vars{'DEBUG_FLAGS'} & NO_VARIOUS_PROPS)
{ ConfigureProperties ( 'various_props', @various_properties ); }
my $x_density = 96;
if ( $global_vars{'MACHINE_ID'} & DELL_E6530 ) {
$x_density = 102;
DoCommand ( 'touch-pad', 'xfconf-query -c pointers -p '.
'/AlpsPS2_ALPS_DualPoint_Stick/Properties/'.
'Device_Enabled -t uint -s 0 -n' );
}
# Create configuration files for various desktop components
unless ( $global_vars{'DEBUG_FLAGS'} & NO_APP_FILES ) {
DoCommand ( 'gnome-terminal', 'cat '.$x_template.'gnome_terminal | '.
'dconf load /org/gnome/terminal/' );
DoCommand ( 'thunar-path', 'mkdir -p '.CONF_DIR.'/Thunar' );
DoCommand ( 'thunar-actions', "cp $x_template".'uca.xml '.CONF_DIR.
'/Thunar/uca.xml' );
DoCommand ( 'mousepad-path', 'mkdir -p '.CONF_DIR.'/Mousepad' );
DoCommand ( 'mousepad-config', "cp $x_template".'mousepad '.CONF_DIR.
'/Mousepad/settings.conf' );
DoCommand ( 'atril-path', 'mkdir -p '.CONF_DIR.'/atril' );
DoCommand ( 'mousepad-config', "cp $x_template".'atril_toolbar.xml '.
CONF_DIR.'/atril/' );
DoBookmarks ( 'thunar-places' );
}
# Erase the cache and restart the panels
DoCommand ( 'restart_a', 'rm -rf .cache/xfce4' );
DoCommand ( 'restart_b', 'xfce4-panel --restart' );
The $global_vars hash contains common control variables defined at initialisation; the upper-case symbols are perl constants used for customising the behaviour of the script - for instancedebugging control (only printing commands rather than launching them, suppressing certain commands - the first argument of the DoCommand call is a label for the debugging output). This example also illustrates how template files for xfce components like Thunar are imported.
Some damping of enthusiasm on the use such scripts: the script itself is easy to use and easy to adapt to specific needs (it took me less than a week to write). But there is a very time-consuming additional action which is hidden: the confection of the application desktop items in .local/share/applications and - if application menu buttons are used - the corresponding files in desktop-directories and .config/menus. In my case, this was a minor effort: I am a KDE refugee, and just needed to do some editing of the files that had been created during many years of using KDE. Anyhow, as illustrated by the import from KDE, this is a on-time effort and will practically require no modification over many years and generations of software.
The script (a directory with several perl .pm modules - the lists that specify the desktop configuration are contained in 2 such modules), along with a sub-directory with all the needed template files, is grouped into a directory - easy to import at system (or user) generation.
I have made this post as short as reasonably possible, just to illustrate the power of such a tool. If there is interest, I can evidently post more explanations and/or extensive pieces of code, resp. mail the code of my application. I think that the technical description of ingrediants that help to configure an xfce desktop is only one aspect of this forum thread.
The - probably more important - other aspect is that there is a need for tools that make life easier for xfce users to efficiently generate their desktop, and to do this again and again as they go from machine to machine, and form OS release to OS release. The examples of the shell script discussed and of my perl script are tuned to specific needs of particular users - is it possible to have something more general and easy to use by users that do not have programming skills?
Offline
I had, a couple of weeks ago, completed something quite similar, but implemented with the power of a perl script. I had hesitated to post such a complex matter, but as a complement to the discussed shell script it now is interesting to give a short illustration of my alternative.
Many thanks for your contribution to the discussion! I had considered using Perl instead of Bash, but my Perl knowledge is just a little too limited to feel comfortable about tackling such a task in Perl without some help.
The examples of the shell script discussed and of my perl script are tuned to specific needs of particular users - is it possible to have something more general and easy to use by users that do not have programming skills?
I've been wondering about this, too. As a first step, perhaps a precise configuration file format (akin to the declarations that you use in your Perl code) could be a great help. Then, if the file format turns out to work well, some kind of front-end, to generate the configuration file, could be developed?
Offline
I have done some "destructive thinking" - as a result, I do not think that it is a good idea to try to develop scripting into some kind of general tool:
Xfce contains a nice and user-friendly GUI for designing an Xfce the desktop;
composing an elaborate desktop environment with this GUI is easy, also for a user without any programming experience - but necessarily a very lengthy activity;
the drawback of present Xfce is that the result of this lengthy and tedious work is lost as soon as Xfce is (re-)initialised / initially created: the desktop environment is stored in internal structures of Xfce, there exist no easy-to-use tools for import and export;
essentially, our scripts are work-arounds that address this drawback - at the price of rejecting the GUI in favour of using a programming approach - from a methodology point of view a regression; there is some unwanted irony in my question on making this accessible to users without programming skills;
A solid solution should probably build on exporting / importing the internal stuctures used by Xfce (at the level of the xml files or of the config-query interface); to decide on the appropriate approach requires insight into Xfce which I do not have. Seeing the large number of posts asking how to carry an environt to another machine or another OS version, this is an important issue.
Offline
A solid solution should probably build on exporting / importing the internal stuctures used by Xfce (at the level of the xml files or of the config-query interface)
Now that you mention it, I think you should be able to backup the XFCE desktop configuration, and restore it under a different user account or on a different computer. It is kept in a directory hierarchy under the home directory, something like ".config/xfce4" or ".xfce4" or some such (cannot check at the moment, since I'm not near an XFCE computer). I remember experimenting with it, and I'm pretty sure it is doable; the only issues that I enccountered were: (a) correctly setting file permissions and ownership (but that's easy to fix with the chmod and chown commands); and (b) fixing references to the user account name and home directory that show up in various places (should also be doable, with a little text substitution logic built in to the process).
I could have further pursued this approach (I must still have a somewhat usable XFCE configuration backup archive lying around somewhere, I believe), but I eventually decided to go for a script-based solution when I realised that I wasn't really interested in a complete backup and restore of the XFCE configuration, but only in the panel setup, which I find tedious to have to redo over and over again.
I think I recently even discovered a backup and restore option on the latest XFCE desktop release, but I haven't tried it.
Offline
This reply put ideas into my head. There exists an extremely simple approach for creating scripts that export a complete Xfce environment and that allow to restore it elsewhere:
Use "xfconfig-query -l" to obtain a list of its channels.
For each channel, use "xfconf-query -c <channel> -lv" to obtain a list of all its properties.
For each property thus obtained, wrap it into a corresponding command that will re-create the property at restore time; this requires editing of the output from xfconf-query to add "type" and "set" items (plus -n and, where necessary, -a ) .
Store each such command into a file (e.g. one file for each channel).
Restore the xfce command by doing the inverse operations, reading the channel-specific files and submitting the xfconf-query commands stored in the file.
I did a quick feasibility check: a bare-bones script for dumping takes about 100 lines of perl code, a script for restoring much less. I had expected problems with issues like (a) is it possibly to determine the type of properties - necessary for restoring - by simply inspecting the values and letting the script guess? and (2) can the sequence of the output generated by the dump be used tel quel as the sequence in which commands are submitted at restore time? For feasibility checking, I only restored (after destroying what there was) the xfce4-panel channel. No problems, the environment thus obtained was perfectly usable.
It should be easy to turn this into a commonly usable tool for cloning Xfce environments - touch wood unless difficulties appear when you get down to the level of details.
Last edited by jharms (2016-12-11 13:53:19)
Offline
Amazing. One of the most well organized, valuable-content-rich community sites I've ever seen. I've been using Xubuntu exclusively for at least 5 years, and knew it was best of breed right away, but never bothered to check out xfce.org until now. Thanks to all contributors. "This is Yuge!".
Offline
So, just to confirm, the above ( #9 ) still is working in XFCE on Debian Bookworm (and all the same caveats apply, this can mess up your panel if something goes wrong.) Also, I adapted #9's instructions to a bash script as follows:
# Add a shortcut to panel-2
# adapted from https://forum.xfce.org/viewtopic.php?id=8619 #9
DESKTOP_FILE=launchMe.desktop
LAUNCHER_UID=90
LAUNCHER_FOLDER=~/.config/xfce4/panel/launcher-$LAUNCHER_UID
PLUGIN_GROUP=/plugins/plugin-$LAUNCHER_UID
PLUGIN_IDs=/panels/panel-2/plugin-ids
mkdir -p $LAUNCHER_FOLDER
cp $DESKTOP_FILE $LAUNCHER_FOLDER
xfconf-query -c xfce4-panel -p $PLUGIN_GROUP -t string -s "launcher" --create
xfconf-query -c xfce4-panel -p $PLUGIN_GROUP/items -t string -s "$DESKTOP_FILE" -a --create
PANEL_IDs=`xfconf-query -c xfce4-panel -p $PLUGIN_IDs| grep -v "Value is an\|^$"`
xfconf-query -c xfce4-panel -p $PLUGIN_IDs -rR
PANEL_ID_ARRAY=($PANEL_IDs)
declare -a BUILD_PANEL=( xfconf-query -c xfce4-panel -p $PLUGIN_IDs )
for i in "${PANEL_ID_ARRAY[@]}"
do
BUILD_PANEL+=( -t int -s "$i" )
done
BUILD_PANEL+=( -t int -s "$LAUNCHER_UID" --create )
`${BUILD_PANEL[@]}`
xfce4-panel -r
Last edited by MangoCat (2024-05-07 18:13:44)
Offline
I've recently been working out how to replace the entire panel by using the utility 'xfce4-panel-profiles' (available in the standard repositories).
Simplified example importing a previously exported panel profile file:
profile='xfce_panel_profile_linux_mint_21.3_2024-05-27.tar.bz2'
xfce4-panel-profiles load "$profile"
but I discovered that one or more of the new launchers would not be configured correctly if there were other launcher directories already present in the folder $HOME/.config/xfce4/panel/. Presumably this results from a bug in xfce4-panel-profiles, but I haven't got around to checking the python source yet.
To mitigate the problem, I first removed the existing launcher directories:
for d in $HOME/.config/xfce4/panel/launcher-*
do
[ -d "$d" ] && rm -r "$d"
done
profile='xfce_panel_profile_linux_mint_21.3_2024-05-27.tar.bz2'
xfce4-panel-profiles load "$profile"
after which it works perfectly.
In case the current panel configuration needs to be retained for possible future use, it can be saved in a panel profile file before the launcher directories are removed:
# Backup existing panel profile
now="$(date +"%F_%H-%M-%S")"
profdir="$HOME/.config/xfce4/panel/profiles"
mkdir -p "$profdir"
xfce4-panel-profiles save "$profdir/$now.tar.bz2"
for d in $HOME/.config/xfce4/panel/launcher-*
do
[ -d "$d" ] && rm -r "$d"
done
profile='xfce_panel_profile_linux_mint_21.3_2024-05-27.tar.bz2'
xfce4-panel-profiles load "$profile"
Offline
my use case for scripting Xfce setup is to copy all the settings in exactly one text-editable file. if everything was in some INI-like or XML-like format, that would be most of what i need. then i would need a tool to export all of the settings (given a user name or home directory if defaults are undesired) to STDOUT or a specified file, and a tool to input (STDIN or a specified file) such a file and set all the saved settings. it could be used to spread settings to a new user and/or host, or as a visible backup. or it could be edited to do fine tweaking of settings (reposition or resize something by ONE pixel, which is hard to do visually).
Last edited by Skaperen (2024-08-08 01:30:29)
Offline
[ Generated in 0.013 seconds, 7 queries executed - Memory usage: 656.38 KiB (Peak: 689.22 KiB) ]