| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Conventionally, the applets on a MATE Panel are positioned relative to the
left edge of the panel (if the panel is horizontal) or the top edge (if the
panel is vertical). There has also been some (buggy) support for positioning
of applets relative to the right (or bottom) edge of the panel, so that
applets on the right side of the panel will stay on the right side even if
the user changes screen resolutions or if the panel changes size for some
other reason.
However, many users want to also place applets at or near the center of their
panel(s). There is no such conventional support for positioning applets
relative to the center of the panel, so users have positioned applets near
the center of the panel -- but the position recorded is relative to the left
side of the panel. As such, the applets will almost certainly shift over
to the left or right slightly if the panel is ever resized, and the user will
have to reposition all those centered applets yet again. This is especially
frustrating if the user switches monitors on a regular basis!
This patch radically revamps the MATE Panel's positioning framework, and
deprecates the original "right-stick" feature. To replace the right-stick
feature, this patch instead associates an "edge relativity" setting with
each and every panel applet: An applet can be relative to the start (left/
top), end (right/bottom), or center of the panel. This setting can be
changed using DConf/GSettings, using a custom panel layout file, or even
by simply dragging the applet to the appropriate place on the panel.
(Conventionally, applets are not even right-stuck automatically even when the
user drags the applet over to the far right of the panel!) As a bonus, when
the user drags an applet across the center of the panel, the applet will
temporarily "stick" to the very center of the panel, to allow the user to
very precisely align any applet they wish.
|
|
|
|
|
|
|
|
|
|
|
|
Don't propose actions that will fail anyway, and create a launcher
automatically if it's the only option. However, still ask for setting
the background to still avoid unintentional changes.
|
|
Instead of unconditionally setting the panel's background when an image
file URI gets dropped on a panel, ask the user whether to create a
launcher for that URI (like for non-image URIs) or to use the image as
the panel's background.
A number of users have seen their panel's background changed
unexpectedly due to unwanted drop of an image file over the panel,
sometimes seeing this as a panel's bug.
Also, this behavior is inconsistent with dropping a URI pointing to any
other type of file, where it would create a launcher for it.
Consequently, and as setting the panel's background doesn't seem like a
so common task it ought to be super fast, ask the user what to do when
receiving an image URI drop.
|
|
It doesn't make any sense to set the panel's background several times
if we get multiple image URIs dropped, so don't consider multi-URI
drops as candidate for setting the background, and handle those like
other non-image URIs.
|
|
|
|
|
|
|
|
g_file_query_info can return NULL. Use g_clear_object to make
sure we don't try to unref NULL pointer.
Origin commit:
https://github.com/GNOME/gnome-panel/commit/73fa9808f24ee6a95e12a8558d6b1f6513b78693#diff-5f461c83a31d7792b939f3a1be40c512
|
|
|
|
|
|
|
|
|
|
and require libmate-desktop >= 1.17
WARNING: use GTK+3 build of libmateweather for this build.
that lib is not migrated to GTK+3 only as we will possibly
use libgweather instead of it.
|
|
panel.c
|
|
|
|
(libmate-panel-applet files are left alone since there are public
header files used by all panel applets)
|
|
|
|
The new GDK_KEY_ keys are also in Gtk+2.
|
|
Closes https://github.com/mate-desktop/mate-panel/pull/268
|
|
fix segfault when gtk_get_current_event return null
fix memory leak: gtk_get_current_event return value must be freed
Closes https://github.com/mate-desktop/mate-panel/pull/243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
