[kde] Re: Running dolphin from a shell script and opening it in a specific directory.
John Woodhouse posted on Thu, 02 Jun 2011 01:38:01 -0700 as excerpted: One aspect - the script will be run via a desktop icon which I assume means a .desktop file to activate it running in the console. That means the shell will flash up briefly which is rather untidy. Maybe there is no need to use run in console?. But I wondered if there was a run in console option to stop it from displaying. I vaguely recollect some mention of achieving that on 3.x You're right about the no need to use run in terminal (console implies non- X, terminal implies konsole/xterm or some other X based terminal window, it's the latter that's in question here and I just checked the option in kde to be sure, at least here, 4.6.3, it's run in terminal), in that case. You only need the run in terminal (whether X app or not, you can use the checkbox to get the STDOUT/STDERR out of an X/KDE app if you want...) if you want to see the output (STDOUT/STDERR, tho you could of course redirect them to a file instead, thus avoiding the need for terminal in that case) or the app needs terminal STDIN (a bit more problematic, unless you can predict the input effectively enough to use redirection from a file for it as well). If you don't need those resources you don't need run in terminal, and thus don't get the momentary terminal popup. PS Duncan I do believe my xorg.conf is indented. The forum posts removed the indentations. It would be rather unusual for me not to do it that way. I should have use the code option in the post. I was wondering what kind of crazy documentation or tool you used that didn't describe or create an indented xorg.conf... But the forum software reformatting it does explain... Meanwhile, are you going to try omitting the various sections as suggested, or are you taking an if it works, don't break it attitude? The don't break what's working stance is certainly a valid choice, but if you do try it without those sections, I'd appreciate it if you posted your results, confirming or disproving my suspicions. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Running dolphin from a shell script and opening it in a specific directory.
Meanwhile, are you going to try omitting the various sections as suggested, or are you taking an if it works, don't break it attitude? The don't break what's working stance is certainly a valid choice, but if you do try it without those sections, I'd appreciate it if you posted your results, confirming or disproving my suspicions. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman When the nvidia drivers are installed even with their own .run files rather than an rpm a separate utility run file is generate to produce the xorg.conf file. I use a mix of old and new in some ways. As a for instance I use a now very old compaq plug in keyboard and a wireless mouse. I have adopted the if it works leave it alone. The only problem was the lack of the edid for self configuration. I will try omitting sections later when I have the rest of the machine ok for me but suspect nvidia will have done what it needs to do. Immediate problem is the nas. Sorting out just what else in the samba,netbios,ldap etc etc line it needs will take some time. White space can be peculiar on some systems so I normally take the precaution of not using tabs other than those that generate spaces. In this case I didn't bother to find out just what kwrite uses. As to indent style personally I dislike small indents some what intensely. A result of being paid to write software on and off for 15 odd years and solidly for another 15+. All in the same company. ;-) We all develop our own preferences. John ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Tim Edwards posted on Thu, 02 Jun 2011 11:53:52 +0200 as excerpted: Recently I found that knetworkmanager wasn't starting up when I logged into KDE. I tried looking for any mention of it in the 'startup and shutdown' control centre module, but no luck. Eventually I found a tip on a forum that I had to set 'Autostart=true' in ~/.kde4/share/config/networkmanagementrc FWIW I don't use networkmanager at all, here. I have two main systems here. My workstation is setup with a constant wired Ethernet connection that's started as one of the system init services. My netbook... isn't really used as a /net/book but rather as a portable un-networked computer most of the time. Its Ethernet, which I use for updating from the dedicated 32-bit chroot system image on my otherwise 64-bit workstation, is likewise initscript controlled but in a non-default runlevel, and its wireless hasn't been a big priority for me. I did try to get the netbook wireless networking running at one point but failed, I believe due to a kernel bug with the particular kernel I was running at the time. I've since upgraded kernels but as I said, it hasn't been a big priority to get that working, and I've not gotten back to it. As such I can't and won't attempt to deal with the networkmanager stuff at all. However, I can help with the following... So my question is, what's the status of the autostart stuff: Shouldn't it all be configurable through the standard control centre module which stores its settings in the standard (~/.config/autostart) directory? Not really. The setting found in that location serve a specific purpose -- USER configurable autostart (and auto-stop). It's not for general KDE/ desktop services (there's a different place to configure that) or for general system services (configured using whatever tools your distribution provides for setting up and configuring system initscripts and services). Does KDE go scanning through ~/.kde4/share/config/ looking for 'Autostart=' in rc-files? I don't believe so in general. However, knetworkmanager is evidently (the caveat about my not running it here applies, thus evidently, based purely on the evidence you reported above) available as a kde desktop service if so configured, and this is /evidently/ the config-file location where that preference is stored. Presumably there's also a GUI option controlling it somewhere, but since I don't have the software installed, I can't be sure where that might be. But, I can explain a bit more about autostart in general... First, it's useful to name the ways that kde does autostart. These are the ones I am as a user aware of, in general from the surface-most to the deepest infrastructure: 1) KDE session. This is controlled via kcontrol[1][2], system administration, startup and shutdown, session management, under on login. If you set restore previous session (as I have), kde will restart the apps that you had running when you logged out, with the exception of anything listed in the exceptions list. Alternatively, you can elect to restore a manually saved session. The help for this item says that if it's checked (I don't know since I use the restore previous session option), there's a save session option added to the leave menu, along with the others. The third alternative is to start with an empty session. At this level, kde autostart is controlled by whatever it found running when it saved the session, either when that option was chosen if save session is set, or at logout, if that setting is set. If you use empty session, you're simply telling kde not to autostart anything at this level. 2) The autostart functionality I believe you were referring to. The GUI for this is kcontrol, system administration, startup and shutdown, autostart. The GUI provided actually controls four different launch options with differing purposes in one place. 2a) Desktop files. This is the freedesktop.org standard *.desktop file launch option. The *.desktop files in question can be found in $XDG_CONFIG_HOME/autostart. The default for XDG_CONFIG_HOME if that variable is unset, is $HOME/.config/, so the default location is ~/.config/autostart/ , if you wish to manually add your own *.desktop files. Once they are added, if you select one and hit advanced, there's an option to autostart in kde only, which adds an appropriate line to the *.desktop file. If this isn't set, any freedesktop.org compliant environment (gnome and xfce I believe, probably others as well) should see and launch these apps when the user logs in. 2b) What the kcontrol autostart GUI lists as script files is actually three separate options, as once you add a script using the GUI, there's a dropdown box allowing you to select startup, shutdown, or pre-kde-startup. Scripts in question should be set executable and named as *.sh. (The startup option lets you use any name, but if you change it to shutdown or
[kde] Re: Autostart locations in KDE4
Tim Edwards wrote, On 06/02/2011 03:53 AM:
Recently I found that knetworkmanager wasn't starting up when I logged
into KDE. I tried looking for any mention of it in the 'startup and
shutdown' control centre module, but no luck. Eventually I found a tip
on a forum that I had to set 'Autostart=true' in
~/.kde4/share/config/networkmanagementrc
So my question is, what's the status of the autostart stuff:
Shouldn't it all be configurable through the standard control centre
module which stores its settings in the standard (~/.config/autostart)
directory?
Does KDE go scanning through ~/.kde4/share/config/ looking for
'Autostart=' in rc-files?
Tim,
In case it's any help, i enclose a script that dumps out the KDE4 configuration
operational environment in a nice concise format.
There would be a difference between the autostart path and the config path.
The config path would be scanned until it finds a networkmanagementrc file.
I believe
kde4-config --locate networkmanagementrc --path config
would show which file ultimately is going to be used. (i think it's a scan
and stop on first found algorithm, rather than a merge all files found
that match in the path operation). it'll show nothing if no config file
is found in the path.
I was surprised when using the kcmshell4 autostart center that it was using
the XDG autostart path to write a new autostart desktop function. I thought
it would prefer the KDE4 autostart path. I'm not sure if that indicates
a future deprecation of the KDE4 specific autostart directory in favor
of XDG integration?
If so, you may need to use the 'OnlyShowIn=KDE' directives in such XDG pathed
autostart files if the given application can't or shouldn't run in other
desktop environments.
--stephen
#!/bin/sh
# Get some Configuration info on KDE
echo [VersionInfo]
#kdeconf() { kde3-config $@ ;} # KDE3
kdeconf() { kde4-config $@ ;} # KDE4
kdeconf --version
# http://techbase.kde.org/KDE_System_Administration/Environment_Variables
echo
echo [Environment]
while read var default; do
printf %24s = %s\n ${var} $(eval echo \${$var-${default}\(\*\)})
doneEOF
KDE_FULL_SESSION
KDE_SESSION_UID
KDE_SESSION_VERSION
KDEWM kwin
KDE_DISPLAY
KDE_MULTIHEAD
KDEDIRS
KDEHOME ${HOME}/.kde
KDE_HOME_READONLY
KDEROOTHOME ~root/.kde
KDESYCOCA
KDETMP /tmp
KDEVARTMP /var/tmp
KDE_LANG
KDE_UTF8_FILENAMES
KDE_NO_IPV6
KDE_USE_IDN at:ch:cn:de:dk:kr:jp:li:no:se:tw
KDE_IS_PRELINKED
KDE_MALLOC
KDE_NOUNLOAD
KDE_DOUNLOAD
KDE_DEBUG
KDE_DEBUG_NOPROCESSINFO
KDE_DEBUG_NOAREANAME
KDE_DEBUG_NOMETHODNAME
KDE_DEBUG_FILELINE
KDE_DEBUG_TIMESTAMP
KDE_COLOR_DEBUG
KDE_FORK_SLAVES
EOF
echo (*) indicates variable unset and a default value substituted
echo
echo [Configuration]
while read option; do
printf %18s = %s\n ${option} $(kde4-config --${option})
doneEOF
prefix
exec-prefix
libsuffix
localprefix
qt-prefix
qt-binaries
qt-libraries
qt-plugins
EOF
# --kde-version Compiled in version string for KDE libraries
# --locate filename Find filename inside the resource type given to
--path
echo
echo [UserPaths]
#KDE3#for upath in desktop trash autostart document; do
for upath in desktop autostart document; do
printf %18s = %s\n ${upath} $(kdeconf --userpath ${upath})
done
echo
echo [Paths]
while read ktype ksep kdescription; do
# printf PATH(${ktype}) [${kdescription}]\n $(kdeconf --path ${ktype})\n
printf %18s = %s [%s]\n ${ktype} $(kdeconf --path ${ktype}) $(kdeconf
--install ${ktype})
done EOF
$(kdeconf --types)
EOF
echo values in []'s are application install paths
exit 0
#!/bin/sh
# Get some Configuration info on XDG
echo [Environment]
while read var default; do
printf %24s = %s\n ${var} $(eval echo \${$var-${default}\(\*\)})
doneEOF
XDG_DATA_HOME ${HOME}/.local/share
XDG_CONFIG_HOME ${HOME}/.config
XDG_DATA_DIRS /usr/local/share/:/usr/share/
XDG_CONFIG_DIRS /etc/xdg
XDG_CACHE_HOME ${HOME}/.cache
XDG_RUNTIME_DIR
EOF
echo (*) indicates variable unset and a default value substituted
echo
echo [Settings]
while read var desc; do
printf %24s = %s\n ${var} $(xdg-settings get ${var})
doneEOF
$(xdg-settings --list | tail -n +2 )
EOF
exit 0
: END_NOTES
xdg-settings get default-web-browser
xdg-settings check default-web-browser firefox.desktop
xdg-settings set default-web-browser google-chrome.desktop
XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
XDG_SESSION_COOKIE=3d6a4039eaa90b76b81b1f610030-1305560072.916037-352205480
sdowdy@zia$ xdg-settings --list
Known properties:
default-web-browser Default web browser
sdowdy@zia$ xdg-settings get default-web-browser
kfmclient_html.desktop
$XDG_DATA_HOME defines the base directory relative to which user specific data
files should be stored. If $XDG_DATA_HOME is either not set or empty, a default
equal to $HOME/.local/share should
[kde] Programmatically adding plasmoid widgets to the plasma panel?
I have hunted around a bit, but not come up with anything i can
run with yet, but want to populate the plasma panel with standard
widgets. Below is a shell script i use on KDE3 to allow user to
quickly select some standard widgets to add to 'kicker' panel,
but i'd like the equivalent for KDE4. At least i'd like to know
how to programmatically install a widget similar to what i'm
doing below.
Anyway, 'kwriteconfig' is certainly not a viable tool to manipulate
either KDE3's kicker panel config file, nor the plasma config file
(that one's even more horrific requiring a full parse to figure
out indexes of multi-variant arrays, blah...)
I ran across some cursory ECMAscript docs for plasma, and if that's
the way to go, any example code anybody's got is welcome.
Anyway, any pointers appreciated.
thanks,
--stephen
#!/bin/sh
# Title:kde3-install-kicker-buttons
# Purpose: Install some standard default buttons on the KDE3 kicker panel
# Author: Stephen Dowdy (sdowdy @ ucar.edu)
if ! dcop /dev/null 21 ; then
echo This must be run in a KDE3 user session
exit 1
fi
add_xfreerdp_button() { winserver=$1 windomain=$2
dcop kicker Panel addNonKDEAppButton \
XFreeRDP to ${winserver} \
XFreeRDP session to Windows terminal server ${winserver} \
/usr/local/freerdp/bin/xfreerdp samba.png \
-u \${USER} ${windomain:+-d ${windomain}} -g 90% -x m --plugin cliprdr
--plugin rdpdr --data disk:LNXWIN:\${HOME}/tsclient -- ${winserver} \
true
if [ ! -d ${HOME}/tsclient ]; then
mkdir ${HOME}/tsclient
chmod 700 ${HOME}/tsclient
fi
}
add_xfreerdp_WINSERVER_button() { add_xfreerdp_button WINSERVER WINDOMAIN ;}
add_locklogout_button() {
# Add Lock/Logout button if it doesn't already exist
if ! dcop kicker Panel listApplets | grep -q 'lockout.desktop'; then
echo Adding Lock/Logout button to Kicker Panel
dcop kicker Panel insertApplet lockout.desktop $(dcop kicker Panel
listApplets | wc -l)
else
echo NOTICE: Lock/Logout button already installed
fi
}
add_konsole_button() {
# Add Konsole button if it doesn't already exist
if ! dcop kicker Panel listApplets | grep -q 'Konsole'; then
echo Adding Lock/Logout button to Kicker Panel
dcop kicker Panel addServiceButton Konsole
else
echo NOTICE: Konsole button already installed
fi
}
add_firefox_button() {
# Add Firefox button if it doesn't already exist (can't really tell easily)
dcop kicker Panel addNonKDEAppButton Firefox Mozilla Firefox Web
Browser /usr/local/firefox/firefox /usr/local/firefox/icons/mozicon128.png
false
}
add_thunderbird_button() {
# Add Thunderbird button if it doesn't already exist (can't really tell easily)
dcop kicker Panel addNonKDEAppButton Thunderbird Mozilla Thunderbird
E-mail client /usr/local/thunderbird/thunderbird
/usr/local/thunderbird/chrome/icons/default/default256.png false
}
for button in \
$(kdialog --geometry 600x400 --title Jazzing up the KDE3 Kicker Panel \
--checklist Select Buttons to add to KDE3 Kicker Panel \
firefox Firefox Browser on \
thunderbird Thunderbird E-Mail client on \
xfreerdp_WINSERVER XFreeRDP session to WINSERVER off \
konsole Konsole Terminal Button on \
locklogout Lock/Logout Buttonon \
| tr -d ''
)
do
echo Selected: ${button}
eval add_${button}_button
done
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
___
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
[kde] Re: Programmatically adding plasmoid widgets to the plasma panel?
On Thursday, 2011-06-02, Stephen Dowdy wrote: I have hunted around a bit, but not come up with anything i can run with yet, but want to populate the plasma panel with standard widgets. Below is a shell script i use on KDE3 to allow user to quickly select some standard widgets to add to 'kicker' panel, but i'd like the equivalent for KDE4. At least i'd like to know how to programmatically install a widget similar to what i'm doing below. Anyway, 'kwriteconfig' is certainly not a viable tool to manipulate either KDE3's kicker panel config file, nor the plasma config file (that one's even more horrific requiring a full parse to figure out indexes of multi-variant arrays, blah...) I ran across some cursory ECMAscript docs for plasma, and if that's the way to go, any example code anybody's got is welcome. Anyway, any pointers appreciated. Best source for answers on this level is probably the plasma-devel mailinglist. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
On Thu, 02 Jun 2011 14:54 +, Duncan 1i5t5.dun...@cox.net wrote: Tim Edwards posted on Thu, 02 Jun 2011 11:53:52 +0200 as excerpted: Recently I found that knetworkmanager wasn't starting up when I logged into KDE. I tried looking for any mention of it in the 'startup and shutdown' control centre module, but no luck. Eventually I found a tip on a forum that I had to set 'Autostart=true' in ~/.kde4/share/config/networkmanagementrc FWIW I don't use networkmanager at all, here. I have two main systems here. My workstation is setup with a constant wired Ethernet connection that's started as one of the system init services. My netbook... isn't really used as a /net/book but rather as a portable un-networked computer most of the time. Its Ethernet, which I use for updating from the dedicated 32-bit chroot system image on my otherwise 64-bit workstation, is likewise initscript controlled but in a non-default runlevel, and its wireless hasn't been a big priority for me. I did try to get the netbook wireless networking running at one point but failed, I believe due to a kernel bug with the particular kernel I was running at the time. I've since upgraded kernels but as I said, it hasn't been a big priority to get that working, and I've not gotten back to it. As such I can't and won't attempt to deal with the networkmanager stuff at all. However, I can help with the following... So my question is, what's the status of the autostart stuff: Shouldn't it all be configurable through the standard control centre module which stores its settings in the standard (~/.config/autostart) directory? Not really. The setting found in that location serve a specific purpose -- USER configurable autostart (and auto-stop). It's not for general KDE/ desktop services (there's a different place to configure that) or for general system services (configured using whatever tools your distribution provides for setting up and configuring system initscripts and services). Does KDE go scanning through ~/.kde4/share/config/ looking for 'Autostart=' in rc-files? I don't believe so in general. However, knetworkmanager is evidently (the caveat about my not running it here applies, thus evidently, based purely on the evidence you reported above) available as a kde desktop service if so configured, and this is /evidently/ the config-file location where that preference is stored. Presumably there's also a GUI option controlling it somewhere, but since I don't have the software installed, I can't be sure where that might be. First off, thanks for the detailed explanation of the autostart locations, I've saved it to a text file as a reference. However the problem is that although all those autostart locations you detailed are managed by the Startup Shutdown control centre module nothing resembling networkmanager appears in that control centre module. I think that's at least 2 bugs: 1) The fact that KDE scans rc-files in some fashion to start programs, a behaviour that sounds hacky and probably isn't documented anywhere but in the code itself. These programs should appear properly in Startup Shutdown-Services 2) A bug in knetworkmanager that it doesn't register itself in Startup Shutdown-Services Not to mention that it's not the only program that does this. Going through the icons in my control bar I see the following programs that start with KDE, do not appear in Startup Shutdown module and are not widgets: Klipper (.kde4/share/config/klipperrc) Kmix (.kde4/share/config/kmixrc) Size Change and Rotate (.kde4/share/config/krandrrc) Korganizer Reminder Module (.kde4/share/config/korgacrc) So if you have any of the following installed on your machine you'll be able to see the same behaviour. Tim ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Autostart locations in KDE4
Tim Edwards wrote, On 06/02/2011 02:10 PM: Thanks for the script. I'm not sure what you mean exactly. The config path is: config = /home/tim/.kde4/share/config/:/usr/share/kde4/config/:/etc/kde4/share/config/ [/usr/share/kde4/config/] Does that mean KDE scans all those directories for rc-files, and then starts any that have autostart=true? No, I think what you're really looking at (i could be wrong), is that the networkmanager desktop autostart file (on my Debian Squeeze machine, this is located in /usr/share/autostart/kde-4-knetworkmanager-autostart.desktop ) has an execution conditional in it... X-KDE-autostart-condition=networkmanagementrc:General:Autostart:true So, in order to autostart networkmanager, it needs to find a configuration key named Autostart within the General group of the networkmanagementrc configuration file that is true. $ kreadconfig --file networkmanagementrc --group General --key Autostart (i don't have such a key in my config search path) So, it must default to 'true', I suspect that you have it set FALSE somewhere. $ kde4-config --locate networkmanagementrc --path config /home/sdowdy/.kde/share/config/networkmanagementrc This is the file that is found first within the config path To force Autostart to True, do... kwriteconfig --file networkmanagementrc --group General --key Autostart true That will write it into the first path component in the config path (for you: /home/tim/.kde4/share/config/networkmanagementrc) So, the *autostart* files are separate from the configuration files, but because the networkmanager desktop autostart file is making a demand for a config path conditional, the config stuff gets pulled into the mix here. From quickly glancing at another message of yours. Those other applications are probably configured in the KDE4 system autostart install path, thus not *user* managed. My 'kde4-info' script doesn't identify that path (because kde4-config doesn't show it either), but as you see from above it is /usr/share/autostart. This brings up a point about *Disabling* those system installed defaults. Theoretically, they should all have a 'X-KDE-autostart-condition' directive so the user could create disabling overrides. But notice they don't all: $ grep -c X-KDE-autostart-condition /usr/share/autostart/* /usr/share/autostart/kab2kabc.desktop:1 /usr/share/autostart/kaddressbookmigrator.desktop:1 /usr/share/autostart/kalarm.autostart.desktop:1 /usr/share/autostart/kgpg.desktop:1 /usr/share/autostart/klipper.desktop:1 /usr/share/autostart/kmix_autostart.desktop:1 /usr/share/autostart/konqy_preload.desktop:1 /usr/share/autostart/korgac.desktop:1 /usr/share/autostart/krunner.desktop:0 /usr/share/autostart/nepomukserver.desktop:1 /usr/share/autostart/plasma-desktop.desktop:0 /usr/share/autostart/restore_kmix_volumes.desktop:1 So, it is presumed that you MUST run krunner and plasma-desktop on my machine. I wanted to replace 'plasma-desktop' with one that started 'plasma-desktop --graphicssystem=raster'. From what little documentation i ran across there was a method of a user created autostart OVERRIDE of a system autostart. I.E. create the same filename and disable it from running. Then i was going to create a 'plasma-desktop-rastergraphics.desktop' that invoked the command above, instead. Unfortunately, Debian Squeeze forcibly deletes any 'plasma-desktop.desktop' file in the user's autostart directory in 'startkde' to address some other bug. I think that solution is itself a bug, breaking this override mechanism (as i understand it) Oh well, there are plenty of other significant bugs in KDE4 i'm having to deal with. (kquitapp plasma-desktop sleep 3 plasma-desktop --graphicssystem=raster) then has to become a KDE4 Autostart script to workaround this particular bug :-( Hopefully that answers your question... --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/ ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Re: Programmatically adding plasmoid widgets to the plasma panel?
Kevin Krammer posted on Thu, 02 Jun 2011 21:33:11 +0200 as excerpted: On Thursday, 2011-06-02, Stephen Dowdy wrote: I have hunted around a bit, but not come up with anything i can run with yet, but want to populate the plasma panel with standard widgets. Below is a shell script i use on KDE3 to allow user to quickly select some standard widgets to add to 'kicker' panel, but i'd like the equivalent for KDE4. At least i'd like to know how to programmatically install a widget similar to what i'm doing below. Anyway, 'kwriteconfig' is certainly not a viable tool to manipulate either KDE3's kicker panel config file, nor the plasma config file (that one's even more horrific requiring a full parse to figure out indexes of multi-variant arrays, blah...) I ran across some cursory ECMAscript docs for plasma, and if that's the way to go, any example code anybody's got is welcome. Anyway, any pointers appreciated. Best source for answers on this level is probably the plasma-devel mailinglist. That's definitely true, but here's some info to get started with... I from 4.6 at least (maybe 4.5 IDR), the plasma panel setup is fully scriptable. I recall reading blogs about it. FWIW I believe the native scripting language is javascript. In kde 4.6, with widgets unlocked, if you context click (or use the cashew/toolbox) and select new panel, there are now several entries including one for default panel. IIRC according to that blog entry, users were frequently deleting their panel and then figuring out how to add a new panel, but it was empty and they had to add back all the default items, pretty hard when you don't remember what they were and you're just a normal user that doesn't really understand what's going on in the first place, and thus is rather intimidated by it all! They had already planned the scripting feature, tho, so after that was committed all they needed was a script to bring back the default panel. =:^) Taking a look at the package (plasma-workspace, here on Gentoo) list of system files, it appears that the templates are in /usr/share/apps/plasma/layout-templates/ Browse that (or your distros equivalent) a bit and you can probably figure out the basics. Let's see if I have similar good luck with google... OK, here's the blog I was remembering... http://aseigo.blogspot.com/2010/04/solving-little-problem-with-slightly.html ... and here's a google search that should get you (OP) started on more (the techbase link should be useful, at first I was getting a bunch of plasma-tv and etc. hits I had to screen out thus the -word bits)... http://www.google.com/search?q=plasma+panel+script+-flat+-tv+-theaterhl=ennum=10lr=ft=icr=safe=imagestbs=#sclient=psyhl=enlr=source=hpq=kde+plasma+panel+script+default+-flat+-tv+-theateraq=faqi=aql=oq=pbx=1bav=on.2,or.r_gc.r_pw.fp=376cf53bf65d1173biw=952bih=892 If that's not enough, then as Kevin suggests, the plasma-devel list is probably your best bet. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
