D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Eike Hein]

hein added a comment.


  In D19822#439336 , @filipf wrote:
  
  > As for options overload, based on the reasoning above and the fact that 
we've recently split up the options and that we have space, I don't agree that 
this should be approached through the prism of UI clutter.
  
  
  "We had so many options we went from one page to two pages, so now we can add 
more options!" :-)

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

CI system maintainability

[Ben Cooksley]

Hi all,

We currently have a rather substantial issue, in that the CI system
has been once again left in a position where it isn't possible to make
any changes to the system.

This means we can't update to newer versions of packages, add new
packages or correct for binary incompatible changes which periodically
get introduced to non-Frameworks.

This issue has arisen because currently we have a recurring failure to
build from source, within KDE PIM. Specifically, KContacts fails due
to broken CMake logic. Despite this breakage having been in place for
several days now, and the relevant mailing list being informed
automatically by the CI system, the issue has not been corrected.

While the most immediate fix is to correct this failure to build from
source, that is only a short term fix and does not fix the underlying
issue which makes the CI system difficult to maintain - and that is
build failure reports being ignored, and people pushing broken code
that doesn't even build.

(For those wondering, the CI system uses OpenSUSE Tumbleweed, a
rolling release distribution, for it's builds, so it isn't a case of
old CMake or anything along those lines)

We therefore need a long term fix for this. Note that pre-commit (as
part of review) CI is not a solution in this instance, as the
offending commits did not go through review.

Does anyone have any ideas for a long term, proper fix to this?

At this point given the amount of effort required to maintain a CI
system vs. the amount of care actually being given by some developers
(who are ignoring it's failure emails) it becomes questionable whether
the effort is worth the return (and if not, we should just shut it
down)

Regards,
Ben Cooksley
KDE Sysadmin

D20086: Fix window height of Screen Locking KCM

[Tigran Gabrielyan]

tigrang created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
tigrang requested review of this revision.

REVISION SUMMARY
  An implicitHeight must be set on QML components to prevent window size being 
too small.
  
  BUG: 400355

TEST PLAN
  1. Open Screen Locking settings
  2. Go to Appearance tab
  3. Two rows of thumbnails with labels should be shown
  
  F6727233: screenlocker_kcm.png 

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D20086

AFFECTED FILES
  kcm/wallpaperconfig.qml

To: tigrang
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D20081: Add readme explaining how kwallet-pam works

[Aleix Pol Gonzalez]

apol added a comment.


  +1 for documenting and the text.
  
  Decorating with some URLs to pam documentation would be nice.

INLINE COMMENTS

> README.txt:3
> +
> +During the pam "auth" (pam_authenticate) stage the module gets the password 
> in plaintext
> +It hashes it against a random salt previously generated by kwallet of random 
> data and keeps it in memory

`plaintext`

> README.txt:9
> +
> +KWalletd recieves the pre-hashed key and then sits there doing nothing. 
> (before the QApp constructor)
> +

QApp -> QApplication

> README.txt:13
> +
> +Kwalletd receives this, sets the env and continues into the normal bootup.
> +

kwalletd

Also what's "the env"?

REPOSITORY
  R107 KWallet PAM Integration

REVISION DETAIL
  https://phabricator.kde.org/D20081

To: davidedmundson, #plasma
Cc: apol, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, mart

D20072: Fix Default Applications KCM window size

[Tigran Gabrielyan]

tigrang updated this revision to Diff 54963.
tigrang added a comment.


  Removed foreach and fixed coding style

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20072?vs=54898&id=54963

REVISION DETAIL
  https://phabricator.kde.org/D20072

AFFECTED FILES
  kcms/componentchooser/componentchooser.cpp
  kcms/componentchooser/componentchooser.h

To: tigrang, #plasma
Cc: ngraham, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Filip Fila]

filipf added a comment.


  Would something like this work?
  
  F6725968: AudioHover 
  
  We would need to port the PlasmaCore.IconItem to Kirigami.Icon to support the 
color property.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Filip Fila]

filipf added a comment.


  In D19822#439568 , @ngraham wrote:
  
  > In D19822#439567 , @faridb wrote:
  >
  > > In D19822#439396 , @ngraham 
wrote:
  > >
  > > > it would be nice if the "playing audio" icon itself changed to reflect 
the current status.
  > >
  > >
  > > The icon already shows the current status:
  > >  F6725945: Mute.gif 
  >
  >
  > Well... sort of. :) What I meant (and should have clearly stated the first 
time) was that it should use the `audio-volume-muted` icon when muted, rather 
than just becoming semi-transparent.
  
  
  Test plan looks like some other icon theme, this is what I get with Breeze:
  
  F6725957: image.png 

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Nathaniel Graham]

ngraham added a comment.


  In D19822#439567 , @faridb wrote:
  
  > In D19822#439396 , @ngraham 
wrote:
  >
  > > it would be nice if the "playing audio" icon itself changed to reflect 
the current status.
  >
  >
  > The icon already shows the current status:
  >  F6725945: Mute.gif 
  
  
  Well... sort of. :) What I meant (and should have clearly stated the first 
time) was that it should use the `audio-volume-muted` icon when muted, rather 
than just becoming semi-transparent.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Farid Boudedja]

faridb added a comment.


  In D19822#439195 , @rooty wrote:
  
  > I like this change I'd just prefer it if you could post screenshots in the 
test plan section?
  
  
  I added a screen recording to the test plan.
  
  In D19822#439396 , @ngraham wrote:
  
  > it would be nice if the "playing audio" icon itself changed to reflect the 
current status.
  
  
  The icon already shows the current status:
  F6725945: Mute.gif 

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D20073: [application-dashboard] Use appropriate search string

[Filip Fila]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:dd1840f0496f: [application-dashboard] Use appropriate 
search string (authored by filipf).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20073?vs=54904&id=54961

REVISION DETAIL
  https://phabricator.kde.org/D20073

AFFECTED FILES
  applets/kicker/package/contents/ui/DashboardRepresentation.qml

To: filipf, ngraham, #plasma, #vdg
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D20072: Fix Default Applications KCM window size

[Nathaniel Graham]

ngraham added a comment.


  Thanks, this works great. And kudos for navigating this very old and crusty 
code.

INLINE COMMENTS

> componentchooser.cpp:210
>  {
> - delete configWidget;
> + foreach (QWidget *configWidget, configWidgetMap)
> + delete configWidget;

No `foreach` in new code. See https://www.kdab.com/goodbye-q_foreach/

Also, follow KDE coding style and always use braces for loops and conditionals.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D20072

To: tigrang, #plasma
Cc: ngraham, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19994: Add microphone indicator

[Andres Betts]

abetts added a comment.


  +1

REPOSITORY
  R115 Plasma Audio Volume Applet

REVISION DETAIL
  https://phabricator.kde.org/D19994

To: broulik, #plasma, #vdg, drosca
Cc: abetts, filipf, apol, plasma-devel, jraleigh, GB_2, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, mart

D19994: Add microphone indicator

[Filip Fila]

filipf added a comment.


  Yeah you want to ignore virtual devices or I guess this audio effects for 
eaxmple app would trigger the indicator?
  
  F6725598: image.png 

REPOSITORY
  R115 Plasma Audio Volume Applet

REVISION DETAIL
  https://phabricator.kde.org/D19994

To: broulik, #plasma, #vdg, drosca
Cc: filipf, apol, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, mart

D19994: Add microphone indicator

[David Rosca]

drosca added a comment.


  Looks good.
  
  Personally I would work directly with the SourceOutputMap (and maybe 
duplicate it as list here in MicrophoneIndicator) instead of working with the 
models. I'm not saying that it's wrong / you should change it though, just a 
note.

INLINE COMMENTS

> microphoneindicator.cpp:42
> +: QObject(parent)
> +// what about "virtual streams"?
> +, m_sourceModel(new QPulseAudio::SourceModel(this))

Just ignore virtual streams? We only care about real devices here.

> microphoneindicator.cpp:198
> +return;
> +
> +}

newline

