Re: [compiz] [RFC] Draft for a compositing manager specification

[Sam Spilsbury]

Hi Martin, All.

On Sun, Aug 15, 2010 at 8:57 PM, Martin Gräßlin
 wrote:
> I want that in the end this becomes a new freedesktop.org specification to be
> used in addition to the EWMH specification. As I am not sure if all composited
> window managers are interested in such a specification I decided to discuss
> this idea first with kwin, compiz (as they implement our proprietary hints)
> and plasma, our most important stakeholder. The result of the discussion
> should be proposed as a joint draft from both compiz and kwin to
> freedesktop.org. I consider each and every of those hints as optional. So a
> window manager implementing none of the hints would be fully compliant.
>
> Even if the attached draft is tainted to the current KWin naming and hints, it
> does not mean that this has to become the standard. I am very open to do
> changes to our code and also implement hints specified by compiz or other
> window managers.

This is a good initiative to start off on. So far I think the list is
good, but it is very specific to KDE in general (considering that most
of these are just KDE hints renamed). I think what needs to be
discussed here is what we agree should be expected from a compositing
manager.

I think one of the major problems we are going to encounter is that
unlike EWMH, this document is focused more on effects and less on
behavior. Considering the current pace of most compositing managers,
the number of effects is likely to grow over the coming years and even
months.

One of the key areas where I think this might happen is in the
"animations" category. Applications could want a whole host of window
animations. It is a good idea to look to things like the Quartz
display system on Mac OS X as to what is possible with this.

In order to address this we need to either have a system of versioning
this specification, or a "base" specification, with a list of agreed
upon properties and client messages hosted on freedesktop.org, with no
versioning (instead using the list of properties stated as "supported"
on the root window.

Of course, the specification is nowhere near finalized now, and I
thought I'd kick off discussion by responding to a few points in the
list of items we have in the specification:

3.3: Present Windows

I think this can more easily be reworked to just set a
_NET_CM_PRESENT_WINDOWS property on the root window, or even as a
client message, with a list of windows that should be presented,
rather than having to support it on a desktop, window class or group
level.

3.4 Dashboard

Unless there is any particular effect that we have in mind for this,
is it possible that clients can just set the Above hint in WM_STATE
and then set one of the various "animation" properties?

3.6 Shadow

Rather than just overriding the shadow altogether, I think a better
approach here is to allow clients to specify here exactly what kind of
shadow or border should be drawn.

The compositor should set the _NET_CM_SHADOW_SUPPORTED hint and
clients should set the following information in the _NET_CM_SHADOW
property on the window.

0 | shadow color (32 bit depth)
1 | shadow radius
2 | shadow x offset
3 | shadow y offset
4 | Number of shadow rects ( > 1 if the window is nonrectangular )
5 | A list of rects specifying shadow extents for each rect.

In the case where there is more than one rect, the compositing manager
should automatically clip shadows  which are not "border" shadows.

>
> I am aware that normally specifications are written in docbook. Unfortunately
> I don't know docbook at all, but I know LaTeX therefore I wrote the draft in
> LaTeX. Attached you find the tex document and a compiled pdf.
>
> If someone has an idea how to collaborate on the document, please tell me. My
> only idea so far is to setup a special repository on gitorious.
>
> Looking forward to your comments.

Thanks,

Sam

>
> Regards
> Martin Gräßlin
>
>
> [1]
> http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.cpp?view=markup
> and http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.h?view=markup
> [2] http://blog.martin-graesslin.com/blog/wp-
> content/uploads/2010/08/compositing.pdf.tar.gz
>
> ___
> compiz mailing list
> com...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>
>



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

Re: [compiz] [RFC] Draft for a compositing manager specification

[Samium Gromoff]

Good day!

> I want that in the end this becomes a new freedesktop.org specification to be 
> used in addition to the EWMH specification. As I am not sure if all 
> composited 
> window managers are interested in such a specification I decided to discuss 
> this idea first with kwin, compiz (as they implement our proprietary hints) 
> and plasma, our most important stakeholder. The result of the discussion 
> should be proposed as a joint draft from both compiz and kwin to 
> freedesktop.org.

Please, forgive me if I'm making a mistake, but otherwise, I strongly
suspect that the Englightenment folks would be an important auditory to
factor in.  What do you think?

-- 
regards,
  Samium Gromoff
--
"Actually I made up the term 'object-oriented', and I can tell you I
did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: New property proposal for StatusNotifierItem protocol: Label

[Sebastian Kügler]

On Friday 13 August 2010 11:11:20 Aurélien Gâteau wrote:
> On 11/08/2010 14:13, Ivan Čukić wrote:
> >> Most likely, we won't use KNotifierStatusItem for KMail's message
> >> indicator, but a proper Plasmoid though -- Lion Mail. The email count
> >> is currently in a
> > 
> > This is a strange decision - what about users that want to use kmail
> > with some other DE?
> 
> This is what I like about SNI (+Label): it provides a nice cross-desktop
> way for a separate process (either a standalone application or a
> separate process desktop tool) to integrate with the desktop.

It cannot sensible show me some kind of preview of my new emails though. I 
mean it could, but then I'd rape the spec.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Krunner Coding Questions

[David Baron]

I have a krunner coded with "run" actions.

1. I add the actions. Their icons overwrite the "wrench" icon on the right. I 
actually prefer the icons rather than a the dropdown usually shown when 
clicking that icon. So I want to not have the "wrench" icon at all, just mine. 
How?

2. The action I have in mind would open the configuration dialog normally 
opened for my runner in the dropdown list of all the runners. Since this is a 
separate "kcm-module," how do I load it and exercise it, getting the 
configuration changed signal to my runner (the parent)?

(I could simply locally create the UI with my own default/apply/cancel 
buttonbox and do this brute force. But why?)

3. I do not want the krunner window to close when I click this action. I want 
to re-perform the match with any new options. How do I keep krunner "live" and 
accomplish this?

Any help or pointers to documentations would be greatly appreciated. Many 
thanks in advance.

(To try current version of recollrunner, get it from kde-apps.org. Recollindex 
runs nicely in the background and does not bog down my system as does the 
"default" kde indexer :-) )
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Extend FolderView::configChanged() to reload configuration values

