Plasma desktop init scripting

[Jeremiah Summers]

On Sat, Dec 25, 2010 at 7:10 PM, Aaron J. Seigo <aseigo at kde.org> wrote:

> 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
>

I have attached the simple script I have so far, maybe someone else will
find a use for it. I have no issue contributing what I know and taking the
time to write it up to the best of my knowledge unfortunately that's
limited. I don't think JavaScript is the most widely used scripting language
for Desktop use, though. It's a little unfair comparison, in that case
everyone should know C#, html etc.. because they are very much widely known
languages. I wouldn't expect anyone to know C# because they knew C++ or visa
versa, or to understand Perl because they knew Python. For that matter
expect the desktop developer to know and use html. Talking to anyone else
outside the KDE world they're a little surprised JavaScript is being used
(outside of desktop webapps). Of course some of those same people have some
quite negative views on JavaScript and security so they may be already
biased. I would like to see some awesome scripts that are creating default
apps like the trash can on the desktop or any other plasmoid that is
actually positioned. The Closest I have seen is Ubuntu's yet it's still not
quite there. You might be trying to call my bluff but I have actually looked
through every known distribution that uses kde4 for an advanced scripting
outside the norm and found nothing, that another script doesn't already do.
I requested one of those features you're talking about, and yes it was done
and I appreciated it. I guess what it comes down to is I would be much more
apt to learn JavaScript if it would actually replace those human readable
files and the bash script I am still using to setup the first run
environment, but at this point I am now trying to figure out Javascript and
still maintaining a bash script and some of those human readable files. I
don't want to do that, I like the idea of one script to rule them all I have
just seen no one (distribution or KDE example) do it. Maybe you have and I
have completely missed it. If so please point me in that direction and I'll
learn what I need too. This is what I mean by I think the point of
JavaScript is being lost because it's not doing what (I think) it was
supposed to do. I could be all wrong and maybe it was never meant to be a
catch all. If so then I'll go back to what's easier. I work on distribution
that's main focus is rebranding I can't expect every branch (rebrand
mainter) to learn JavaScript for a few things that can already be covered by
replacing some files. However if I can write a script that can cover all
those files and just have variables changed by anyone who wants to rebrand,
then in my little brain that makes this all worth it.


Thanks for the Help

Jeremiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20110103/ce3bebe6/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 00-defaultLayout.js
Type: application/x-javascript
Size: 1713 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110103/ce3bebe6/attachment-0001.bin