> microphoneindicator.cpp:202
> +// Otherwise unmute the devices we muted
> +for (auto &idx : m_mutedIndices) {
> +if (!idx.isValid()) {

qAsConst(m_mutedIndices)

> microphoneindicator.cpp:253
> +m_osd->showMicrophone(volumePercent(preferredSource));
> +
> +}

newline

> microphoneindicator.cpp:274
> +} else {
> +// this can never be empty, right? It's always at least the 
> process name
> +names.append(name);

Yes, this should never be empty.

> plugin.cpp:67
>  qmlRegisterSingletonType(uri, 0, 1, "PulseAudio", pulseaudio_singleton);
> +qmlRegisterSingletonType(uri, 0, 1, 
> "MicrophoneIndicator",
> +[](QQmlEngine *engine, QJSEngine *jsEngine) -> QObject* {

Any reason why you used singleton?

REPOSITORY
  R115 Plasma Audio Volume Applet

REVISION DETAIL
  https://phabricator.kde.org/D19994

To: broulik, #plasma, #vdg, drosca
Cc: apol, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, mart

D20081: Add readme explaining how kwallet-pam works

[David Edmundson]

davidedmundson created this revision.
davidedmundson added a reviewer: Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
davidedmundson requested review of this revision.

REVISION SUMMARY
  I wasted too long before starting some hacking, I want
  to make it easier for the next person

TEST PLAN
  N/A

REPOSITORY
  R107 KWallet PAM Integration

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D20081

AFFECTED FILES
  README.txt

To: davidedmundson, #plasma
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Nathaniel Graham]

ngraham added a comment.


  +1 for refining the visuals to make it clear when a click will activate the 
Task vs mute/unmute its audio streams. Also now that I think of it, it would be 
nice if the "playing audio" icon itself changed to reflect the current status.
  
  I'll stay out of the to-option-or-not-to-option debate for now. I just want 
this on by default, regardless of whether or not it has an option attached to 
it. :)

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Krešimir Čohar]

rooty added a comment.


  > The suggestion about the hover effect though is a nice one +1
  
  I wonder if we should make it turn gray when hovering over the option and 
stay gray while muted, or just turn gray and then once you move your cursor 
away it gets its color back regardless of whether muted or not.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Filip Fila]

filipf added a comment.


  I made the suggestion to have an option not because there might be something 
wrong with the feature, but because there is a subset of users who have a 
harder time finding their way around the UI - the non-tech say people and/or 
(now that I think of it) perhaps those with impaired vision who might not 
register the changed icon.
  
  We could work around not having an option by spawning a notification "Audio 
in %application has been muted. Click on the audio icon again to re-enable it". 
But then you'd probably want to have an option to remove the notification...
  
  As for options overload, based on the reasoning above and the fact that we've 
recently split up the options and that we have space, I don't agree that this 
should be approached through the prism of UI clutter.
  
  The Chrome example was more to show that users want this sort of a feature. 
Which is why I don't think:
  
  > No, if that bug report comes and comes repeatedly, we know it's a bad 
feature and drop it again.
  
  would be the right approach. Also, generalizing this position and applying it 
to some existing cases would probably be troublesome.
  
  The suggestion about the hover effect though is a nice one +1

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Krešimir Čohar]

rooty added a comment.


  > No, it's not.
  
  Yeah it is :D
  
  > Trivial options have a lot of cost attached to them: They make a UI noisier 
and more intimidating, and therefore less appealing. They also make it less 
effective by making it harder to find what you're looking for, as you have to 
scan through more options. They also introduce additional codepath and states, 
increasing the maintenance burden and complicating user support ("is your 
configuration X or Y?").
  
  And that's why :D Your argument hinges on the idea that something trivial 
makes the UI cluttered (and also imposes a maintenance burden). I think that's 
too broad/dogmatic and can be true but it really doesn't have to be the case. 
The task manager settings aren't really laden with settings so this would 
hardly be an imposition.
  
  Plasma's incredibly tweakable. I like to think that's one of the reasons 
people like it so much.
  But if you're gonna force the issue, I'd much rather keep the feature and 
remove the option to disable it.
  
  > Moreoever, adding options like this is almost always lazy and unloading a 
burden on the user instead of designing a UI that does the right thing and 
doesn't need the option.
  >  Options have to be earned.
  
  Lazy? No.
  A UI that wouldn't require you to pick an option might be a better choice.
  A UI that wouldn't require you to pick an option but would still allow you to 
do so might be the best choice.
  
  > My take is this:
  > 
  > - If the danger of users clicking the indicator accidentally and getting 
upset by it is high, this is a bad feature and shouldn't go in.
  
  Agreed.
  
  > - If the danger isn't actually that high, there's no need for an option.
  
  Agree to disagree.
  
  > A possible improvement to make here is to make the indicator visually react 
to hover by recoloring the icon, to teach that it's seperately interactive and 
will do something different than clicking elsewhere on the task button, so 
users get habituated not to click it accidentally. This should probably be done 
anyway (we're usally pretty triggerhappy on the hover feedback).
  
  This would be nice to have, I agree. This might also be a good thing to 
implement in Latte, @mvourlakos thoughts?
  
  > No, if that bug report comes and comes repeatedly, we know it's a bad 
feature and drop it again.
  
  While a potential consideration, it's not certain that the feature should be 
removed in case this happens. It would be silly for us to, say, stop shipping 
the notification widget just because there we get bug reports about glitchy 
placement, for example.
  
  > According to the linked discussion, Chrome is nuking the entire feature - 
it's not about the indicator being clickable. And they're doing it for 
unrelated reasons that are mostly strategic to the web platform and don't 
concern us here.
  
  They GNOME'd it. :D

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Eike Hein]

hein requested changes to this revision.
hein added a comment.
This revision now requires changes to proceed.


  > This is a specious argument.
  
  No, it's not. Trivial options have a lot of cost attached to them: They make 
a UI noisier and more intimidating, and therefore less appealing. They also 
make it less effective by making it harder to find what you're looking for, as 
you have to scan through more options. They also introduce additional codepath 
and states, increasing the maintenance burden and complicating user support 
("is your configuration X or Y?").
  
  Moreoever, adding options like this is almost always lazy and unloading a 
burden on the user instead of designing a UI that does the right thing and 
doesn't need the option.
  
  Options have to be earned.
  
  My take is this:
  
  - If the danger of users clicking the indicator accidentally and getting 
upset by it is high, this is a bad feature and shouldn't go in.
  - If the danger isn't actually that high, there's no need for an option.
  
  A possible improvement to make here is to make the indicator visually react 
to hover by recoloring the icon, to teach that it's seperately interactive and 
will do something different than clicking elsewhere on the task button, so 
users get habituated not to click it accidentally. This should probably be done 
anyway (we're usally pretty triggerhappy on the hover feedback).
  
  > As for the checkbox, I think it's only a matter of are we going to add it 
now or after someone opens up a bug report.
  
  No, if that bug report comes and comes repeatedly, we know it's a bad feature 
and drop it again.
  
  > Chrome BTW even totally nuked the flag: 
https://www.reddit.com/r/chrome/comments/9hi48g/the_ability_to_mute_a_tab_that_is_currently/e6clssr/
  
  According to the linked discussion, Chrome is nuking the entire feature - 
it's not about the indicator being clickable. And they're doing it for 
unrelated reasons that are mostly strategic to the web platform and don't 
concern us here.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf, hein
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Filip Fila]

filipf added a comment.


  In D19822#439167 , @hein wrote:
  
  > I'm not a fan of the checkbox, I think it's a little gratuitous. If you add 
a small feature and need to immediately add a checkbox to disable it, it's 
rather a red flag to me. It means either the feature or the checkbox should 
probably go. Firefox gets away without the option BTW.
  
  
  I don't see a correlation between the quality of a feature and having a 
checkbox in this case. The feature is useful. As for the checkbox, I think it's 
only a matter of are we going to add it now or after someone opens up a bug 
report.
  
  Chrome BTW even totally nuked the flag: 
https://www.reddit.com/r/chrome/comments/9hi48g/the_ability_to_mute_a_tab_that_is_currently/e6clssr/
  
  But we can do better than Firefox and Chrome.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  taskmanager-mute (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19822: [Task Manager] Toggle mute when the audio indicator is clicked

[Krešimir Čohar]

rooty added a comment.


  In D19822#439167 , @hein wrote:
  
  > I'm not a fan of the checkbox, I think it's a little gratuitous. If you add 
a small feature and need to immediately add a checkbox to disable it, it's 
rather a red flag to me. It means either the feature or the checkbox should 
probably go.
  
  
  This is a specious argument. It's like the single click vs double click 
debate. Either the single clicking goes or the option to disable it does - 
neither a particularly delightful option. Keep both and you get to avoid this 
pitfall.
  
  In essence, I believe that whether or not you can disable this feature should 
have no bearing on whether it should be included. And as far as dropping the 
option to disable it goes, why? It just detracts from more versatility.
  
  I like this change I'd just prefer it if you could post screenshots in the 
test plan section?

REPOSITORY
  R119 Plasma Desktop

BRANCH
  taskmanager-mute (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D19822

To: faridb, #plasma, #vdg, ngraham, filipf
Cc: rooty, hein, filipf, mvourlakos, ngraham, broulik, plasma-devel, jraleigh, 
GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart