John Lindgren authored 10 years ago and Olivier Fourdan committed 10 years ago

Bug: 11058

The logical screen width/height as reported by X may be larger than
the outer bounds of all the monitors combined.

Compute the actual outer bounds of the monitors and place the panel
accordingly.

But keep the struts based on the logical screen width/height as this is
what the standard expects.

This reverts commit 75ed12ce.

After closing the panel preferences, the panel was always hidden when
intelligent autohiding was selected. This patch adds a check whether the
currently active window actually overlaps with the panel and only hides
it in case it does.

ochosi:
"Just to document the findings I made during a quick debug session
with the panel from git master (4.11.x). Intelligent hiding
generally works, but the mouse-pointer behavior is buggy.
Steps to reproduce the bug:
1) set panel to intelligent hiding
2) give a window focus that doesn't overlap with the panel
3) hover the panel with the mouse
4) upon leaving the panel hides again, even though there
   is no window overlapping

What it should do instead: if intelligent hiding is in use
it should check (possibly in panel_window_leave_notify_event
or _enter_ in panel-window.c) whether there are windows
overlapping with the panel and if not, the panel shouldn't
hide on leave_notify."

This configuration option only makes sense when not hiding a panel
automatically, so whenever one of the two autohide behaviors is enabled,
the option is now greyed out in the UI.

Instead of a single "Show/hide panel automatically" check box, we now
use a "Automatically hide the panel" combo box with the options "Never",
"Intelligently" and "Always".

We could write a migration script for it to avoid additional code being
added to the panel itself but the solution presented here is simple and
works: when a panel is created (e.g. during startup), we check whether
there is an old "autohide" property in the Xfconf channel. If the new
"autohide-behavior" property is not yet set, we translate "autohide"
FALSE and TRUE into "autohide-behavior" NEVER and ALWAYS, respectively.
We then reset the "autohide" property and thereby achieve an automatic,
transparent migration from old to new.

This implementation of intelligent autohiding works as follows:

The current WnckScreen is monitored. Whenever the active window changes
or whenever the geometry of an already active window changes, the
algorithm checks whether the active window and the panel overlap. If
this is the case, the panel is hidden. Otherwise, it is made or remains
visible.

Desktop windows are treated special. Even though they overlap
with panels technically, we don't consider this relevant and always make
the panel visible when a desktop window becomes active.

Internally, there are three autohide behaviors now: never (disables
autohiding altogether), intelligent (implements the above method) and
always (the old "hide when not focused/grabbed by mouse or keyboard).

This will be needed for intelligent autohiding, which is implemented by
monitoring the current WnckScreen for active window changes and hiding
the panel whenever the active window geometry overlaps with the panel.

visible at the new position

(Raphael Groner <projects.rg{at}smart.ms>)

+ some cleanup.

Arnout Engelen authored 11 years ago and Nick Schermer committed 11 years ago

This is for window managers to tell them a pager or tasklist
requested the action.

Start-up crashes of external plugins resulted in API being not set properly,
Then, the panel was trying to use a non-existing "wrapper" binary.
This prevented normal crash reporting mechanism from working and resulted
in an "empty" plugin being inserted into the panel.

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.