Re: [Ayatana] White text in lenses doesn't work well with light background images.

2011-08-31 Thread Mirco Müller

Am 31.08.2011 08:52, schrieb Thorsten Wilms:

On 08/31/2011 02:25 AM, Conscious User wrote:


1 - use an outline
2 - use the opposite of the background in a chosen color space


3 - switch to black text for any background that exceeds some 
brightness level on most of its surface.


4 - forget about the transparency. Set static back- and foreground 
colors. Have a heart for everyone with less than perfect vision.



It should be mentioned that GNOME always had this problem with the label
of desktop icons...


Indeed, if I squint my eyes just a bit, what I see resembles a badly 
rendered dark gray text. That is, what I can see is the shadow 
duplicate of the text, while the white original only serves to shoot 
holes through it.


This is why I propose to switch the main text color, if you don't 
restrict the background more tightly.


If we use the same approach currently implemented in notify-osd, we 
don't need to make any of the text in the dash adapt to the background, 
restrict anything or add even more logic in code. notify-osd does all 
its text-rendering with a centered and slightly blurred drop-shadow 
(white text against black drop-shadow).


This makes sure there's always enough contrast for the text no 
matter what kind of background is used. See the attached sample for the 
technique implemented in notify-osd.


I also added this suggestion to LP: #824916

Best regards...

Mirco
attachment: text-rendering-suggestion.png___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


[Ayatana-commits] [Merge] lp:~sense/notify-osd/fix-465801 into lp:notify-osd/trunk

2011-02-13 Thread Mirco Müller
The proposal to merge lp:~sense/notify-osd/fix-465801 into lp:notify-osd/trunk 
has been updated.

Status: Approved = Merged

For more details, see:
https://code.launchpad.net/~sense/notify-osd/fix-465801/+merge/14265
-- 
https://code.launchpad.net/~sense/notify-osd/fix-465801/+merge/14265
Your team ayatana-commits is subscribed to branch lp:notify-osd/trunk.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana-commits] [Merge] lp:~cjcurran/indicator-sound/metadata-tidyup into lp:indicator-sound

2010-06-28 Thread Mirco Müller
Review: Approve
Looks good to me. Approved.
-- 
https://code.launchpad.net/~cjcurran/indicator-sound/metadata-tidyup/+merge/28627
Your team ayatana-commits is subscribed to branch lp:indicator-sound.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] GSoC '10 Idea : NotifyOSD improvements

2010-05-17 Thread Mirco Müller
Am Montag, den 15.03.2010, 21:45 +0530 schrieb Akshay Gupta:

 I posted a GSoC project Idea on the ubuntu-soc list yesterday and I
 thought it'd be more appropriate if I run it down by developers in the
 Ayatana list.
 https://lists.ubuntu.com/archives/ubuntu-soc/2010-March/47.html
 
 
 Some of the things that this project could help solve :
 
 
 1.) Make the OSD customizable 
  * setting up persistence time

I'd rather finish the time-out specs, than work around it like this.

  * UI modifications over a basic structure

Not sure what you mean by this?

  * Font size/style

You can change the font-size/-style already. notify-osd picks up the
font from your system-wide settings.

  ...other similar stuff we can decide upon.
 2.) Most of the above things would be customized by an OSD Manager
 that could handle all those by a native GTK+ application.

I would not suggest that. Great care has been taken to avoid the need
for a preferences UI for notifications. Completing the implementation
would be of greater benefit, than taking this shortcut of a
settings-UI. With these kind of UIs we get into the realm of
undiscoverability again. We try to move away from this, not towards
it.

 3.) Implementing unresolved work in the Design Specs. 

I could help with that, e.g. the growing timer needed for getting all
the time-outs stated in the spec could be used finally. I've implemented
it already, but it still needs to be hooked up.

Furthermore the expanding bubble for the append-case could be
revisited. The needed animation-framework is in place. Numerous (unit-)
test-programs of notify-osd trunk already demonstrate these features.

There are some low-hanging fruits within the scope of fulfilling the
spec.

 1.) Stacking, that'd make the bubbles dock downwards as they are
 initiated and start to stack up as the bubble times finish away.

 2.) A close button on the corner of the bubble as soon as a mouseover
 occurs (like Growl, instead of disappearing away)

