Hi,
I have been going through notify-osd code lately and discussed it with
Mirco a bit. It seems we can provide a Qt implementation for notify-osd
while trying to keep as much code in common as possible. To do so we
need to split notify-osd in two layers: Core and UI. The actual
implementation of
David Barth wrote:
> There are parts of the existing "API" (rather the exposed GObject
> interface) that are there for wrong reasons, like "need to stabilize and
> release soon, so no time for fancy refactoring", though we still did
> some of that up to late in the development cycle.
>
> What I t
David Barth wrote:
> fade_in/out and show/hide should be reconsidered. The Plasma API should
> help make that more generic.
Depending on how we want to unify notification handling, we may or may
not need to use the Plasma API:
# Solution 1
- We modify notify-osd to handle both Galago and KDE d
Scott Kitterman wrote:
>> David Barth wrote:
>>
>>> fade_in/out and show/hide should be reconsidered. The Plasma API should
>>> help make that more generic.
>> Depending on how we want to unify notification handling, we may or may
>> not need to use the Plasma API:
>
> I thought the goal was about
Aurélien Gâteau wrote:
> Solution 2 makes GNOME notifications use Plasma notification system.
Oups, sorry. It makes GNOME applications use Plasma notifications on KDE
and KDE applications use notify-osd on GNOME.
___
Mailing list: https://launchpad.
Roderick B. Greening wrote:
> Not sure how best to phrase this... however, here goes.
>
> If we develop a specification and present to f.d.o, which would allow all
> DE's
> to integrate this spec via a low level API, which would send D-BUS
> notifications and allow any "listener" to pick them u
Anthony McTaggart wrote:
> since KDE is pushing their notifications system...
I think there is some confusion here: what KDE is pushing right now is a
specification for what is often called a systray: an area in the desktop
where applications can show icons. These icons can respond to click
events
Celeste Lyn Paul wrote:
> 1) are features such as display position and display timeout part of the
> notification spec, and are they handled by the notification daemon or display?
> 2) are display decisions, such as whether to show a notification or not (e.g.
> in presentation mode), handled by
David Barth wrote:
> I'm also very interested in Celeste's suggestion of having a monitor,
> similar to what kwin does, to delay the display of notifications.
>
> Aurélien: could you take a look at this last one?
kdelibs provides an API to interact with the window manager. This makes
it easy to l
Celeste Lyn Paul wrote:
> On Tuesday 02 June 2009 10:28:04 am Aurélien Gâteau wrote:
>> David Barth wrote:
>>> I'm also very interested in Celeste's suggestion of having a monitor,
>>> similar to what kwin does, to delay the display of notifications.
>>&g
Hi list,
I am working on bug 372789 "NotifyOSD notifications shouldn't appear
when using fullscreen applications".
https://bugs.launchpad.net/bugs/372789
I created a patch which detects fullscreen windows and disables
notifications in this case, but it does not take the multiple monitors
case int
David Siegel wrote:
> Personally, I would want notifications more often than not when
> fullscreen-ed in games, while browsing in Firefox, while watching any
> movie shorter than an hour in length, while programming in an IDE like
> MonoDevelop, while working in OpenOffice writer on my netbook, wh
Alex Launi wrote:
> David Siegel also had a really great idea for making updates fun (and it
> also solves the issue of how to handle updates- notification icon or
> pop-under window) at the "install updates on shutdown" discussion. Let me
> preface this with these are his ideas and not mine, I thi
13 matches
Mail list logo