[Marco Martin]

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

Ship it!


this patch was really needed to make folderview correctly controllable via 
javascript.

to me is good, modulo a couple of style issues below.
if it's ok from fredrik for me it can go in


/trunk/KDE/kdebase/apps/plasma/applets/folderview/folderview.cpp


remove trailing spaces



/trunk/KDE/kdebase/apps/plasma/applets/folderview/folderview.cpp


open curly brace on the previous line



/trunk/KDE/kdebase/apps/plasma/applets/folderview/folderview.cpp


here too


- Marco


On 2010-08-16 14:31:05, Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5049/
> ---
> 
> (Updated 2010-08-16 14:31:05)
> 
> 
> Review request for Plasma and Fredrik Höglund.
> 
> 
> Summary
> ---
> 
> Extend FolderView::configChanged() such that all configuration options are 
> read there on FolderView start. This will ensure that configuration changes 
> made "behind its back" (e.g. by the Desktop Scripting) will take effect.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/apps/plasma/applets/folderview/folderview.cpp 1164320 
> 
> Diff: http://reviewboard.kde.org/r/5049/diff
> 
> 
> Testing
> ---
> 
> Im looking for testers at the moment, but i know for a fact that after 
> applying the patch that kdebase compiles.Will report back when i can get hold 
> of testers and see if it actually works
> 
> 
> Thanks,
> 
> Rohan
> 
>

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

Re: Review Request: Game of Life Plasmoid -- Cleanup and reflection/density feature addition

[the . goofeedude]

> On 2010-08-15 07:56:46, Marco Martin wrote:
> > that'a a good feature.
> > would be possible separe in two commits, bugfix and feature? the bugfix one 
> > (and only that) should be backported to 4.5

I definitely can split this up into two commits. Should I include the variable 
renaming below (prepending m_ to member variables) in the bugfix submit? Or 
should I include them as part of the feature submit (or a new commit 
altogether?)

Also, I have applied for a kdesvn account, but currently have not heard back. I 
can upload an updated diff here for the feature, and an additional diff for the 
bugfix, but I'll need a kind reviewer to commit each after they pass review.

