- adds the kcm rule option to set the activity - one or all option like
for virtual desktops
- makes the windows obey the rule
- makes the rule enforced even when the user tries to change the
window's activity via the alt+f3 menu
REVIEW:104972
Behavior is now like all xinerama related options are enabled.
There seems to be no valid reasons to run multi screen without
xinerama support and even if a user would wish to do so she can
just disable xinerama in xorg.conf.
Furhtermore thanks to KWin scripting it is possible to achieve the
behavior as it used to be with the options disabled. E.g. it is
possible to span a window in fullscreen mode over all screens.
This change is in accordance to the discussion on kwin and plasma
mailinglists:
http://mail.kde.org/pipermail/plasma-devel/2012-January/018542.html
Unlike stated at several places in the code it is not difficult to
setup the connections to all Clients.
It would have been nice if the failed attempts to connect the Clients
would not have made it into the code as emitted signals which are
nowhere used. Not to mention that like in all places the signals to
inform that a state changed were emitted before the state changed was
performed.
I did something wrong. The recent four fixes for klipper bugs were
cherry-picked from master into KDE/4.8. So they appear twice in the
merged history.
Conflicts:
klipper/urlgrabber.cpp
Maximization of oversized windows must happen BEFORE keepInArea() is called
because that will through resizeWithChecks() lead to an artificial constrainment
to the WorkArea which is the combination of all screens minus all struts
this fails if only one screen struts and as a result the window is no more
bigger than FullArea which is used as maximization enforcing condition.
(Maximization must also happen AFTER placement, because otherwise the window
will eventually be maximized to the wrong MaximizeArea - Screens(s) - (local) struts
depending on xinerama settings)
BUG:285967
CCBUG:286146
CCBUG:183694
FIXED-IN:4.8
This input-only window is used to capture events above the
client window and preventing them from reaching the client.
It is currently used to enlarge the borders by an invisible
amount, using the ExtendedBorderRegion provided by the
decoration.
This patch implements an XProperty named _KDE_NET_WM_OPAQUE_REGION
which gives the compositor the information which part of a window
is opaque although it is an ARGB visual. The basic ideas are from
http://www.mail-archive.com/wm-spec-list@gnome.org/msg00715.html
Additionally the patch makes kwin use this information to do a better
clipping in Scene::paintSimpleScreen which should result in a higher
performance.
REVIEW: 102933
It is possible that adding this build option broke the Scripting
component. This is something that should not happen. Unfortunately
by just ifdefing everything scripting related with scripting enabled
we have build errors. These are caused by the fact that the scripting
code includes e.g. client.h through "./../client.h". At one offending
place I changed that to "client.h", but there is also a client.h in
the scripting directory.
The includes and naming of the scripting files clearly have to be fixed!
Since the funtionality of TopMenu did no longer work in KDE4 this feature was
removed from Workspace. Every reference to it was removed as well as commentaries
and documentation.
REVIEW: 101485
- plasma extenders (callendar etc.)
- applet browser, activity manager
- programs like chromium - since there's no border, there is
no obvious way of moving them between activities.
(alt+f3 menu is not commonly known)
svn path=/trunk/KDE/kdebase/workspace/; revision=1196797
the new property name is "_KDE_NET_WM_ACTIVITIES", of type XA_STRING,
and it's a comma-separated list of activity UUIDs.
kwin should respond to other processes changing the activity list for a
window, and filter out any bogus IDs. It also caches KActivityController's
list of activities to prevent dbus deadlocks.
CCMAIL: plasma-devel@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=1179043
Every disorder causes every duration, which ensures the one that stays.
reality is relative. natural is disorder.
[R]obinhood[P]andey
Merging scripting from
^/branches/work/kwin_scripting TO
^/trunk
svn path=/trunk/KDE/kdebase/workspace/; revision=1177865
It still crashes when kwin is restarted with a shade group (same backtrace, but needs a different fix).
CCBUG: 242206
svn path=/trunk/KDE/kdebase/workspace/; revision=1140342
where the titlebar is still clickable even if it is outside the normal
work area. When struts are added or removed only move the windows that
cover the same area, leave all others untouched. If a strut is removed
on a xinerama screen that is not on the edge of the full desktop area
prevent the windows from being moved offscreen. Prevent struts/panels
from interfering with the movement of windows on other xinerama screens.
BUG: 74559
BUG: 90833
BUG: 160068
svn path=/trunk/KDE/kdebase/workspace/; revision=927466
- the NormalState/IconicState things in ICCCM need to match exactly
the real mapping state, so ensure that, no matter how superfluous that is
- extend the option for having live window previews either for all
windows or for only all shown windows (default)
FEATURE: 163385
svn path=/trunk/KDE/kdebase/workspace/; revision=845772
but it was internall optimized away (e.g. one group transient plasma
dialog open, minimized, open another group transient dialog from plasma).
svn path=/trunk/KDE/kdebase/workspace/; revision=798569
and set by the user - they're now interchangeable. Which means
that Alt+F3/Advanced/No border can put the window decoration
back on the KRunner window regardless of what Plasma or any other
app thinks.
svn path=/trunk/KDE/kdebase/workspace/; revision=788964
being v2+ (right now it says just GPL, which according to GPL itself
means any GPL). Decoration clients will come later.
CCMAIL: kwin@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=742302
r603296 | lunakl | 2006-11-08 15:09:06 +0100 (Wed, 08 Nov 2006) | 3 lines
One change that was supposed to go with r603295.
svn path=/trunk/KDE/kdebase/workspace/; revision=659309
even with stable 8776 nvidia drivers (the beta ones lock up on me
from time to time with multiple X running).
svn path=/branches/work/kwin_composite/; revision=597767
work in the work/kwin_composite branch.
svn merge revs 558154,558180,558236,558243,558258,562201
svn path=/trunk/KDE/kdebase/workspace/; revision=571776
besides drawing what should be drawn anyway, and there are
still some things missing like stacking order for override
redirect windows, but KWin is basically a compositing manager now.
svn path=/branches/work/kwin_composite/; revision=558168
If you want KWin to obey the app's idea of what fullscreen geometry might be
just force obeying strict geometry in the workarounds tab in window-specific
settings.
svn path=/trunk/KDE/kdebase/workspace/; revision=514433
svn+ssh://coolo@svn.kde.org/home/kde/branches/work/kde4/kdebase
.
I couldn't resolve one kicker conflict that results from different
development directions, so I rely on Aaron to sort it out - the file
is commited with conflicts
svn path=/trunk/KDE/kdebase/kwin/; revision=439627
it manually all the time using setGeometry( geometry()).
Needed for getting geometry of the damn shaded windows right
finally.
svn path=/trunk/KDE/kdebase/kwin/; revision=423506
to also set some things only temporarily. E.g. in order
to set skiptaskbar flag on a window, it's just
Alt+F3/Advanced/Special Window Settings/Preferences ->
Apply Now for Skip taskbar, and turn on the checkbox.
svn path=/trunk/KDE/kdebase/kwin/; revision=423112
feature to KWin. There shouldn't hopefully be any visible user
difference other than fixed bugs.
BUG: 78109
BUG: 99524
svn path=/trunk/KDE/kdebase/kwin/; revision=413066
type means anyway, let's simply consider it to be a legacy way of saying "noborder"
and nothing more.
svn path=/trunk/KDE/kdebase/kwin/; revision=412372
policy for dialogs if they request a specific geometry. Too bad apps
always specify geometry for dialogs, so if they specify silly positions
like under mouse or centered on the screen the only solution for now
is choosing ignoring requested position in window-specific settings.
BUG: 78082
svn path=/trunk/kdebase/kwin/; revision=382906
possible to always have certain shortcuts assigned to their windows
if such windows are open. Still few TODO items left, but let's consider
it enough for #44268 to be marked as done.
FEATURE: 44268
svn path=/trunk/kdebase/kwin/; revision=379444
For dialogs prefer placing together with mainwindow to data
from startup notification (happens with kio_uiserver dialogs).
svn path=/trunk/kdebase/kwin/; revision=360448
what to do with it. I've never liked this hack much, and this should
also take care of #49375, and should make sure kstart options will
have higher priority than settings configured in kwin.
svn path=/trunk/kdebase/kwin/; revision=319662
Initial work on kwin rules, i.e. #36377 , per window specific settings.
So far only desktop/above/below work, no GUI, and settings from the old
'Save window settings' are ignored for now.
svn path=/trunk/kdebase/kwin/; revision=315446
workaround, don't make their user timestamp newer than the active window's
one (unless a real user activity takes place in them).
As they are belong to the active application and just fail to say so,
this makes sure they won't prevent that application from getting focus
by having newer timestamp. E.g. Alt+F2, typing URL, kio_uiserver dialog
shows (has workaround), SSL certificate dialog shows (shown by kdesktop),
and it wouldn't get focus, because kio_uiserver's timestamp would be later.
svn path=/trunk/kdebase/kwin/; revision=298357