These two above mentioned items I'd rather see implemented in a fork
than in notify-osd trunk itself.

The reasons for notify-osd not exposing these kind of behaviours have
been discussed to great lengths in the past on this list. I don't want
to see this discussion reignite again.

Best regards ...

Mirco



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana-commits] [Merge] lp:~lifeless/notify-osd/tests into lp:notify-osd

2009-11-24 Thread Mirco Müller
 On Tue, 2009-11-24 at 11:08 +, Mirco Müller wrote:
 
  Review: Disapprove
 
 Meta: why? what part of this is so bad that you don't want it fix, but
 just want it to go away (thats what disapprove means). The actual body
 of your review reads more like 'I may have to merge this carefully and
 please explain about Xvfb' which is not really disapproval.

Oh, that should have been Needs Information.

  Not so fast folks... notify-osd trunk is behind notify-osd/karmic at
  the moment.
 
 This makes it very hard to figure out where to do work. I presume there
 is a good reason for this. Can we figure out how to avoid that in
 future?

Isn't this the normal procedure? Do feature work in trunk during Alpha-period. 
Once Beta-period starts branch off for bug-fix-only to mature the code-base. 
After final release merge fixes back to trunk.

That merge back has not happened yet, because jumping on Lucid for helping to 
work on unity became highest/only priority.

Even now I don't have explicit green light for the merge-back yet. But this 
is meant to come during the week, once I've send David my fixes-list for the 
notify-osd Karmic-SRU.

 It also implies that the karmic changes didn't get code reviewed, if
 reviews are happening only on trunk.

No. From the branch off for Karmic code-reviews happened on the karmic-branch 
of notify-osd. So far nobody complained about the way we go about our 
code-review targets. Well, I also did TDD on notify-osd as good as I could, 
once it was demanded, which was - according to your remarks from the 
Montreal-sprint - not reasonable to do as an afterthought.

It looks like there are still differences in the applied best practices. I'm 
eager to learn about a better approach, but so far didn't feel I was doing 
something wrong.

  What's test-support.am doing exactly? In particular how does Xvfb work
  and what are all those XIDs good for?
 
 Its just machinery to get an X server up and running without linear
 probing for available server slots.

Is that something I can easily test locally on my box here? If so I'd like to 
know how in order to replicate this, just for getting a better understanding 
what's going on there on the testing-systems.
-- 
https://code.edge.launchpad.net/~lifeless/notify-osd/tests/+merge/15182
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana-commits] [Merge] lp:~jassmith/notify-osd/exponential-blur into lp:notify-osd

2009-11-24 Thread Mirco Müller
Review: Approve 
The fix is good and I'll plan to make it part of the notify-osd SRU for Karmic 
and also move it into trunk.
-- 
https://code.edge.launchpad.net/~jassmith/notify-osd/exponential-blur/+merge/14456
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


[Ayatana-commits] [Merge] lp:~jassmith/notify-osd/exponential-blur into lp:notify-osd updated

2009-11-24 Thread Mirco Müller
The proposal to merge lp:~jassmith/notify-osd/exponential-blur into 
lp:notify-osd has been updated.

Status: Needs review = Approved
-- 
https://code.edge.launchpad.net/~jassmith/notify-osd/exponential-blur/+merge/14456
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana-commits] [Merge] lp:~qense/notify-osd/fix-465801 into lp:notify-osd

2009-11-24 Thread Mirco Müller
Review: Approve 
BTW, thanks for the fix. I'll add that to notify-osd SRU for Karmic (and hope 
it'll get accepted by the desktop-team).
-- 
https://code.edge.launchpad.net/~qense/notify-osd/fix-465801/+merge/14265
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana-commits] [Merge] lp:~qense/notify-osd/fix-465801 into lp:notify-osd

2009-11-18 Thread Mirco Müller
I'll test-run and merge that with other notify-osd related work once I'm back 
home from UDS next week.
-- 
https://code.edge.launchpad.net/~qense/notify-osd/fix-465801/+merge/14265
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


[Ayatana-commits] [Merge] lp:~asac/notify-osd/theme-icon-prefix into lp:notify-osd updated

2009-10-19 Thread Mirco Müller
The proposal to merge lp:~asac/notify-osd/theme-icon-prefix into lp:notify-osd 
has been updated.

Status: Needs review = Merged
-- 
https://code.edge.launchpad.net/~asac/notify-osd/theme-icon-prefix/+merge/12731
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana-commits] [Merge] lp:~asac/notify-osd/theme-icon-prefix into lp:notify-osd

2009-10-19 Thread Mirco Müller
Actually merged in the form of my adaptation of asac's branch here to the 
Karmic maintainance branch. Also see lp:~macslow/notify-osd/theme-icon-prefix.
-- 
https://code.edge.launchpad.net/~asac/notify-osd/theme-icon-prefix/+merge/12731
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana-commits] [Merge] lp:~asac/notify-osd/theme-icon-prefix into lp:notify-osd

2009-10-01 Thread Mirco Müller
Review: Needs Information
Did you run make check against notify-osd trunk with your patch? Did you also 
run all the examples from notify-osd/examples/*py and the test-script 
notify-osd/src/send-test-notification.sh? Do all those work and don't cause a 
crash?
-- 
https://code.edge.launchpad.net/~asac/notify-osd/theme-icon-prefix/+merge/12731
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


[Ayatana-commits] [Merge] lp:~macslow/notify-osd/fix-427924 into lp:notify-osd

2009-09-23 Thread Mirco Müller
Mirco Müller has proposed merging lp:~macslow/notify-osd/fix-427924 into 
lp:notify-osd.

Requested reviews:
Notify OSD Developers (notify-osd-developers)

After lots of work this seems to fix LP: #427924 for good. Major difference to 
trunk is bubble-disposal happens in a GWeakNotify callback now and 
stack_purge_old_bubbles() has been decommissioned.
-- 
https://code.launchpad.net/~macslow/notify-osd/fix-427924/+merge/12281
Your team ayatana-commits is subscribed to branch lp:notify-osd.
=== modified file 'src/display.c'
--- src/display.c	2009-09-10 13:11:32 +
+++ src/display.c	2009-09-23 13:14:20 +
@@ -286,8 +286,6 @@
 
 	g_return_if_fail (self != NULL);
 
-	stack_purge_old_bubbles (self);
-
 	bubble = stack_select_next_to_display (self);
 	if (bubble == NULL)
 		/* this actually happens when we're called for a synchronous

=== modified file 'src/stack.c'
--- src/stack.c	2009-09-10 13:11:32 +
+++ src/stack.c	2009-09-23 13:14:20 +
@@ -245,34 +245,13 @@
 	return (Bubble*) entry-data;
 }
 
-
 static void
-stack_purge_old_bubbles (Stack* self)
+_weak_notify_cb (gpointer data,
+		 GObject* former_object)
 {
-	Bubble* bubble = NULL;
-	GList*list = NULL;
-
-	g_return_if_fail (self != NULL);
-
-	for (list = g_list_first (self-list);
-	 list != NULL;)
-	{
-		bubble = (Bubble*) list-data;
-		
-		if (! IS_BUBBLE (bubble))
-		{
-			self-list = g_list_delete_link (self-list, list);
-			list = self-list;
-		} else if (! bubble_is_visible (bubble) 
-			   (bubble_get_timeout (bubble) == 0))
-		{
-			self-list = g_list_delete_link (self-list, list);
-			list = self-list;
-			g_object_unref (bubble);
-		} else {
-			list = g_list_next (list);
-		}
-	}
+	Stack* stack = STACK (data);
+
+	stack-list = g_list_remove (stack-list, former_object);
 }
 
 static void
@@ -618,6 +597,10 @@
 		gchar *sender;
 		new_bubble = TRUE;
 		bubble = bubble_new (self-defaults);
+		g_object_weak_ref (G_OBJECT (bubble),
+   _weak_notify_cb,
+   (gpointer) self);
+		
 		sender = dbus_g_method_get_sender (context);
 		bubble_set_sender (bubble, sender);
 		g_free (sender);
@@ -627,7 +610,12 @@
 	{
 		data   = (GValue*) g_hash_table_lookup (hints, x-canonical-append);
 		compat = (GValue*) g_hash_table_lookup (hints, append);
-		if (G_VALUE_HOLDS_STRING (data) || G_VALUE_HOLDS_STRING (compat))
+		g_print (--- %s(): data = %p, compat = %p ---\n,
+			 G_STRFUNC,
+			 data,
+			 compat);
+		if ((data  G_VALUE_HOLDS_STRING (data)) ||
+		(compat  G_VALUE_HOLDS_STRING (compat)))
 			bubble_set_append (bubble, TRUE);
 		else
 			bubble_set_append (bubble, FALSE);
@@ -656,7 +644,7 @@
 	{
 		data   = (GValue*) g_hash_table_lookup (hints, x-canonical-private-synchronous);
 		compat = (GValue*) g_hash_table_lookup (hints, synchronous);
-		if (G_VALUE_HOLDS_STRING (data) || G_VALUE_HOLDS_STRING (compat))
+		if ((data  G_VALUE_HOLDS_STRING (data)) || (compat  G_VALUE_HOLDS_STRING (compat)))
 		{
 			if (sync_bubble != NULL
 			 IS_BUBBLE (sync_bubble))
@@ -665,10 +653,10 @@
 bubble = sync_bubble;
 			}
 
-			if (G_VALUE_HOLDS_STRING (data))
+			if (data  G_VALUE_HOLDS_STRING (data))
 bubble_set_synchronous (bubble, g_value_get_string (data));
 
-			if (G_VALUE_HOLDS_STRING (compat))
+			if (compat  G_VALUE_HOLDS_STRING (compat))
 bubble_set_synchronous (bubble, g_value_get_string (compat));
 		}
 	}
@@ -676,14 +664,14 @@
 	if (hints)
 	{
 		data = (GValue*) g_hash_table_lookup (hints, value);
-		if (G_VALUE_HOLDS_INT (data))
+		if (data  G_VALUE_HOLDS_INT (data))
 			bubble_set_value (bubble, g_value_get_int (data));
 	}
 
 	if (hints)
 	{
 		data = (GValue*) g_hash_table_lookup (hints, urgency);
-		if (G_VALUE_HOLDS_UCHAR (data))
+		if (data  G_VALUE_HOLDS_UCHAR (data))
 			bubble_set_urgency (bubble,
 	   g_value_get_uchar (data));
 		/* Note: urgency was defined as an enum: LOW, NORMAL, CRITICAL
@@ -695,7 +683,7 @@
 	{
 		data   = (GValue*) g_hash_table_lookup (hints, x-canonical-private-icon-only);
 		compat = (GValue*) g_hash_table_lookup (hints, icon-only);
-		if (G_VALUE_HOLDS_STRING (data) || G_VALUE_HOLDS_STRING (compat))
+		if ((data  G_VALUE_HOLDS_STRING (data)) || (compat  G_VALUE_HOLDS_STRING (compat)))
 			bubble_set_icon_only (bubble, TRUE);
 		else
 			bubble_set_icon_only (bubble, FALSE);
@@ -764,7 +752,8 @@
 		stack_layout (self);
 	}
 
-	dbus_g_method_return (context, bubble_get_id (bubble));
+	if (bubble)
+		dbus_g_method_return (context, bubble_get_id (bubble));
 
 	return TRUE;
 }
@@ -774,20 +763,20 @@
   guintid,
   GError** error)
 {
-	Bubble *bubble = find_bubble_by_id (self, id);
-
-	/* exit but pretend it's ok, for applications
-	   that call us after an action button was clicked */
-	if (bubble == NULL)
-		return TRUE;
-
-	dbus_send_close_signal (bubble_get_sender (bubble),
-bubble_get_id (bubble),
-3);
-	bubble_hide (bubble);
-	g_object_unref (bubble);
-
-	stack_layout (self);
+	//Bubble *bubble = find_bubble_by_id (self, id);
+
+	// exit but pretend

Re: [Ayatana-commits] [Merge] lp:~macslow/notify-osd/fix-427924 into lp:notify-osd

2009-09-23 Thread Mirco Müller
 Hmmm. That's a fair point, but it's a change that we don't advertise at
 the protocol level. There are occasions where that happens and we
 haven't audited all apps that do it for good reasons. I recommend to
 keep it as is for this release. And next time, return an error to
 indicate more clearly that the call failed, because we're not supporting
 the call anymore.

Pushed a compromise as rev 401. stack_close_notification_handler() acts upon 
invocation again, but leaves the notification-queue in Stack untouched. I also 
added a warning when we get an id == 0 from DBus.
-- 
https://code.edge.launchpad.net/~macslow/notify-osd/fix-427924/+merge/12281
Your team ayatana-commits is subscribed to branch lp:notify-osd.

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


[Ayatana-commits] [Merge] lp:~macslow/notify-osd/forced-shutdown into lp:notify-osd

2009-09-23 Thread Mirco Müller
Mirco Müller has proposed merging lp:~macslow/notify-osd/forced-shutdown into 
lp:notify-osd.

Requested reviews:
Notify OSD Developers (notify-osd-developers)

I added a forced shutdown of notify-osd to work around building up mem-leaks 
outside of notify-osd's control. At a currently set threshold of 500 
notifications passed to notify-osd over time (not necessarily displayed yet) it 
exits, thus implicitly freeing any left allocated system-memory.
-- 
https://code.launchpad.net/~macslow/notify-osd/forced-shutdown/+merge/12296
Your team ayatana-commits is subscribed to branch lp:notify-osd.
=== modified file 'src/stack.c'
--- src/stack.c	2009-09-10 13:11:32 +
+++ src/stack.c	2009-09-23 16:44:26 +
@@ -43,6 +43,8 @@
 
 G_DEFINE_TYPE (Stack, stack, G_TYPE_OBJECT);
 
+#define FORCED_SHUTDOWN_THRESHOLD 500
+
 /* fwd declaration */
 void close_handler (GObject* n, Stack*  stack);
 
@@ -627,7 +629,7 @@
 	{
 		data   = (GValue*) g_hash_table_lookup (hints, x-canonical-append);
 		compat = (GValue*) g_hash_table_lookup (hints, append);
-		if (G_VALUE_HOLDS_STRING (data) || G_VALUE_HOLDS_STRING (compat))
+		if ((data  G_VALUE_HOLDS_STRING (data)) || (compat  G_VALUE_HOLDS_STRING (compat)))
 			bubble_set_append (bubble, TRUE);
 		else
 			bubble_set_append (bubble, FALSE);
@@ -656,7 +658,7 @@
 	{
 		data   = (GValue*) g_hash_table_lookup (hints, x-canonical-private-synchronous);
 		compat = (GValue*) g_hash_table_lookup (hints, synchronous);
-		if (G_VALUE_HOLDS_STRING (data) || G_VALUE_HOLDS_STRING (compat))
+		if ((data  G_VALUE_HOLDS_STRING (data)) || (compat  G_VALUE_HOLDS_STRING (compat)))
 		{
 			if (sync_bubble != NULL
 			 IS_BUBBLE (sync_bubble))
@@ -665,10 +667,10 @@
 bubble = sync_bubble;
 			}
 
-			if (G_VALUE_HOLDS_STRING (data))
+			if ((data  G_VALUE_HOLDS_STRING (data)))
 bubble_set_synchronous (bubble, g_value_get_string (data));
 
-			if (G_VALUE_HOLDS_STRING (compat))
+			if ((compat  G_VALUE_HOLDS_STRING (compat)))
 bubble_set_synchronous (bubble, g_value_get_string (compat));
 		}
 	}
@@ -676,14 +678,14 @@
 	if (hints)
 	{
 		data = (GValue*) g_hash_table_lookup (hints, value);
-		if (G_VALUE_HOLDS_INT (data))
+		if ((data  G_VALUE_HOLDS_INT (data)))
 			bubble_set_value (bubble, g_value_get_int (data));
 	}
 
 	if (hints)
 	{
 		data = (GValue*) g_hash_table_lookup (hints, urgency);
-		if (G_VALUE_HOLDS_UCHAR (data))
+		if ((data  G_VALUE_HOLDS_UCHAR (data)))
 			bubble_set_urgency (bubble,
 	   g_value_get_uchar (data));
 		/* Note: urgency was defined as an enum: LOW, NORMAL, CRITICAL
@@ -695,7 +697,7 @@
 	{
 		data   = (GValue*) g_hash_table_lookup (hints, x-canonical-private-icon-only);
 		compat = (GValue*) g_hash_table_lookup (hints, icon-only);
-		if (G_VALUE_HOLDS_STRING (data) || G_VALUE_HOLDS_STRING (compat))
+		if ((data  G_VALUE_HOLDS_STRING (data)) || (compat  G_VALUE_HOLDS_STRING (compat)))
 			bubble_set_icon_only (bubble, TRUE);
 		else
 			bubble_set_icon_only (bubble, FALSE);
@@ -712,7 +714,7 @@
 		else if ((data = (GValue*) g_hash_table_lookup (hints, image_path)))
 		{
 			g_debug(Using image_path hint\n);
-			if (G_VALUE_HOLDS_STRING (data))
+			if ((data  G_VALUE_HOLDS_STRING (data)))
 bubble_set_icon (bubble, g_value_get_string(data));
 			else
 g_warning (image_path hint is not a string\n);
@@ -766,6 +768,14 @@
 
 	dbus_g_method_return (context, bubble_get_id (bubble));
 
+	// FIXME: this is a temporary work-around, I do not like at all, until
+	// the heavy memory leakage of notify-osd is fully fixed...
+	// after a threshold-value of 500 notifications, forcefully exit
+	// notify-osd in order to get the leaked memory freed again, any new
+	// notification will instruct the session to restart notify-osd
+	if (bubble_get_id (bubble) == FORCED_SHUTDOWN_THRESHOLD)
+		gtk_main_quit ();
+
 	return TRUE;
 }
 

___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help   : https://help.launchpad.net/ListHelp


[Ayatana-commits] [Merge] lp:~macslow/notify-osd/two-slots into lp:notify-osd

2009-09-03 Thread Mirco Müller
Mirco Müller has proposed merging lp:~macslow/notify-osd/two-slots into 
lp:notify-osd.

Requested reviews:
Notify OSD Developers (notify-osd-developers)

This branch introduces the two slots-concept for holding the two possible 
notification-bubbles (one for async./feedback notifications, one for 
sync./normal notifications). It extends the API of class Stack a bit (with 
unit-tests for the newly introduced calls) and works for both gravity cases 
(here still called Placement). It also fixes LP: #371422. A major culprit that 
still needs some fixing/clean up love is display.c, but it better now with this 
branch already.
-- 
https://code.launchpad.net/~macslow/notify-osd/two-slots/+merge/11168
Your team ayatana-commits is subscribed to branch lp:notify-osd.
=== modified file 'src/bubble.c'
--- src/bubble.c	2009-08-26 11:17:55 +
+++ src/bubble.c	2009-08-27 09:52:34 +
@@ -83,7 +83,6 @@
 	gboolean icon_only;
 	gint future_height;
 	gboolean prevent_fade;
-	BubblePlacement  placement;
 
 	// these will be replaced by notification_t* later on
 	GString* title;
@@ -2251,7 +2250,6 @@
 	this-priv-tile_body= NULL;
 	this-priv-tile_indicator   = NULL;
 	this-priv-prevent_fade = FALSE;
-	this-priv-placement		 = PLACEMENT_NEW;
 
 	update_input_shape (window, 1, 1);
 
@@ -3649,12 +3647,3 @@
 	bubble_start_timer (self);
 	bubble_start_timer (other);
 }
-
-BubblePlacement
-bubble_get_placement (Bubble* self)
-{
-	if (!self || !IS_BUBBLE (self))
-		return PLACEMENT_NONE;
-
-	return GET_PRIVATE (self)-placement;
-}

=== modified file 'src/bubble.h'
--- src/bubble.h	2009-08-26 09:35:02 +
+++ src/bubble.h	2009-08-27 09:52:34 +
@@ -48,13 +48,6 @@
 	LAYOUT_TITLE_ONLY
 } BubbleLayout;
 
-typedef enum
-{
-	PLACEMENT_NONE = 0,
-	PLACEMENT_OLD, // top-right of screen
-	PLACEMENT_NEW  // vertically centered at right of screen
-} BubblePlacement;
-
 G_BEGIN_DECLS
 
 #define BUBBLE_TYPE (bubble_get_type ())
@@ -267,9 +260,6 @@
 		const char *process_name,
 		gchar **actions);
 
-BubblePlacement
-bubble_get_placement (Bubble* self);
-
 G_END_DECLS
 
 #endif // __BUBBLE_H

=== modified file 'src/display.c'
--- src/display.c	2009-08-26 09:35:02 +
+++ src/display.c	2009-09-03 08:39:04 +
@@ -71,42 +71,122 @@
 	return y1 == y2;
 }
 
-
 static void
 stack_display_position_sync_bubble (Stack *self, Bubble *bubble)
 {
 	Defaults* d = self-defaults;
 	gint  y = 0;
 	gint  x = 0;
-	Bubble*   async;
 
 	defaults_get_top_corner (d, x, y);
 
 	// TODO: with multi-head, in focus follow mode, there may be enough
 	// space left on the top monitor
 
-	switch (bubble_get_placement (bubble))
+	switch (stack_get_placement (self))
 	{
 		case PLACEMENT_OLD:
-			async = stack_find_bubble_on_display (self);
-			if (async != NULL)
-			{
-d = self-defaults;
-y += bubble_get_future_height (async);
-y += EM2PIXELS (defaults_get_bubble_vert_gap (d), d) -
-2 * EM2PIXELS (defaults_get_bubble_shadow_size (d), d);
+			// see if we're call at the wrong moment, when both
+			// slots are occupied by bubbles
+			if (!stack_is_slot_vacant (self, SLOT_TOP) 
+			!stack_is_slot_vacant (self, SLOT_BOTTOM))
+			{
+g_warning (%s(): Both slots taken!\n,
+   G_STRFUNC);
+			}
+			else
+			{
+// first check if we can place the sync. bubble
+// in the top slot and the bottom slot is still
+// vacant, this is to avoid the gap between
+// bottom slot and panel
+if (stack_is_slot_vacant (self, SLOT_TOP) 
+stack_is_slot_vacant (self, SLOT_BOTTOM))
+{
+	stack_get_slot_position (self,
+		 SLOT_TOP,
+	 bubble_get_height (bubble),
+		 x,
+		 y);
+	if (x == -1 || y == -1)
+		g_warning (%s(): No coords!\n,
+			   G_STRFUNC);
+	else
+		stack_allocate_slot (self,
+			 bubble,
+			 SLOT_TOP);
+}
+// next check if top is occupied and bottom is
+// still vacant, then place sync. bubble in
+// bottom slot
+else if (!stack_is_slot_vacant (self,
+SLOT_TOP) 
+ stack_is_slot_vacant (self,
+   SLOT_BOTTOM))
+{
+	stack_get_slot_position (self,
+		 SLOT_BOTTOM,
+	 bubble_get_height (bubble),
+		 x,
+		 y);
+	if (x == -1 || y == -1)
+		g_warning (%s(): No coords!\n,
+			   G_STRFUNC);
+	else
+	{
+		stack_allocate_slot (
+			self,
+			bubble,
+			SLOT_BOTTOM);
+
+		bubble_sync_with (
+			bubble,
+			self-slots[SLOT_TOP]);
+	}
+}
+// this case, top vacant, bottom occupied,
+// should never happen for the old placement,
+// we want to avoid the gap between the bottom
+// bubble and the panel
+else

[Ayatana] Urgency-display-bar in notify-osd

2009-05-15 Thread Mirco Müller
Greetings everyone!

For the the development cycle of Karmic an urgency-display bar has been
added to notify-osd trunk.

If enabled (start notify-osd like DEBUG=1 notify-osd from a terminal)
you'll see the application-set urgency of a notification indicated in a
top-bar:

http://people.ubuntu.com/~mmueller/urgency-debug-display.ogg

There's no karmic package for this yet. But if you want to give it a
try grab it from notify-osd trunk.

The main reason for doing this is to have a mean to quickly identify
wrongly set urgencies of notifications. We could consider adding the
originating application-name to that bar, thus helping to file more
meaningful bugs.

While it will compile and run on Ubuntu 9.04 I do not recommend that,
since there are patches in trunk which alter some behaviours of
notify-osd not intended for Ubuntu 9.04.

Best regards ...

Mirco


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp