Andrzej authored 12 years ago and Nick Schermer committed 12 years ago

(cherry picked from commit 0f546d7384ad0fde00f496df087efe0826a09bc7)

This add a difference to the panel and plugin submenu,
but it is better then nothing.

Return to the client if a plugin event was handled.

Andrzej authored 13 years ago and Nick Schermer committed 13 years ago

Problem:

get_requisition on external plugins returns an old size_request
value when the size of the panel is changed quickly (e.g. when
user controls the "size" slider using cursor keys).

In case of "small" external plugins this means that they are
"losing" their "small" status when the user quickly decreases
the panel size. This is because their get_requisition size
is temporarily larger than the row size. This in turn causes
a lot of flicker when the user changes (decreases) the panel size.

(the above was tested using an xfce4-mixer plugin with a patch from:
https://bugzilla.xfce.org/show_bug.cgi?id=8350 )

Arguably, the itembar doesn't have to check the plugin size, only
the "small" flag. It's then the plugins responsibility to render itself
in such a way it fits in a single row.

The itembar is still using the plugin size to decide the row height.
It may temporarily be incorrect when the panel size changes quickly
but that doesn't cause flicker.

Andrzej authored 13 years ago and Nick Schermer committed 13 years ago

When a shrinkable plugin was shrunk too much it was
given an allocation area equal to the requested area.
In such case we'd rather want it to stay at a minimum
size (child_len=1px, which is set immediately below).

(cherry picked from commit 4f0b035f64a06dbb1f410ca38390c7146df39c99)

Andrzej authored 13 years ago and Nick Schermer committed 13 years ago

(cherry picked from commit 4c86ea04a09c2c6770059f3a3f4ac720673ca7d8)

This can lead to problems if the window is destroyed
when the signal still connected: the configuration is
lost. Do this explicitly in a function, so this problem
never occurs.

The dialog was realize too soon, so the hidden widgets
make it grow for no reason.

Also remove auto save from the session mananger and
improve what is saved.

The panel is saving everything when the configuration
changes, so no need to do that in an interval and during
exit. It can only lead to data loss.

Give each panel a unique id that does not change over
its lifetime. This should prevent most of the problems
where panel configuration is lost or strange resets when
a panel is removed from the preferences dialog.

If it happens the panel looses some settings and the position
string is also lost, it won't be visible on the next restart.
Make sure the position is set, if it is not restored, set something
new. Although this is not the position the user defined, it is
better then no panel at all.

Andrzej authored 13 years ago and Nick Schermer committed 13 years ago

(cherry picked from commit 22b63ca5d140a1210a74079b42ef164891e19d8d)

Based on a patch of Andrzej.

This makes it easier to understand in the code, only
a single option of expand/shrink/small works property.

Also warn if a plugin tries to enable 2 of them.

This will be replaced by the nrows property.

Andrzej authored 13 years ago and Nick Schermer committed 13 years ago

This properly will be used to pack a plugin only on a single row instead
of the whole panel height.

Instead of the horizontal property, there is now a mode property
with 3 values. The orientation communication has been completely
removed, only the properties exist.

Properly migrate the orientation property.

Plugins and the panel should not act any different with this commit.

This allows to update the configuration for new plugins.

Instead of hiding the compositing settings, make them
insensitive and show an info bubble how to enable
the settings.

See https://bugzilla.gnome.org/show_bug.cgi?id=576492.