Strange startup...

[Duncan]

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.