Plasma desktop init scripting

[Aaron J. Seigo]

On Friday, December 24, 2010, Jeremiah Summers wrote:
> On Fri, Dec 24, 2010 at 9:36 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Wednesday, December 22, 2010, Jeremiah Summers wrote:
> > > It would be nice if there were examples for loading folderview as the
> > > default activity (ie. classic desktop) setting its backend and maybe
> > > placing a widget at the bottom right of the screen ie. a trash can. I
> > 
> > have
> > 
> > so ... you want us to write your init script for you ;P
> > 
> > more seriously, i'm unclear as to what is missing in the documentation
> > that makes this difficult to achieve. perhaps that's because i wrote it
> > and so can't see what's missing or unclear.
> > 
> > afaiu, what your script needs is:
> > 
> > * a way to create a new containment with a given type
> > * the ability to write a config value
> > * the ability to get the size of a screen and/or containment
> > * a way to create a new widget in your containment
> > 
> > what is missing from that list? which items in that list are not well
> > answered
> > in the documentation?
> 
> It really doesn't matter as I do not know JavaScript so you could try and

look, i'm trying to help you. you're evidently more interested in complaining 
than trying to get what you need done and accepting the help of others to get 
there.

in any case ... if you know perl or any of the other common sys admin 
languages, i'll bet you could sling together a script for plasma-desktop 
without much/any effort. other than perhaps knowing how to iterate through an 
array (which isn't that surprising either, and which you can find examples of 
in the examples dir) there is little if any javascript language specific 
knowledge required.

> Scripting is great but it adds another language on to the list that I never
> had to know before (or ever wanted to).
> Most DE package don't require a knowledge of JS.

neither does plasma-desktop. you can happily continue using /etc/skel or 
plasma-default-layoutrc

> is replacing, config files that were human readable, could be easily
> edited, and placed in a default location. 

all which are true of the javascript scripts too. :)

> Most distributions (Like Suse)
> were using a startkde bash script in /usr/share/kde4/env/ . Bash is pretty
> much a all around known language for anyone who wished to go in depth at
> all in the CLI. So by the time you came around to building your own
> version of KDE you knew enough of it to do your own configuration.

kicker+kdesktop nor plasma were scriptable prior to this, and shell scripting 
(would never use bash, btw, due to portability) would never work unless we 
embedded a shell interpreter into plasma. this isn't about modifying plasma-
dekstop externally, these scripts actually run -within- plasma-destop.

> you've forced someone to learn yet
> another scripting language for one small area of packaging in KDE 4. So

javascript is the most commonly used scripting language on the planet right 
now, you hardly need to learn any of it in this context to be useful and you 
can start with the default scripts and the examples.

> you have quite complexed moving to simplicity.

this wasn't about simplicity. this was about offering features that our 
downstreams really needed. you can always use a file based result :)
 
> My point is unless you plan on creating awesome example scripts with
> supporting scenarios (some thing much more complex then changing panel icon
> locations). Doing a lot of hand holding at first (like mine) then interest
> in this is going to be lost.

it may be true that some will give up (can't win them all), but it seems like 
most distributions are managing just fine.

> As this perspective just supports in
> non-fanboy KDE communities, KDE once again doing it "their" way and
> convoluting once was quite simple for something much more complex under a
> guise of betterment.

this feature set was written at the request of a pair of major KDE deployments 
in Germany, actually, and fulfilled some very specific feature requests that 
represented deployment gaps at the time. :)

> This feature has been out for how many releases? I have yet to see a
> distribution to yet take off with it, many just use the default file, some

several distributions have shipped custom scripts. i know because i've added 
features for them over the past releases :)

so .. it seems you're annoyed that you have to learn something new. 
understandable (though i don't understand this particular level of complaining 
about it), but it's not a zero sum game: the scripting gives us a lot of 
features that downstreams are actually very happy about having in a way that 
is low overhead and in a language that is both suited to the task and pretty 
broadly known.

in any case, once you've accomplished what you wish to, if you'd like to 
contribute back examples of what was unclear to you when you got started, 
that'd be a great way to give back. cheers...

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101225/1a7337dd/attachment.sig