<br><br><div class="gmail_quote">On Sat, Dec 25, 2010 at 7:10 PM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Friday, December 24, 2010, Jeremiah Summers wrote:<br>
> On Fri, Dec 24, 2010 at 9:36 AM, Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br>
> > On Wednesday, December 22, 2010, Jeremiah Summers wrote:<br>
> > > It would be nice if there were examples for loading folderview as the<br>
> > > default activity (ie. classic desktop) setting its backend and maybe<br>
> > > placing a widget at the bottom right of the screen ie. a trash can. I<br>
> ><br>
> > have<br>
> ><br>
> > so ... you want us to write your init script for you ;P<br>
> ><br>
> > more seriously, i'm unclear as to what is missing in the documentation<br>
> > that makes this difficult to achieve. perhaps that's because i wrote it<br>
> > and so can't see what's missing or unclear.<br>
> ><br>
> > afaiu, what your script needs is:<br>
> ><br>
> > * a way to create a new containment with a given type<br>
> > * the ability to write a config value<br>
> > * the ability to get the size of a screen and/or containment<br>
> > * a way to create a new widget in your containment<br>
> ><br>
> > what is missing from that list? which items in that list are not well<br>
> > answered<br>
> > in the documentation?<br>
><br>
> It really doesn't matter as I do not know JavaScript so you could try and<br>
<br>
</div>look, i'm trying to help you. you're evidently more interested in complaining<br>
than trying to get what you need done and accepting the help of others to get<br>
there.<br>
<br>
in any case ... if you know perl or any of the other common sys admin<br>
languages, i'll bet you could sling together a script for plasma-desktop<br>
without much/any effort. other than perhaps knowing how to iterate through an<br>
array (which isn't that surprising either, and which you can find examples of<br>
in the examples dir) there is little if any javascript language specific<br>
knowledge required.<br>
<div class="im"><br>
> Scripting is great but it adds another language on to the list that I never<br>
> had to know before (or ever wanted to).<br>
> Most DE package don't require a knowledge of JS.<br>
<br>
</div>neither does plasma-desktop. you can happily continue using /etc/skel or<br>
plasma-default-layoutrc<br>
<div class="im"><br>
> is replacing, config files that were human readable, could be easily<br>
> edited, and placed in a default location.<br>
<br>
</div>all which are true of the javascript scripts too. :)<br>
<div class="im"><br>
> Most distributions (Like Suse)<br>
> were using a startkde bash script in /usr/share/kde4/env/ . Bash is pretty<br>
> much a all around known language for anyone who wished to go in depth at<br>
> all in the CLI. So by the time you came around to building your own<br>
> version of KDE you knew enough of it to do your own configuration.<br>
<br>
</div>kicker+kdesktop nor plasma were scriptable prior to this, and shell scripting<br>
(would never use bash, btw, due to portability) would never work unless we<br>
embedded a shell interpreter into plasma. this isn't about modifying plasma-<br>
dekstop externally, these scripts actually run -within- plasma-destop.<br>
<div class="im"><br>
> you've forced someone to learn yet<br>
> another scripting language for one small area of packaging in KDE 4. So<br>
<br>
</div>javascript is the most commonly used scripting language on the planet right<br>
now, you hardly need to learn any of it in this context to be useful and you<br>
can start with the default scripts and the examples.<br>
<div class="im"><br>
> you have quite complexed moving to simplicity.<br>
<br>
</div>this wasn't about simplicity. this was about offering features that our<br>
downstreams really needed. you can always use a file based result :)<br>
<div class="im"><br>
> My point is unless you plan on creating awesome example scripts with<br>
> supporting scenarios (some thing much more complex then changing panel icon<br>
> locations). Doing a lot of hand holding at first (like mine) then interest<br>
> in this is going to be lost.<br>
<br>
</div>it may be true that some will give up (can't win them all), but it seems like<br>
most distributions are managing just fine.<br>
<div class="im"><br>
> As this perspective just supports in<br>
> non-fanboy KDE communities, KDE once again doing it "their" way and<br>
> convoluting once was quite simple for something much more complex under a<br>
> guise of betterment.<br>
<br>
</div>this feature set was written at the request of a pair of major KDE deployments<br>
in Germany, actually, and fulfilled some very specific feature requests that<br>
represented deployment gaps at the time. :)<br>
<div class="im"><br>
> This feature has been out for how many releases? I have yet to see a<br>
> distribution to yet take off with it, many just use the default file, some<br>
<br>
</div>several distributions have shipped custom scripts. i know because i've added<br>
features for them over the past releases :)<br>
<br>
so .. it seems you're annoyed that you have to learn something new.<br>
understandable (though i don't understand this particular level of complaining<br>
about it), but it's not a zero sum game: the scripting gives us a lot of<br>
features that downstreams are actually very happy about having in a way that<br>
is low overhead and in a language that is both suited to the task and pretty<br>
broadly known.<br>
<br>
in any case, once you've accomplished what you wish to, if you'd like to<br>
contribute back examples of what was unclear to you when you got started,<br>
that'd be a great way to give back. cheers...<br>
<div><div></div><div class="h5"><br>
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br></div></div></blockquote><div><br>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.<br>
<br><br>Thanks for the Help<br><br>Jeremiah<br></div></div>