---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/686/
---
(Updated 2009-05-11 03:47:16.790293)
Review request for Plasma.
Changes
On 2009-05-10 13:18:35, Aaron Seigo wrote:
hm.. how about a close symbol in the group header, which would then close
the whole group, just as closing one item closes a single item?
done, looks nice indeed.
but i wonder if it wouldn't cause some accidental clear when the user wants
just
On 2009-05-10 13:18:35, Aaron Seigo wrote:
hm.. how about a close symbol in the group header, which would then close
the whole group, just as closing one item closes a single item?
Marco Martin wrote:
done, looks nice indeed.
but i wonder if it wouldn't cause some accidental
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/686/
---
Review request for Plasma.
Summary
---
the links for more/less info and
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/686/#review1102
---
hm.. how about a close symbol in the group header, which would then
Hello
This time I would like to share some of my ideas regarding these infamous
progress notifications that were moved to systray starting from KDE 4.2.
I don't know how it currently look in trunk so maybe they were already
implemented or at least proposed.
First idea is about making autohide
On Sun, Apr 5, 2009 at 12:40 PM, Emdek emd...@gmail.com wrote:
Hello
This time I would like to share some of my ideas regarding these infamous
progress notifications that were moved to systray starting from KDE 4.2.
I don't know how it currently look in trunk so maybe they were already
On Sunday 05-04-2009 13:02:59 Marco Martin wrote:
now the progress windows are collapsed in only one (with the average)
that can be expanded, don't remember if the collapsed progress window
is autohidden or not.
Yes, I've read about collapsing also, but I'm not sure if everyone wants to
group
On Sonntag 30 November 2008 23:31:13 Rob Scheepmaker wrote:
How come that kopete suddenly decided to spam your screen full of
notifications? That sounds more like the real problem here...
That is the standard setting, and I was somehow used to being spamed by new
mesages spawning
On Samstag 29 November 2008 15:15:58 Rob Scheepmaker wrote:
Well, with more notifications then space available stuff will obviously be
suboptimal. The question is how often this situation arises. I'm using
these notifications in the systray for some time now, and the amount of
simultaneous
Hi,
First I know that the systray notifications are very new.
Second I have some problems with them ;) [1]:
*When logging in some messages telling me that the Ktorrent logs are copied
somewhere pop up -- annoying
*When clicking an image in a folderview I get _two_ notifications
On Saturday 29 November 2008 13:55:15 Matthias Fuchs wrote:
Hi,
First I know that the systray notifications are very new.
Second I have some problems with them ;) [1]:
*When logging in some messages telling me that the Ktorrent logs are copied
somewhere pop up -- annoying
*When clicking
On Saturday 29 November 2008 15:36:59 Anne-Marie Mahfouf wrote:
On Saturday 29 November 2008 15:15:58 Rob Scheepmaker wrote:
On Saturday 29 November 2008 13:55:15 Matthias Fuchs wrote:
Hi,
First I know that the systray notifications are very new.
Second I have some problems
Rob Scheepmaker wrote:
Agreed, Ideally those should be hidden. Something I could do is only let
notifications appear after a job has been running for a couple of seconds
so all those very short jobs won't bother you,
As far as I know this is exactly what happens with the old dialogs.
On Saturday 29 November 2008 16:41:25 Andras Mantia wrote:
There is a way to know if the progress info should be visible or not, and
namely the JobFlags argument for the kio methods. See the API docs (like
http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/namespaceKIO.html#09f67
--- On Sat, 11/29/08, Andras Mantia [EMAIL PROTECTED] wrote:
From: Andras Mantia [EMAIL PROTECTED]
Subject: Re: Systray Notifications
To: plasma-devel@kde.org
Date: Saturday, November 29, 2008, 7:41 AM
Rob Scheepmaker wrote:
There is a way to know if the progress info should be
visible
of notifications shown at the same time? It
could show, for example, the latest 3 (or whatever max number) unexpired
notifications and all unexpired notifications could be available upon click of
the systray notifications icon. This max number *could* be configurable
(hidden for 4.2, UI for 4.3
tell. :)
Regards,
Rob
How about having a max number of notifications shown at the same time? It
could show, for example, the latest 3 (or whatever max number) unexpired
notifications and all unexpired notifications could be available upon click
of the systray notifications icon. This max
On Wednesday 22 October 2008 19:26:22 Sebastian Kügler wrote:
Only the ones that open popups automatically. The power management control
extender from the battery and the calendar should have focus. (But I think
it's fine to make that explicit in the applet itself.)
Ok, so we need some function
2008/10/22 Dmitry Suzdalev [EMAIL PROTECTED]:
Hello!
I just found a real problem with new notifications system. Let me describe
it.
New notifications are shown using a PopupApplet which is a full-blown window
from the KWin POV. So what happens is the following:
dimsuz is touch-typing with
Hello!
I just found a real problem with new notifications system. Let me describe it.
New notifications are shown using a PopupApplet which is a full-blown window
from the
KWin POV. So what happens is the following:
dimsuz is touch-typing with amazing speed in his kmail window. at the same
On Wednesday 22 October 2008 15:27:18 Dmitry Suzdalev wrote:
Hello!
I just found a real problem with new notifications system. Let me describe
it. New notifications are shown using a PopupApplet which is a full-blown
window from the KWin POV. So what happens is the following:
dimsuz is
On Wednesday 22 October 2008, Dmitry Suzdalev wrote:
So I'm thinking what's the best way to do this? A parameter to popup()
function? A new function PopupApplet::setPopupAsTooltip(bool)? something
setPopupWindowFlags(Qt::WindowFlags)?
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint:
On Wednesday 22 October 2008 18:54:28 Rob Scheepmaker wrote:
Popup Dialogs used to be Qt::Tooltip, only that doesn't function correctly
when you want to be able to drag widgets away from the window, as is
possible with extender items. But I agree we should avoid the dialog
stealing focus. I
On Wednesday 22 October 2008 16:54:28 Rob Scheepmaker wrote:
So I'm thinking what's the best way to do this? A parameter to popup()
function? A new function PopupApplet::setPopupAsTooltip(bool)? something
else?
I think the don't steal focus behavior should be default for all
popupapplets.
On Wednesday 22 October 2008 19:13:01 Aaron J. Seigo wrote:
On Wednesday 22 October 2008, Rob Scheepmaker wrote:
So I'm thinking what's the best way to do this? A parameter to popup()
function? A new function PopupApplet::setPopupAsTooltip(bool)?
something else?
I think the don't
On Wednesday 22 October 2008, Rob Scheepmaker wrote:
Popup Dialogs used to be Qt::Tooltip, only that doesn't function correctly
when you want to be able to drag widgets away from the window, as is
possible with extender items.
what problems does this cause, exactly?
--
Aaron J. Seigo
humru
On Wednesday 22 October 2008 18:36:57 Aaron J. Seigo wrote:
On Wednesday 22 October 2008, Rob Scheepmaker wrote:
Popup Dialogs used to be Qt::Tooltip, only that doesn't function
correctly when you want to be able to drag widgets away from the window,
as is possible with extender items.
28 matches
Mail list logo
