| Summary: | Window Specific Settings dialog has no help function | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Nick Cross <kde> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | kde, lueck, pablo |
| Priority: | NOR | ||
| Version: | 4.7.3 | ||
| Target Milestone: | 4.9 | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.9.0 | |
| Sentry Crash Report: | |||
|
Description
Nick Cross
2011-11-16 14:39:21 UTC
due to string freeze we cannot do anything before 4.9. Ok. Could you at least tell what the following mean/do: Autogroup with identical Autogroup in foreground Autogroup by ID and the difference between Apply Initially Apply Now Remember Force Force Temporarily Thanks! On a general note: This is not the user help forum. -> http://forum.kde.org/ You can also contact this guy: "pablo 'æt' blueoakdb 'døt' com" He's writing on a extensive documentation on windowrules. Also "taking the mysteries" out of the rule dialog is an ongoing task. (Autogrouping refers to tabbing, an the three most important strategies are "force" - window cannot alter this value ever "apply initially" - window starts with this value and "remember" - window starts with the value it had on last close) Howdy, Thomas is right, I've tasked myself with documenting the feature-rich kwin window rules. Unfortunately, as a self-employed consultant I have to balance `making money' with `helping out The Cause [tm]' :) It's on my to-do to finish what I started: document the kwin rules. Let me address the following - I'll hit the other questions shortly (I'm not sure how much data I have on them): Apply Initially --------------- The attributes are changeable by the application and/or end-user after initially set. Apply Now --------- Useful when debugging rules. :) It's applied only at this instance and never again. For example, if you're goofing around with a rule and you hork your window, you can create a new rule with `Apply Now' to undo the hork. Remember -------- When the application re-starts, `remember' the setting value when we closed the application last. For example, if you'd like to preserve the position of a window from invocation to invocation, use this matching. Force ----- The attributes associated with Force may never be changed by the end-user nor the application. kwin will ignore the requests. Force Temporarily ----------------- ** According to my notes, Thomas is wasn't sure about this setting. :) ** Howdy, At the moment, I don't have anything concrete to provide on Autogroup'ing. Thomas wasn't sure how Autogroup'ing worked and due to time constraints, wasn't able to comb through the code. :) On my todo was to empirically test Autogroup'ing in order understand the functionality. The current believe is Autogroup'ing is driven by Window Class. If you goof with Autogroup'ing, please flick me an email message with you what you determine and I'll add it to my stack of (electronic) notes. :) @Pablo "ForceTemporarily" means "Force on /this/ window, ie. until it's closed. Then the rule is discarded." Hi Thomas, Thank you for the additional information. When you say "... the rule is discarded.", do you mean it's deleted or logically discarded (i.e. kwin will ignore the rule for any other windows which may match the criteria)? Merci! Thanks for the additional information. I have played with the settings for Autogroup with identical Autogroup in foreground and I *think* it seems to do the following: I have created a Window Rule for a Window Class exact match to okular. By overriding 'Autogroup with identical' for Force/True this seems to mean that PDF's will always be grouped. By setting 'Autogroup in foreground' to true *as well* this brings the okular tab group to the foreground when opening a new pdf. This was testing on a dual monitor single desktop setup. Hope this helps and can eventually make it into the docs. Thank you Nick for your help. (In reply to comment #1) > due to string freeze we cannot do anything before 4.9. first part of that sentence ("string freeze") is correct, but the conclusion ("we cannot do anything before 4.9") is completely wrong: 1) GUI: If you want to introduce new gui strings (whatsthis, tooltip) ask on the translators list kde-i18n-doc@kde.org for approval. You usually always will get the OK to break the string freeze. 2) Documentation: Since two years the doc string freeze rule exists only for everybody except the translation team, see http://lists.kde.org/?l=kde-i18n-doc&m=126324708706419&w=2. And the translation team is using the string break policy excessively since 3.4/3.5 with thousands of updated and backported doc strings in every realease. In this case (a new documentation) you could add a default Help button (reusing existing gui translation) and a help call for a docbook. Send some plain text info to the doc team kde-doc-english@kde.org, we'll markup it to docbook and translation team can introduce that at any time, even one day before the release date, into 4.8. -- KDE Translation Team kde-i18n-doc@kde.org KDE Documentation Team kde-doc-english@kde.org (In reply to comment #7) > When you say "... the rule is discarded.", do you mean it's deleted or > logically discarded (i.e. kwin will ignore the rule for any other windows which may match the criteria)? Completely gone - the rule is only temporary and will in doubt be removed from the kwinrulesrc as well. As Burkhard says that it would be ok to add documentation could this be considered for a release before 4.9 ? Thanks! :-) Howdy, My plan is to write pages for the KDE site so we wouldn't be tied to a particular release. Howdy, I spoke with Anne Wilson on the best way for me to get started (iterative documentation writing is what I need) and she's provided me direction. :) Once I get Anne's okay that I'm following a proper process, I'll post a link here so folks who are so inclined, can watch the page mature. For now, the work-in-progress documentation can be found here: http://userbase.kde.org/Kwin_Rules Please note that I'll only poke at the documentation as time permits. :) Correction: http://userbase.kde.org/KWin_Rules (note capitalization of KWin) Hi Nick, Recently, I've had a bit of time to work on the KWin Rules documentation. It needs some final editing (which I hope to get done tomorrow) however please have a look and let me know whether it addresses your concerns. If so, perhaps we can close this ticket. Thanks! Looks good! :-) I would say: implemented :-) Thanks a lot for the work on the documentation (In reply to comment #19) > I would say: implemented :-) Thanks a lot for the work on the documentation You're very welcome Martin. As you know, I'm thankful to you and the team for KWin. Also, for the record, the documentation would not have been possible for the patience of Thomas Lübking. I thought he'd strangle me with some of my questions! :) |