Re: [Ayatana] Usability - Useless effect when clicking an icon (Unity)
On Wed, Dec 8, 2010 at 16:01, Peterson Silva peterson@gmail.com wrote: Recently I've posted this bug at Launchpad: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/686822 So the thing is, if you have only one instance of an active window and you click its icon in the Launcher, the effect is useless. Users coming from Windows 7 (or any other version of it for that matter) or Mac OS will expect the application to minimize; instead, it will just float. It is useless and counter-intuitive already. On the other hand, when there are multiple windows of the same app, the effect is very cool and useful; +1 and well, i miss my SUPER+W !!! If Scale aka Expose becomes so central, i would strongly recommend to associate the scale addon features: * secondary click to zoom in * middle click to close especially the unread messages from the Messaging Menu shouldn't get acknowledged, before i haven't seen them at full scale. Seeing the window, scaled down on a Netbook 10 display in Exposé, surely doesn't validate removing a message indicator from the Messaging Menu as seen. ___ 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] Allowing windows to move past launchers
Hi, I was doing some work on the snap windows plugin for compiz and I was wondering if it is the correct behaviour design wise to allow windows to move underneath the launcher and the panel. Currently we have it so that windows snap to the launcher but the user can move the window past the launcher if they move hard enough but I was wondering if we should even allow windows to move past these panels in the first place. Let me know what you all think. Cheers -- Sam Spilsbury ___ 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] Allowing windows to move past launchers
Le jeudi 09 décembre 2010 à 18:55 +0800, Sam Spilsbury a écrit : Hi, I was doing some work on the snap windows plugin for compiz and I was wondering if it is the correct behaviour design wise to allow windows to move underneath the launcher and the panel. Currently we have it so that windows snap to the launcher but the user can move the window past the launcher if they move hard enough but I was wondering if we should even allow windows to move past these panels in the first place. Let me know what you all think. We should just perhaps agree on the snap value? I mean, we want to avoid false positive on intellihide but still enabling people to have intellihide :) Cheers Didier ___ 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] Allowing windows to move past launchers
On 09/12/10 10:59, Didier Roche wrote: Le jeudi 09 décembre 2010 à 18:55 +0800, Sam Spilsbury a écrit : Hi, I was doing some work on the snap windows plugin for compiz and I was wondering if it is the correct behaviour design wise to allow windows to move underneath the launcher and the panel. Currently we have it so that windows snap to the launcher but the user can move the window past the launcher if they move hard enough but I was wondering if we should even allow windows to move past these panels in the first place. Let me know what you all think. We should just perhaps agree on the snap value? I mean, we want to avoid false positive on intellihide but still enabling people to have intellihide :) In the intellihide, moving the window against the launcher should kick the launcher out immediately, as it currently does. I think Sam's referring more to the case where the launcher is locked in place, not intellihide. Mark signature.asc Description: OpenPGP digital signature ___ 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] progress window chrome
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 frederik.nn...@gmail.com wrote on 08/12/10 21:24: On Wed, Dec 8, 2010 at 20:57, Roth Robert evf...@gmail.com ... On Wed, Dec 8, 2010 at 2:22 PM, Matthew Paul Thomas ... Yes. It is a bug in the HIG that it recommends repeating title bar text as primary text in progress windows. The sentence that recommended repeating the title bar text as primary text in progress windows was removed since 2.30... you can still see it in 2.28, but it does not appear since 2.30 anymore. I guess that the screenshot was not updated. whow, such historical detail ;) Oh, it's even worse than that. The person who removed it was ... me. http://mail.gnome.org/archives/usability/2010-March/msg00021.html I just forgot yesterday that I'd done it. Now let's hope that the 3.0 will rid us of the necessity of talking about how many titles a progress window needs.. Or, if hoping isn't your style, you could report bugs and make patches for the programs (like Synaptic) that currently repeat titles. In reality, even the current stable HIG recommends against using windows for the indication of progress, That's a misleading summary. The guidelines recommend against using progress windows in specific cases -- where the task prevents you from doing anything in an existing window (in which case you should show progress in that existing window), or where the task will take only a few seconds. There are still many cases where progress windows are appropriate. which itself leads to the conclusion that displaying progress within an extra window is an improper way of presenting that kind of data. It doesn't really. - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0A2GoACgkQ6PUxNfU6ecpOaACeNvKjsqv3OOJbvWoMhEdKiPBS C7IAoKBxJsSX4yGZoNDWBmwwkQrKRryv =1wLe -END PGP SIGNATURE- ___ 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] Usability - Useless effect when clicking an icon (Unity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peterson Silva wrote on 08/12/10 15:01: ... So the thing is, if you have only one instance of an active window and you click its icon in the Launcher, the effect is useless. Users coming from Windows 7 (or any other version of it for that matter) or Mac OS will expect the application to minimize; That's what it does in Windows 7, for some applications but not others: for example, it works for Windows Explorer, but not for Windows Backup. It's not what it does in Mac OS X, at all: clicking the launcher of a running application always brings all its windows to the front, and if they already are, it does nothing. ... So here's what we could do, then: to have different effects based on the windows opened, but with a visual hint so the user knows what to expect (and can easily understand the point of the behaviour). I'm not currently using Unity, but as far as I remember, there's no visual hint as to whether or not there are multiple instances of a window opened. We could put a small emblem over the program icon in the launcher (like in one of its corners) with a number indicating the number of windows. ... Unity will soon have something very much like this. - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0A/+kACgkQ6PUxNfU6ecqDGgCgiiivwgBZp6o+Jh8i7cn6DxZL MqEAn1CSYglwHEYT4gzuhTKYcEUBrASN =z9At -END PGP SIGNATURE- ___ 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] Allowing windows to move past launchers
On Fri, Dec 10, 2010 at 1:33 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 09/12/10 10:59, Didier Roche wrote: Le jeudi 09 décembre 2010 à 18:55 +0800, Sam Spilsbury a écrit : Hi, I was doing some work on the snap windows plugin for compiz and I was wondering if it is the correct behaviour design wise to allow windows to move underneath the launcher and the panel. Currently we have it so that windows snap to the launcher but the user can move the window past the launcher if they move hard enough but I was wondering if we should even allow windows to move past these panels in the first place. Let me know what you all think. We should just perhaps agree on the snap value? I mean, we want to avoid false positive on intellihide but still enabling people to have intellihide :) In the intellihide, moving the window against the launcher should kick the launcher out immediately, as it currently does. I think Sam's referring more to the case where the launcher is locked in place, not intellihide. I was thinking something like this (warning: coder's POV, it gets a bit technical). Bit of lingo here since I tend to use it regularly: - strut: A property called _NET_WM_STRUT_PARTIAL that docks, launchers, etc place on windows to reserve an area of the screen. Windows don't get placed there and they cannot maximize over it. - placement: where the window is positioned on open. My idea was this: 1) On the intellihide case: - We don't set the strut property, which means that windows can implicitly get placed underneath the launcher (this can be overridden in the unityshell plugin) - On maximisation the launcher is going to go away anyway, since the window will be covering it - When moving a window near the launcher, if it goes close then the launcher will go away (intellihide) - When resizing a window, if the resize border touches the launcher, it goes away, easy 2) On the fixed launcher case: - We set the strut property, so no implicit incorrect placement - On maximization the window does not cover the launcher - Windows cannot be resized underneath the launcher - Windows cannot be moved underneath the launcher. The reason for the fourth one is because we have the window buttons on the left - we do not want to have to obscure them in the case that we move a window. Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ 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] Allowing windows to move past launchers
On 09/12/10 17:43, Sam Spilsbury wrote: My idea was this: 1) On the intellihide case: [...] - When resizing a window, if the resize border touches the launcher, it goes away, easy I'd like to see a proximity push in this case. When the window is brought close to the launcher, we start to push the launcher away. Say, when the edge of the window is 10px from the launcher, we start to move the launcher 1px for each 2px it approaches. When the window gets to the point where it would have touched the launcher, the launcher goes away. I think this would feel a little more organic and real than the current insta-trigger. The px values might best be shared with the notify-osd proximity-effect fade boundary too. 2) On the fixed launcher case: - We set the strut property, so no implicit incorrect placement - On maximization the window does not cover the launcher - Windows cannot be resized underneath the launcher - Windows cannot be moved underneath the launcher. The reason for the fourth one is because we have the window buttons on the left - we do not want to have to obscure them in the case that we move a window. Let's do some testing with a less rigid interpretation - allow the window to be resized or moved so its left edge is under the launcher, but make sure it encounters some resistance when it touches, before pushing through under the launcher. Mark signature.asc Description: OpenPGP digital signature ___ 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] Allowing windows to move past launchers
On Fri, Dec 10, 2010 at 2:14 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 09/12/10 17:43, Sam Spilsbury wrote: My idea was this: 1) On the intellihide case: [...] - When resizing a window, if the resize border touches the launcher, it goes away, easy I'd like to see a proximity push in this case. When the window is brought close to the launcher, we start to push the launcher away. Say, when the edge of the window is 10px from the launcher, we start to move the launcher 1px for each 2px it approaches. When the window gets to the point where it would have touched the launcher, the launcher goes away. This is easy to implement in compiz. I think this would feel a little more organic and real than the current insta-trigger. The px values might best be shared with the notify-osd proximity-effect fade boundary too. 2) On the fixed launcher case: - We set the strut property, so no implicit incorrect placement - On maximization the window does not cover the launcher - Windows cannot be resized underneath the launcher - Windows cannot be moved underneath the launcher. The reason for the fourth one is because we have the window buttons on the left - we do not want to have to obscure them in the case that we move a window. Let's do some testing with a less rigid interpretation - allow the window to be resized or moved so its left edge is under the launcher, but make sure it encounters some resistance when it touches, before pushing through under the launcher. Right. I'll look into implementing edge resistance for resize as well in the snap plugin Mark -- Sam Spilsbury ___ 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] Allowing windows to move past launchers
Lovely concept. I think it would make positioning windows near the launcher less frustrating. On Thu, 2010-12-09 at 18:14 +, Mark Shuttleworth wrote: On 09/12/10 17:43, Sam Spilsbury wrote: My idea was this: 1) On the intellihide case: [...] - When resizing a window, if the resize border touches the launcher, it goes away, easy I'd like to see a proximity push in this case. When the window is brought close to the launcher, we start to push the launcher away. Say, when the edge of the window is 10px from the launcher, we start to move the launcher 1px for each 2px it approaches. When the window gets to the point where it would have touched the launcher, the launcher goes away. I think this would feel a little more organic and real than the current insta-trigger. The px values might best be shared with the notify-osd proximity-effect fade boundary too. 2) On the fixed launcher case: - We set the strut property, so no implicit incorrect placement - On maximization the window does not cover the launcher - Windows cannot be resized underneath the launcher - Windows cannot be moved underneath the launcher. The reason for the fourth one is because we have the window buttons on the left - we do not want to have to obscure them in the case that we move a window. Let's do some testing with a less rigid interpretation - allow the window to be resized or moved so its left edge is under the launcher, but make sure it encounters some resistance when it touches, before pushing through under the launcher. Mark -- Jason Smith | Desktop Experience Team GNOME Developer Canonical USA Inc. T. +1.248.756.6266 | jason.sm...@canonical.com Ubuntu - Linux for human beings | www.ubuntu.com ___ 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] Seeking feedback on professional video import UX design
Frederik, On Wed, Dec 8, 2010 at 3:53 AM, frederik.nn...@gmail.com frederik.nn...@gmail.com wrote: Hi Jason, well, this is what i've been waiting for all along: professional post production software for Ubuntu! Music to my ears. :) For anyone who missed earlier emails, discussion is about this pro file import UX design: https://wiki.ubuntu.com/AyatanaDmediaLovefest On Tue, Dec 7, 2010 at 19:33, Jason DeRose jder...@novacut.com wrote: I didn't make it clear, but in my scenario there will very likely be a person editing at the workstation. Being a devoted AVID user (audio), I'm well aware of the various zombie states one can assume, operating a digital workstation for the better part of the day.. Nice. We haven't received as much feedback yet from AVID user (more FCP), nor from pro audio users, so we really appreciate your thoughts on any of this. In your pro audio work, are you typically importing from cards, or recording directly to your workstation? We need to support both, but right now we're trying to make the most common HDSLR hardware setup work very smoothly... which pretty much means recording on a Zoom H4n or similar, importing from SD cards. Out of curiosity, have you used any of AVID's Media Asset Management software? If so, what do you think of it, any features stand out as especially worthwhile? When someone is there editing, I think NotifyOSD strikes a wonderful balance between reliably capturing the user's attention yet not distracting them. It's all because the notifications are non-interactive. They're strangely soothing, IHMO. (Mad props to those who designed them so well.) I can only begin to imagine the benefits of my ProTools being integrated into its hosting DE for once.. that would change everything! Notify OSD and AppIndicators provide such an easy way of integrating one's professional software into the Desktop Environment seamlessly. That's my thinking... why shouldn't creative professionals have some first-class DE features just for them? IHMO, there is a *huge* opportunity right now to bring creative professionals to Ubuntu, especially in the big-data, compute-intensive areas of pro video and audio. Like what already has happened with super computing, I think Linux will become the preferred platform for creative professionals. Hollywood special effects and 3d animation have been done almost exclusively on Linux for some time, and from talking to a friend that works in the industry, production shops are foaming at the mouth to move to a *fully* Linux-based solution... they just need a suitable video editor, suitable Media Asset Management. I personally think Apple sees the writing on the wall already... I think there is clear evidence that Apple isn't making further serious investment in its pro content creation software. It's all about iOS and content consumption. And that has opened the door for Ubuntu to provide a new home for a lot of creative professionals. All the same, it would be a small effort to try both approaches, get feedback from the users. If you ever have a mockup of what you had in mind for said window, I'd love to see it. Menus are condensed interfaces, they offer the most frequently used options of an otherwise more comprehensive interface for rapid interaction. In a similar way, as in Ayatana Indicator Menus, they can also offer the most recent and current event/process/progress/item in a given activity, e.g. a conversation, a message or a completed transfer. I think it is always easy to see a menu as a proxy to the more comprehensive main window of the same respective project. Only that the menu will give back focus to the thing you were working on without the disturbing requirements of window management. I know this is a very specialized use case and it might seem like I'm splitting hairs, but it's also a use case where small improvements can make a big difference to the user. I can confirm that. When only a single keyboard command changes, it can have a severe effect on how usable my workstation is! Imagine.. you sit behind that workstation for a dozen of hours on many a day, doing the same thing over and over again, how terrible would it be, to run into a logical regression in the UI design. Thanks again for your input! I'll add your suggestion to the wiki page. keep me posted as the software becomes available for testing, i for one can't wait to get professional post production work done in desktop Linux. So the features described in this UX design should almost all land in dmedia 0.2, which will be released on December 30th: https://launchpad.net/dmedia/+milestone/0.2 Although the content of the RenderMenu will still be quiet rough and cards wont automatically be formatted yet. I'll let you know when it's available! Thanks again for the feedback! ___ Mailing list: https://launchpad.net/~ayatana Post to :
Re: [Ayatana] Usability - Useless effect when clicking an icon (Unity)
That's what it does in Windows 7, for some applications but not others: for example, it works for Windows Explorer, but not for Windows Backup. What an inconsistency oO It's not what it does in Mac OS X, at all: Sorry, I've never used a Mac, but as all the docks out there which try to copy it somehow have this behaviour, I assumed that it was there where it came from. Unity will soon have something very much like this. Awesome! =D But then with only one window will it minimise after clicking? *Peterson* *http://petercast.net* On 9 December 2010 14:12, Matthew Paul Thomas m...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peterson Silva wrote on 08/12/10 15:01: ... So the thing is, if you have only one instance of an active window and you click its icon in the Launcher, the effect is useless. Users coming from Windows 7 (or any other version of it for that matter) or Mac OS will expect the application to minimize; That's what it does in Windows 7, for some applications but not others: for example, it works for Windows Explorer, but not for Windows Backup. It's not what it does in Mac OS X, at all: clicking the launcher of a running application always brings all its windows to the front, and if they already are, it does nothing. ... So here's what we could do, then: to have different effects based on the windows opened, but with a visual hint so the user knows what to expect (and can easily understand the point of the behaviour). I'm not currently using Unity, but as far as I remember, there's no visual hint as to whether or not there are multiple instances of a window opened. We could put a small emblem over the program icon in the launcher (like in one of its corners) with a number indicating the number of windows. ... Unity will soon have something very much like this. - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0A/+kACgkQ6PUxNfU6ecqDGgCgiiivwgBZp6o+Jh8i7cn6DxZL MqEAn1CSYglwHEYT4gzuhTKYcEUBrASN =z9At -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatanahttps://launchpad.net/%7Eayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatanahttps://launchpad.net/%7Eayatana More help : https://help.launchpad.net/ListHelp ___ 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] [Branch ~dbusmenu-team/dbusmenu/trunk] Rev 174: Upping the library version as we're different ABI than 0.3.90 even :-/
revno: 174 committer: Ted Gould t...@gould.cx branch nick: trunk timestamp: Thu 2010-12-09 10:18:26 -0600 message: Upping the library version as we're different ABI than 0.3.90 even :-/ modified: configure.ac -- lp:dbusmenu https://code.launchpad.net/~dbusmenu-team/dbusmenu/trunk Your team ayatana-commits is subscribed to branch lp:dbusmenu. To unsubscribe from this branch go to https://code.launchpad.net/~dbusmenu-team/dbusmenu/trunk/+edit-subscription === modified file 'configure.ac' --- configure.ac 2010-12-07 15:26:30 + +++ configure.ac 2010-12-09 16:18:26 + @@ -135,7 +135,7 @@ # Lib versioning ### -LIBDBUSMENU_CURRENT=2 +LIBDBUSMENU_CURRENT=3 LIBDBUSMENU_REVISION=0 LIBDBUSMENU_AGE=0 ___ 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:~ted/dbusmenu/check-item-fix into lp:dbusmenu
Ted Gould has proposed merging lp:~ted/dbusmenu/check-item-fix into lp:dbusmenu.
Requested reviews:
DBus Menu Team (dbusmenu-team)
Fixing check items.
--
https://code.launchpad.net/~ted/dbusmenu/check-item-fix/+merge/43304
Your team ayatana-commits is subscribed to branch lp:dbusmenu.
=== modified file 'libdbusmenu-gtk/genericmenuitem.c'
--- libdbusmenu-gtk/genericmenuitem.c 2010-12-02 19:52:54 +
+++ libdbusmenu-gtk/genericmenuitem.c 2010-12-09 22:49:53 +
@@ -65,6 +65,7 @@
static void draw_indicator (GtkCheckMenuItem *check_menu_item, GdkRectangle *area);
static void (*parent_draw_indicator) (GtkCheckMenuItem *check_menu_item, GdkRectangle *area) = NULL;
#endif
+static void (*parent_menuitem_activate) (GtkMenuItem * mi) = NULL;
/* Initializing all of the classes. Most notably we're
disabling the drawing of the check early. */
@@ -86,6 +87,7 @@
GtkMenuItemClass * menuitem_class = GTK_MENU_ITEM_CLASS (klass);
menuitem_class-set_label = set_label;
menuitem_class-get_label = get_label;
+ parent_menuitem_activate = menuitem_class-activate;
menuitem_class-activate = activate;
return;
@@ -333,21 +335,19 @@
item-priv-state = state;
GtkCheckMenuItem * check = GTK_CHECK_MENU_ITEM(item);
-
- gboolean old_active = gtk_check_menu_item_get_active (check);
- gboolean old_inconsist = gtk_check_menu_item_get_inconsistent (check);
+ gboolean goal_active = FALSE;
switch (item-priv-state) {
case GENERICMENUITEM_STATE_UNCHECKED:
- gtk_check_menu_item_set_active (check, FALSE);
+ goal_active = FALSE;
gtk_check_menu_item_set_inconsistent (check, FALSE);
break;
case GENERICMENUITEM_STATE_CHECKED:
- gtk_check_menu_item_set_active (check, TRUE);
+ goal_active = TRUE;
gtk_check_menu_item_set_inconsistent (check, FALSE);
break;
case GENERICMENUITEM_STATE_INDETERMINATE:
- gtk_check_menu_item_set_active (check, TRUE);
+ goal_active = TRUE;
gtk_check_menu_item_set_inconsistent (check, TRUE);
break;
default:
@@ -355,15 +355,11 @@
return;
}
- if (old_active != gtk_check_menu_item_get_active (check)) {
- g_object_notify(G_OBJECT(item), active);
- }
-
- if (old_inconsist != gtk_check_menu_item_get_inconsistent (check)) {
- g_object_notify(G_OBJECT(item), inconsistent);
- }
-
- gtk_widget_queue_draw(GTK_WIDGET(item));
+ if (goal_active != gtk_check_menu_item_get_active(check)) {
+ if (parent_menuitem_activate != NULL) {
+ parent_menuitem_activate(GTK_MENU_ITEM(check));
+ }
+ }
return;
}
___
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:~ted/dbusmenu/check-item-fix into lp:dbusmenu
The proposal to merge lp:~ted/dbusmenu/check-item-fix into lp:dbusmenu has been updated. Status: Needs review = Merged -- https://code.launchpad.net/~ted/dbusmenu/check-item-fix/+merge/43304 Your team ayatana-commits is subscribed to branch lp:dbusmenu. ___ 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
