[Ayatana] Change launcher icon size.
Look to this video: http://www.youtube.com/watch?v=DJH3Tmuc4TE I have already made the patch but i don't know if it's a good idea. There are some probelems with the counters and the progress bar but are easy to solve problem. What do you think about it? Is a good idea? Thanks. ___ 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] Change launcher icon size.
https://bugs.launchpad.net/ayatana-design/+bug/713087 ^_^ On Mon, Feb 21, 2011 at 7:40 PM, andrea azzarone aazzar...@hotmail.itwrote: Look to this video: http://www.youtube.com/watch?v=DJH3Tmuc4TE I have already made the patch but i don't know if it's a good idea. There are some probelems with the counters and the progress bar but are easy to solve problem. What do you think about it? Is a good idea? Thanks. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana 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] Global menu/indicator synchronisation
I noticed this interesting behaviour today---I must have been subconsciously aware of it before, but didn't think twice about: a. Click on File menu, scrub with mouse to indicators (Menus stay visible) b. Click on Indicators and scrub to File menu (Menus toggle back and forth) I don't have an opinion on correctness---but possibly other people might! ;-) -Paul ___ 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] Launcher DnD - import applications on DnD start
On Thu, Feb 10, 2011 at 3:53 PM, Neil Jagdish Patel neil.pa...@canonical.com wrote: I guess you could argue about where it would stop, +1 I think the important is to show clearly that those new tiles are very special ones, not running, not favorites. Seems to add complexity. chr ___ 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] Windicators
A sound windicator in Banshee seems like an edge case to me, because Banshee (a) already lives in the system sound indicator, and (b) usually runs in the background. A better starting point might be to consider something like a sound windicator in Totem, which doesn't normally have an entry in the system indicator. Here's the behaviour I would like to see: 1) window floating = application volume in window decoration 2) window maximized and focused = application volume in system sound menu (with some sort of cue that it's available) 3) any other case = application volume not available This way, window indicators are always available for the window that you are interacting with, while indicators for background windows don't get in your way. Applications like Banshee that are *designed* to run in the background can put their functionality in the system indicator directly. Connor On Sun, Feb 20, 2011 at 12:51 PM, Carl Simpson cwd.simp...@gmail.com wrote: Annoyingly, this somehow ended up in a completely different thread due to the horrors of human error. I'm reposting here. Sticking with the examples of Banshee and volume, for the sake of argument, we also recognise two sorts of window indicator: a) A window indicator that stands alone as functionality dedicated to a particular window. I call these “window-specific” window indicators. b) A window indicator which is a candidate for merger with system indicators under a “collapsing” indicator system, because they encapsulate system-relevant behaviours. I call these “system-relevant” window indicators. With the collapsing idea in place, things are like this: 1. Banshee is maximised. Volume controls (as system-relevant) for Banshee are collapsed into the appropriate system indicator. Window-specific window indicators for Banshee are present to the left of the system indicators. No separate window indicator for Banshee's volume is shown. 2. Banshee is not maximised. Volume controls for Banshee are in a window indicator, situated on Banshee's window decoration. Volume controls for Banshee in the system indicator are now not present. Other, window-relevant window indicators for Banshee are present on Banshee's window decoration as well. System-relevant and window-specific window indicators do not appear distinguishable at this stage. 3. Banshee is minimised. ?? (Banshee's volume cannot be changed?) My concern is that the functionality of changing the volume of Banshee moves about quite a bit. It does this in two ways: 1) It moves from place to place in the interface- namely between the panel and the window decoration of Banshee. 2) When in Banshee's window decoration it literally changes place on the screen. This will be true of all system-relevant window indicators. Is such a degree of movement of functionality acceptable? Something also needs to be said about the case of minimisation. Does the volume control for Banshee end up back in the system indicator, or does it simply become unavailable? Other window indicator functionality would become unavailable in the case of minimisation, and it might be argued that this is only natural and intuitive. However, we have two sorts of indicators (window-specific and system-relevant), and we have them for a reason- namely that some of them (system-relevant window indicators) encapsulate system-relevant behaviours. It is only natural for window-specific behaviours to disappear with the window with which they are associated. Without the window being at the forefront, its content does not affect us and the behaviours made available by its window-specific window indicators is not important to us. For that reason, having window-specific window indicators tied to window decorations seems uncontroversial. Should system-relevant behaviours, however, such as changing the volume of some sound that is playing, be tied to specific windows in this way? System-relevant behaviours (such as a playing sound) continue to affect us regardless of the position or status of the windows of the applications producing them. Do we really want users to be unable to change the volume of Banshee (or alter any other system-relevant thing for any application) when it is minimised? Putting the system-relevant window indicators for minimised applications back in the panel adds yet another occasion on which that functionality moves position. Looking at things as they are, I do not think that having window-indicators for system relevant behaviours is remotely wise. If a behaviour is best placed inside a system indicator, my opinion is that it stay there at all times at which it is available at all. In the context of the example at hand- Banshee's volume would be present in the system indicator when Banshee is running, and available nowhere else at any other time. ___ Mailing list:
Re: [Ayatana] Windicators
Still I fail to see what actual problem(s) windicators are meant solve or in what way are they supposed to better UX. To me it seem like it's a solution in of search of a problem to solve. Mitja - Original Message - From: Mark Shuttleworth m...@ubuntu.com To: Mitja Pagon mitja.pa...@inueni.com Cc: he...@owaislone.org, ayatana@lists.launchpad.net, Carl Simpson cwd.simp...@gmail.com Sent: Monday, February 21, 2011 8:08:53 AM Subject: Re: [Ayatana] Windicators On 20/02/11 18:39, Mitja Pagon wrote: Using the example of volume control mentioned below, am I the only one who thinks windicators make little sense and are in fact bad UX. No, of course you are not the only person, there's lots of dissent, which is fine and stimulates discussion to get a better result. Follow my example. What is the added benefit of having the per-application volume control as windicator. Music players already have per application volume controls in their UIs and space gained by moving them into the window title is minimal. Are there any other benefits am missing? It would not make sense to have volume controls both inside the UI, and in the title bar as an indicator. But the suggestion of course was to let apps *move* that functionality to the indicator, not duplicate the functionality. Indicators are abstract, logical entities that are exported from the app. They can thus be useful in more general cases. For example, in the window spread views, indicators could be rendered at full size, so their semantic meaning can be scanned in the spread view. They could even be interactive in those views, allowing one to set the appropriate volume for multiple windows, quickly, in the volume example. On the other hand you are adding visual clutter to the title bar, introducing confusing behavior, as the same indicator is sometimes applications specific, other times it system wide, not to mention you are giving yourself additional technical problems to solve and thus requiring more resources. All of this are negative implications of this idea. Giving technical problems to solve is called challenging the engineers and we rather like to do that, and they rather like it too, round here ;-) As long as the work feels like it is foundational and will stick around for a long time and be used, solving hard problems is worthwhile. If you apply simple math to this you can conclude that he negatives of this idea outweigh the positives. There are some other use cases mentioned, but most of the same logic applies and as for using windicators for notifying users there is already notify-osd. Notify-OSD is purely for momentary events, not status. Indicators combine status and manipulation of the status, they are entirely different from notifications. 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
[Ayatana] semantic hide
how about this: when i did a quick unity --replace earlier today, i realized that certain launchers tucked them selves away later than all the others... while that was probably a bug.. how about semantic aka selective hiding? i would find it extremely cool to see those apps which are running disappear only a bit later than the other launchers.. this would make the launcher feel useful and smart, it would be well behaved. Another thing would be to hide the launchers even faster, when an application (window) is open maximized in the foreground. The hiding behaviour should be a bit better, it would be more polite to either be more transparent above windows and/or to hide sooner. what do you think? are there other hiding features that might be useful for the unity launchers? ___ 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:~ted/indicator-application/love-null-pointers into lp:indicator-application
Review: Approve review approve zomg its teh nul! -- https://code.launchpad.net/~ted/indicator-application/love-null-pointers/+merge/50434 Your team ayatana-commits is subscribed to branch lp:indicator-application. ___ 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:~pitti/dbusmenu/fix-annotations into lp:dbusmenu
I now merged to the new version from trunk. It seems the xml - variant change magically fixed this, and the test-gtk-shortcut-client.py test case now works perfectly; so I pushed this as well. -- https://code.launchpad.net/~pitti/dbusmenu/fix-annotations/+merge/50578 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
Re: [Ayatana-commits] [Merge] lp:~pitti/dbusmenu/fix-annotations into lp:dbusmenu
Review: Approve In the parser the annotation should be transfer full. I'll fix that and merge it in. Thanks! review approve -- https://code.launchpad.net/~pitti/dbusmenu/fix-annotations/+merge/50578 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:~pitti/dbusmenu/fix-annotations into lp:dbusmenu
The proposal to merge lp:~pitti/dbusmenu/fix-annotations into lp:dbusmenu has been updated. Status: Needs review = Merged For more details, see: https://code.launchpad.net/~pitti/dbusmenu/fix-annotations/+merge/50578 -- https://code.launchpad.net/~pitti/dbusmenu/fix-annotations/+merge/50578 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/doc-check into lp:dbusmenu
Ted Gould has proposed merging lp:~ted/dbusmenu/doc-check into lp:dbusmenu. Requested reviews: DBus Menu Team (dbusmenu-team) For more details, see: https://code.launchpad.net/~ted/dbusmenu/doc-check/+merge/50657 Making it so that the documentation checks is part of 'make check'. Oh, and doing the work to make sure we pass the test ;) -- https://code.launchpad.net/~ted/dbusmenu/doc-check/+merge/50657 Your team ayatana-commits is subscribed to branch lp:dbusmenu. === modified file 'docs/libdbusmenu-glib/reference/Makefile.am' --- docs/libdbusmenu-glib/reference/Makefile.am 2010-06-10 20:20:24 + +++ docs/libdbusmenu-glib/reference/Makefile.am 2011-02-21 21:22:28 + @@ -48,11 +48,12 @@ # Header files to ignore when scanning. # e.g. IGNORE_HFILES=gtkdebug.h gtkintl.h IGNORE_HFILES= \ + dbus-menu-clean.xml.h \ + client-menuitem.h \ + client-private.h \ menuitem-marshal.h \ server-marshal.h \ - menuitem-private.h \ - dbusmenu-client.h \ - dbusmenu-server.h + menuitem-private.h # Images to copy into HTML directory. # e.g. HTML_IMAGES=$(top_srcdir)/gtk/stock-icons/stock_about_24.png @@ -88,5 +89,13 @@ #DISTCLEANFILES += # Comment this out if you want your docs-status tested during 'make check' -#TESTS = $(GTKDOC_CHECK) +TESTS = gtkdoc-in-srcdir + +gtkdoc-in-srcdir: Makefile.am + @echo #!/bin/sh $@ + @echo cd \$(srcdir)\ $@ + @echo $(GTKDOC_CHECK) $@ + @chmod +x $@ + +DISTCLEANFILES = gtkdoc-in-srcdir === modified file 'docs/libdbusmenu-glib/reference/libdbusmenu-glib-docs.sgml' --- docs/libdbusmenu-glib/reference/libdbusmenu-glib-docs.sgml 2010-06-09 16:24:31 + +++ docs/libdbusmenu-glib/reference/libdbusmenu-glib-docs.sgml 2011-02-21 21:22:28 + @@ -28,6 +28,10 @@ titleAPI Index/title xi:include href=xml/api-index-full.xmlxi:fallback //xi:include /index + index id=api-index-deprecated +titleDeprecated API Index/title +xi:include href=xml/api-index-deprecated.xmlxi:fallback //xi:include + /index xi:include href=xml/annotation-glossary.xmlxi:fallback //xi:include /book === modified file 'docs/libdbusmenu-glib/reference/libdbusmenu-glib-sections.txt' --- docs/libdbusmenu-glib/reference/libdbusmenu-glib-sections.txt 2010-06-10 16:01:53 + +++ docs/libdbusmenu-glib/reference/libdbusmenu-glib-sections.txt 2011-02-21 21:22:28 + @@ -4,6 +4,8 @@ DBUSMENU_CLIENT_SIGNAL_LAYOUT_UPDATED DBUSMENU_CLIENT_SIGNAL_ROOT_CHANGED DBUSMENU_CLIENT_SIGNAL_NEW_MENUITEM +DBUSMENU_CLIENT_SIGNAL_EVENT_RESULT +DBUSMENU_CLIENT_SIGNAL_ITEM_ACTIVATE DBUSMENU_CLIENT_PROP_DBUS_NAME DBUSMENU_CLIENT_PROP_DBUS_OBJECT DBUSMENU_CLIENT_TYPES_DEFAULT @@ -12,19 +14,21 @@ DbusmenuClient DbusmenuClientClass DbusmenuClientTypeHandler +DbusmenuClientTypeDestroyHandler dbusmenu_client_new dbusmenu_client_get_root dbusmenu_client_add_type_handler -dbusmenu_client_send_event -dbusmenu_client_send_about_to_show +dbusmenu_client_add_type_handler_full SUBSECTION Standard DBUSMENU_CLIENT DBUSMENU_IS_CLIENT DBUSMENU_TYPE_CLIENT -dbusmenu_client_get_type DBUSMENU_CLIENT_CLASS DBUSMENU_IS_CLIENT_CLASS DBUSMENU_CLIENT_GET_CLASS +SUBSECTION Private +DbusmenuClientPrivate +dbusmenu_client_get_type /SECTION SECTION @@ -37,6 +41,8 @@ DBUSMENU_MENUITEM_SIGNAL_CHILD_MOVED DBUSMENU_MENUITEM_SIGNAL_REALIZED DBUSMENU_MENUITEM_SIGNAL_REALIZED_ID +DBUSMENU_MENUITEM_SIGNAL_ABOUT_TO_SHOW +DBUSMENU_MENUITEM_SIGNAL_SHOW_TO_USER DBUSMENU_MENUITEM_PROP_TYPE DBUSMENU_MENUITEM_PROP_VISIBLE DBUSMENU_MENUITEM_PROP_ENABLED @@ -46,6 +52,7 @@ DBUSMENU_MENUITEM_PROP_TOGGLE_TYPE DBUSMENU_MENUITEM_PROP_TOGGLE_STATE DBUSMENU_MENUITEM_PROP_CHILD_DISPLAY +DBUSMENU_MENUITEM_PROP_SHORTCUT DBUSMENU_MENUITEM_TOGGLE_CHECK DBUSMENU_MENUITEM_TOGGLE_RADIO DBUSMENU_MENUITEM_TOGGLE_STATE_UNCHECKED @@ -53,9 +60,13 @@ DBUSMENU_MENUITEM_TOGGLE_STATE_UNKNOWN DBUSMENU_MENUITEM_ICON_NAME_BLANK DBUSMENU_MENUITEM_CHILD_DISPLAY_SUBMENU +DBUSMENU_MENUITEM_SHORTCUT_ALT +DBUSMENU_MENUITEM_SHORTCUT_CONTROL +DBUSMENU_MENUITEM_SHORTCUT_SHIFT +DBUSMENU_MENUITEM_SHORTCUT_SUPER DbusmenuMenuitem dbusmenu_menuitem_about_to_show_cb -dbusmenu_menuitem_buildxml_slot_t +dbusmenu_menuitem_buildvariant_slot_t DbusmenuMenuitemClass dbusmenu_menuitem_new dbusmenu_menuitem_new_with_id @@ -72,13 +83,13 @@ dbusmenu_menuitem_child_find dbusmenu_menuitem_find_id dbusmenu_menuitem_property_set -dbusmenu_menuitem_property_set_value dbusmenu_menuitem_property_set_bool dbusmenu_menuitem_property_set_int +dbusmenu_menuitem_property_set_variant dbusmenu_menuitem_property_get -dbusmenu_menuitem_property_get_value dbusmenu_menuitem_property_get_bool dbusmenu_menuitem_property_get_int +dbusmenu_menuitem_property_get_variant dbusmenu_menuitem_property_exist dbusmenu_menuitem_properties_list dbusmenu_menuitem_properties_copy @@ -88,14 +99,17 @@ dbusmenu_menuitem_foreach dbusmenu_menuitem_handle_event dbusmenu_menuitem_send_about_to_show +dbusmenu_menuitem_show_to_user SUBSECTION Standard DBUSMENU_MENUITEM
