Re: Change Wallpaper through a Service?

[Jeremiah Summers]

> you can, but think about the structure of a dbus service that maps to the
> wallpapers in a multiple-containment layout. i doubt we'd end up with a nice
> single "setWallpaper" method without it being rather simplified (e.g. only
> possible to set the wallpaper for the current desktop, current screen and
> current containment).
>
> while we could do this, it would only be used for setting wallpapers and would
> not be at all a full dbus interface to plasma-desktop. given one can drag 'n
> drop things onto the desktop and get more accurate and interesting options
> there, i'm not convinced its worth it.
>
> --
> Aaron J. Seigo

I guess I could just spend the time and effort to retrain her on how
to do wallpapers, I was just looking at if from the perspective of
it's expected behaviour to right click picture and set it as a
backgound, people do it in internet explorer, firefox, and why
wouldn't you be able to do it when viewing a image preview in dolphin.
Coming from a Windows/Mac world she can click on multiple images and
create a slide show for backgrounds, she's not the first person or
will she be the last that will expect at least similar functionality.
I wasn't even asking for that functionality, just the means to
implement it myself as it used to be possible with dcop. I guess I
could just tell her, that she's doing it wrong and take the Apple
iPhone approach of we're better then the rest so do it our way or get
dropped calls, but I kinda don't feel like lying to myself as I am
surprised myself by your answer. With all the ECMA scripting and
possibilities in KDE/Plamsa simply changing the background is not
possible through a simple desktop file? I don't mean to be
inflammatory, but it just seems like a point was missed some where.

Regardless, thanks for all your hard work I know this is just a little
annoyance in what is a very nice desktop environment.

Kind Regards,

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Change Wallpaper through a Service?

[Jeremiah Summers]

Shantanu,
  Actually that's what I had her do, but she had saved the
image to her desktop so it was copy it into a folder in home then have
her drag it back "like" she was going to move it back to the desktop
then select "Set as Wallpaper", When a right mouse click, hover and
left mouse click would have been _a lot_ more simple. For that matter
more simple to explain as well. In actualyity she just wanted to see
how it was going to look, since she has changed her wallpaper multiple
times. I'm really hoping there's some way to do this, it just seems so
simple and it was doable in the past with dcop. Searching multiple
forums I see it's popular request, so if it is semi simple it needs to
be documented some place. I will have no issue doing it, if I can
figure it out. Thanks for you response

Jeremiah

On Fri, Jun 10, 2011 at 11:18 PM, Shantanu Tushar Jha
 wrote:
> Hi Jeremiah,
>
> What I usually do for setting an image as wallpaper is dragging the image
> from Dolphin and dropping on the desktop, and then select "Wallpaper" (If
> your dolphin is maximised, you can hover over the Show Desktop icon).
>
> As far as I remember, Plasma doesn't expose a DBus call for setting a
> wallpaper.
>
> Shantanu Tushar    (UTC +0530)
> http://www.shantanutushar.com
>
>
> On Sat, Jun 11, 2011 at 11:40 AM, Jeremiah Summers 
> wrote:
>>
>> The other day my wife asked me (not a heavy Linux/KDE User) why when
>> she right clicked on an image did she not have an option in "Actions"
>> to set it as her wallpaper. I thought that was a good question.
>> Remember the KDE 3 days I thought it should be pretty simple (now
>> especially with dbus instead of dcop) create a simple desktop file and
>> add it too services. Looking for the method in qbusviewer came up with
>> no real results so to furth my knowledge I went to google. Only to
>> find dishearted posters saying something so simple (and once easy)
>> could no longer be done. I was wonder if that is true, or maybe if it
>> might be a bit more complex (Javascript) but still doable? If so how
>> might I go about it?
>>
>> Kind Regards
>>
>> Jeremiah
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Change Wallpaper through a Service?

[Jeremiah Summers]

