Only queuedraw and return true if value really changed (likely to happen, but nicer to see :)).
Also, in PanelMenuView you added a new var "menu_bar_visible_"... We already had show_now_activated_ for this purpose... I'm not sure if them might clash here, but what about just using one?
Also, to make the panel show the menu items correctly underlined, each PanelIndicatorEntry should have the show-now state...
251 + current_action_id_++;
Prefixed increment?
261 + CompAction& added(actions_.back());
Mnh, this is needed to access to the reference of it?
As I'd just use action instead... But maybe compiz definitions makes things harder.
262 + if (grabs_by_binding_[added.key()]++ == 0)
263 + screen_->addAction(&added);
A little hard to read... Probably using (with proper spacing):
auto& grab = grabs_by_binding_[added.key()];
if (grab == 0) { screen_->addAction(&added) }
++grab;
Auto is your friend here...
auto i = action_ids_by_action_.find(&action);
And everywhere we have iterators or complex or duplicated types (like A = new A()), just use it.
283 + if (--grabs_by_binding_[j->key()] == 0)
284 + screen_->removeAction(&*j);
As before... Also this &* thing is not the best to see...
248 +unsigned int GnomeKeyGrabber::Impl::addAction(const CompAction& action,
249 + bool addressable)
As for general style, we generally try to keep method names (with parameters) in just one line, unless it really becomes too long (where "too long" is not exactly specified) :P
Also we use Type const&, not const Type&...
Mh, I'm not a fan of using non-smart pointers in stl containers, even though action_ vector is the owner... Could be possible to use something better than pure pointers here?
Can you also unit-tests for GnomeKeyGrabber (in the same way I did for GnomeSessionManager)?
Also I'd move the whole KeyGrabber thing on a separate library/folder... That links with unity-shared-compiz.
action(_info)_by_entry would be a better name imho.
However, as for general design thing... Whouldn't be possible to handle the Activation, and registration of actions inside unity itself (instead of doing the work by dbus)? I know it's the standard way at this point, but maybe it would have kept the panel service simpler...
+bool PanelMenuView: :SetMenuBarVisi ble(bool visible)
75 +{
76 + menu_bar_visible_ = visible;
77 + QueueDraw();
78 + return true;
79 +}
80 +
Only queuedraw and return true if value really changed (likely to happen, but nicer to see :)).
Also, in PanelMenuView you added a new var "menu_bar_ visible_ "... We already had show_now_activated_ for this purpose... I'm not sure if them might clash here, but what about just using one?
Also, to make the panel show the menu items correctly underlined, each PanelIndicatorEntry should have the show-now state...
251 + current_ action_ id_++;
Prefixed increment?
261 + CompAction& added(actions_ .back() );
Mnh, this is needed to access to the reference of it?
As I'd just use action instead... But maybe compiz definitions makes things harder.
262 + if (grabs_ by_binding_ [added. key()]+ + == 0) ->addAction( &added) ;
263 + screen_
A little hard to read... Probably using (with proper spacing): binding_ [added. key()]; ->addAction( &added) }
auto& grab = grabs_by_
if (grab == 0) { screen_
++grab;
270 + std::map<const CompAction*, unsigned int>::const_ iterator i(action_ ids_by_ action_ .find(& action) );
Auto is your friend here... ids_by_ action_ .find(& action) ;
auto i = action_
And everywhere we have iterators or complex or duplicated types (like A = new A()), just use it.
283 + if (--grabs_ by_binding_ [j->key( )] == 0) ->removeAction( &*j);
284 + screen_
As before... Also this &* thing is not the best to see... ::Impl: :addAction( const CompAction& action,
248 +unsigned int GnomeKeyGrabber
249 + bool addressable)
As for general style, we generally try to keep method names (with parameters) in just one line, unless it really becomes too long (where "too long" is not exactly specified) :P
Also we use Type const&, not const Type&...
315 + g_variant_ builder_ init(&builder, G_VARIANT_ TYPE("au" ));
This is, fine... But for your convenience you can use glib::Variant: :FromVector for generating arrays such this...
action. setInitiate( boost:: bind(&GnomeKeyG rabber: :Impl:: actionInitiated , this, _1, _2, _3));
std::bind? Or probably you can just use lambdas here, as they improve readability for small cases such these ones.
568 + std::map<const CompAction*, unsigned int> action_ ids_by_ action_ ; by_action_ id_;
569 + std::map<unsigned int, const CompAction*> actions_
Mh, I'm not a fan of using non-smart pointers in stl containers, even though action_ vector is the owner... Could be possible to use something better than pure pointers here?
Can you also unit-tests for GnomeKeyGrabber (in the same way I did for GnomeSessionMan ager)?
Also I'd move the whole KeyGrabber thing on a separate library/folder... That links with unity-shared- compiz.
938 + priv->info_by_entry = g_hash_ table_new_ full (NULL, NULL, NULL, action_info_free);
720 + <option name="show_ menu_bar" type="key">
Since this will clash with Hud reveal key, could you include in both descriptions that one is a "Tap", while the other is a key-press?
808 + PanelService *service;
As panelservice uses a singleto, I think you don't need to pass the service to every entry... Just use the global instance.
938 + priv->info_by_entry = g_hash_ table_new_ full (NULL, NULL, NULL, action_info_free);
action( _info)_ by_entry would be a better name imho.
However, as for general design thing... Whouldn't be possible to handle the Activation, and registration of actions inside unity itself (instead of doing the work by dbus)? I know it's the standard way at this point, but maybe it would have kept the panel service simpler...