Re: containing plasmoid crashes

[Bogdan Bivolaru]

Hello,

Well, I haven't really thought about a how-to before writing that mail... I
was expecting it to work just as for catching crashes with Dr. Krash.

But it turns out that there is a solution on Plasma wishlist:
[Plasma] Plasmoids as separate processes

So I voted for it and I hope someone will find the time to do it.
I guess that also means I should pay more attention to KDE Brainstorm,
well...


Have fun hacking,
Bogdan



On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo  wrote:

> On Saturday 25 July 2009, Bogdan Bivolaru wrote:
> > I'm writing to you because I'd like to make a suggestion to make a
> > containment for errors around each plasmoid, so that when one crashes, it
> > doesn't take the whole plasma environment with it.
>
> and how do you suggest this is accomplished, exactly?
>
> --
> 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 Software
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
"The best way to predict the future is to invent it.", 1971, Alan Kay:
http://www.smalltalk.org/alankay.html
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: containing plasmoid crashes

[Bogdan Bivolaru]

Oh, well, there is an intense debate on how to accomplish this...
http://forum.kde.org/viewtopic.php?f=83&t=45255&start=30

Oh everyone brings their pet issue to the table: performance issues, ease of
development, stability. I hope you plasma hackers will find the middle
ground to keep everyone happy.

Bogdan



On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru  wrote:

> Hello,
>
> Well, I haven't really thought about a how-to before writing that mail... I
> was expecting it to work just as for catching crashes with Dr. Krash.
>
> But it turns out that there is a solution on Plasma wishlist:
> [Plasma] Plasmoids as separate processes
>
> So I voted for it and I hope someone will find the time to do it.
> I guess that also means I should pay more attention to KDE Brainstorm,
> well...
>
>
> Have fun hacking,
> Bogdan
>
>
>
> On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo  wrote:
>
>> On Saturday 25 July 2009, Bogdan Bivolaru wrote:
>> > I'm writing to you because I'd like to make a suggestion to make a
>> > containment for errors around each plasmoid, so that when one crashes,
>> it
>> > doesn't take the whole plasma environment with it.
>>
>> and how do you suggest this is accomplished, exactly?
>>
>> --
>> 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 Software
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
>
> --
> "The best way to predict the future is to invent it.", 1971, Alan Kay:
> http://www.smalltalk.org/alankay.html
>



-- 
"The best way to predict the future is to invent it.", 1971, Alan Kay:
http://www.smalltalk.org/alankay.html
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: containing plasmoid crashes

[Marco Martin]

On 7/26/09, Bogdan Bivolaru  wrote:
> Oh, well, there is an intense debate on how to accomplish this...
> http://forum.kde.org/viewtopic.php?f=83&t=45255&start=30
>
> Oh everyone brings their pet issue to the table: performance issues, ease of
> development, stability. I hope you plasma hackers will find the middle

..and you lose the single scene, so no more containments, the desktop
becomes a bunch of little windows and the pnel is simply not possible
to do anymore

Cheers,
Marco Martin
> ground to keep everyone happy.
>
> Bogdan
>
>
>
> On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru > wrote:
>
>> Hello,
>>
>> Well, I haven't really thought about a how-to before writing that mail...
>> I
>> was expecting it to work just as for catching crashes with Dr. Krash.
>>
>> But it turns out that there is a solution on Plasma wishlist:
>> [Plasma] Plasmoids as separate processes
>>
>> So I voted for it and I hope someone will find the time to do it.
>> I guess that also means I should pay more attention to KDE Brainstorm,
>> well...
>>
>>
>> Have fun hacking,
>> Bogdan
>>
>>
>>
>> On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo  wrote:
>>
>>> On Saturday 25 July 2009, Bogdan Bivolaru wrote:
>>> > I'm writing to you because I'd like to make a suggestion to make a
>>> > containment for errors around each plasmoid, so that when one crashes,
>>> it
>>> > doesn't take the whole plasma environment with it.
>>>
>>> and how do you suggest this is accomplished, exactly?
>>>
>>> --
>>> 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 Software
>>>
>>> ___
>>> Plasma-devel mailing list
>>> Plasma-devel@kde.org
>>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>>
>>>
>>
>>
>> --
>> "The best way to predict the future is to invent it.", 1971, Alan Kay:
>> http://www.smalltalk.org/alankay.html
>>
>
>
>
> --
> "The best way to predict the future is to invent it.", 1971, Alan Kay:
> http://www.smalltalk.org/alankay.html
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [PATCH] BUG 199107 make the popup dialog of group hide automatically on taskbar

[潘卫平(Peter Pan)]

潘卫平(Peter Pan) 写道:
> Aaron J. Seigo 写道:
>> On Thursday 16 July 2009, 潘卫平(Peter Pan) wrote:
>>> For tooltips, I agree that they are less important than the popup
>>> dialog, so I made another patch to reject showing tooltips when a popup
>>> dialog is showing.
>> looks good :)
>>
> 
> Thanks for your comments.
> 
> Shall I commit it, or wait some time for reviews ?
> 
> Any comments are welcomed!
> 
> Regards
> 
Hi, all

Has anybody tried this patch?
Any idea to improve it?

Regards

-- 
潘卫平(Peter Pan)
Red Flag Software Co., Ltd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Window runner to switch windows and desktops

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/
---

(Updated 2009-07-26 10:21:46.864061)


Review request for Plasma.


Changes
---

Support for window actions. By entering one of the following keywords an action 
can be performed on the matches:
 * activate: activate the window (default if there is no keyword)
 * close: close the window
 * min(imize): (un)minimize the window
 * max(imize): maximize/restore the window
 * fullscreen: toggle fullscreen
 * shade: (un)shade the window
 * keep above: toggle keep above
 * keep below: toggle keep below


Summary
---

This runner lists the windows and virtual desktops. It allows to activate a 
selected window or switch to a selected desktop. The runner works in the 
following way:
 * input is matched on window name, class or role; matching windows are listed
 * input is matched on desktop name. Matching desktops are shown for switching 
to, all windows on matching desktops are listed.
 * keyword "desktop": lists all desktops (except current) if additional number 
is inserted the list is reduced to that desktop
 * keyword "window": lists all windows. Additional text will be used to 
restrict like in first case. Following sub queries to restrict search are 
possible:
   * name=: restrict on name
   * class=: restrict on window class
   * role=: restrict on window role
   * desktop=: restrict on desktop
  those subqueries can be combined in any order. Each input not containing a 
'=' will be interpreted as a name restriction if there is no explicit name 
restriction. In that case it's ignored. Example query: "window desktop=2 
class=kmail role=composer" will list all open KMail composer windows on desktop 
2.


Diffs (updated)
-

  trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt 1000707 
  trunk/KDE/kdebase/workspace/plasma/runners/windows/CMakeLists.txt 
PRE-CREATION 
  
trunk/KDE/kdebase/workspace/plasma/runners/windows/plasma-runner-windows.desktop
 PRE-CREATION 
  trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.h 
PRE-CREATION 
  trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp 
PRE-CREATION 

Diff: http://reviewboard.kde.org/r/1114/diff


Testing
---


Thanks,

Martin

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

Re: containing plasmoid crashes

[Bogdan Bivolaru]

Wow! Well, sounds like you've got a tough job to do, but I'm sure you'll
find a way to solve this issue, as always. May you have a happy hacking and
a nice day!

Cheers,
Bogdan



On Sun, Jul 26, 2009 at 11:07 AM, Marco Martin  wrote:

> On 7/26/09, Bogdan Bivolaru  wrote:
> > Oh, well, there is an intense debate on how to accomplish this...
> > http://forum.kde.org/viewtopic.php?f=83&t=45255&start=30
> >
> > Oh everyone brings their pet issue to the table: performance issues, ease
> of
> > development, stability. I hope you plasma hackers will find the middle
>
> ..and you lose the single scene, so no more containments, the desktop
> becomes a bunch of little windows and the pnel is simply not possible
> to do anymore
>
> Cheers,
> Marco Martin
> > ground to keep everyone happy.
> >
> > Bogdan
> >
> >
> >
> > On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru <
> bogdan.bivol...@gmail.com
> >> wrote:
> >
> >> Hello,
> >>
> >> Well, I haven't really thought about a how-to before writing that
> mail...
> >> I
> >> was expecting it to work just as for catching crashes with Dr. Krash.
> >>
> >> But it turns out that there is a solution on Plasma wishlist:
> >> [Plasma] Plasmoids as separate processes
> >>
> >> So I voted for it and I hope someone will find the time to do it.
> >> I guess that also means I should pay more attention to KDE Brainstorm,
> >> well...
> >>
> >>
> >> Have fun hacking,
> >> Bogdan
> >>
> >>
> >>
> >> On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo 
> wrote:
> >>
> >>> On Saturday 25 July 2009, Bogdan Bivolaru wrote:
> >>> > I'm writing to you because I'd like to make a suggestion to make a
> >>> > containment for errors around each plasmoid, so that when one
> crashes,
> >>> it
> >>> > doesn't take the whole plasma environment with it.
> >>>
> >>> and how do you suggest this is accomplished, exactly?
> >>>
> >>> --
> >>> 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 Software
> >>>
> >>> ___
> >>> Plasma-devel mailing list
> >>> Plasma-devel@kde.org
> >>> https://mail.kde.org/mailman/listinfo/plasma-devel
> >>>
> >>>
> >>
> >>
> >> --
> >> "The best way to predict the future is to invent it.", 1971, Alan Kay:
> >> http://www.smalltalk.org/alankay.html
> >>
> >
> >
> >
> > --
> > "The best way to predict the future is to invent it.", 1971, Alan Kay:
> > http://www.smalltalk.org/alankay.html
> >
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
"The best way to predict the future is to invent it.", 1971, Alan Kay:
http://www.smalltalk.org/alankay.html
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: panels and popups sliding effect