The other day my wife asked me (not a heavy Linux/KDE User) why when
she right clicked on an image did she not have an option in "Actions"
to set it as her wallpaper. I thought that was a good question.
Remember the KDE 3 days I thought it should be pretty simple (now
especially with dbus instead of dcop) create a simple desktop file and
add it too services. Looking for the method in qbusviewer came up with
no real results so to furth my knowledge I went to google. Only to
find dishearted posters saying something so simple (and once easy)
could no longer be done. I was wonder if that is true, or maybe if it
might be a bit more complex (Javascript) but still doable? If so how
might I go about it?

Kind Regards

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma desktop init scripting

[Jeremiah Summers]

On Mon, Jan 3, 2011 at 9:10 AM, Marco Martin  wrote:

>
> at the moment only plasma supports it, a reason is not being trivial to
> adjust
> a default layout that will llook correctly on diffrent screen resolutions,
> while other apps are being less affected (tough i tink for some of them a
> similr approach would be sound)
> again, correct approach is to contect us when specific roadblock are
> encountered, "look i can't script this specific detail" that maybe wasn't
> clear ho to do it, maybe is not possible yet. In this case we can fix it.
>
> Cheers,
> Marco Martin


Marco,
  Thanks, I just realized how unclearly I was thinking. Of course
this is just for plasma so defaults in KDE apps they may need to be set,
can't be set. However is there a way to call kwriteconfig in the javascript
and write to configs on startup? If so then it would be very much possible
to replace config files in branding packages. I thought before that some
things would require a relaunching of the application, is this still the
case, does it depend on the application etc..? If I understand you correctly
then JavaScript can't remove files etc.. So the bash script in env (in my
case) will always be needed as it offers more flexibility.

Thanks for your Replay (Both you and Aaron)

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma desktop init scripting

[Jeremiah Summers]

On Sat, Dec 25, 2010 at 7:10 PM, Aaron J. Seigo  wrote:

> On Friday, December 24, 2010, Jeremiah Summers wrote:
> > On Fri, Dec 24, 2010 at 9:36 AM, Aaron J. Seigo  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

Re: Plasma desktop init scripting

[Jeremiah Summers]

On Fri, Dec 24, 2010 at 9:36 AM, Aaron J. Seigo  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
explain any of that and the documentation could be Awesome as I'm sure it
is, but the languages I must know to be a packager is ever growing. Plasma
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. I am not a web developer, but it seems the ever increasing
load on what I need to know to edit and run KDE, or Linux in general is
growing. Yes JavaScript is a great option, but look at what it (seems it) is
replacing, config files that were human readable, could be easily edited,
and placed in a default location. 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.

So now comes plasma scripting an awesome feature, however the language of
choice is JavaScript. You're trading a lot of human readable files to edit
and keep track of for hopefully what will be one script. It sounds great and
is great in theory but now you've either left out the packagers that don't
like JavaScript and don't think there should be a need to learn yet another
scripting language for KDE or you've forced someone to learn yet another
scripting language for one small area of packaging in KDE 4. So you have
quite complexed moving to simplicity.

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. 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 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
tweak it a little and some ignore it all together. There's obviously a
disconnect here and from my perspective (limited I will admit) it seems
Awesome documentation may not cut it, even though it's still appreciated.

Kind Regards

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma desktop init scripting

[Jeremiah Summers]

On Tue, Dec 21, 2010 at 10:42 PM, Aaron J. Seigo  wrote:

> On Tuesday, December 21, 2010, Aaron J. Seigo wrote:
> > you are probably the third person to ask about this. evidently we need to
> > add an example for wallpaper setting
>
> done:
>
>
> http://websvn.kde.org/*checkout*/trunk/KDE/kdeexamples/plasma/javascript/plasma-
> shell-scripting/setWallpaper.js
>
> (i also added mention of the examples to the techbase page that documents
> the
> API)
>
> --
> 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
>

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 noticed
looking at all the default plasma first time scripts (from Fedora, Ubuntu
Arch etc..) that very few even come close to using the functionality of
scripting or for that matter even differ to each other in comparison. I
think very few people (packagers) know JavaScript as opposed to other
languages such as bash, python or perl. It is my personal opinion that a lot
of the example scripts do not reflect real world usage. As a packager I am
struggling with getting the script just right and where normally Google or
Techbase would play a large role my, over all understanding of JavaScript
doesn't seem to be up to par to that of which the documentation has been
written. I am still trying as I Love the concept. However I see a gross
neglect from distributions and packagers of this feature where it could be
used. For example PCLinuxOS (not my distro of choice) bypasses the whole
script and just shoves everything into /etc/skel not a ideal solution at
all, very hackish. Maybe I am wrong but I think if more examples were
available and more distributions took advantage of scripting then it would
just feed on itself and be even more successful then as you may already view
it.

Hope this is seen as somewhat beneficial criticism, my whole point is please
more examples, so those of us who look at techbase with bewilderment can see
scripting in action and hack from there. Keep up the good work, it's so good
I'm requesting more ;)

Kind Regards

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Right Click issue in SystemTray

[Jeremiah Summers]

On Wed, Aug 11, 2010 at 4:01 PM, Jeremiah Summers wrote:

> Sorry not sure if it's a bug or not. The issue is right click is non
> responsive for various icons in the System Tray the most used of these would
> be kmix and klipper. If I go to right click in the system tray one of these
> icons no menu appears or action happens. If I left click there seems to be a
> click action as the icon will shrink a little bit on the mouse click but no
> action other than the icon looking as if it's been pressed takes place.
>
> I have learned that if I disable "Status Notifier Manager" in kded4 (System
> Setting -> Startup and Shutdown -> Service Manager) that the kmix and
> klipper icons will change to their old defaults (instead of the new shiny
> icons) and then work weather I left or right click. All seems to be well.
> This was noted before as a bug and was closed out because Aaron suggestion
> it was a old dbusmenu-qt version.
>
> It's also noted here:
> http://kdeatopensuse.wordpress.com/2010/05/28/week-21-kde-at-opensuse/
>
> I am running the latest git pull as previously stated and have restarted
> etc.. to make sure the new libraries are loaded.
>
> I am just wondering if there's something else I need to update. Previous
> versions (4.4.95) RC 3 worked fine with the same packages.
>
> Hope this explains it better
>
> Kind regards,
>
> Jeremiah
>

Suggestions.. Anyone?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Right Click issue in SystemTray

[Jeremiah Summers]

On Wed, Aug 11, 2010 at 8:57 AM, David Hubner  wrote:

>  On 11/08/2010 09:20, Marco Martin wrote:
> > On Wednesday 11 August 2010, Jeremiah Summers wrote:
> >> Hello all,
> >> I have an issue with the System Notifier Daemon in kded4
> >> blocking right click action in systray for klipper and kmix. I
> > uhm, can you explain better what the problem is?
> >
> > Cheers,
> > Marco Martin
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> Could possibly be this issue
> http://forum.kde.org/viewtopic.php?f=22&t=87677 with A4 tech mice.
>
> Its a guess as I don't know if this bug only effects sorting.
>
> --
> David Hubner
> KinfoCenter Developer
>
> E-mail: hubn...@ntlworld.com
> Portfolio: http://homepage.ntlworld.com/hubnerd/
> LinkedIn Profile: http://uk.linkedin.com/in/hubnerd


Sorry not sure if it's a bug or not. The issue is right click is non
responsive for various icons in the System Tray the most used of these would
be kmix and klipper. If I go to right click in the system tray one of these
icons no menu appears or action happens. If I left click there seems to be a
click action as the icon will shrink a little bit on the mouse click but no
action other than the icon looking as if it's been pressed takes place.

I have learned that if I disable "Status Notifier Manager" in kded4 (System
Setting -> Startup and Shutdown -> Service Manager) that the kmix and
klipper icons will change to their old defaults (instead of the new shiny
icons) and then work weather I left or right click. All seems to be well.
This was noted before as a bug and was closed out because Aaron suggestion
it was a old dbusmenu-qt version.

It's also noted here:
http://kdeatopensuse.wordpress.com/2010/05/28/week-21-kde-at-opensuse/

I am running the latest git pull as previously stated and have restarted
etc.. to make sure the new libraries are loaded.

I am just wondering if there's something else I need to update. Previous
versions (4.4.95) RC 3 worked fine with the same packages.

Hope this explains it better

Kind regards,

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Right Click issue in SystemTray

[Jeremiah Summers]

Hello all,
   I have an issue with the System Notifier Daemon in kded4 blocking
right click action in systray for klipper and kmix. I have updated to the
latest git pull of dbusmenu-qt (0.5.2 I Believe) and am wondering if anyone
else has any suggestions. I am running Qt 4.7 Beta 2 and a self compiled
version of KDE 4.5.0. I am basically copying Fedora devel (CVS), minus a few
patches, however they are still at 0.3 and Mandriva is also, so I didn't
think that was the issue but I tried anyways. I have restarted the whole
system just in case I was missing something that needed to be killed other
than kded4 and plasma-desktop. Just wondering if there's some other requires
or package I am missing that is needed, maybe dbus versions or something a
long those lines. Funny thing is, 4.4.95 worked fine and I have updated
nothing (now with the exception of the dbusmenu-qt package) to go to 4.5.0.
Suggestions?

Kind Regards

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Desktop Scripting Question

[Jeremiah Summers]

On Sun, Aug 1, 2010 at 3:24 PM, Aaron J. Seigo  wrote:
> On August 1, 2010, Aaron J. Seigo wrote:
>> On August 1, 2010, Aaron J. Seigo wrote:
>> > On July 31, 2010, Jeremiah Summers wrote:
>> > > maybe my philosophy here is flawed and I'm trying to use scripting for
>> > > more than what it's meant for. If so please let me know. I'm actually
>> >
>> > i think you explained yourself quite well and i'd have a hard time
>> > arguing against it other than to try and save myself the 10 minutes it
>> > would take to add the feature.
>>
>> done in r1158013.
>
> and documented
>  here:
>
> http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting#Mis
> c._Global_Properties_and_Functions
>
> --
> 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

Thanks a ton Aaron, can't wait till 4.6 and 4.5 hasn't been announced yet!

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Desktop Scripting Question

[Jeremiah Summers]

On Sat, Jul 31, 2010 at 5:51 PM, Aaron J. Seigo  wrote:
> On July 31, 2010, Jeremiah Summers wrote:
>> Maybe I missed something, I have been reading through techbase and a
>> few fourms and mailinglist and I haven't found any mention of being
>> able to change the widgetStyle in plasma through ecma/Javascript. If
>> this is at all possible (with 4.5?) would anyone know of a example
>> they could point me too or maybe some more documentation that goes
>> over it.
>
> it isn't possible right now, no. not because it wouldn't be possible, but
>  because the scripting simply doesn't include that.
>
> unlike the things that the scripting covers, the widget style is a static
> entry easily found in a config file and changes are picked up automatically
> when made to the file, so it doesn't really benefit much from a runtime
>  control.
>
> i can understand why you would expect it to be there though, since it is
>  "just another setting" more or less.
>
> before deciding on whether ot add it or not, could you share your use case
>  for this feature?
>
> --
> 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'm just being greedy, seeing if I can get most of the configuration
done by scripting. Right now I just have my default configuration
files in /etc/kde4/share/config/ I have been playing with scripting to
see if I can retire any of those and have the vast majority done by
one script file. I package for a Distribution (Unity Linux) that acts
as a "core" to other distributions, people can use our KDE 4 Packages
but just repackage our branding packages. I have found simplicity to
be key. The less configuration files to hurd the easier it is for
those wanting to create KDE 4 with their own look and feel for their
own purposes. I hope to present a script and a brief overview of it on
out wiki so others can take it and tweak it for their liking. However
maybe my philosophy here is flawed and I'm trying to use scripting for
more than what it's meant for. If so please let me know. I'm actually
quite happy with the way things are going I think the right choice was
made with ecma/Javascript so of course now I want too use it to do
everything I can ;)

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Desktop Scripting Question

[Jeremiah Summers]

Maybe I missed something, I have been reading through techbase and a
few fourms and mailinglist and I haven't found any mention of being
able to change the widgetStyle in plasma through ecma/Javascript. If
this is at all possible (with 4.5?) would anyone know of a example
they could point me too or maybe some more documentation that goes
over it.

Kind Regards

Jeremiah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel