[Ayatana] Restart Required
hello there ;) is anybody working on the FUSA currently? Allow me to raise the topic for brief elaboration.. Restart Required seems incorrect to me: after executing a partial upgrade, Ubuntu shows two red elements in the indicator area of my top panel * dysfunctional conman * FUSA in alert condition first of all, restart required is not an action, it is an informative sentence, therefore it doesn't belong into any menu as an interactive menu item. One could instead place it above the FUSA as it is opened on click via its indicator icon in the panel. Furthermore, the red color on the indicator-session icon calls ERROR or network-failure to mind, this is not correct in this case. We are not failing anything, there also is no error, so red is incorrect in this situation. Perhaps yellow or orange, maybe blue. The fact of colorization alone should be informative enough for the user to notice timely. A hover in that screen corner should also reveal the suggested action: upgrade complete, please restart the computer. The menu item should not change IMO, it should still be called Restart. My original idea of indicators when i first heard about them was that they would turn out to be website-like multi-state buttons, perhaps animated and with some alpha ;) Since we decided to dismiss the menus upon action, except for indicator-sound, why not keep the activity i called via a menu item indicated via mouse cursor sometimes? for Restarting i can imagine a clean visual metaphor, as it exists already: an animated power switch. I guess MPT designed something like that already in one of his documents.. ___ 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] Restart Required
On 30 July 2010 16:31, Frederik Nnaji frederik.nn...@gmail.com wrote: hello there ;) is anybody working on the FUSA currently? Allow me to raise the topic for brief elaboration.. Restart Required seems incorrect to me: after executing a partial upgrade, Ubuntu shows two red elements in the indicator area of my top panel * dysfunctional conman * FUSA in alert condition first of all, restart required is not an action, it is an informative sentence, therefore it doesn't belong into any menu as an interactive menu item. One could instead place it above the FUSA as it is opened on click via its indicator icon in the panel. Furthermore, the red color on the indicator-session icon calls ERROR or network-failure to mind, this is not correct in this case. We are not failing anything, there also is no error, so red is incorrect in this situation. Perhaps yellow or orange, maybe blue. The fact of colorization alone should be informative enough for the user to notice timely. A hover in that screen corner should also reveal the suggested action: upgrade complete, please restart the computer. The menu item should not change IMO, it should still be called Restart. +1 The red indicator has been a bug bear of mine for a while, red is far to severe a colour for something that isn't an error condition. I'd again suggest blue for information, or at most an amber to indicate a warning (I guess it's possible a kernel update had a security fix). Also, Restart required isn't an action, and it's not required. Restart (recommended) might make more sense, brackets differentiating the action from the recommendation. Luke. ___ 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] Restart Required
On 30/07/10 16:44, Luke Benstead wrote: The red indicator has been a bug bear of mine for a while, red is far to severe a colour for something that isn't an error condition. I'd again suggest blue for information, or at most an amber to indicate a warning (I guess it's possible a kernel update had a security fix). The strong likelihood is that you are insecure until you reboot, so we class it as a warning and make it red. Also, Restart required isn't an action, and it's not required. Restart (recommended) might make more sense, brackets differentiating the action from the recommendation. Agreed, the language is bad. The current plan is to change it to Restart, completing updates... which is more accurate. Still open to a better choice of words if you have something in mind. 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] Restart Required
On Fri, 2010-07-30 at 18:26 +0100, Mark Shuttleworth wrote: On 30/07/10 16:44, Luke Benstead wrote: The red indicator has been a bug bear of mine for a while, red is far to severe a colour for something that isn't an error condition. I'd again suggest blue for information, or at most an amber to indicate a warning (I guess it's possible a kernel update had a security fix). The strong likelihood is that you are insecure until you reboot, so we class it as a warning and make it red. Also, Restart required isn't an action, and it's not required. Restart (recommended) might make more sense, brackets differentiating the action from the recommendation. Agreed, the language is bad. The current plan is to change it to Restart, completing updates... which is more accurate. Still open to a better choice of words if you have something in mind. I've tried to look for gnome-menu items with commas or explanation words within brackets but have not noticed any. Usually where text needs to be an explanation , menu item tends to be longer. [ex: evolution, Download Messages for Offline Usage . really shouldnt be citing evo as an example, but it had the longest I could find ;)] How about : Restart To Apply Updates... or Restart and Apply Updates... -- Cheers, Vish ___ 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] Restart Required
On 30/07/10 19:24, Vishnoo wrote: How about : Restart To Apply Updates... or Restart and Apply Updates... Could do, yes. By then the updates have been installed, so I was looking for language which indicated that the update process wasn't complete. 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] Restart Required
On 30/07/10 20:01, Martin Owens wrote: On Fri, 2010-07-30 at 19:31 +0100, Mark Shuttleworth wrote: Could do, yes. By then the updates have been installed, so I was looking for language which indicated that the update process wasn't complete. Could the level of warning not be directly related to the severity of the security problems in the update? I don't think we know - it's either reboot required or not. 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] Restart Required
On 30/07/10 20:01, Martin Owens wrote: Could the level of warning not be directly related to the severity of the security problems in the update? Also... we don't want to get too anorack about this. In theory, we could use blue for informational updates, orange for low priority updates and red for critical security. But that's more likely to confuse people than help them. So for the moment we'll pick one colour and stick to it. 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] Restart Required
On 30/07/10 20:57, Vishnoo wrote: Right , just wanted to mention that we dont need to use punctuations or brackets in menus: Restart To Complete Update... [ or s/complete/finish or any synonym ] Yes, that would fit nicely :-) 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] The Future of Window Borders, Menu Bars, and More
On 07/29/2010 10:35 AM, Martin Owens wrote: On Thu, 2010-07-29 at 18:28 +0800, Allan Caeg wrote: Conventions in Windows and OS X are evolving (see the ribbon interface and app buttons on Office, Paint, etc.) while the Linux desktop is limited (probably) because we can't make new things work everywhere (different window managers, desktop environments, etc.). I think it's more important to have standards in data format and communication, than to have standards in interfaces across competing products. Internal design consistency is very important and that can only really be achieved with standards. Insisting on a left aligned set of window buttons is something you can only do within a distro, it's hard to enforce that sort of thing on your collaborators, let alone your competitors. So it's best not to standardise the look and feel of the product when it's pretty much the one feature that separates various products in the market. Applications should tell the desktop what they mean, not what they want. I think things like the windicators and the indicators are going in the right direction, but communication is only very slowly getting better. I remember the almost flaming row I had with DX-Gould at UDS-J about removing the indicators. The impression I got was not what the results have turned into and I would have been quite happy to accept the current design had it been possible to explain at the time. Martin, ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp May I add my own view of this? *ahem*: (tl;dr version at the bottom) GNOME 3 comes out next year. With it comes many new technologies including the Application Menu, a message tray for non-system applications, and GTK+ 3. The GNOME Shell design page has an interesting page on the Application Menu (aka AppMenu), a feature coming in GNOME Shell. The menus that Chrome and Firefox and Opera and every other application with menus are often relevant to two different things at once: the window and the application. The difference between the two is that there are some options, such as Open File, Print, or the View menu that only affect the current window, and some options such as Preferences, options for Add-Ons, Bookmarks, (maybe) History, Help, Check for Updates, and About, that affect the entire program, meaning every open window. The Firefox Button makes sense on something like Windows because Windows doesn't have a menu like this. On Mac, the button doesn't make sense because of the global menu bar. On Linux, it's unclear because there are so many different conventions with which to do things, some more efficient than others. Remember: All that the Firefox Button does is re-package the menu bar in a more compact space on the window border, that is it. It's simply re-organizing the current menu structure into a drop-down menu. Each operating system and desktop environment does things differently and this is expected. Windows users often complain about how hard to use Mac is, Mac users complain how hard to use Windows is, KDE users complain how hard to use GNOME is, GNOME users complain how hard to use KDE is and so on because they are used to different things. Each OS has their own way of being efficient and organized with their own unique styles. People switching from Windows to Mac or Linux do so partially because of this; it's told as being easy to use once you are used to it. The Application Menu is one of GNOME 3's unique quirks, which is, in my opinion, for the better. It works like this: The parts of the menu bar that are relevant to the application as a whole go into the Application Menu, so that no matter what window you have open, you can still access "entire-application functions", while the things that modify the window alone stay there. This mockup shows how it could work for Firefox. The Application Menu page I linked to at the beginning says this menu could be used to hold the following types of options: Quit (all windows of the application that are open) Preferences/Settings About Check for updates (maybe) Clipboard (maybe) Show/hide Windows (maybe) New Application Window This could work very well because instead of looking through the various menu bar options for the right option, you'd know where they are instantly by simply looking in the Application Menu. Firefox isn't the best example for this personally, so lets take Pidgin for example. you have a buddy list and a conversation window open. The conversation window would keep
Re: [Ayatana] Restart Required
Hi Vish, Hi Conscious ;) On Fri, Jul 30, 2010 at 21:57, Vishnoo v...@ubuntu.com wrote: On a related note, we first need to fix: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/548981 Once that is fixed , the session-menu wording and the icon changing only after the update would all fit well. wow, i wasn't aware that this was a problem! now would be a good time to introduce a large indicator for progress.. especially system maintenance load should gradually begin to visualize superficially, so we can observe how much of our computer's power is truly being consumed by technology and how much of it is intelligent interaction with human input.. ___ 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:~dbarth/appmenu-gtk/tb-crasher-fix into lp:appmenu-gtk
Review: Approve approved. -- https://code.launchpad.net/~dbarth/appmenu-gtk/tb-crasher-fix/+merge/31254 Your team ayatana-commits is subscribed to branch lp:appmenu-gtk. ___ 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:~dbarth/appmenu-gtk/local-fallback into lp:appmenu-gtk
makes sense, approved. -- https://code.launchpad.net/~dbarth/appmenu-gtk/local-fallback/+merge/31311 Your team ayatana-commits is subscribed to branch lp:appmenu-gtk. ___ 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:~ted/dbusmenu/open-menu-signal into lp:dbusmenu
Review: Approve -- https://code.launchpad.net/~ted/dbusmenu/open-menu-signal/+merge/30472 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
[Ayatana-commits] [Merge] lp:~ted/dbusmenu/open-menu-signal into lp:dbusmenu
The proposal to merge lp:~ted/dbusmenu/open-menu-signal into lp:dbusmenu has been updated. Status: Needs review = Merged -- https://code.launchpad.net/~ted/dbusmenu/open-menu-signal/+merge/30472 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
[Ayatana-commits] [Branch ~dbusmenu-team/dbusmenu/trunk] Rev 139: Merge open-menu-signal branch.
Merge authors:
Ted Gould (ted)
Related merge proposals:
https://code.launchpad.net/~ted/dbusmenu/open-menu-signal/+merge/30472
proposed by: Ted Gould (ted)
review: Approve - Cody Russell (bratsche)
revno: 139 [merge]
committer: Cody Russell cruss...@canonical.com
branch nick: dbusmenu
timestamp: Fri 2010-07-30 12:27:30 -0500
message:
Merge open-menu-signal branch.
modified:
libdbusmenu-glib/dbus-menu.xml
libdbusmenu-glib/server-marshal.list
libdbusmenu-glib/server.c
libdbusmenu-glib/server.h
--
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 'libdbusmenu-glib/dbus-menu.xml'
--- libdbusmenu-glib/dbus-menu.xml 2010-06-07 12:30:52 +
+++ libdbusmenu-glib/dbus-menu.xml 2010-07-20 13:18:22 +
@@ -344,6 +344,20 @@
/dox:d
/arg
/signal
+ signal name=ItemActivationRequested
+ dox:d
+ The server is requesting that all clients displaying this
+ menu open it to the user. This would be for things like
+ hotkeys that when the user presses them the menu should
+ open and display itself to the user.
+ /dox:d
+ arg type=i name=id direction=out
+dox:dID of the menu that should be activated/dox:d
+ /arg
+ arg type=u name=timestamp direction=out
+dox:dThe time that the event occured/dox:d
+ /arg
+ /signal
!-- End of interesting stuff --
=== modified file 'libdbusmenu-glib/server-marshal.list'
--- libdbusmenu-glib/server-marshal.list 2010-02-09 16:52:21 +
+++ libdbusmenu-glib/server-marshal.list 2010-07-20 21:15:25 +
@@ -1,2 +1,3 @@
VOID: INT, STRING, POINTER
VOID: UINT, INT
+VOID: INT, UINT
=== modified file 'libdbusmenu-glib/server.c'
--- libdbusmenu-glib/server.c 2010-07-02 13:47:23 +
+++ libdbusmenu-glib/server.c 2010-07-20 21:21:13 +
@@ -65,6 +65,7 @@
ID_PROP_UPDATE,
ID_UPDATE,
LAYOUT_UPDATED,
+ ITEM_ACTIVATION,
LAST_SIGNAL
};
@@ -165,6 +166,22 @@
NULL, NULL,
_dbusmenu_server_marshal_VOID__UINT_INT,
G_TYPE_NONE, 2, G_TYPE_UINT, G_TYPE_INT);
+ /**
+ DbusmenuServer::item-activation-requested:
+ @arg0: The #DbusmenuServer emitting the signal.
+ @arg1: The ID of the parent for this update.
+ @arg2: The timestamp of when the event happened
+
+ This is signaled when a menuitem under this server
+ sends it's activate signal.
+ */
+ signals[ITEM_ACTIVATION] = g_signal_new(DBUSMENU_SERVER_SIGNAL_ITEM_ACTIVATION,
+ G_TYPE_FROM_CLASS(class),
+ G_SIGNAL_RUN_LAST,
+ G_STRUCT_OFFSET(DbusmenuServerClass, item_activation),
+ NULL, NULL,
+ _dbusmenu_server_marshal_VOID__INT_UINT,
+ G_TYPE_NONE, 2, G_TYPE_INT, G_TYPE_UINT);
g_object_class_install_property (object_class, PROP_DBUS_OBJECT,
@@ -359,6 +376,15 @@
return;
}
+/* Called when a menu item emits its activated signal so it
+ gets passed across the bus. */
+static void
+menuitem_activated (DbusmenuMenuitem * mi, guint timestamp, DbusmenuServer * server)
+{
+ g_signal_emit(G_OBJECT(server), signals[ITEM_ACTIVATION], 0, dbusmenu_menuitem_get_id(mi), timestamp, TRUE);
+ return;
+}
+
/* Connects all the signals that we're interested in
coming from a menuitem */
static void
@@ -368,6 +394,7 @@
g_signal_connect(G_OBJECT(mi), DBUSMENU_MENUITEM_SIGNAL_CHILD_REMOVED, G_CALLBACK(menuitem_child_removed), data);
g_signal_connect(G_OBJECT(mi), DBUSMENU_MENUITEM_SIGNAL_CHILD_MOVED, G_CALLBACK(menuitem_child_moved), data);
g_signal_connect(G_OBJECT(mi), DBUSMENU_MENUITEM_SIGNAL_PROPERTY_CHANGED, G_CALLBACK(menuitem_property_changed), data);
+ g_signal_connect(G_OBJECT(mi), DBUSMENU_MENUITEM_SIGNAL_ITEM_ACTIVATED, G_CALLBACK(menuitem_activated), data);
return;
}
=== modified file 'libdbusmenu-glib/server.h'
--- libdbusmenu-glib/server.h 2010-02-03 00:32:49 +
+++ libdbusmenu-glib/server.h 2010-07-20 21:15:25 +
@@ -46,6 +46,7 @@
#define DBUSMENU_SERVER_SIGNAL_ID_PROP_UPDATE item-property-updated
#define DBUSMENU_SERVER_SIGNAL_ID_UPDATE item-updated
#define DBUSMENU_SERVER_SIGNAL_LAYOUT_UPDATED layout-updated
+#define DBUSMENU_SERVER_SIGNAL_ITEM_ACTIVATION item-activation-requested
#define DBUSMENU_SERVER_SIGNAL_LAYOUT_UPDATE DBUSMENU_SERVER_SIGNAL_LAYOUT_UPDATED
#define DBUSMENU_SERVER_PROP_DBUS_OBJECT dbus-object
@@ -58,10 +59,10 @@
@id_prop_update: Slot for #DbusmenuServer::id-prop-update.
@id_update: Slot for #DbusmenuServer::id-update.
@layout_updated: Slot for
[Ayatana-commits] [Merge] lp:~dbarth/appmenu-gtk/local-fallback into lp:appmenu-gtk
The proposal to merge lp:~dbarth/appmenu-gtk/local-fallback into lp:appmenu-gtk has been updated. Status: Needs review = Merged -- https://code.launchpad.net/~dbarth/appmenu-gtk/local-fallback/+merge/31311 Your team ayatana-commits is subscribed to branch lp:appmenu-gtk. ___ 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