Thanks!


- obby


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


On 2010-08-14 22:51:07, obby wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5027/
> ---
> 
> (Updated 2010-08-14 22:51:07)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch fixes a bug wherein the very last cell in the board would never 
> come alive. Also, the configuration UI was updated so that using "tab" to 
> scroll through options would be consistent (top to bottom.)
> 
> The patch also adds to new features: game board reflection (the user can 
> choose to generate initial populations that are symmetrical about the 
> horizontal and/or vertical axes,) and user-configurable population density 
> (the user can choose what approximate percentage of cells will be alive in 
> the initial population.)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdeplasma-addons/applets/life/life.h 1163310 
>   /trunk/KDE/kdeplasma-addons/applets/life/life.cpp 1163310 
>   /trunk/KDE/kdeplasma-addons/applets/life/lifeConfig.ui 1163310 
> 
> Diff: http://reviewboard.kde.org/r/5027/diff
> 
> 
> Testing
> ---
> 
> Various game board sizes were tested (odd and even heights and widths, square 
> and non-square.) The configuration dialog was opened several times and tested 
> to confirm tab order.
> 
> Various population densities were tested, including 0% (confirmed no cells 
> were alive) and 100% (confirmed that all cells were alive.)
> 
> All combinations of vertical/horizontal/no reflection were tested at odd and 
> even heights and widths, square and non-square.
> 
> Tests consisted of setting the proper configuration options, then watching 
> the board for a few generations and confirming that no crashes occurred and 
> that all cells appeared to live and die properly. 
> 
> 
> Screenshots
> ---
> 
> Updated Configuration Dialog
>   http://reviewboard.kde.org/r/5027/s/481/
> Board Using Vertical and Horizontal Reflection
>   http://reviewboard.kde.org/r/5027/s/482/
> 
> 
> Thanks,
> 
> obby
> 
>

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

Re: Review Request: Game of Life Plasmoid -- Cleanup and reflection/density feature addition

[Marco Martin]

> On 2010-08-15 07:56:46, Marco Martin wrote:
> > that'a a good feature.
> > would be possible separe in two commits, bugfix and feature? the bugfix one 
> > (and only that) should be backported to 4.5
> 
> obby wrote:
> I definitely can split this up into two commits. Should I include the 
> variable renaming below (prepending m_ to member variables) in the bugfix 
> submit? Or should I include them as part of the feature submit (or a new 
> commit altogether?)
> 
> Also, I have applied for a kdesvn account, but currently have not heard 
> back. I can upload an updated diff here for the feature, and an additional 
> diff for the bugfix, but I'll need a kind reviewer to commit each after they 
> pass review.
> 
> Thanks!

yes, the variable renaming should be in the feature one.
I hope your account gets approved soon.
in the meantime i could do it if it would still not have been approved.


- Marco


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


On 2010-08-14 22:51:07, obby wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5027/
> ---
> 
> (Updated 2010-08-14 22:51:07)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch fixes a bug wherein the very last cell in the board would never 
> come alive. Also, the configuration UI was updated so that using "tab" to 
> scroll through options would be consistent (top to bottom.)
> 
> The patch also adds to new features: game board reflection (the user can 
> choose to generate initial populations that are symmetrical about the 
> horizontal and/or vertical axes,) and user-configurable population density 
> (the user can choose what approximate percentage of cells will be alive in 
> the initial population.)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdeplasma-addons/applets/life/life.h 1163310 
>   /trunk/KDE/kdeplasma-addons/applets/life/life.cpp 1163310 
>   /trunk/KDE/kdeplasma-addons/applets/life/lifeConfig.ui 1163310 
> 
> Diff: http://reviewboard.kde.org/r/5027/diff
> 
> 
> Testing
> ---
> 
> Various game board sizes were tested (odd and even heights and widths, square 
> and non-square.) The configuration dialog was opened several times and tested 
> to confirm tab order.
> 
> Various population densities were tested, including 0% (confirmed no cells 
> were alive) and 100% (confirmed that all cells were alive.)
> 
> All combinations of vertical/horizontal/no reflection were tested at odd and 
> even heights and widths, square and non-square.
> 
> Tests consisted of setting the proper configuration options, then watching 
> the board for a few generations and confirming that no crashes occurred and 
> that all cells appeared to live and die properly. 
> 
> 
> Screenshots
> ---
> 
> Updated Configuration Dialog
>   http://reviewboard.kde.org/r/5027/s/481/
> Board Using Vertical and Horizontal Reflection
>   http://reviewboard.kde.org/r/5027/s/482/
> 
> 
> Thanks,
> 
> obby
> 
>

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

