xfwm gives possibility for title bar buttons for stick, shade, etc. It would be nice to have it also for "Always On Top". Not everyone needs that but it's quite handy. Same counts for the shortcut keys as reported in bug 1121 (Add possibility to make shorcut for "Always on top") Reproducible: Always Steps to Reproduce:
Created attachment 805 svn diff from xfwm4 Changes: Added "Always on top" button. Added window shortcut for "Always on top". Added "Always on top" icon in default theme. Made "title" in Window Manager config pannel movable (not removable). And some small changes
As much as I agree with adding a keyboard shortcut for the "Always on top" flag (I think there is already a feature request for that), I'm a bit skeptical with the need to a title bar button because none of the existing themes implement it. BTW, this is for 4.6 as feature are frozen for 4.4, so are strings (for translations).
(In reply to comment #2) > As much as I agree with adding a keyboard shortcut for the "Always on top" flag > (I think there is already a feature request for that), I'm a bit skeptical with > the need to a title bar button because none of the existing themes implement > it. > > BTW, this is for 4.6 as feature are frozen for 4.4, so are strings (for > translations). > But because of the desire of artists for Xfce MetaThemes, and compatibility with freedesktop-icon-naming-spec, is there really a need for xfwm4 to remain compatible with older themes? I mean, other theming stuff will probably de redesigned for the next one (or two, if there will be a fixed release cycle) releases. just my 2ct
(In reply to comment #3) > But because of the desire of artists for Xfce MetaThemes, and compatibility > with freedesktop-icon-naming-spec, is there really a need for xfwm4 to remain > compatible with older themes? I mean, other theming stuff will probably de > redesigned for the next one (or two, if there will be a fixed release cycle) > releases. I don't know wher you've got that information, but there is no plan on my side to break compatibility in any forseable future. I'm not saying it cannot happen, but it's not planned. And backward compatibilty is something I've always taken care so far (you can use xfce 4.0 themes with xfwm4 4.4, and that's not just by chance)
(In reply to comment #4) > (In reply to comment #3) > > > But because of the desire of artists for Xfce MetaThemes, and compatibility > > with freedesktop-icon-naming-spec, is there really a need for xfwm4 to remain > > compatible with older themes? I mean, other theming stuff will probably de > > redesigned for the next one (or two, if there will be a fixed release cycle) > > releases. > > I don't know wher you've got that information, but there is no plan on my side > to break compatibility in any forseable future. > > I'm not saying it cannot happen, but it's not planned. And backward > compatibilty is something I've always taken care so far (you can use xfce 4.0 > themes with xfwm4 4.4, and that's not just by chance) > Sorry, i did not mean it like that. I was just trying to point out that re-evaluating the themability once every few years might not be a bad idea (4.0 was released 3 years and 1 day ago). Especially since there are is heavy development going on within Xfce, with new features, being added every other week. Let it be clear, that i am not saying that i think themes 'should' be changed, just asking if you would concider it if there are enough benefits to it. Like a global theming change for entire Xfce. I understand it is just looks, so it does not have nearly as much priority as any other feature. Perhaps that is an issue not existing until Xfce 5.0 comes in sight. Leaving 4.x backwards-compatible. In which case, all the feature-requests regarding theme's should be post-poned until 5.0 and i have been a total fool mentioning it for 4.6.
Well, theme changed a lot since 4.0 and several fatures where added (icon button, compsition, support for various ). As you said, we need to have real benefit to breaking theme compat, and as much as I understand the need for the shortcut, I'm a lot more doubtfull about an additional title bar button. There are already 6 buttons (which is already a lot). Having 7 buttons can look really odd IMHO. In terms of usability too: If the user has to take the mouse to click the button, it could also select the item in the menu. But being able to place a window on top with a single key shortcut makes more sense, IMHO.
(In reply to comment #6) > Well, theme changed a lot since 4.0 and several fatures where added (icon > button, compsition, support for various ). As you said, we need to have real > benefit to breaking theme compat, and as much as I understand the need for the > shortcut, I'm a lot more doubtfull about an additional title bar button. > > There are already 6 buttons (which is already a lot). Having 7 buttons can look > really odd IMHO. There will probably be few users who will have all 7 buttons visible at any given time. And if they do, it is up to them imho. > In terms of usability too: If the user has to take the mouse to click the > button, it could also select the item in the menu. But being able to place a > window on top with a single key shortcut makes more sense, IMHO. For users that use apps like gimp and dia extensively, apps that require the user to access multiple windows to do easy tasks, it can be a nice feature. And it can (depending on your use of gimp) increase productivity. Nonetheless, by itself it does not validate breaking theme compatibility. But when there are other theming issues to be solved in upcoming releases this could be a feature worth concidering imho.
I understand you don't want to break the current themeing system for one icon. But for the always on top icon the minimize/maximize icon can also be used (that icon gives a good representation too). Which won't break the theme's. (In reply to comment #7) > There will probably be few users who will have all 7 buttons visible at any > given time. And if they do, it is up to them imho. The user can add the icons he/she wants, so its up to them, who many they have. (most users don't use the stick and shade icons either) (In reply to comment #6) > There are already 6 buttons (which is already a lot). Having 7 buttons can look > really odd IMHO. With the theme is use 7 icons (6 button + menu icon), doesn't look odd, but that's a mather of oppinion. > For users that use apps like gimp and dia extensively, apps that require the > user to access multiple windows to do easy tasks, it can be a nice feature. And > it can (depending on your use of gimp) increase productivity. This is the exact reason I made the extra button, also because there was not short cut key. But for a shurt cut key to work the window has to be active (this can be done either by mouse or acrive window switch keys), this will be more actions as just click the icon button. Same counts for stick, enz too. I made some more changes, like the short cut key, maybe those are useable. I could make sepperate diffs for those.
(In reply to comment #8) > > For users that use apps like gimp and dia extensively, apps that require the > > user to access multiple windows to do easy tasks, it can be a nice feature. And > > it can (depending on your use of gimp) increase productivity. > > This is the exact reason I made the extra button, also because there was not > short cut key. Humm, I'm somehow not convinced with this argument. If those satellite windows are supposed to be on top of the others related windows, then they should be declared as "transient for group" by the application. Most window managers, including xfwm4, place transients always above their parent window(s). > I made some more changes, like the short cut key, maybe those are useable. I > could make separate diffs for those. Right now, the goal is to get xfce 4.4 out. This feature, in this form or another will not be added to 4.4 but to 4.6. So you have time.
Any news? I'd also like to see a Always On Top title bar button.
Created attachment 4657 Add always on top button This is an update of the previous patch. This one applies to the current git master.
I am still against adding a yet another button for this, but would agree on the dbl-click action. If you could you split your patch in 2, I'll push the one for the dbl-click action (and leave the icon/title bar alone for those who want to patch it locally)
Created attachment 4659 Added "always on top" to the double click action This patch adds the double click action. I undestand your reasoning. Would like the patch myself. For that reason I want to keep the previous patch around, I might extend it some more. Maybe an alternative: use right click on the stick button to toggle always on top, and middle click for below others?
Given the new Gnome 3.14 windows, this becomes much more important to me. I have no GUI way to toggle "above" ("always on top") anymore in gedit, gnome-calculator, etc. (Why there is a "stick", but no "above" button is beyond me.)
(In reply to C. Conrad Cady from comment #14) > Given the new Gnome 3.14 windows, this becomes much more important to me. I > have no GUI way to toggle "above" ("always on top") anymore in gedit, > gnome-calculator, etc. (Why there is a "stick", but no "above" button is > beyond me.) Right click on the CSD windows' title will show up the WM menu (xfwm4 is now compatible with that GTK+ hint as well).
(In reply to Olivier Fourdan from comment #15) > Right click on the CSD windows' title will show up the WM menu (xfwm4 is now > compatible with that GTK+ hint as well). Not so. Right-clicking on the title gives me nothing. Right-clicking on the bar below the title only gives me a "Close" item. See http://i.imgur.com/DKD36AL.png
(In reply to C. Conrad Cady from comment #16) > (In reply to Olivier Fourdan from comment #15) > > > Right click on the CSD windows' title will show up the WM menu (xfwm4 is now > > compatible with that GTK+ hint as well). > > Not so. Right-clicking on the title gives me nothing. Right-clicking on > the bar below the title only gives me a "Close" item. See > http://i.imgur.com/DKD36AL.png What version of xfwm4 and gtk3 are you using? As I said, xfwm4 4.12 supports GTK_SHOW_WINDOW_MENU implemented in gtk+ 3.13
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/1. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev