Summary:
Otherwise the content overflows the frame when scrolling.
QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true"
Test Plan:
Before:
{F8121150}
After:
{F8121152}
Reviewers: #kwin, #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27558
Summary:
We need to schedule a workspace repaint in minimize() to ensure that
there are no ghost windows on Wayland.
Test Plan:
Make sure that window minimization effects are disabled,
minimize a window. Without this patch, you are going to see a ghost
window. With this patch, no ghost window.
Reviewers: #kwin, davidedmundson, apol
Reviewed By: #kwin, davidedmundson, apol
Subscribers: apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27516
Summary:
QDateTime::fromMSecSinceEpoch uses Qt::LocalTime by default. This involves an
expensive localtime conversion. So instead force things to use UTC, as there
is no need for timezone information when tracking durations.
This is especially noticeable on Bedrock Linux, which uses a Fuse mounted
/etc, which is slower than a plain /etc and causes quite some slowdown there.
See https://github.com/bedrocklinux/bedrocklinux-userland/issues/140 for
details.
Test Plan: The screenedge unit test still passes.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: zzag, anthonyfieroni, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27114
Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
Summary:
KDE is known for having a strong view on the client-side decorations vs
server-side decorations issue. The main argument raised against CSD is
that desktop will look less consistent when clients start drawing window
decorations by themselves, which is somewhat true. It all ties to how
well each toolkit is integrated with the desktop environment.
KDE doesn't control the desktop market on Linux. Another big "player"
is GNOME. Both KDE and GNOME have very polarized views on in which
direction desktop should move forward. The KDE community is pushing more
toward server-side decorations while the GNOME community is pushing
more toward client-side decorations. Both communities have developed
great applications and it's not rare to see a GNOME application being
used in KDE Plasma. The only problem is that these different views are
not left behind the curtain and our users pay the price. Resizing GTK
clients in Plasma became practically impossible due to resize borders
having small hit area.
When a client draws its window decoration, it's more likely that it also
draws the drop-shadow around the decoration. The compositor must know
the extents of the shadow so things like snapping and so on work as
expected. And here lies the problem... While the xdg-shell protocol has
a way to specify such things, the NetWM spec doesn't have anything like
that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with
it is that it's a proprietary atom, which is specific only to GTK apps.
Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing
anything like that would require major changes in how we think about
geometry.
Recent xdg-shell window geometry patches adjusted geometry abstractions
in kwin to such a degree that it's very easy to add support for client
side decorated clients on X11. We just have to make sure that the
X11Client class provides correct buffer geometry and frame geometry when
the gtk frame extents are set.
Even though the X11 code is feature frozen, I still think it's worth
to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize
issues. Also, because KWin/Wayland is unfortunately far from becoming
default, it will help us with testing some implementation bits of the
window geometry from xdg-shell.
BUG: 390550
FIXED-IN: 5.18.0
Test Plan:
Things like quick tiling, maximizing, tiling scripts and so on work as
expected with GTK clients.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: cblack, trmdi, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24660
Summary:
The stored buffer geometry can be useful for detecting whether the
buffer geometry has been changed.
Test Plan: Compiles.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24659
Summary:
Rename geometryBeforeUpdateBlocking in order to better reflect that it
corresponds to the last frame geometry.
Test Plan: Compiles.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24658
Summary:
In order to properly implement xdg_surface.set_window_geometry we need
two kinds of geometry - frame and buffer. The frame geometry specifies
visible bounds of the client on the screen, excluding client-side drop
shadows. The buffer geometry specifies rectangle on the screen that the
attached buffer or x11 pixmap occupies on the screen.
This change renames the geometry property to frameGeometry in order to
reflect the new meaning assigned to it as well to make it easier to
differentiate between frame geometry and buffer geometry in the future.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24334
Summary:
Currently each managed X11 client is represented with an instance of
Client class, however the name of that class is very generic and the
only reason why it's called that way is because historically kwin
was created as an x11 window manager, so "Client" was a sensible choice.
With introduction of wayland support, things had changed and therefore
Client needs to be renamed to X11Client in order to better reflect what
that class stands for.
Renaming of Client to X11Client was agreed upon during the last KWin
sprint.
Test Plan: Compiles, the test suite is still green.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24184
Summary:
So far wayland was used by internal clients to submit raster buffers
and position themselves on the screen. While we didn't have issues with
submitting raster buffers, there were some problems with positioning
task switchers. Mostly, because we had effectively two paths that may
alter geometry.
A better approach to deal with internal clients is to let our QPA use
kwin core api directly. This way we can eliminate unnecessary roundtrips
as well make geometry handling much easier and comprehensible.
The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
style use platform-specific APIs to set and unset shadows. We need to
add shadows API to KWindowSystem. Even though some internal clients lack
drop-shadows at the moment, I don't consider it to be a blocker. We can
add shadows back later on.
CCBUG: 386304
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T9600
Differential Revision: https://phabricator.kde.org/D22810
Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
Summary:
clang-tidy has a check that converts all usages of null pointer literals
to nullptr keyword. However, there's a small issue related to QFlags<T>.
Apparently, QFlags<T> has a constructor that takes a pointer and if you
pass 0 to it, clang-tidy will replace 0 with nullptr, e.g.
NET::States(0) -> NET::States(nullptr)
Even though passing nullptr is totally correct, it looks very weird.
Test Plan: Complies.
Reviewers: #kwin, gladhorn
Reviewed By: #kwin, gladhorn
Subscribers: gladhorn, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23948
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
Switch to Q_ASSERT in order to make code a bit more consistent. We have
places where both assert and Q_ASSERT are used next to each other. Also,
distributions like Ubuntu don't strip away assert(), let's hope that
things are a bit different with Q_ASSERT.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23605
Summary:
This change makes easier to refactor geometry handling in the future.
The main motivation for avoiding using geom directly is to make code
more readable and ensure that the geometry is updated only through
designated methods, e.g. setGeometry, plainResize, etc.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23072
Summary:
There are rules that have to be applied only once, e.g. every Remember
and Apply Initially rule, as well rules that need to configure the client,
e.g. size, etc. In the best scenario the compositor would evaluate such
rules when the client is about to be mapped.
This change limits window rules only to xdg-shell clients because right
now only this protocol lets compositors to intervene in the client
initialization process. Also, it makes things a bit easier for us on the
compositor side.
xdg-shell protocol satisfies most of ours requirements to implement window
rules, but not all of them. If the client is about to be mapped for the
second time and its size is forced by a rule, then compositor may need
to configure it. Currently, xdg-shell protocol doesn't have any mechanism
that a client could use to notify the compositor about its intent to map.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: fmonteiro, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19411
Summary:
All internal clients live in the x stacking order, but when such a
client is closed, it will be moved to the normal stacking order.
Given that internal clients don't specify the desired layer, they will
be moved to the normal layer, which is not really what we want because
it means that the task switcher window will be placed below docks.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D21116
Summary:
The name of Workspace::getMovingClient() method implies that the
returned value is a client that is currently being moved around
by the user, but this is of course incorrect.
Reviewers: #kwin, apol
Reviewed By: apol
Subscribers: apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D20663
This reverts commit 1e2a0028c3.
Unfortunately, we can't move clients from the above layer to the normal
layer because some of those clients have to be visible when showing
desktop, one such client for example is krunner.
CCBUG: 406101
Summary:
Implementation of the Show Desktop feature moves desktop windows to
the Above layer, but it doesn't take into account existing clients
that belong to the Above layer. If there are any, we have to move
them to a layer below (e.g. normal), otherwise those clients will be
visible when showing the desktop.
BUG: 406101
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D20153
Summary: those windows should always take all the space no matter what
Test Plan: text areas on desktop or fullscreen windows don't cause resizes anymore
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19922
Summary:
alternative approach: try to resize the winidow to make room for the keyboard.
the new input wayland protocol doesn't have anymore the overlap rectangle (and it would not be going to work with qwidget apps anyways)
in the future will probably be needed anextension to the input protocol v3 which partially gets back this, tough window resizing is needed regardless
what's missing: the resize should be "temporary" and the window should be restored to its previous geometry when the keyboard closes
Test Plan: tested with test QML code
Reviewers: #plasma, #kwin, bshah, graesslin, romangg, davidedmundson
Reviewed By: #plasma, #kwin, romangg, davidedmundson
Subscribers: nicolasfella, mart, kwin, davidedmundson, graesslin
Tags: #kwin
Maniphest Tasks: T9815
Differential Revision: https://phabricator.kde.org/D18818
Summary:
EffectsAPI explicitly says:
"On X11, the window will end up on the last window in the list" and
DesktopGrid reliaed on that.
Using the last makes sense as it means the
enterDesktop method will work for both.
Somehow in the refactors AbstractClient ended up doing the opposite.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18339
Summary:
The default implementations just return false/nullptr. The advantage of
having this in AbstractClient is that we can reduce the needed casts
from AbstractClient to Client in core as can be seen in this change.
There are more cases which can be improved thanks to this refactoring
which will follow in dedicated commits.
Test Plan: ctest passes
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17890
Summary:
As setDesktop was changed to "move" this left unSetDesktop non-symetric.
This replaces it with explicit API to enter/leave.
This also moves new API to the new object based API rather than still
using ints.
Where numbers are used it has been tidied up so that desktop IDs are
uint, which should be used when we have a list of desktops.
int is used only when we have either a desktop ID or NET::OnAllDesktops
(-1)
Effects API cleared up to use this and use a set of x11 IDs, which
avoids any potential complications of handling add and removes any
ambiguity with what happens if you leave all desktops and such.
Test Plan:
testVirtualDesktops passes (with pending kwayland patch)
Moving a window in the desktop grid on X11 behaves
Moving a window in the desktop grid on wayland behaves
Reviewers: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16704
Summary:
Currently setDesktop and unsetDesktop were out of sync, with the latter
missing several important signals and updating of transients.
By using a a shared implementation we avoid that, it also allows for an
atomic move of a window between desktops.
setDesktop is changed back to be a moval of desktop as it currently
broke several unit tests as well as changing the behaviour of the move
to desktop shortcut on wayland.
Test Plan:
testBindings now passes
Moved windows with the context menu on X11
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16703
Summary:
If you resize a decorated client by using the resize user action(press
Alt + F3 > More Actions > Resize), then KWin will crash because it gets
stuck in an infinite loop (AbstractClient::performMoveResize <->
ShellClient::setGeometry).
Here's how KWin gets stuck in that loop:
* when you finish resizing the client, AbstractClient::keyPressEvent
will call AbstractClient::finishMoveResize;
* the first thing that finishMoveResize does is block geometry updates,
then it does some clean up (e.g. reset the value of isMoveResize(), etc),
updates the geometry of the client and when it's done, it will emit
clientFinishUserMoveResized signal;
* when PointerInputRedirection notices that signal, it will call
processDecorationMove on the client, which in its turn will indirectly
call AbstractClient::startMoveResize;
* when it's time to go back to AbstractClient::keyPressEvent, geometry
updates are unblocked and if there are any pending geometry updates,
then ShellClient::setGeometry will be called;
* ShellClient::setGeometry will eventually call ShellClient::doSetGeometry;
* ShellClient::doSetGeometry will call AbstractClient::performMoveResize
because AbstractClient::processDecorationMove indirectly called
AbstractClient::startMoveResize;
* AbstractClient::performMoveResize calls ShellClient::setGeometry;
* (at this point, KWin got stuck in the infinite loop)
This change swaps setMoveResizePointerButtonDown and finishMoveResize,
so processDecorationMove won't indirectly call startMoveResize.
BUG: 397577
FIXED-IN: 5.14.4
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16846
Summary:
Doesn't have any meaningful impact. It's the same performance when T is a pointer,
but it'll bring it consistent with VirtualDesktopManager::desktops
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16736
Summary:
implement virtual desktop support for Wayland.
use the new virtual desktop protocol from D12820
The VirtualDesktopManager class needed some big change in order
to accomodate it, which is where most changes are.
Other than that, it's mostly connections to wire up
VirtualDesktopsManager and VirtualDesktopsManagement(the wayland protocol impl)
Depends on D12820
Other notable detail, is the client visibility updated to reflect the presence
of the client in the plasmavirtualdesktop.
(and the unSetDesktop concept)
Test Plan: used a bit a plasma session together with D12820, D13748 and D13746
Reviewers: #plasma, #kwin, graesslin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: hein, zzag, davidedmundson, kwin
Tags: #kwin
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D13887
Summary:
Support XDGShell Positioning. This gives a client a lot more control
over where the popup will be placed as well as control over how to
handle constraints. i.e what to do if the popup doesn't fit.
trasientOffset was replaced with a method on the client as semantically
it's the role of the client to handle constraints.
Both slide and flip constraint adjustments are implemented. Resize
constraint adjustment will be handled in a future patch.
WlShell is handled by treating it as 1x1 sized anchor with slide
constraint adjustment.
Test Plan:
Manual test of a client implementing xdgpopup exists in kwayland
Extensive unit test here
Existing WlShell test passes (after D16314 which fixes the original)
XdgPopup has a new unit test suite against manually calculated values
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16325
Summary:
This exposes colorScheme as a property which is then usable by kwin
scripts.
Wanted by T9769.
Test Plan:
Michail to test in a script.
Reviewers: #kwin, zzag, graesslin
Reviewed By: #kwin, zzag, graesslin
Subscribers: mvourlakos, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15913
Summary:
The change to make maximize mode asynchronous featured the comment
>Things are a bit complex with borders. Technically we
>shouldn't update them till we get a response, but we also need to have
>the correct geometry of the full size window in our request. For now
>they behave as before, updating when we request the change.
We call setNoBorder when we request the geometry but decoratedClient
also checks the maximise mode, in order to follow the scheme above we
need this to operate on the requested state not current state.
X is unaffected.
This fixes the borders being restored correct after maximize/restore.
Test Plan:
Chose a theme with visible borders
Maximised a window and back
They restored
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15991
Summary:
Instead of seeing the cursor <--> on the left edge you now see an icon
that looks like |<- .
This brings kwin decorations in line with GTK CSD icons.
In theory this is also useful to tell which window will resize in the
case of side-by-side windows (regardless of whether borders are on or
not). In practice with the adwaita icon theme I tested with it's not
very intuitive to realise which is which till you learn the icon.
Change is more involved than it should be as Qt::CursorShape doesn't
have these entries, and I don't want to shadow that enum internally or
have
to change kwin effect code.
Specifics depend on cursor icon theme if they are not present it will
fallback to the <--> icon. (Breeze does not have them currently)
Test Plan:
Resized some windows (on X and on Wayland)
Correct icon appeared on Adwaita
Existing icon appeared on Breeze
Reviewers: #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13396
This reverts commit 8a2a00a4ca.
It was likely wrongly pushed before the KWayland changes, so it won't
compile.
Feel free to reinstate it once the dependent changes (KWayland) are in.
CCMAIL: bundito@gmail.com
CCMAIL: kwin@kde.org
Summary:
Adding "SkipSwitcher" to the API, following discussion in
BUG 375921
Depends on / related to D11925 and D11924
Reviewers: hein, #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: davidedmundson, #plasma, ngraham, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11926
Summary:
This allows to override the desktop file name.
CCBUG: 351055
Test Plan: Created a window rule for telegram-desktop to fix the icon
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11266
Summary:
There's a call to a virtual doSetSkipPager for performing this call and
Client implements it with the code which now is removed.
This fixes a crash when using setSkipPager for a Wayland window.
Test Plan:
Crash which happens with a new test case (see dependent phab
request) is fixed.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9865
Summary:
So far a not-active fullscreen X11 window was kept in the active layer if
the newly activated window is in the same group (that is same client
leader). For example a fullscreen X11 kwrite window is in the active layer
if another kwrite window is active. The two kwrite windows obviously
don't have anything to do with each other, but are in the same group.
This creates problems as it's not possible to raise other windows above
the active not-fullscreen kwrite window. E.g. the panel is stacked below.
The idea behind the check makes sense: if a fullscreen window opens
another window (e.g. a configuration dialog) it should not be put back
to normal layer. Thus the check is adjusted whether the new active
window is a transient to the fullscreen window. Thus the intention is
still the same, but does not cause the problems.
As the code now does not need to differentiate between X11 and Wayland
windows (group only on X11) the Client specific implementation is
removed and the method unvirtual'ed.
BUG: 388310
FIXED-IN: 5.12.0
Test Plan: Test passes
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9699
Summary:
Commit 5d9027b110 introduced a regression in TabBox by using the generic
framework inside KWin to test for same application. What I did not
consider was that the code in TabBox was "broken by design". It didn't
use the generic check as that is too strict and considers windows from
different processes as not belonging to the same application. But this
is not wanted in the case of TabBox.
On the other hand the change itself is an improvement to also support
Wayland in a better way and not have special handling situations. Thus
just reverting would not help.
Instead this change addresses the problem by extending the internal API
and to allow more adjustements. So far there was already an
"active_hack" boolean flag. This is extended to proper flags with an
additional flag to allow cross application checks.
The checks in Client which would filter out different applications check
for this flag and are skipped if set. In addition ShellClient also adds
support for this flag and compares for the desktop file name.
Thus we get in TabBox the same behavior as before with the advantage of
having a better shared code base working on both X11 and Wayland.
BUG: 386043
FIXED-IN: 5.11.4
Test Plan:
Started two kwrite processes on X11, clicked new in one of them,
used Alt+` and verified that there are three windows shown.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8661