Re: Review Request: Game of Life Plasmoid -- Cleanup and reflection/density feature addition

[the . goofeedude]

> On 2010-08-15 07:56:46, Marco Martin wrote:
> > that'a a good feature.
> > would be possible separe in two commits, bugfix and feature? the bugfix one 
> > (and only that) should be backported to 4.5
> 
> obby wrote:
> I definitely can split this up into two commits. Should I include the 
> variable renaming below (prepending m_ to member variables) in the bugfix 
> submit? Or should I include them as part of the feature submit (or a new 
> commit altogether?)
> 
> Also, I have applied for a kdesvn account, but currently have not heard 
> back. I can upload an updated diff here for the feature, and an additional 
> diff for the bugfix, but I'll need a kind reviewer to commit each after they 
> pass review.
> 
> Thanks!
> 
> Marco Martin wrote:
> yes, the variable renaming should be in the feature one.
> I hope your account gets approved soon.
> in the meantime i could do it if it would still not have been approved.

I've opened http://reviewboard.kde.org/r/5055/ for the bugfix. Once that is 
submitted, I'll have quite an easier time creating an updated diff for just the 
feature addition here. I'll update the description here after the bugfix is in 
as well.


- obby


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


On 2010-08-14 22:51:07, obby wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5027/
> ---
> 
> (Updated 2010-08-14 22:51:07)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch fixes a bug wherein the very last cell in the board would never 
> come alive. Also, the configuration UI was updated so that using "tab" to 
> scroll through options would be consistent (top to bottom.)
> 
> The patch also adds to new features: game board reflection (the user can 
> choose to generate initial populations that are symmetrical about the 
> horizontal and/or vertical axes,) and user-configurable population density 
> (the user can choose what approximate percentage of cells will be alive in 
> the initial population.)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdeplasma-addons/applets/life/life.h 1163310 
>   /trunk/KDE/kdeplasma-addons/applets/life/life.cpp 1163310 
>   /trunk/KDE/kdeplasma-addons/applets/life/lifeConfig.ui 1163310 
> 
> Diff: http://reviewboard.kde.org/r/5027/diff
> 
> 
> Testing
> ---
> 
> Various game board sizes were tested (odd and even heights and widths, square 
> and non-square.) The configuration dialog was opened several times and tested 
> to confirm tab order.
> 
> Various population densities were tested, including 0% (confirmed no cells 
> were alive) and 100% (confirmed that all cells were alive.)
> 
> All combinations of vertical/horizontal/no reflection were tested at odd and 
> even heights and widths, square and non-square.
> 
> Tests consisted of setting the proper configuration options, then watching 
> the board for a few generations and confirming that no crashes occurred and 
> that all cells appeared to live and die properly. 
> 
> 
> Screenshots
> ---
> 
> Updated Configuration Dialog
>   http://reviewboard.kde.org/r/5027/s/481/
> Board Using Vertical and Horizontal Reflection
>   http://reviewboard.kde.org/r/5027/s/482/
> 
> 
> Thanks,
> 
> obby
> 
>

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

Review Request: Game of Life Applet - fix to off-by-one in array traversal

[the . goofeedude]

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

Review request for Plasma and Marco Martin.


Summary
---

This patch fixes a off-by-one error which would lead to the last cell of the 
array never coming alive.

Also, parentheses were added to disambiguate some arithmetic expression and 
enforce operator precedence.


Diffs
-

  /trunk/KDE/kdeplasma-addons/applets/life/life.cpp 1163310 

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


Testing
---

Started applet, determined that the state of last cell in the array (bottommost 
rightmost cell) was calculated properly, and came alive when appropriate.


Thanks,

obby

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

Re: Review Request: Game of Life Applet - fix to off-by-one in array traversal

[Marco Martin]

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

Ship it!


go for it :)


/trunk/KDE/kdeplasma-addons/applets/life/life.cpp


watch the trailing spaces


- Marco


On 2010-08-16 18:18:18, obby wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5055/
> ---
> 
> (Updated 2010-08-16 18:18:18)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Summary
> ---
> 
> This patch fixes a off-by-one error which would lead to the last cell of the 
> array never coming alive.
> 
> Also, parentheses were added to disambiguate some arithmetic expression and 
> enforce operator precedence.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdeplasma-addons/applets/life/life.cpp 1163310 
> 
> Diff: http://reviewboard.kde.org/r/5055/diff
> 
> 
> Testing
> ---
> 
> Started applet, determined that the state of last cell in the array 
> (bottommost rightmost cell) was calculated properly, and came alive when 
> appropriate.
> 
> 
> Thanks,
> 
> obby
> 
>

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

Re: Review Request: Manual panel hiding [WIP]

[Will Stephenson]

> On 2010-05-04 03:49:54, Aaron Seigo wrote:
> > any updates on this?
> 
> Will Stephenson wrote:
> Ditto - our users are still asking for it - as they do on every release.
> 
> Aaron Seigo wrote:
> *gasp* all of them? ;)
> 
> more seriously, "our users" as a generic term is not a very interesting 
> metric, since in reality it could be 10 loud users out of 1000 or it could be 
> an actually significant %. :)
> 
> that said ... looks like this patch is abandoned. would be nice if 
> someone picked it up and finished it out.

It's the loud and unhelpful crew.


- Will


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


On 2010-03-04 19:19:53, Andrzej JR Hunt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3121/
> ---
> 
> (Updated 2010-03-04 19:19:53)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Manual panel hiding patch (still in progress). Currently only horizontal 
> panels are properly implemented, there is still a display bug whereby the 
> plasma toolbox (cashew) ignores the contentsMargins set on the containment 
> and thus gets covered by the hiding buttons.
> 
> 
> This addresses bug 158556.
> https://bugs.kde.org/show_bug.cgi?id=158556
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.h 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.cpp 
> 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.h 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.cpp 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/panel.cpp 
> 1097398 
> 
> Diff: http://reviewboard.kde.org/r/3121/diff
> 
> 
> Testing
> ---
> 
> Hiding the panels, changing states, changing positions and sizes.
> 
> 
> Thanks,
> 
> Andrzej JR
> 
>

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

Re: Krunner Coding Questions

[Sebastian Kügler]

On Monday 16 August 2010 12:13:10 David Baron wrote:
> I have a krunner coded with "run" actions.
> 
> 1. I add the actions. Their icons overwrite the "wrench" icon on the right.
> I actually prefer the icons rather than a the dropdown usually shown when
> clicking that icon. So I want to not have the "wrench" icon at all, just
> mine. How?
> 
> 2. The action I have in mind would open the configuration dialog normally
> opened for my runner in the dropdown list of all the runners. Since this is
> a separate "kcm-module," how do I load it and exercise it, getting the
> configuration changed signal to my runner (the parent)?
> 
> (I could simply locally create the UI with my own default/apply/cancel
> buttonbox and do this brute force. But why?)
> 
> 3. I do not want the krunner window to close when I click this action. I
> want to re-perform the match with any new options. How do I keep krunner
> "live" and accomplish this?
> 
> Any help or pointers to documentations would be greatly appreciated. Many
> thanks in advance.
> 
> (To try current version of recollrunner, get it from kde-apps.org.
> Recollindex runs nicely in the background and does not bog down my system
> as does the "default" kde indexer :-) )

Sounds like what you actually want to do is implement a completely different 
KRunner UI. In that case, a good start is the RunnerManager class.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [compiz] [RFC] Draft for a compositing manager specification

[Sam Spilsbury]

On Mon, Aug 16, 2010 at 8:37 AM, Samium Gromoff
<_deepf...@feelingofgreen.ru> wrote:
> Good day!
>
>> I want that in the end this becomes a new freedesktop.org specification to be
>> used in addition to the EWMH specification. As I am not sure if all 
>> composited
>> window managers are interested in such a specification I decided to discuss
>> this idea first with kwin, compiz (as they implement our proprietary hints)
>> and plasma, our most important stakeholder. The result of the discussion
>> should be proposed as a joint draft from both compiz and kwin to
>> freedesktop.org.
>
> Please, forgive me if I'm making a mistake, but otherwise, I strongly
> suspect that the Englightenment folks would be an important auditory to
> factor in.  What do you think?

Yes, that is a good idea. Can they be CC'd in?
>
> --
> regards,
>  Samium Gromoff
> --
> "Actually I made up the term 'object-oriented', and I can tell you I
> did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)
> ___
> compiz mailing list
> com...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>



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

Re: [compiz] [RFC] Draft for a compositing manager specification

[Sam Spilsbury]

On Tue, Aug 17, 2010 at 8:34 AM, Sam Spilsbury  wrote:
> On Mon, Aug 16, 2010 at 8:37 AM, Samium Gromoff
> <_deepf...@feelingofgreen.ru> wrote:
>> Good day!
>>
>>> I want that in the end this becomes a new freedesktop.org specification to 
>>> be
>>> used in addition to the EWMH specification. As I am not sure if all 
>>> composited
>>> window managers are interested in such a specification I decided to discuss
>>> this idea first with kwin, compiz (as they implement our proprietary hints)
>>> and plasma, our most important stakeholder. The result of the discussion
>>> should be proposed as a joint draft from both compiz and kwin to
>>> freedesktop.org.
>>
>> Please, forgive me if I'm making a mistake, but otherwise, I strongly
>> suspect that the Englightenment folks would be an important auditory to
>> factor in.  What do you think?
>
> Yes, that is a good idea. Can they be CC'd in?

The key enlightenment developer has been CC'd in.

>>
>> --
>> regards,
>>  Samium Gromoff
>> --
>> "Actually I made up the term 'object-oriented', and I can tell you I
>> did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)
>> ___
>> compiz mailing list
>> com...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/compiz
>>
>
>
>
> --
> Sam Spilsbury
>



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

Re: Krunner Coding Questions

[David Baron]

On Tuesday 17 August 2010 02:13:44 Sebastian Kügler wrote:
> On Monday 16 August 2010 12:13:10 David Baron wrote:
> > I have a krunner coded with "run" actions.
> > 
> > 1. I add the actions. Their icons overwrite the "wrench" icon on the
> > right. I actually prefer the icons rather than a the dropdown usually
> > shown when clicking that icon. So I want to not have the "wrench" icon
> > at all, just mine. How?

If I do not set the run options true, I only get my icons and they are 
active--i.e activities to trigger.

> > 
> > 2. The action I have in mind would open the configuration dialog normally
> > opened for my runner in the dropdown list of all the runners. Since this
> > is a separate "kcm-module," how do I load it and exercise it, getting
> > the configuration changed signal to my runner (the parent)?
> > 
> > (I could simply locally create the UI with my own default/apply/cancel
> > buttonbox and do this brute force. But why?)
> > 
> > 3. I do not want the krunner window to close when I click this action. I
> > want to re-perform the match with any new options. How do I keep krunner
> > "live" and accomplish this?
> > 
> > Any help or pointers to documentations would be greatly appreciated. Many
> > thanks in advance.
> > 
> > (To try current version of recollrunner, get it from kde-apps.org.
> > Recollindex runs nicely in the background and does not bog down my system
> > as does the "default" kde indexer :-) )
> 
> Sounds like what you actually want to do is implement a completely
> different KRunner UI. In that case, a good start is the RunnerManager
> class.

I found this. I need to know how to get to the instance that has access to the 
runners rather than just a "new" one I new. Similarly, I need get to the 
configuration UI for my runner. Then, if I change the config, I would 
launchQuery().

Not really such a radically different interface per se. In my runner, I am 
tweaking a search engine so want to be able to do this "live." Runners like 
recent docs and execs do not need this. Nepomukers and recollrunners might, 
and there may be more that might take this code once it works :-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel