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

Gtk3 plugins (e.g. xfce4-indicator-plugin/master) are not recognized
(treated as gtk2 ones).

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

Addeding X-XFCE-API to the plugin .desktop files to determine which
wrapper to use. This falls back to 1.0 wrapper for compatibility with
the current plugins.

Conflicts:
	panel/panel-module.c
	panel/panel-plugin-external-wrapper.c

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

Requires a gtk3 version of libxfce4-panel and wrapper to be compiled
from another branch.

This commit is only a quick hack to make the plugins to load.
It should be reworked (starting from better naming) for a release
version.

Better wrt grab and stuff.

Save every 10 minutes and on shutdown.

Give it a better name too, since insensitive panels are long
gone.

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.