J posted on Mon, 06 Jun 2011 08:05:32 -0400 as excerpted:
>> J posted on Sun, 05 Jun 2011 09:54:08 -0400 as excerpted:
>>
>> > Recently, when I start up my test system the desktop is messed up.
>> > Once I unlock the widgets, then open the panel (taskbar, menu,
>> > system try widgets on it), select more settings, and tell it to shift
>> > right, or left, then back to centered, everything goes back to normal.
>> >
>> > The obvious symptom is that everything opens its top left corner
>> > outside the top left corner of the screen. If I am using folder view
>> > for the desktop, it also seems to open that outside the screen area
>> > as well, creating a scrollbar that does nothing when moved up or
>> > down, causing the folder view items to now show. The next obvious
>> > symptom is that the menu opens at the bottom of the screen and the
>> > panel is at the top of the screen.
>> Unfortunately you don't give us a whole lot to go on, in terms of the
>> version of kde you're running.
>
> KDE 4.6.x
Thanks.
> Since I HAVE to edit the settings on the panel to get things to fix, I
> suspect you are correct about kwin. Since I have it at the top of the
> screen, I would think it is already set to a fixed location. Top,
> centered, and maximized are the settings I have for it.
With this bug, top bars have seemed to be more likely to trigger it than
bottom bars. (I don't know about sidebars.) So it could well be that
it's the already known 4.6.x bug that's triggering for you, even if the
symptoms aren't quite the same.
FWIW, I wonder if the devs don't use top bars. That might explain them
not catching the bug before release. I'm a gentoo user, where packages
often have several USE flags (optional build and dependency flags), and
it's often simply not practical or even possible for the devs to check
every permutation (some packages have enough USE flags that there's
literally hundreds of possibilities, the Gentoo PHP package is infamous
for this). As such I understand that such bugs can and do slip thru,
because it simply isn't possible, let alone practical, to test every
possible variant with a package as highly customizable as plasma, or as kde
in general, happens to be. Despite that, I'd have it no other way, since
the alternative is the top-down, our-way-or-you-hand-edit-configs-to-
change-it (at best, sometimes hand-edit hard-coded sources), approach that
Gnome, for instance, seems to like to take. IOW, there's a reason, for me
at least, that we're not having this discussion on a gnome list. (I don't
and won't even have gnome installed here. I got frustrated with that long
ago, and from what I've read it has gotten much worse since.)
>> However, if you're running 4.6.2 or 4.6.3, a lot of users are having
>> problems ATM due to some patches gone awry. The problem is usually
>> kwin getting mixed up and trying to treat the panels as normal windows,
>> so it's usually panels not the plasmoids on them, but it's possible the
>> plasmoids are getting placed strangely due to the strange panel
>> handling in some instances as well.
>>
>> If you're running one of those two versions, try setting up a window
>> rule (I had to experiment a bit to get mine to take) either setting no
>> placement for the window, or forcing its absolute position. If you can
>> get the rule to override the screwups kwin is doing with it's normal
>> handling, you may be fine -- I was.
>
> How does one set a rule? I'm fairly new to the inner workings of KDE.
Somewhat counterintuitively for the panels (I filed a bug and it was
another user that pointed out in a comment there that this was possible,
even tho I have some two dozen custom window rules for various other
windows so obviously use and very much depend on the feature regularly in
other instances, but it was still counterintuitive for me to use it on a
/panel/), these are the /same/ window rules that can normally be set thru
the window menu (accessed via the app icon on the title-bar) on normal
apps, configure window behavior. So either select that in any title-bar
that happens to be handy, or go to kcontrol (systemsettings, except it's
NOT systemsettings but rather user-specific kde settings, the old kde name
kcontrol thus being far more accurate), workspace appearance and behavior,
window behavior, window rules.
Click the new button, then detect window properties, and finally on the
panel in question. This will fill the selector dialog with some
information about the panel, that becomes the initial settings for the
filter that determines which windows the rule applies to.
In this case, type: dock (panel) is very important. You don't want the
setting applying to ordinary plasma dialog windows, for instance. You can
play with the settings a bit in the actual rule after you click OK on the
info dialog, too (and I tend to do just that, fine tuning the exact
filters used), or hit detect window properties again, so you don't have to
get the results of the picker /exactly/ right the first time. But you
can't change that here and the choices you do have are fine as they are.
You'll adjust them a bit later.
When you do click OK on the window info popup, you'll be back to the five-
tabbed edit window-specific settings rule creation dialog. Here, the
first two tabs form the filter (thus corresponding to the info in the
selector, but giving you rather more fine detail control) used to apply
the rules setup in the last three tabs.
On the first tab, window, you may want to change the description -- that's
simply the human-readable name used in the window rules list, and doesn't
affect the way the rule actually works at all. If you leave it alone/
blank, it'll be filled in generically, "Settings for plasma", when you
click OK. But we already KNOW it's settings, and after you get about half
a dozen entries all saying "settings for <whatever>, it gets a bit
tiresome seeing that on all of them. What I put on mine is "plasma top
panel", specifically identifying the rule to me. (If I have another rule
for a different plasma window, simply "plasma" wouldn't be enough, but
adding "top panel" adds enough info for me to know exactly what the filter
is trying to accomplish.)
Window class: plasma . The drop-down default match is exact. But as I
said in the earlier post, I had to experiment a bit to get this to work,
as despite the fact that it was using the exact thing it had picked up
from detect window properties, the rule refused to take effect initially,
until I changed this to substring match, instead of exact. But apparently
the guy that told me about this workaround didn't have the same problem
there, or at least he didn't mention it. And if you get too lax, the
filter will start applying to windows you don't expect, so if the strict
exact match works for you, all the better. You probably don't need match
whole window class, as that tends to be an alternative to window role,
which we'll use instead.
Window role. If you have several panels, this one is important as it
selects the specific panel you wish the rule applied to. You don't want
them ALL forced to the same place. Here, it was panel_9 , exact match.
(That's not to say that I actually have 9 panels. I'd added and deleted
them, tho, in the experimentation process that eventually lead to a setup
I liked, and this was evidently the 9th panel I had setup. FWIW, I only
have two panels actually deployed. But the other one has far different
settings and I didn't want the rule to apply to both, so...).
Second tab: Window Extra .
As I mentioned above, Window Type Dock (panel) is VERY important, as you
don't want the rule applying to, for instance, confirmation dialogs, etc,
by accident.
Window title: plasma-desktop , exact match. Again, you can play with this
as necessary, but if exact match works, use it.
Extra role: Unimportant. Apparently kde doesn't use the extra role label
very often, so this is the usual setting for kde app windows. But some
non-kde apps sometimes use it to help distinguish between various windows
in the application, so I'm glad the rules expose it as a filtering choice.
Machine hostname: unimportant. If you run remote X setups, this can be
useful. But I don't and you /probably/ don't, so...
Then we get to the actual rules. Here, it depends on your specific
setup. For the guy that suggested trying window rules to work around this
problem, setting placement, force, no placement, on the bottom of the
geometry tab, was apparently the trick.
For me, again on the geometry tab, setting position, force, and the
appropriate position (0,0 , top left corner, in my case) worked better.
No-placement might have actually worked, but as I said above I had to play
with the filters a bit to get the rule to take effect at all, and by the
time I figured out why it wasn't working, I was using position, force,
instead, and I left it at what worked for me.
Not helpful for me in this case, but as a hint if you're trying to get a
positioning rule to work and it's not, sometimes the application itself is
interfering, and the workarounds tab can be quite helpful then. In
particular, I've had force-position rules that simply didn't work until I
set BOTH ignore requested geometry, force, checked/ON, AND strictly obey
requested geometry, force, unchecked/OFF. (That non-kde app, apparently,
was PARTICULARLY insistent on being placed in a particular location at a
particular size, but I had other ideas, and was finally able to get them
to apply after forcing BOTH strict geometry OFF and ignore geometry ON.
Setting just ONE of them wasn't enough.)
I've also had cases where setting minimum size was useful, and can
envision cases where the app's idea of global shortcuts conflicts with
shortcuts kde is trying to use, thus making that one useful.
Kwin normally uses focus stealing prevention to prevent popup windows from
appearing unexpectedly when you're typing, such that you suddenly find
half the sentence you just wrote got submitted as, for instance, the
password in a password popup! But there are cases with browsers, in
particular, where if a popup doesn't get the focus it was expecting, there
are potential security implications, and there are other cases where you
WANT popups to get the focus regardless, and still other cases where you
don't want a particular popup that INSISTS on focus stealing to actually
get it. That's what the focus stealing option is all about, and why kde
has shipped at various times with default rules forcing no-focus-stealing-
prevention, as a short-term workaround until kwin itself can have its
logic updated so the user-visible rule is no longer needed.
There have been specific cases where preferences tab rules, keep above/
below, no border, and active/inactive opacity, have been helpful as well.
(Unfortunately the opacity ones haven't always worked. I have the window
translucency effect on and inactive windows set to about 80% opaque, but
some windows I want 100%, regardless of whether they're active or not,
which is what setting the specific window inactive opacity should allow,
but apparently for quite some time kwin hadn't implemented specific window
exceptions and the general inactive opacity would override, despite what I
set here. I've learned to live with it, tho, and can't say for sure
whether the problem still exists in 4.6 or not, as I don't recall
registering irritation at it for awhile. Maybe they've fixed it. Maybe
I've just gotten used to it. I don't know which. But it's clear what
that option /should/ be able to do, in any case.)
I believe that's a reasonable intro to window rules. Hopefully it's
helpful regardless of whether it helps with this specific problem for
you. But of course I hope it ends up as a valid workaround for this
problem, until they get it fixed, too. If it's a side effect of the bug
I'm seeing, it should, but the effects you're describing are enough
different that I'm not sure whether it's the same bug (tho a different
side effect of it) or a different one. Here's hoping the workaround is
valid for you, regardless!
Meanwhile, be aware that this IS a workaround. When the bug is ultimately
fixed, it may be that this will cause other conflicts. So remember that
you've set it up and be ready to disable it with a later 4.6 or when you
upgrade to 4.7, etc. (You can temporarily disable a rule by for example
setting it to match some weird machine hostname, thus keeping the rule
around but disabled if you want to test if it's still needed or if it's
interfering with something else, without the risk of actually deleting it,
if desired. It's easy enough to set the machine/hostname back to ignore,
if you decide the rule's still needed, and just as easy to delete it
either way, if you decide it's not.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
