--use a different shadows manager for dialogs such as
dock settings window through the Latte::Corona class.
The new shadow manager is responsible to draw
"dialogs/background" shadows for windows instead of
the PanelShadows original class which is responsible
to draw "widgets/background" shadows
--identify better what is the plasma theme color
palette the creator has chosen and use ALWAYS
the same color palette that Plasma is also using.
In the past, Latte was trying to protect the
color palette because Latte REVERSED colors mode
did not work fine for all plasma themes. That
approach is abandoned, Latte will use the same
colors group with plasma themes and it is on
the creators responsibility to provide enough
contrast
--provide a new way to identify which application
launcher has the highest priority in order to be
triggered. When an application launcher applet
has a global shortcut assigned to it then that
application launcher applet has the highest
priority in order to be triggered through
"Super" global key.
--fix showing advanced settings window in order to update
the window geometry ONLY WHEN there are availableScreenGeometry
changes from Latte::View(s).
--As a side effect changing docks/panels location under wayland
when they have enabled their background blur has reduced crashes
during location changes.
--for floating views the hide timer can do
the trick about when to make the checks
that the view must become hidden. In floating
views should support different default and
current value because it should be greater
that the normal use cases.
--improve the new worksarounds in order to always
apply the activities that a view and its windows are
present when the workarounds were triggered from
kwin faulty behavior. The kwin faulty behavior is
that when any activity is paused then all Latte::Views
become hidden and lose their activities references.
The workarounds are timers that when they trace
a faulty visible state !visible are restoring the
normal behavior to views.
--trying an alternative approach concerning real floating
Views and screen edge triggering. In such case the user
has triggered to show a REAL FLOATING VIEW, it is considered
normal from user point of view for the view to remain shown
until there is windows changed state or the mouse has
escaped the View main window area
-- when the user hovers the screen edge there is a chance that
screenedgeghostwindow has become underneath the view. In such
case when the real floating window slides in the screenghostwindow
becomes unhovered faulty and it is destroyed afterwards. It is
much better if the screenedgeghostwindow in such case remains shown
until the mouse is not contained neither in the view or the screen
ghost window
-- expose screen edge ghost window thickness
--when the floating view is a real panel window and
slides out-in with real animation if the user keeps
its mouse on the screen edge the view can remain
shown without sliding out
--when dock settings window is shown it is good to
NOT overlap with plasma panels. Under X11 this is
possible because the real availableScreenGeometry
is exposed through QScreen.
--indicators are now tracked only based on their
installation path, that means that are updated
more precise when changes are applied and
at the same time views are recreated only when
the show the specific indicator that was changed
--improved settings for Floating windows in Behavior
tab and add a new option to hide ALL screen gaps meaning
both length screen and thickness screen gap when there
is a maximized window in the screen
BUG:415630
--following the new design applied first at
View:availableScreenRegionChangedFrom instead of different
View parts to trigger directly m_corona relevant signal,
all View parts are triggering the View relevant signal
and as such the can be disabled all together
easily.
--set a minimumLength in order to avoid the indicator
to become TOO SMALL and not noticable. The minimum
length has been set to be 25% of the screen edge length
that the view as attached.
--when as Always Visible view was unloaded from
a CentralLayout because its Activity was closing
it was creating a crash. This patch fixes the
situation by releasing sensitive view signals
earlier.
Summary:
- Add `Configure Latte Global Settings...` because it's too hidden in Layout > Configure and does not relate to the Layout menu.
- Insert a new `Separator` to separate between Global settings and View settings (see screenshot)
- Rename `Panel/Dock Settings` to `Edit Panel/Dock` (Verb + Noun)
- Rename `Layout > Configure...` to `Layout > Manage Layouts` (Verb + Noun)
Menu Items Order:
a. -separator-
b. Layouts->
c. Configure Application...
e. -separator-
f. Add Widgets...
g. Edit Dock...
h. -separator- [only for Tasks plasmoid]
i. Close... [only for Tasks plasmoid]
BUG: 415584
Test Plan:
Before:
{F7844554}
After:
a. context menu of applets
{F7845184}
b. context menu of a task that hasn't/has one window shown
{F7844944}
{F7845185}
c. context menu of Latte Tasks plasmoid when used on the desktop
{F7845186}
{F7845187}
Reviewers: #latte_dock, #vdg, mvourlakos
Reviewed By: #latte_dock, mvourlakos
Subscribers: ngraham, ndavis, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26238
--app is crashing if we set for Latte::Views
KWin visibility mode to WindowsCanCover because
Latte is hiding its Views at some animations.
In such case only the KWin AutoHide mode allows
that, otherwise it is crashing.
--when the application launcher is not a popup then
we do not have to wait for the dock show we can execute
the activation code immediately
--when Latte activates an entry can now understand
if a popup is going to be shown in order to delay
the execution. If a popup is NOT going to show either
for a latte task or an applet then the code is executed
immediately
BUG:415417
FIXED-IN:0.9.6
--all the qml handling code from globalshortcuts is
now moved to Latte::View::ContaimentInterface. This
way the code is cleaner and can be expanded easier.
--Latte panels when they touch each other are informing
each other in order to provide consistent appearance. For
example the Unity mode where a top panel and a left panel
exist at the same time. In such case if the left panel is
INBUSY background state then the top panel is informed and
because inBusy state also. This way the top border of left dock
background does not look out of place. ON THE OTHER hand if
the left dock is hidden because the use has chosen auto-hide
visibility mode or any of the dodge(s) choices then the top
panel does not have to stay in isBusy state. The patch fixes
this by applying this behavior only when the left dock is shown
e.g. the mouse has entered the dock or the dodge mode is not
activated
BUG:415347
FIXED-IN:0.9.6
Michail Vourlakos
Johnny Jazeix
Tranter Madi