[Marco Martin]

On Saturday 25 July 2009, Aaron J. Seigo wrote:
> On Friday 24 July 2009, Marco Martin wrote:
> > what about a small library (just statics probably) in workspace to deal
> > with this stuff? KWindowSystemExtra?
>
> the code needs to be accessible from libplasma though so that e.g.
> PopupApplet can animate its stuff.
>
> that's why i suggested Animator. a Plasma::WindowEffects namespace would be
> fine as well imo.

i'm really on the fence on where to put this and how to call it.
Becasue if we put other stuff like that like the taskbar thumbnails and the 
glow effect they wouldn't have much to do with animation, and i'm kinda 
wondering if plasma is the right namespace/lib for that, hmm..
anyways next patch is a tiny WindowEffect namespace (or maybe WindowUtils? so 
it mnatches with PaintUtils)

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

Re: containing plasmoid crashes

[David Baron]

A similar problem has seemingly been solved, by  Google. Since google's 
browser is opensource, one might take a look.

Every one of those tabs, plugin processes, etc., is a separate process, shows 
up on top as such. I have an upload going on now, apparently in a chrome 
process initiated from a website. No browser is showing at all--closed it.

Their approach is still very beta, has some interesting problems, but it 
works. We would probably want to use dbus (I do not know whether they do).

Example of their success: Clicking a link in kmail, for example, will spawn 
that as a tab in an existing chrome browser if one is running. Caveat--if one 
died and is still an existing process, one must kill it before chrome will 
work correctly. Beta.

> Wow! Well, sounds like you've got a tough job to do, but I'm sure you'll
> find a way to solve this issue, as always. May you have a happy hacking and
> a nice day!
>
> Cheers,
> Bogdan
>
> On Sun, Jul 26, 2009 at 11:07 AM, Marco Martin  wrote:
> > On 7/26/09, Bogdan Bivolaru  wrote:
> > > Oh, well, there is an intense debate on how to accomplish this...
> > > http://forum.kde.org/viewtopic.php?f=83&t=45255&start=30
> > >
> > > Oh everyone brings their pet issue to the table: performance issues,
> > > ease
> >
> > of
> >
> > > development, stability. I hope you plasma hackers will find the middle
> >
> > ..and you lose the single scene, so no more containments, the desktop
> > becomes a bunch of little windows and the pnel is simply not possible
> > to do anymore
> >
> > Cheers,
> > Marco Martin
> >
> > > ground to keep everyone happy.
> > >
> > > Bogdan
> > >
> > >
> > >
> > > On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru <
> >
> > bogdan.bivol...@gmail.com
> >
> > >> wrote:
> > >>
> > >> Hello,
> > >>
> > >> Well, I haven't really thought about a how-to before writing that
> >
> > mail...
> >
> > >> I
> > >> was expecting it to work just as for catching crashes with Dr. Krash.
> > >>
> > >> But it turns out that there is a solution on Plasma wishlist:
> > >> [Plasma] Plasmoids as separate processes
> > >>
> > >> So I voted for it and I hope someone will find the time to do it.
> > >> I guess that also means I should pay more attention to KDE Brainstorm,
> > >> well...
> > >>
> > >>
> > >> Have fun hacking,
> > >> Bogdan
> > >>
> > >>
> > >>
> > >> On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo 
> >
> > wrote:
> > >>> On Saturday 25 July 2009, Bogdan Bivolaru wrote:
> > >>> > I'm writing to you because I'd like to make a suggestion to make a
> > >>> > containment for errors around each plasmoid, so that when one
> >
> > crashes,
> >
> > >>> it
> > >>>
> > >>> > doesn't take the whole plasma environment with it.
> > >>>
> > >>> and how do you suggest this is accomplished, exactly?
> > >>>
> > >>> --
> > >>> 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 Software
> > >>>
> > >>> ___
> > >>> Plasma-devel mailing list
> > >>> Plasma-devel@kde.org
> > >>> https://mail.kde.org/mailman/listinfo/plasma-devel
> > >>
> > >> --
> > >> "The best way to predict the future is to invent it.", 1971, Alan Kay:
> > >> http://www.smalltalk.org/alankay.html
> > >
> > > --
> > > "The best way to predict the future is to invent it.", 1971, Alan Kay:
> > > http://www.smalltalk.org/alankay.html
> >
> > ___
> > 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

Re: containing plasmoid crashes

[Marco Martin]

On Sunday 26 July 2009, David Baron wrote:
> A similar problem has seemingly been solved, by  Google. Since google's
> browser is opensource, one might take a look.
>
> Every one of those tabs, plugin processes, etc., is a separate process,
> shows up on top as such. I have an upload going on now, apparently in a
> chrome process initiated from a website. No browser is showing at
> all--closed it.

how it works the linux version? i suppose tabs are xembedded separate 
windows? that would really not be acceptable for plasma

> Their approach is still very beta, has some interesting problems, but it
> works. We would probably want to use dbus (I do not know whether they do).
>
> Example of their success: Clicking a link in kmail, for example, will spawn
> that as a tab in an existing chrome browser if one is running. Caveat--if
> one died and is still an existing process, one must kill it before chrome
> will work correctly. Beta.
>
> > Wow! Well, sounds like you've got a tough job to do, but I'm sure you'll
> > find a way to solve this issue, as always. May you have a happy hacking
> > and a nice day!
> >
> > Cheers,
> > Bogdan
> >
> > On Sun, Jul 26, 2009 at 11:07 AM, Marco Martin  
wrote:
> > > On 7/26/09, Bogdan Bivolaru  wrote:
> > > > Oh, well, there is an intense debate on how to accomplish this...
> > > > http://forum.kde.org/viewtopic.php?f=83&t=45255&start=30
> > > >
> > > > Oh everyone brings their pet issue to the table: performance issues,
> > > > ease
> > >
> > > of
> > >
> > > > development, stability. I hope you plasma hackers will find the
> > > > middle
> > >
> > > ..and you lose the single scene, so no more containments, the desktop
> > > becomes a bunch of little windows and the pnel is simply not possible
> > > to do anymore
> > >
> > > Cheers,
> > > Marco Martin
> > >
> > > > ground to keep everyone happy.
> > > >
> > > > Bogdan
> > > >
> > > >
> > > >
> > > > On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru <
> > >
> > > bogdan.bivol...@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> Hello,
> > > >>
> > > >> Well, I haven't really thought about a how-to before writing that
> > >
> > > mail...
> > >
> > > >> I
> > > >> was expecting it to work just as for catching crashes with Dr.
> > > >> Krash.
> > > >>
> > > >> But it turns out that there is a solution on Plasma wishlist:
> > > >> [Plasma] Plasmoids as separate processes
> > > >>
> > > >> So I voted for it and I hope someone will find the time to do it.
> > > >> I guess that also means I should pay more attention to KDE
> > > >> Brainstorm, well...
> > > >>
> > > >>
> > > >> Have fun hacking,
> > > >> Bogdan
> > > >>
> > > >>
> > > >>
> > > >> On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo 
> > >
> > > wrote:
> > > >>> On Saturday 25 July 2009, Bogdan Bivolaru wrote:
> > > >>> > I'm writing to you because I'd like to make a suggestion to make
> > > >>> > a containment for errors around each plasmoid, so that when one
> > >
> > > crashes,
> > >
> > > >>> it
> > > >>>
> > > >>> > doesn't take the whole plasma environment with it.
> > > >>>
> > > >>> and how do you suggest this is accomplished, exactly?
> > > >>>
> > > >>> --
> > > >>> 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 Software
> > > >>>
> > > >>> ___
> > > >>> Plasma-devel mailing list
> > > >>> Plasma-devel@kde.org
> > > >>> https://mail.kde.org/mailman/listinfo/plasma-devel
> > > >>
> > > >> --
> > > >> "The best way to predict the future is to invent it.", 1971, Alan
> > > >> Kay: http://www.smalltalk.org/alankay.html
> > > >
> > > > --
> > > > "The best way to predict the future is to invent it.", 1971, Alan
> > > > Kay: http://www.smalltalk.org/alankay.html
> > >
> > > ___
> > > 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


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

Re: panels and popups sliding effect

[Martin Gräßlin]

Am Sonntag 26 Juli 2009 12:55:55 schrieb Marco Martin:
> On Saturday 25 July 2009, Aaron J. Seigo wrote:
> > On Friday 24 July 2009, Marco Martin wrote:
> > > what about a small library (just statics probably) in workspace to deal
> > > with this stuff? KWindowSystemExtra?
> >
> > the code needs to be accessible from libplasma though so that e.g.
> > PopupApplet can animate its stuff.
> >
> > that's why i suggested Animator. a Plasma::WindowEffects namespace would
> > be fine as well imo.
>
> i'm really on the fence on where to put this and how to call it.
> Becasue if we put other stuff like that like the taskbar thumbnails and the
> glow effect they wouldn't have much to do with animation, and i'm kinda
> wondering if plasma is the right namespace/lib for that, hmm..
> anyways next patch is a tiny WindowEffect namespace (or maybe WindowUtils?
> so it mnatches with PaintUtils)
what about having a small lib in workspace/lib? Could be difficult for the 
thumbnails as IIRC they are set in libplasma, but that is probably solveable 
as well.


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: panels and popups sliding effect

[Marco Martin]

On Sunday 26 July 2009, Martin Gräßlin wrote:
> Am Sonntag 26 Juli 2009 12:55:55 schrieb Marco Martin:
> > On Saturday 25 July 2009, Aaron J. Seigo wrote:
> > > On Friday 24 July 2009, Marco Martin wrote:
> > > > what about a small library (just statics probably) in workspace to
> > > > deal with this stuff? KWindowSystemExtra?
> > >
> > > the code needs to be accessible from libplasma though so that e.g.
> > > PopupApplet can animate its stuff.
> > >
> > > that's why i suggested Animator. a Plasma::WindowEffects namespace
> > > would be fine as well imo.
> >
> > i'm really on the fence on where to put this and how to call it.
> > Becasue if we put other stuff like that like the taskbar thumbnails and
> > the glow effect they wouldn't have much to do with animation, and i'm
> > kinda wondering if plasma is the right namespace/lib for that, hmm..
> > anyways next patch is a tiny WindowEffect namespace (or maybe
> > WindowUtils? so it mnatches with PaintUtils)
>
> what about having a small lib in workspace/lib? Could be difficult for the
> thumbnails as IIRC they are set in libplasma, but that is probably
> solveable as well.
problem with workspace is that we need it in libplasma, for 
Dialog::animateShow Dialog::animateHide

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

Re: panels and popups sliding effect

[Marco Martin]

On Sunday 26 July 2009, Marco Martin wrote:
> On Saturday 25 July 2009, Aaron J. Seigo wrote:
> > On Friday 24 July 2009, Marco Martin wrote:
> > > what about a small library (just statics probably) in workspace to deal
> > > with this stuff? KWindowSystemExtra?
> >
> > the code needs to be accessible from libplasma though so that e.g.
> > PopupApplet can animate its stuff.
> >
> > that's why i suggested Animator. a Plasma::WindowEffects namespace 
would
> > be fine as well imo.
>
> i'm really on the fence on where to put this and how to call it.
> Becasue if we put other stuff like that like the taskbar thumbnails and the
> glow effect they wouldn't have much to do with animation, and i'm kinda
> wondering if plasma is the right namespace/lib for that, hmm..
> anyways next patch is a tiny WindowEffect namespace (or maybe 
WindowUtils?
> so it mnatches with PaintUtils)
here it is

Cheers,
Marco Martin
Index: dialog.h
===
--- dialog.h	(revision 1002551)
+++ dialog.h	(working copy)
@@ -120,6 +120,7 @@
 bool eventFilter(QObject *watched, QEvent *event);
 void hideEvent(QHideEvent *event);
 void showEvent(QShowEvent *event);
+void focusInEvent(QFocusEvent *event);
 void mouseMoveEvent(QMouseEvent *event);
 void mousePressEvent(QMouseEvent *event);
 void mouseReleaseEvent(QMouseEvent *event);
Index: windoweffects.cpp
===
--- windoweffects.cpp	(revision 0)
+++ windoweffects.cpp	(revision 0)
@@ -0,0 +1,83 @@
+/*
+ *   Copyright 2009 Marco Martin 
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU Library General Public License as
+ *   published by the Free Software Foundation; either version 2, or
+ *   (at your option) any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details
+ *
+ *   You should have received a copy of the GNU Library General Public
+ *   License along with this program; if not, write to the
+ *   Free Software Foundation, Inc.,
+ *   51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include "windoweffects.h"
+
+#include 
+
+
+namespace Plasma
+{
+
+namespace WindowEffects
+{
+
+void setSlidingWindow(WId id, Plasma::Location location)
+{
+#ifdef Q_WS_X11
+Display *dpy = QX11Info::display();
+//set again the atom, the location could have changed
+QDesktopWidget *desktop = QApplication::desktop();
+
+Window dummy;
+int x;
+int y;
+uint width;
+uint height;
+uint bw;
+uint d;
+XGetGeometry(dpy, id, &dummy, &x, &y, &width, &height, &bw, &d);
+
+QRect avail = desktop->availableGeometry(QPoint(x, y));//desktop->screenNumber(pos()));
+
+Atom atom = XInternAtom( dpy, "_KDE_SLIDE", False );
+QVarLengthArray data(2);
+
+switch (location) {
+case LeftEdge:
+data[0] = avail.left();
+data[1] = 0;
+break;
+case TopEdge:
+data[0] = avail.top();
+data[1] = 1;
+break;
+case RightEdge:
+data[0] = avail.right();
+data[1] = 2;
+break;
+case BottomEdge:
+data[0] = avail.bottom();
+data[1] = 3;
+default:
+break;
+}
+
+if (location == Desktop || location == Floating) {
+XDeleteProperty(dpy, id, atom);
+} else {
+XChangeProperty(dpy, id, atom, atom, 32, PropModeReplace,
+reinterpret_cast(data.data()), data.size());
+}
+#endif
+}
+
+}
+
+}
Index: dialog.cpp
===
--- dialog.cpp	(revision 1002551)
+++ dialog.cpp	(working copy)
@@ -49,6 +49,7 @@
 #include "plasma/private/extender_p.h"
 #include "plasma/framesvg.h"
 #include "plasma/theme.h"
+#include "plasma/windoweffects.h"
 
 #ifdef Q_WS_X11
 #include 
@@ -526,6 +527,19 @@
 emit dialogVisible(true);
 }
 
+void Dialog::focusInEvent(QFocusEvent *event)
+{
+Q_UNUSED(event)
+
+if (d->view) {
+d->view->setFocus();
+}
+
+if (d->graphicsWidget) {
+d->graphicsWidget->setFocus();
+}
+}
+
 void Dialog::moveEvent(QMoveEvent *event)
 {
 Q_UNUSED(event)
@@ -559,37 +573,26 @@
 return;
 }
 
-#ifdef Q_WS_X11
-//set again the atom, the location could have changed
-QDesktopWidget *desktop = QApplication::desktop();
-QRect avail = desktop->availableGeometry(desktop->screenNumber(pos()));
+Location location = Desktop;
 
-Display *dpy = QX11Info::display();
-Atom atom = XInternAtom( dpy, "_KDE_SLIDE", False );
-QVarLengthArray data(2);
-
 switch (direction) {
+case Down:
+location = BottomEdge;
+break;
+case 

Re: Review Request: Window runner to switch windows and desktops

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/
---

(Updated 2009-07-26 12:34:22.065536)


Review request for Plasma.


Changes
---

Support for showing the window icons. It's not really nice, so if anyone has a 
better idea I'm glad to hear about it.


Summary
---

This runner lists the windows and virtual desktops. It allows to activate a 
selected window or switch to a selected desktop. The runner works in the 
following way:
 * input is matched on window name, class or role; matching windows are listed
 * input is matched on desktop name. Matching desktops are shown for switching 
to, all windows on matching desktops are listed.
 * keyword "desktop": lists all desktops (except current) if additional number 
is inserted the list is reduced to that desktop
 * keyword "window": lists all windows. Additional text will be used to 
restrict like in first case. Following sub queries to restrict search are 
possible:
   * name=: restrict on name
   * class=: restrict on window class
   * role=: restrict on window role
   * desktop=: restrict on desktop
  those subqueries can be combined in any order. Each input not containing a 
'=' will be interpreted as a name restriction if there is no explicit name 
restriction. In that case it's ignored. Example query: "window desktop=2 
class=kmail role=composer" will list all open KMail composer windows on desktop 
2.


Diffs (updated)
-

  trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt 1000707 
  trunk/KDE/kdebase/workspace/plasma/runners/windows/CMakeLists.txt 
PRE-CREATION 
  
trunk/KDE/kdebase/workspace/plasma/runners/windows/plasma-runner-windows.desktop
 PRE-CREATION 
  trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.h 
PRE-CREATION 
  trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp 
PRE-CREATION 

Diff: http://reviewboard.kde.org/r/1114/diff


Testing
---


Thanks,

Martin

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

Re: Review Request: Window runner to switch windows and desktops

[Ryan Bitanga]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/#review1788
---



trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp


One of the reasons I worked on multiple action support for KRunner in 4.2 
was so that we could avoid this exact use case of having multiple subkeywords 
and instead make it easier for the user by providing a standard set of actions 
to choose from. I know this is isn't exposed in the default interface but I 
think the solution should be to expose it in the interface rather than have a 
more complex language in a runner.

I also suggested you use libtaskmanager to avoid a long chain of if clauses 
like the one here. Using libtaskmanager also provides a more consistent feel 
than directly calling methods from KWindowSystem because it the user will be 
prompted with the same actions in the window menu and the task bar. It also 
simplifies the run method to a simple call to action->trigger().



trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp


ditto as above. I'm not a huge fan of writing code that does something 
another library already simplifies.

Why don't you take a look at playground/base/plasma/runners/windows for an 
idea of how to do this? :) The one in playground was a proof of concept runner 
to show: 1) how to execute code in the GUI thread from within the match method 
and 2) how to provide possible actions once a user chooses a match.


- Ryan


On 2009-07-26 12:34:22, Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1114/
> ---
> 
> (Updated 2009-07-26 12:34:22)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This runner lists the windows and virtual desktops. It allows to activate a 
> selected window or switch to a selected desktop. The runner works in the 
> following way:
>  * input is matched on window name, class or role; matching windows are listed
>  * input is matched on desktop name. Matching desktops are shown for 
> switching to, all windows on matching desktops are listed.
>  * keyword "desktop": lists all desktops (except current) if additional 
> number is inserted the list is reduced to that desktop
>  * keyword "window": lists all windows. Additional text will be used to 
> restrict like in first case. Following sub queries to restrict search are 
> possible:
>* name=: restrict on name
>* class=: restrict on window class
>* role=: restrict on window role
>* desktop=: restrict on desktop
>   those subqueries can be combined in any order. Each input not containing a 
> '=' will be interpreted as a name restriction if there is no explicit name 
> restriction. In that case it's ignored. Example query: "window desktop=2 
> class=kmail role=composer" will list all open KMail composer windows on 
> desktop 2.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt 1000707 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/CMakeLists.txt 
> PRE-CREATION 
>   
> trunk/KDE/kdebase/workspace/plasma/runners/windows/plasma-runner-windows.desktop
>  PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.h 
> PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/1114/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin
> 
>

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

Re: Review Request: Window runner to switch windows and desktops

[Martin Gräßlin]

> On 2009-07-26 15:44:49, Ryan Bitanga wrote:
> > trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp, line 
> > 129
> > 
> >
> > One of the reasons I worked on multiple action support for KRunner in 
> > 4.2 was so that we could avoid this exact use case of having multiple 
> > subkeywords and instead make it easier for the user by providing a standard 
> > set of actions to choose from. I know this is isn't exposed in the default 
> > interface but I think the solution should be to expose it in the interface 
> > rather than have a more complex language in a runner.
> > 
> > I also suggested you use libtaskmanager to avoid a long chain of if 
> > clauses like the one here. Using libtaskmanager also provides a more 
> > consistent feel than directly calling methods from KWindowSystem because it 
> > the user will be prompted with the same actions in the window menu and the 
> > task bar. It also simplifies the run method to a simple call to 
> > action->trigger().

I used the actions and reverted all changes in my git repository for various 
reasons. The most important: a runner for window management should be fast. 
It's a complete difference if I have to "kop close" to close my kopete window, 
or if I have to first search the kopete window and than to select the action. 
Nevertheless having the powerfull commands does not limit to add additional 
actions. But as long as there are no actions in the default run interface I 
consider it as a nice to have feature.

About libtaskmanager: I am a KWin def. For me KWindowSystem is very high level 
;-) I want to have the power KWindowSystem provides. If the plasma devs tell me 
to use libtaskmanager I might consider to change it, but personally I don't see 
any reason for it and for me the code is still good structured and easy to read.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/#review1788
---


On 2009-07-26 12:34:22, Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1114/
> ---
> 
> (Updated 2009-07-26 12:34:22)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This runner lists the windows and virtual desktops. It allows to activate a 
> selected window or switch to a selected desktop. The runner works in the 
> following way:
>  * input is matched on window name, class or role; matching windows are listed
>  * input is matched on desktop name. Matching desktops are shown for 
> switching to, all windows on matching desktops are listed.
>  * keyword "desktop": lists all desktops (except current) if additional 
> number is inserted the list is reduced to that desktop
>  * keyword "window": lists all windows. Additional text will be used to 
> restrict like in first case. Following sub queries to restrict search are 
> possible:
>* name=: restrict on name
>* class=: restrict on window class
>* role=: restrict on window role
>* desktop=: restrict on desktop
>   those subqueries can be combined in any order. Each input not containing a 
> '=' will be interpreted as a name restriction if there is no explicit name 
> restriction. In that case it's ignored. Example query: "window desktop=2 
> class=kmail role=composer" will list all open KMail composer windows on 
> desktop 2.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt 1000707 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/CMakeLists.txt 
> PRE-CREATION 
>   
> trunk/KDE/kdebase/workspace/plasma/runners/windows/plasma-runner-windows.desktop
>  PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.h 
> PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/1114/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin
> 
>

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

Re: Prospective costs of the 3rd Plasma meeting (Tokamak3) - part 2

[Ana Cecília Martins Barbosa]

thank you, morpheuz, for remembering that for me!
that's true :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Prospective costs of the 3rd Plasma meeting (Tokamak3) - part 2

[Mario Fux]

Am Sonntag, 26. Juli 2009 schrieb Artur Souza (MoRpHeUz):

Good morning

> On Thursday 23 July 2009, 15:42 Ivan Čukić wrote:
> > Ana Cecília Martins Barbosa: anaceciliamb at gmail.com
>
> Just came to my mind that she'll also need an invitation letter. I don't
> need as I have double citizenship and I come as an italian. But it's better
> for brazilians to have invitation letters when coming to europe.

Ana: Please send us your address.
Sebas: Could you please do for her the same as for Ivan?

> Cheers,

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

Re: containing plasmoid crashes

[Chani]

>
> Example of their success: Clicking a link in kmail, for example, will spawn
> that as a tab in an existing chrome browser if one is running. Caveat--if
> one died and is still an existing process, one must kill it before chrome
> will work correctly. Beta.
>

that's got nothing to do with separate processes. konqueror's had that feature 
for *years*.


anyways, this problem only exists for c++ plasmoids. solution: don't write in 
c++. you can't send c++ ones over GHNS either, anyways. we've been over this 
before.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [PATCH] BUG 199107 make the popup dialog of group hide automatically on taskbar

[Aaron J. Seigo]

On Sunday 26 July 2009, 潘卫平(Peter Pan) wrote:
> Any idea to improve it?

i think the last patch you posted can be committed to trunk ...

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


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Problems with DataEngine in Python

[John Hobbs]

Hello,

I've been trying to write my first Plasmoid in python, and I've been stuck
on using the DataEngines [1].  I'm working off of the microblog applet [2]
to try and understand how to interact with that engine.  My problem comes
when I try to get a service from my engine.  I'm getting an error:
*AttributeError:
'DataEngine' object has no attribute 'serviceForSource'* even though the api
says it should be there [3]

Here is the chunk that is erroring out on me:

  self.engine = self.dataEngine("microblog")
  if not self.engine.isValid:
self.setFailedToLaunch(True, "Could not get DataEngine")
  service = self.engine.serviceForSource("Timeline:Jmhobbs@
https://twitter.com/";)
  cg = service.operationDescription("auth");
  cg.writeEntry("password", "SuperSecret");
  service.startOperationCall(cg);

I'm running  Python 2.5.4, and KDE - 4.2.4  (Debian sid)

My questions are,

   1. Is there something fundamentally wrong with my understanding on how to
   use DataEngines?
   2. Is there just a version mismatch between the bindings (as documented)
   and my system?
   3. Is there documentation on the microblog engine and how to use it?
   4. Do I have an alternative? I tried QThreads/urllib (crashes
   unpredictably), and KIO (KUrl seems to ignore setUser() and setPass())
   already to no avail.

Thanks so much in advance for your assistance.  I'm looking forward to
creating more community content once I iron this stuff out :-)

[1] -
http://techbase.kde.org/Development/Tutorials/Plasma/Python/Using_DataEngines
[2] -
http://websvn.kde.org/trunk/KDE/kdeplasma-addons/applets/microblog/microblog.cpp?view=markup
[3] -
http://api.kde.org/pykde-4.2-api/plasma/Plasma.DataEngine.html#obj3065602732

- John Hobbs

j...@velvetcache.org

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

Re: panels and popups sliding effect

[Aaron J. Seigo]

On Sunday 26 July 2009, Marco Martin wrote:
> i'm really on the fence on where to put this and how to call it.
> Becasue if we put other stuff like that like the taskbar thumbnails and the
> glow effect they wouldn't have much to do with animation, and i'm kinda
> wondering if plasma is the right namespace/lib for that, hmm..

Plasma::WindowEffects as a name space in libplasma is just fine i think.

cons:

* it's not really 100% in the right "theme" for libplasma (a components-on-
canvas library)

* it's potentially useful to many other applications that otherwise wouldn't 
need libplasma


pros:

* it allows us to use it in libplasma (Dialog, ToolTip, etc)

* it allows us to use Plasma defines, such as location (which putting it in 
kdeui, for instance, wouldn't); perhaps this could be worked around, though

* from libplasma all plasma shells and plugins can easily take advantage of 
this functionality


so not perfect, but i don't see a better place for it. let's put it in trunk, 
start using it and see if something better doesn't become evident before 4.4.0 
is released.

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


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Window runner to switch windows and desktops

[Aaron Seigo]

> On 2009-07-26 15:44:49, Ryan Bitanga wrote:
> > trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp, line 
> > 129
> > 
> >
> > One of the reasons I worked on multiple action support for KRunner in 
> > 4.2 was so that we could avoid this exact use case of having multiple 
> > subkeywords and instead make it easier for the user by providing a standard 
> > set of actions to choose from. I know this is isn't exposed in the default 
> > interface but I think the solution should be to expose it in the interface 
> > rather than have a more complex language in a runner.
> > 
> > I also suggested you use libtaskmanager to avoid a long chain of if 
> > clauses like the one here. Using libtaskmanager also provides a more 
> > consistent feel than directly calling methods from KWindowSystem because it 
> > the user will be prompted with the same actions in the window menu and the 
> > task bar. It also simplifies the run method to a simple call to 
> > action->trigger().
> 
>  wrote:
> I used the actions and reverted all changes in my git repository for 
> various reasons. The most important: a runner for window management should be 
> fast. It's a complete difference if I have to "kop close" to close my kopete 
> window, or if I have to first search the kopete window and than to select the 
> action. Nevertheless having the powerfull commands does not limit to add 
> additional actions. But as long as there are no actions in the default run 
> interface I consider it as a nice to have feature.
> 
> About libtaskmanager: I am a KWin def. For me KWindowSystem is very high 
> level ;-) I want to have the power KWindowSystem provides. If the plasma devs 
> tell me to use libtaskmanager I might consider to change it, but personally I 
> don't see any reason for it and for me the code is still good structured and 
> easy to read.

right, so the question is "when are actions most suitable?"

to me, krunner should allow one to easily and quickly "talk" to the computer. 
so "kop close" is just about perfect: it's quick, it's succinct and it's me 
"talking" to my computer.

actions should be there, at imho, to give additional options not directly 
related to the query on something that does match the query. e.g. if i type in 
"quarterly report" and that pops up the pdf of the last report from the e.V. 
then selecting that action should open it ... but maybe there are other things 
i'd like to do with it that aren't really related to the direct query, such as 
deleting it or opening it with a non-default application or ...

now, we could just list all of those possibilities as other possible matches 
with low, but that really doesn't scale and would be a lot less convenient to 
navigate.

in this case, i think that showing "min/max/etc" as actions when the user just 
types in "kop" which brings up the kopete window as a possibility makes sense. 
that way the user can find the window, then access various actions on it.

this is a duplication of function ("close kop" vs "kop" and select the close 
action) but is likely the most flexible and natural, depending on how the user 
wants to go about it. i don't think such duplication of functionality will be 
overly common, however. most items nicely divided between "object" and "action 
without object"

sooo... i think the code as it stands in this patch is fine, and that adding 
actions to the general match case would be a nice bonus.


- Aaron


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/#review1788
---


On 2009-07-26 12:34:22, Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1114/
> ---
> 
> (Updated 2009-07-26 12:34:22)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This runner lists the windows and virtual desktops. It allows to activate a 
> selected window or switch to a selected desktop. The runner works in the 
> following way:
>  * input is matched on window name, class or role; matching windows are listed
>  * input is matched on desktop name. Matching desktops are shown for 
> switching to, all windows on matching desktops are listed.
>  * keyword "desktop": lists all desktops (except current) if additional 
> number is inserted the list is reduced to that desktop
>  * keyword "window": lists all windows. Additional text will be used to 
> restrict like in first case. Following sub queries to restrict search are 
> possible:
>* name=: restrict on name
>* class=: restrict on window class
>* role=: restrict on window role
>* desktop=: restrict on desktop
>   those subqueries c

Re: panels and popups sliding effect

[Marco Martin]

On Sunday 26 July 2009, Aaron J. Seigo wrote:
> On Sunday 26 July 2009, Marco Martin wrote:
> > i'm really on the fence on where to put this and how to call it.
> > Becasue if we put other stuff like that like the taskbar thumbnails and
> > the glow effect they wouldn't have much to do with animation, and i'm
> > kinda wondering if plasma is the right namespace/lib for that, hmm..
>
> Plasma::WindowEffects as a name space in libplasma is just fine i think.
>
> cons:
>
> * it's not really 100% in the right "theme" for libplasma (a components-on-
> canvas library)
>
> * it's potentially useful to many other applications that otherwise
> wouldn't need libplasma
>
>
> pros:
>
> * it allows us to use it in libplasma (Dialog, ToolTip, etc)
>
> * it allows us to use Plasma defines, such as location (which putting it in
> kdeui, for instance, wouldn't); perhaps this could be worked around, though
>
> * from libplasma all plasma shells and plugins can easily take advantage of
> this functionality
>
>
> so not perfect, but i don't see a better place for it. let's put it in
> trunk, start using it and see if something better doesn't become evident
> before 4.4.0 is released.
ok, so for now WindowEffects is in :)


Cheers, 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Window runner to switch windows and desktops

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/#review1792
---


my only comment is that it would be nice if one could type "close kop" as "kop 
close" seems backwards (though i do recognize that that is a language issue, 
where in English we do verb->noun :)

not using libtaskmanager in this case is just fine; it's not a lot of code, the 
code is clear and libtaskmanager does a ton of extra stuff that just isn't 
needed here.

- Aaron


On 2009-07-26 12:34:22, Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1114/
> ---
> 
> (Updated 2009-07-26 12:34:22)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This runner lists the windows and virtual desktops. It allows to activate a 
> selected window or switch to a selected desktop. The runner works in the 
> following way:
>  * input is matched on window name, class or role; matching windows are listed
>  * input is matched on desktop name. Matching desktops are shown for 
> switching to, all windows on matching desktops are listed.
>  * keyword "desktop": lists all desktops (except current) if additional 
> number is inserted the list is reduced to that desktop
>  * keyword "window": lists all windows. Additional text will be used to 
> restrict like in first case. Following sub queries to restrict search are 
> possible:
>* name=: restrict on name
>* class=: restrict on window class
>* role=: restrict on window role
>* desktop=: restrict on desktop
>   those subqueries can be combined in any order. Each input not containing a 
> '=' will be interpreted as a name restriction if there is no explicit name 
> restriction. In that case it's ignored. Example query: "window desktop=2 
> class=kmail role=composer" will list all open KMail composer windows on 
> desktop 2.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt 1000707 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/CMakeLists.txt 
> PRE-CREATION 
>   
> trunk/KDE/kdebase/workspace/plasma/runners/windows/plasma-runner-windows.desktop
>  PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.h 
> PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/1114/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin
> 
>

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

Re: containing plasmoid crashes

[David Baron]

On Sunday 26 July 2009 21:20:55 Chani wrote:
> > Example of their success: Clicking a link in kmail, for example, will
> > spawn that as a tab in an existing chrome browser if one is running.
> > Caveat--if one died and is still an existing process, one must kill it
> > before chrome will work correctly. Beta.
>
> that's got nothing to do with separate processes. konqueror's had that
> feature for *years*.

Each such click brings up a new konqueror window, unless I am missing 
something. Konqueror has not worked right for a while now.

>
>
> anyways, this problem only exists for c++ plasmoids. solution: don't write
> in c++. you can't send c++ ones over GHNS either, anyways. we've been over
> this before.
Do not the various interperators or VMs need be loaded in memory to service 
their plasmoids, i.e., if I write in in Java, the entire Java business needs 
be around all the time now. Add one in Python (OK, much more economical), 
Ruby, etc. and things can get a bit full up. All those C++ers share the same 
libraries as Plasma and QT itself.

What about Mono/.Net :-) ??

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

Re: Review Request: Window runner to switch windows and desktops

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/#review1793
---


ok, now the implementation review part of things :)

one thing that is useful to observe about this is that it takes a more memory 
intensive approach, storing the individual icons, window info and winid of all 
available windows, to make matching (at least in theory?) faster.

the downside is that krunner is going to wake up (and therefore stay in main 
memory and be executing code) whenever windows change. that may not be exactly 
optimal ;)

the windowinfo isn't actually used except for when one of the keywords like 
desktop is used, and the icons aren't used unless a match is made. but fetching 
the list of windowinfo in each pass through match can't be great either.

what would really be useful here would be some way to tell the runner "you 
should be prepping yourself for use now" and then later "ok, we're done with 
this search session". krunner itself could delete the runners between 
invocations of the interface, but depending on the runner that can be rather 
slow-ish and if there are runners that ever require a constant and stateful 
connection to something external that would hurt.

so it would seem we need some mechanism to prod a runner to get ready for 
searches and then let it know again when it can not worry about it at all. that 
way this runner could populate the windowInfo collection and only pay attention 
to window changes when the krunner interface is actually activated by the user.



trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp


plasma style is " } else if (..) {"

if this is meant to go into kdebase (where i thin it does belong) those ws 
changes will need to be made at some point :)



trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp


don't use keys(); it's a very slow mechanism (iterates over the collection, 
allocates a new list, and then you iterate over that again in the foreach). 
should use a QMapIterator here instead



trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp


should use a proper iterator here rather than keys()



trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp


another usage of keys()


- Aaron


On 2009-07-26 12:34:22, Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1114/
> ---
> 
> (Updated 2009-07-26 12:34:22)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This runner lists the windows and virtual desktops. It allows to activate a 
> selected window or switch to a selected desktop. The runner works in the 
> following way:
>  * input is matched on window name, class or role; matching windows are listed
>  * input is matched on desktop name. Matching desktops are shown for 
> switching to, all windows on matching desktops are listed.
>  * keyword "desktop": lists all desktops (except current) if additional 
> number is inserted the list is reduced to that desktop
>  * keyword "window": lists all windows. Additional text will be used to 
> restrict like in first case. Following sub queries to restrict search are 
> possible:
>* name=: restrict on name
>* class=: restrict on window class
>* role=: restrict on window role
>* desktop=: restrict on desktop
>   those subqueries can be combined in any order. Each input not containing a 
> '=' will be interpreted as a name restriction if there is no explicit name 
> restriction. In that case it's ignored. Example query: "window desktop=2 
> class=kmail role=composer" will list all open KMail composer windows on 
> desktop 2.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt 1000707 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/CMakeLists.txt 
> PRE-CREATION 
>   
> trunk/KDE/kdebase/workspace/plasma/runners/windows/plasma-runner-windows.desktop
>  PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.h 
> PRE-CREATION 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/1114/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin
> 
>

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

Re: containing plasmoid crashes

[Aaron J. Seigo]

On Sunday 26 July 2009, David Baron wrote:
> A similar problem has seemingly been solved, by  Google. Since google's
> browser is opensource, one might take a look.

chrome solves a completely different problem. it displays a completely 
_different_ canvas (in this case, an html one) in each tab.

we are showing a single canvas with items in it.

the semi-equivalent in chrome would be to make each html element in the page 
it's own process and then have them all paint to the same canvas. it's still 
only semi-equivalent because, while there is javascript interaction, the html-
paint-to-canvas mechanism is a lot less complex than what QGraphicsView 
offers.

now, if you think that it's still a sane idea, go map out on paper all the 
details including data synchronization and managing painting from multiple 
process, remembering that the desktop is supposed to be very responsive and 
take as little cpu as possible.

the real solution is to use scripting languages and make sure the c++ plugins 
are absolutely solid.

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


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: containing plasmoid crashes

[Aaron J. Seigo]

On Sunday 26 July 2009, David Baron wrote:
> Do not the various interperators or VMs need be loaded in memory to service
> their plasmoids

so we need to:

* have full ecma script bindings available
* promote use of ecma script over other options
* use ruby/python only as really needed (e.g access to additional libraries 
with python/ruby bindings)

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


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: containing plasmoid crashes

[Aaron J. Seigo]

On Sunday 26 July 2009, Bogdan Bivolaru wrote:
> [Plasma] Plasmoids as separate processes

this will not be implemented. see my other replies in this thread as to why.

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


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Window runner to switch windows and desktops

[Martin Gräßlin]

> On 2009-07-26 19:19:43, Aaron Seigo wrote:
> > ok, now the implementation review part of things :)
> > 
> > one thing that is useful to observe about this is that it takes a more 
> > memory intensive approach, storing the individual icons, window info and 
> > winid of all available windows, to make matching (at least in theory?) 
> > faster.
> > 
> > the downside is that krunner is going to wake up (and therefore stay in 
> > main memory and be executing code) whenever windows change. that may not be 
> > exactly optimal ;)
> > 
> > the windowinfo isn't actually used except for when one of the keywords like 
> > desktop is used, and the icons aren't used unless a match is made. but 
> > fetching the list of windowinfo in each pass through match can't be great 
> > either.
> > 
> > what would really be useful here would be some way to tell the runner "you 
> > should be prepping yourself for use now" and then later "ok, we're done 
> > with this search session". krunner itself could delete the runners between 
> > invocations of the interface, but depending on the runner that can be 
> > rather slow-ish and if there are runners that ever require a constant and 
> > stateful connection to something external that would hurt.
> > 
> > so it would seem we need some mechanism to prod a runner to get ready for 
> > searches and then let it know again when it can not worry about it at all. 
> > that way this runner could populate the windowInfo collection and only pay 
> > attention to window changes when the krunner interface is actually 
> > activated by the user.
> >

Of course I didn't want to cache all data. The problem is that when I fetch the 
data during execeution, KRunner crashes somewhere in the upper Qt stack :-( I 
rarely saw DrKonqui and it looks like the problem was in xcb not being able to 
handle so many request at the same time.

So yes that preparing to run and finishing afterwards sounds like a good 
solution. That way nothing would need to be cached and KRunner could remain 
sleeping.


> On 2009-07-26 19:19:43, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp, lines 
> > 187-188
> > 
> >
> > plasma style is " } else if (..) {"
> > 
> > if this is meant to go into kdebase (where i thin it does belong) those 
> > ws changes will need to be made at some point :)

no problem - I'll change. Btw. that rule is missing on 
http://techbase.kde.org/Policies/Kdelibs_Coding_Style


> On 2009-07-26 19:19:43, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/plasma/runners/windows/windowsrunner.cpp, line 
> > 206
> > 
> >
> > don't use keys(); it's a very slow mechanism (iterates over the 
> > collection, allocates a new list, and then you iterate over that again in 
> > the foreach). should use a QMapIterator here instead

thanks for pointing out. I'll change all of those.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1114/#review1793
---


On 2009-07-26 12:34:22, Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1114/
> ---
> 
> (Updated 2009-07-26 12:34:22)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This runner lists the windows and virtual desktops. It allows to activate a 
> selected window or switch to a selected desktop. The runner works in the 
> following way:
>  * input is matched on window name, class or role; matching windows are listed
>  * input is matched on desktop name. Matching desktops are shown for 
> switching to, all windows on matching desktops are listed.
>  * keyword "desktop": lists all desktops (except current) if additional 
> number is inserted the list is reduced to that desktop
>  * keyword "window": lists all windows. Additional text will be used to 
> restrict like in first case. Following sub queries to restrict search are 
> possible:
>* name=: restrict on name
>* class=: restrict on window class
>* role=: restrict on window role
>* desktop=: restrict on desktop
>   those subqueries can be combined in any order. Each input not containing a 
> '=' will be interpreted as a name restriction if there is no explicit name 
> restriction. In that case it's ignored. Example query: "window desktop=2 
> class=kmail role=composer" will list all open KMail composer windows on 
> desktop 2.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdebase/workspace/plasma/runners/CMakeLists.txt 1000707 
>   trunk/KDE/kdebase/workspace/plasma/runners/windows/CMakeLists.txt 
> PRE-CREATION 
>   
> trunk/KDE/kdebase/

Plasmate Status

[Shantanu Tushar Jha]

So, another 2 weeks, and here comes the Plasmate status report :)

As the CHANGELOG says, we have

1. Fixed the problem with the project name not taking input.
(KRestrictedLine issue)
2. Plasmate remembers positioning of the docks, and reloads on startup.
3. Options to select the scripting language while creating a new project.
4. Made some UI changes.

And about the savesystem and Timeline, I believe Deigo is working hard.
( Btw, I can't see the Timeline menus and see it in action, just a "Not a
savepoint" icon. Diego, Am I missing something, or its not commited yet? )

Make it rock !!
-- 
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Prospective costs of the 3rd Plasma meeting (Tokamak3) - part 2

[Sebastian Kügler]

On Sunday 26 July 2009 19:06:51 Mario Fux wrote:
> Am Sonntag, 26. Juli 2009 schrieb Artur Souza (MoRpHeUz):
> > On Thursday 23 July 2009, 15:42 Ivan Čukić wrote:
> > > Ana Cecília Martins Barbosa: anaceciliamb at gmail.com
> >
> > Just came to my mind that she'll also need an invitation letter. I don't
> > need as I have double citizenship and I come as an italian. But it's
> > better for brazilians to have invitation letters when coming to europe.
>
> Ana: Please send us your address.
> Sebas: Could you please do for her the same as for Ivan?

Sure. Ana, can you send me your address? (Private email is fine of course.)
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: containing plasmoid crashes

[Chani]

On July 26, 2009 12:10:25 David Baron wrote:
> On Sunday 26 July 2009 21:20:55 Chani wrote:
> > > Example of their success: Clicking a link in kmail, for example, will
> > > spawn that as a tab in an existing chrome browser if one is running.
> > > Caveat--if one died and is still an existing process, one must kill it
> > > before chrome will work correctly. Beta.
> >
> > that's got nothing to do with separate processes. konqueror's had that
> > feature for *years*.
>
> Each such click brings up a new konqueror window, unless I am missing
> something. Konqueror has not worked right for a while now.
>

WorksForMe.
check your configuration.
believe me, if this broke I would've raised hell until someone fixed it ;)

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: containing plasmoid crashes

[Artur Souza (MoRpHeUz)]

On Sunday 26 July 2009, 16:24 Aaron J. Seigo wrote:
> the real solution is to use scripting languages and make sure the c++
> plugins are absolutely solid.

+1 here. It's the sanest (does this word exist in english :) ?) way to do this 
stuff.

Cheers :)

--
Artur Duque de Souza
openBossa Research Labs
INdT - Instituto Nokia de Tecnologia
--
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
--


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix layout problems in the pager applet

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1124/#review1799
---

Ship it!


ok, this looks safe enough .. pls commit this to trunk, let's test it 
thoroughly there, and then we can backport it if/when no problems arise.

- Aaron


On 2009-07-25 21:40:41, Anthony Bryant wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1124/
> ---
> 
> (Updated 2009-07-25 21:40:41)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch fixes a few problems with the pager that are especially apparent 
> in vertical panels. Specifically, the rows and columns are unnecessarily 
> swapped in recalculateGeometry() which causes bug 200013.
> Also, due to the way the rectangle sizes were calculated it was possible for 
> certain areas to be clipped. This patch makes sure every item can fit into 
> the current space.
> This also fixes a bug I only noticed when reading the code, where extra 
> unnecessary columns could be added if desktopCount % rows > 1
> 
> My main concern about this patch is that it removes a mechanism for ignoring 
> some constraints events, I think these events are needed in order to avoid 
> clipping some of the virtual desktops, but I'm not sure how to reproduce the 
> bug that made this filtering necessary in the first place.
> 
> 
> This addresses bug 200013.
> https://bugs.kde.org/show_bug.cgi?id=200013
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.h 1002081 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.cpp 1002081 
> 
> Diff: http://reviewboard.kde.org/r/1124/diff
> 
> 
> Testing
> ---
> 
> Tested in vertical and horizontal panels and on the desktop.
> 
> 
> Thanks,
> 
> Anthony
> 
>

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

Re: Review Request: Fix layout problems in the pager applet

[Anthony Bryant]

> On 2009-07-27 00:08:35, Aaron Seigo wrote:
> > ok, this looks safe enough .. pls commit this to trunk, let's test it 
> > thoroughly there, and then we can backport it if/when no problems arise.

Thanks! I don't actually have an svn account... Could you commit it for me?


- Anthony


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1124/#review1799
---


On 2009-07-25 21:40:41, Anthony Bryant wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1124/
> ---
> 
> (Updated 2009-07-25 21:40:41)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch fixes a few problems with the pager that are especially apparent 
> in vertical panels. Specifically, the rows and columns are unnecessarily 
> swapped in recalculateGeometry() which causes bug 200013.
> Also, due to the way the rectangle sizes were calculated it was possible for 
> certain areas to be clipped. This patch makes sure every item can fit into 
> the current space.
> This also fixes a bug I only noticed when reading the code, where extra 
> unnecessary columns could be added if desktopCount % rows > 1
> 
> My main concern about this patch is that it removes a mechanism for ignoring 
> some constraints events, I think these events are needed in order to avoid 
> clipping some of the virtual desktops, but I'm not sure how to reproduce the 
> bug that made this filtering necessary in the first place.
> 
> 
> This addresses bug 200013.
> https://bugs.kde.org/show_bug.cgi?id=200013
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.h 1002081 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.cpp 1002081 
> 
> Diff: http://reviewboard.kde.org/r/1124/diff
> 
> 
> Testing
> ---
> 
> Tested in vertical and horizontal panels and on the desktop.
> 
> 
> Thanks,
> 
> Anthony
> 
>

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

Review Request: Allow runners to do quick prepare and teardown for match sessions

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1133/
---

Review request for Plasma.


Summary
---

Right now runners have only one opportunity to set themselves up: when init() 
is called. It has become apparent that for _some_ runners it is advantageous to 
do a bit of set up before a matching session starts and teardown afterwards. 
For instance, the new window runner needs to keep track of the windows that 
exist and it shouldn't be getting that information constantly as the user 
types; equally so, it shouldn't be holding onto and keeping this information up 
to date even when the krunner interface isn't shown.

This patch provides a set of signals that runners may optionally listen to. A 
user of RunnerManager may call prepareForMatchSession and matchSessionComplete 
itself, or just let RunnerManager call prepareForMatchSession itself if it 
doesn't care about resource usage.

Users of AbstractRunner which aren't using RunnerManager to do so can "fudge" 
this by connecting a local signal to the AbstractRunner signal and then 
emitting the local signal inside the local code. Not overly elegant, but 
certainly an edge case (and one we don't have right now). All AbstractRunner 
usage really should be going through RunnerManager.

I'm still looking for better names for the new methods/signals, so suggestions 
welcome there, too! Wanted to get some feedback on the design earlier, though.


Diffs
-

  /trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.cpp 1002691 
  /trunk/KDE/kdebase/workspace/krunner/krunnerdialog.h 1002202 
  /trunk/KDE/kdebase/workspace/krunner/krunnerdialog.cpp 1002202 
  /trunk/KDE/kdelibs/plasma/abstractrunner.h 1002205 
  /trunk/KDE/kdelibs/plasma/runnermanager.h 1002205 
  /trunk/KDE/kdelibs/plasma/runnermanager.cpp 1002205 

Diff: http://reviewboard.kde.org/r/1133/diff


Testing
---

built, ran krunner ...


Thanks,

Aaron

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

Re: Review Request: Fix layout problems in the pager applet

[Aaron Seigo]

> On 2009-07-27 00:08:35, Aaron Seigo wrote:
> > ok, this looks safe enough .. pls commit this to trunk, let's test it 
> > thoroughly there, and then we can backport it if/when no problems arise.
> 
> Anthony Bryant wrote:
> Thanks! I don't actually have an svn account... Could you commit it for 
> me?

sure :)

note that if you start submitting more patches, i'll be sending you over to 
http://techbase.kde.org/Contribute/Get_a_SVN_Account ;)


- Aaron


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1124/#review1799
---


On 2009-07-25 21:40:41, Anthony Bryant wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1124/
> ---
> 
> (Updated 2009-07-25 21:40:41)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch fixes a few problems with the pager that are especially apparent 
> in vertical panels. Specifically, the rows and columns are unnecessarily 
> swapped in recalculateGeometry() which causes bug 200013.
> Also, due to the way the rectangle sizes were calculated it was possible for 
> certain areas to be clipped. This patch makes sure every item can fit into 
> the current space.
> This also fixes a bug I only noticed when reading the code, where extra 
> unnecessary columns could be added if desktopCount % rows > 1
> 
> My main concern about this patch is that it removes a mechanism for ignoring 
> some constraints events, I think these events are needed in order to avoid 
> clipping some of the virtual desktops, but I'm not sure how to reproduce the 
> bug that made this filtering necessary in the first place.
> 
> 
> This addresses bug 200013.
> https://bugs.kde.org/show_bug.cgi?id=200013
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.h 1002081 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.cpp 1002081 
> 
> Diff: http://reviewboard.kde.org/r/1124/diff
> 
> 
> Testing
> ---
> 
> Tested in vertical and horizontal panels and on the desktop.
> 
> 
> Thanks,
> 
> Anthony
> 
>

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

Re: Review Request: Fix layout problems in the pager applet

[Aaron Seigo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1124/#review1802
---


just found a "small" problem when doing some more testing before commit: when 
it's in a non horiz/vert form factor (e.g. planar, aka "the desktop") the size 
of the desktop bits don't scale down consistently to fit the width. you can 
test this easily with `plasmoidviewer pager`

- Aaron


On 2009-07-25 21:40:41, Anthony Bryant wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1124/
> ---
> 
> (Updated 2009-07-25 21:40:41)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch fixes a few problems with the pager that are especially apparent 
> in vertical panels. Specifically, the rows and columns are unnecessarily 
> swapped in recalculateGeometry() which causes bug 200013.
> Also, due to the way the rectangle sizes were calculated it was possible for 
> certain areas to be clipped. This patch makes sure every item can fit into 
> the current space.
> This also fixes a bug I only noticed when reading the code, where extra 
> unnecessary columns could be added if desktopCount % rows > 1
> 
> My main concern about this patch is that it removes a mechanism for ignoring 
> some constraints events, I think these events are needed in order to avoid 
> clipping some of the virtual desktops, but I'm not sure how to reproduce the 
> bug that made this filtering necessary in the first place.
> 
> 
> This addresses bug 200013.
> https://bugs.kde.org/show_bug.cgi?id=200013
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.h 1002081 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.cpp 1002081 
> 
> Diff: http://reviewboard.kde.org/r/1124/diff
> 
> 
> Testing
> ---
> 
> Tested in vertical and horizontal panels and on the desktop.
> 
> 
> Thanks,
> 
> Anthony
> 
>

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

Re: Plasma::Package::registerPackage stops working?

[Dong Tiger]

2009/7/25 Aaron J. Seigo 

> On Friday 24 July 2009, Dong Tiger wrote:
> > After removing the line of "X-KDE-ParentApp=", it appears in the dialog.
>
> aha! and looking at the code in libplasma, the reason for that is fairly
> obvious. i'll be committing (and backporting) a fix for this shortly.
> thanks
> for tracking down the exact issue.
>
My pleasure:)

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

Re: Review Request: Allow runners to do quick prepare and teardown for match sessions

[Artur de Souza (MoRpHeUz)]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1133/#review1803
---


The idea seems pretty nice. I've played a little bit with runners and this 
seems very useful for some runner ideas. So, idea++ and implementation++. I'm 
just not sure about the names, as you said, but I don't have better ideas 
either. =/

- Artur


On 2009-07-27 00:19:26, Aaron Seigo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1133/
> ---
> 
> (Updated 2009-07-27 00:19:26)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Right now runners have only one opportunity to set themselves up: when init() 
> is called. It has become apparent that for _some_ runners it is advantageous 
> to do a bit of set up before a matching session starts and teardown 
> afterwards. For instance, the new window runner needs to keep track of the 
> windows that exist and it shouldn't be getting that information constantly as 
> the user types; equally so, it shouldn't be holding onto and keeping this 
> information up to date even when the krunner interface isn't shown.
> 
> This patch provides a set of signals that runners may optionally listen to. A 
> user of RunnerManager may call prepareForMatchSession and 
> matchSessionComplete itself, or just let RunnerManager call 
> prepareForMatchSession itself if it doesn't care about resource usage.
> 
> Users of AbstractRunner which aren't using RunnerManager to do so can "fudge" 
> this by connecting a local signal to the AbstractRunner signal and then 
> emitting the local signal inside the local code. Not overly elegant, but 
> certainly an edge case (and one we don't have right now). All AbstractRunner 
> usage really should be going through RunnerManager.
> 
> I'm still looking for better names for the new methods/signals, so 
> suggestions welcome there, too! Wanted to get some feedback on the design 
> earlier, though.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.cpp 
> 1002691 
>   /trunk/KDE/kdebase/workspace/krunner/krunnerdialog.h 1002202 
>   /trunk/KDE/kdebase/workspace/krunner/krunnerdialog.cpp 1002202 
>   /trunk/KDE/kdelibs/plasma/abstractrunner.h 1002205 
>   /trunk/KDE/kdelibs/plasma/runnermanager.h 1002205 
>   /trunk/KDE/kdelibs/plasma/runnermanager.cpp 1002205 
> 
> Diff: http://reviewboard.kde.org/r/1133/diff
> 
> 
> Testing
> ---
> 
> built, ran krunner ...
> 
> 
> Thanks,
> 
> Aaron
> 
>

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

Re: Review Request: Fix layout problems in the pager applet

[Anthony Bryant]

> On 2009-07-27 00:35:33, Aaron Seigo wrote:
> > just found a "small" problem when doing some more testing before commit: 
> > when it's in a non horiz/vert form factor (e.g. planar, aka "the desktop") 
> > the size of the desktop bits don't scale down consistently to fit the 
> > width. you can test this easily with `plasmoidviewer pager`

Hmm... I don't think I can reproduce it here...
When I test it (both in plasmoidviewer and on the desktop) it scales the 
virtual desktop rectangles properly whenever it is resized. The problem you 
described actually sounds like how it was before this patch if I remember 
rightly...


- Anthony


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1124/#review1802
---


On 2009-07-25 21:40:41, Anthony Bryant wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1124/
> ---
> 
> (Updated 2009-07-25 21:40:41)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch fixes a few problems with the pager that are especially apparent 
> in vertical panels. Specifically, the rows and columns are unnecessarily 
> swapped in recalculateGeometry() which causes bug 200013.
> Also, due to the way the rectangle sizes were calculated it was possible for 
> certain areas to be clipped. This patch makes sure every item can fit into 
> the current space.
> This also fixes a bug I only noticed when reading the code, where extra 
> unnecessary columns could be added if desktopCount % rows > 1
> 
> My main concern about this patch is that it removes a mechanism for ignoring 
> some constraints events, I think these events are needed in order to avoid 
> clipping some of the virtual desktops, but I'm not sure how to reproduce the 
> bug that made this filtering necessary in the first place.
> 
> 
> This addresses bug 200013.
> https://bugs.kde.org/show_bug.cgi?id=200013
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.h 1002081 
>   /trunk/KDE/kdebase/workspace/plasma/applets/pager/pager.cpp 1002081 
> 
> Diff: http://reviewboard.kde.org/r/1124/diff
> 
> 
> Testing
> ---
> 
> Tested in vertical and horizontal panels and on the desktop.
> 
> 
> Thanks,
> 
> Anthony
> 
>

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

Re: zui, windows, desktops

[Chani]

so, me and aaron discussed this last week, and then I promptly forgot all 
about writing any of it down. ;)

it makes a lot more sense when you see the mockups...

I'll try and re-explain it in my own words, hopefully it'll be clearer when 
seen from > 1 POV :)

basically, the idea is to replace the zui (and the proposed windowgroup effect) 
 
with a full overview of everything. no more confusing separation of windows 
and activities, get all your context-switching right here. this isn't really 
about a a UI for switching windows any more, it's about managing them.

on the [top two thirds?] of the screen we have window groups (aka tags). on 
the bottom third we have a row of activities (which are secretly also tags 
too).

in terms of window management, you can (iirc) move/copy windows into different 
groups. you can also copy them to an activity (which really is just tagging 
htem with that activity). windows tagged with an activity only show in the 
overview when that activity is selected. by default new windows wouldn't be 
associated with an activity, and would be in the current window group 
(basically the same behaviour as now).
I assume we could use drag&drop for this as well as clicking buttons.

iirc, when you leave the overview you'll see the windows that were showing in 
the selected window group (so, those with that tag AND the current activity's 
tag). so now you can switch groups as you switched virtual-desktops before, 
but if some windows are tagged with an activity then they're not going to show 
up until you go to the overview and switch to that activity (or use a plasmoid 
to switch activity, or use my mouse plugin, or...)

back to the overview:
the activity strip at the bottom might only have interaction possible for the 
current activity; you'll still be able to drag applets off that one onto 
another activity. unless a plasmoid doesn't have anywhere to drag from :P (the 
notes applet has a richtext bar at the bottom now, phew)

each screen will show a strip with the activities for just that screen (I'm 
assuming we can still drag an activity to another screen). inactive 
containments will be available through some other mechanism which I've 
forgotten. possibly you press a button and a second strip pops up.

to me, this kind of sounds like another kind of dashboard; the current 
dashboard lets me get at my desktop (but not zoom out :( ), this overview one 
would let me get at all my activites and windows and manage them properly.

hrm. I guess that means we need another global keyboard shortcut to activate 
it? it's either that or I put the "show overview" plasmoid on one of my 
panels, and I like keyboard shortcuts better than buttons on panels.


oh, and I still think window tagging should also be available by right-
clicking the titlebar of windows, the way you can move them to another desktop 
now. and through the regular taskbar too.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Prospective costs of the 3rd Plasma meeting (Tokamak3) - part 2

[Ana Cecília Martins Barbosa]

Sent to sebas :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel