[Active] [Bug 308715] Plasma Active crashes, expecially while dragging down top bar
https://bugs.kde.org/show_bug.cgi?id=308715 Thomas Lübking thomas.luebk...@gmail.com changed: What|Removed |Added CC||rnwilson...@mail.com --- Comment #7 from Thomas Lübking thomas.luebk...@gmail.com --- *** Bug 322282 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Re: kwin vs kwinactive
On Dienstag, 30. Oktober 2012 19:42:46 CEST, Martin Gräßlin wrote: On Monday 29 October 2012 21:50:47 Aaron J. Seigo wrote: On Monday, October 29, 2012 21:11:32 Martin Gräßlin wrote: On Monday 29 October 2012 20:54:49 Marco Martin wrote: hi all, i seen that when kwin is built as kwinactive executable it takes its config from kwinactiverc, but the rules are still taken from kwinrulesrc, shouldn't it be kwinactiverulesrc as well? (to have different sets, ie one would want the fullscreen prevention only on kwinactive) we currently do not ship any rules for active and given that the kcm is not compiled for kwinactive, I am not sure whether it is needed. Marco wrote his email because we are probably going to be shipping rules for active; we ran into an issue with applications written for Nemo where things are done a bit differently. i'm guessing that's what motivated his mail. ah yes, then it would make sense to change that part, too. Especially if the rules are useless for the desktop case. Would we need more generic support here then? Eg. one might need a rule for plasma-netbook (yes stupid window, you *can* maximize!) which makes no sense on the desktop at all. Cheers, Thomas ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 293051] Thumbnails in Task Switcher overlap virtual keyboard
https://bugs.kde.org/show_bug.cgi?id=293051 --- Comment #10 from Thomas Lübking thomas.luebk...@gmail.com --- Yes, one _has_ to separate them in 2D Leaving aside that this is actually unlikely wanted in this case, a Dock (actually any managed window) will not go above an unmanaged window and KWin cannot manage its own window (the tabbox) However, due to the special nature of the keyboard i wonder whether it should not rather be unmanaged and raise itself everytime a(n unmanaged) window is mapped. -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 293051] Thumbnails in Task Switcher overlap virtual keyboard
https://bugs.kde.org/show_bug.cgi?id=293051 --- Comment #3 from Thomas Lübking thomas.luebk...@gmail.com --- just guessing*: the thumbnail will be in a popup '(ie. unmanaged window) and the keyboard ideally as well (if it is not, it cannot go above the popup) in this case the keyboard could occasionally just raise itself - another solution would be to have the thumbnail in a managed window and tag the keyboard to keep above * xprop keyboard.txt; xprop thumbnail.txt will tell, but in case it's a popup, xprop will unlikely work this way, because the pointer is grabbed -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: [kde-workspace] kwin/data/desktop: Move kwin/data to kwin/data/desktop so that I can add kwin/data/active.
Am 24.04.2012, 10:58 Uhr, schrieb Lamarque V. Souza lamar...@kde.org: Em Monday 23 April 2012, Martin Gräßlin escreveu: I'm quite confused by your three commits [1, 2, 3]. Why are they PA2 uses thumbnails as LayoutName, PA3 uses window_strip, we need to change that when someone upgrades PA2 to PA3: https://bugs.kde.org/show_bug.cgi?id=298285 The commits somewhat conflict with pending https://git.reviewboard.kde.org/r/104299/ In general changing the directory structure is always a bold move and probably not even required or the best solution here (aside the other review one could have simply ifdef'd the script in question or alter it's behavior at runtime) Why did you push directly to master without consulting the KWin It looked a simple change and has been tested. Such would be git rm clients/oxygen - nevertheless it would certainly cause some stir, yesno? ;-) In general we (and that explicitly includes Martin as maintainer) actually pass most stuff through reviewboard - keeps everyone up-to-date and prevents conflicting approaches. Also two heads are better than none (-: :-) Cheers, Thomas ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
