Many, if not most modern themes seem to prefer 1px window borders. This makes resizing windows with the mouse a nightmare in Xfwm. I've had many of my users complain about resizing difficulties. Other wm (Unity, Gnome, Cinnamon) add an invisible, larger region to make resizing easier. This is a topic that has been discussed by theme creators many times, with divergent opinions. For example, here: https://github.com/shimmerproject/Numix/issues/100 Thus it would be a huge usability improvement if Xfwm could solve the problem on a core level instead of the theme level. It should provide "magical" resize borders that are larger that the actual window, possibly limited to only the active window. I am aware of bug 11439, however I do feel that it should be reconsidered. Even if only those using a compositor can use these enlarged borders, that would already be an improvement, seeing as pretty much all modern devices support compositors.
This requires the compositor, which is optional in xfwm4. See bug 11439, bug 9490 and probably a lot of others.
I feel the same as the OP. The resizing of windows in Xfwm does require too much precision and attention and is not very easy or practical. Sometimes I use [alt] + [drag right mouse button on window] to resize the window (try e.g. "alt+right drag" upper left quarter of the window). It works nice, but it does require two hands. I've created a feature request, with the immodest proposal to (re)employ RMB drag on the titlebar for resize, bug#12026
In 2016 that's really weird that is the theme that decide the size of the resizing region. As haarp said, with modern themes that prefer 1px window borders this makes resizing windows with the mouse a nightmare in Xfwm...
> This requires the compositor, which is optional in xfwm4. I've seen the compositor is on by default since 4.12, so, could OP's solution be implemented now? It would be a relief to have this annoyance gone. It's one of my top gripes with Xfce.
I think to have a settable border is a neccesity - I personally need it all some minutes. It was one of the point, which hinders me really to come to linux at all ! OS, which have usuablity studies, have this thing since 1993 (the event of Windows 3.1 ...). Sad to say this! Additionally, the compositor is not working in XRDP & Co.
(In reply to Manfred Braun from comment #5) > I think to have a settable border is a neccesity - I personally need it all > some minutes. It was one of the point, which hinders me really to come to > linux at all ! You have settable borders, just use a sensible window manager there instead of the one some distro insist on shipping by default which has 1pix wide border for the sole sake of the look... > OS, which have usuablity studies, have this thing since 1993 (the event of > Windows 3.1 ...). Sad to say this! > Additionally, the compositor is not working in XRDP & Co. If you want to have an input border larger than the actual visible border, then you need a compositor, so your last comment actually shows that in this case, the best option is to use a different theme.
(In reply to Olivier Fourdan from comment #6) > You have settable borders, just use a sensible window manager there instead ^^^^^ Typo here, I meant sensible window manager theme (not "there"), like the ones that ship as default with xfwm4 4.12.x upstream.
Thanks for your reply. I am on debian with XFCE4 - so I am nailed at this, otherwise, I am on myself, if somethings breaks (what really happens over and over again). And I theme, which gives me a border, is just a beast, which removes other settings, which initially lead to to the other one. Its really a pain for me just again to remember the windows 3.1, there is reaklly something ultra-simple: A setting for the border, the title and all window decorations. I am writing, because I hope to make a useful hint about future development.
Xfce used with Mutter have large border independent of the theme used. It will be very great if xfmw4 can do the same.
except that mutter cannot work uncomposited whereas xfwm4 can enable/disable the compositor on the fly. What I wrote in comment 1 still stands. Comment 6 is common sense, some distributions change the default theme and use a 1 pixel border, which I think is wrong.
(In reply to Olivier Fourdan from comment #10) > What I wrote in comment 1 still stands. Comment 6 is common sense, some > distributions change the default theme and use a 1 pixel border, which I > think is wrong. Even so, larger borders only work around the problem. Ideally, for usability, you'd have something like 10px borders, or even more on HiDPI screens. At the same time, no theme would want to waste so much space on window decorations, and rightfully so. I only see one way to make both happy - invisible resize regions.
So, xfwm4 has a compositor, what good reasons would there be not to implement invisible resize borders on the compositor?
(In reply to Olivier Fourdan from comment #10) > except that mutter cannot work uncomposited whereas xfwm4 can enable/disable > the compositor on the fly. > > What I wrote in comment 1 still stands. Comment 6 is common sense, some > distributions change the default theme and use a 1 pixel border, which I > think is wrong. Invisible resize regions are clearly a huge usability improvement. Every modern desktop have it. If a theme want to offer a 1px border for design purpose it should be able to do it without sacrificing the usability. Xfwm4 should be able to have invisible resize regions when the desktop is composited and fallback on theme border size when the desktop is uncomposited.
This is my first post regarding Linux and I'm a total noob, therefore I don't exactly understand what this Guide is doing. But I assure you it works fine for me. This may be a rough solution not suited for those needing xfwm4 because of limited system resources. But you can change the default window manager to compiz. This solved the issue for me and I can now enjoy the xcfe simplicity combined with generous grabbing areas. https://wiki.ubuntuusers.de/Compiz/ Enter in terminal: "sudo apt-get install compiz compiz-gnome compiz-plugins-extra" "sudo apt-get install compizconfig-settings-manager" "ccsm" _______________________ In CCSM you need to enable OpenGL, Composite, GNOME Compatibility in 'General' Tab. Within the 'General Options' menu, you can set the focus steal prevention to zero, so that new windows are placed always on top, and choose your workplaces In 'Effects', enable Fading Windows, Window decorations, and if you like Animations In 'Other', you can enable Window previews (may need png) In Tools enable Compiz Library Toolbox, D-Bus, Mousepolling (gets activated if you choose Window previews), Session Management and Workarounds Now in 'Window Management', you need to choose Application Switcher, Move Windows, Place Windows, Scale Windows Put and Window Rules. Ring, Static & Shift Switcher are more advanced Application Switchers you can configure as you like. In the CCSM Settings you need to enable Gsettings Configuration Backend. ________________________ Now Compiz is configured, make a Backup of "/home/user/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml" and enter "xfconf-query -c xfce4-session -p /sessions/Failsafe/Client0_Command -t string -sa compiz" in terminal to configure xcfe to use compiz as the default window manager. ________________________ To spare you from needing GNOME Tweak to set your theme now, you can use "gsettings set org.gnome.metacity theme insertyourthemehere" to change the window decoration theme and the default xcfe theme settings to change the rest of the UI. I experienced that my minimize/maximize Buttons were gone after that. you can use "gsettings set org.gnome.desktop.wm.preferences button-layout ':minimize,maximize,close,'" to restore them. And that's it.
I don't know how to edit posts, but I realized the desktop icon texts get displaced if you follow the steps. This is the fix: xfconf-query -c xfce4-desktop -p /desktop-icons/center-text -n -t bool -s false
(In reply to tm.selsingen from comment #14) > This is my first post regarding Linux and I'm a total noob, therefore I > don't exactly understand what this Guide is doing. [...] This is bugzilla, not a forum nor a wiki, this is absolutely not the right place to post such "howto".
I'm sorry, I wasn't aware of it's strict nature. Feel free to delete all my posts. I just didn't find any open Threads regarding this Problem and thought that might be a place people might come across this solution. But I know now and will try to find a different more suited place. Sorry for Spamming.
I would also really appreciate this feature. Rather than spend hours searching for a theme with huge enough borders that doesn't look like trash, it would be nice if it just worked. Not everybody has pixel precise control over their hands. Its incredibly difficult to resize windows at high res especially when you have nerve damage in your hands. If basic usability features like that are not doable in the built in wm in this dm why not abandon it for a more mature wm that is better supported by the linux community at large. Honest question, no insult intended it just seems like help is already spread thin. Is there just not one that is light weight enough?
You know you don't need to click on borders to move or resize windows in xfwm4, right? Simply press Alt and right mouse button to resize from any size anywhere within the window. As to using an alternative window manager with xfce, this is up to the users (but again, this is *bugzilla* not a general discussion forum, there are much better tools like mailing lists, forum and wiki to discuss these).
(In reply to Olivier Fourdan from comment #19) > You know you don't need to click on borders to move or resize windows in > xfwm4, right? > > Simply press Alt and right mouse button to resize from any size anywhere > within the window. This is a very handy solution if you're using a mouse, but not really a solution for anyone using a trackpad (with which right click dragging is very awkward). Also it just isn't a very intuitive solution - most users will just expect to be able to resize windows by clicking on the corners and dragging.
For anyone interested, a great workaround I've found to this issue: switch to Linux Mint.
Olivier please try to implement a most reasonable solution if you can to xfwm4 to resolve this common Xfce nuisance. Alt+right-click drag is an inconvenient workaround for laptop users, I can't even do that on my trypad unless I try at least 3 times.
No, I already commented many times, this would require the compositor which is not mandatory in xfwm4. all that just because some "fashionable" themes set a 1pix border and prefer looks before usability.
I mean, I understand the frustration and the need (that's why the bug is not closed as wontfix), but it requires a substantial amount of work and there are workarounds (even using keyboard resize), so it's somehow a low prio issue for me.
I'd like to mention that Manjaro XFCE has this issue. Sounds like it's due to the theme they choose to use. I wasn't a big fan of the look and feel of XFCE prior to trying out Manjaros version. It's pretty disappointing to find out that one of the more modern and well configured distributions of XFCE comes with such a glaring flaw, and that there are no plans in the near future to fix it. I wonder how the maintainers over at Manjaro came to the decision to use a theme that results in this issue. It's very strange to me there hasn't been larger complaints about this over there. Not being able to easily resize windows is a pretty big issue.
You can easily resize any window from anywhere using the appropriate modifier (Super) and clicking inside de window, so stating you're not able to resize windows easily in xfce is dishonest, at best. Anyhow, if the border of the windows are two thin it's because your distribution of choice uses a theme with tiny borders, i.e. it values the look more than usability, but that's a downstream decision. The default xfwm4 theme has fairly large borders, and it even comes with larger variants for HiDPI screens. And at last, most applications nowadays use CSD, so this is becoming more and more irrelevant.
*** Bug 13732 has been marked as a duplicate of this bug. ***
Hello, Olivier. It is unhelpful to accuse reporters of being dishonest. From one developer to another, please can you refrain from doing this. The current workaround (Alt + right mouse button + drag) is great for mouse users, but it is a massive problem for users working with other setups. Alt+rightbutton+drag: 1. cannot be used by touchscreen users at all, because they lack a right button (and sometimes an Alt key). 2. sometimes cannot be used with a graphics tablet stylus because some of those lack pointer buttons beyond the first. 3. cannot be used easily on a tablet PC, or a Cintiq only drawing setup because they lack a hardware Alt key (the only way forward here is to do something really clumsy with onboard) 4. is very hard to use with buttonless touchpads, which often overload the 2-finger tap gesture as a scroll gesture (clickpads are a little easier) In addition, some users simply lack the coordination needed to use a mouse and a keyboard at the same time for this. New users will lack the rather obscure knowledge for this key+mouse combo. The modifier+button+drag combo is a great workaround for experienced, well-coordinated users with a mouse. Another workaround may be better for everyone else: Window menu → resize! So how do we build in a more forgiving nature? Well, resize areas projecting beyond the extents of the window are one of the better solutions to this mess of problems, and it would be lovely to see composited Xfwm4 do this as a workaround for broken downstream themes like Numix, or themes like its own (non-hdpi) Default. ("Most applications use CSD" is clearly hyperbole, and irrelevant since many important ones do not and have no plans to change.)
Prior to the invisible extents being added to the GNOME compositor, resize grips were a commonplace solution to the resizing issue. These were deprecated in GTK+ 3.14 with the assumption that invisible extents would be available. https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.17 "In more recent versions of GTK+ 3, the resize grip functionality has been removed entirely, in favor of invisible resize borders around the window. When updating to newer versions of GTK+ 3, you should simply remove all code dealing with resize grips." It's probably not fair to make that assumption, but what's done is done. We should consider either requesting that they be restored in the toolkit or consider including the invisible resize borders. Contributing a patch would likely the the quickest way to add invisible resize borders.
I am suffering this problem since many days. Hope developers will fix it soon!
I agree that this is a bug. I also bump the comment that this has been a topic of usability studies since Windows 3.1. Also, in Windows 3.1, most people had displays at 640x480 resolution (or sometimes 800x600 for power users who knew how to change resolution). Now, with monitors of similar size (or smaller on laptops), we have 1920x1080 as the norm. This means that with a screen of similar height, resizing the window in the expected, intuitive way (dragging side or corner--don't forget about the top and/or left), resizing the window is 225% more difficult than in Windows 3.1.
The newest issue of the German computer magazine c't features Xfce in an article about alternative desktops. They, too, criticize the difficulty of resizing windows compared to other desktops. https://www.heise.de/ct/ausgabe/2017-24-Desktop-Alternativen-fuer-Ubuntu-17-10-3878452.html
(In reply to haarp from comment #32) > The newest issue of the German computer magazine c't features Xfce in an > article about alternative desktops. They, too, criticize the difficulty of > resizing windows compared to other desktops. > > https://www.heise.de/ct/ausgabe/2017-24-Desktop-Alternativen-fuer-Ubuntu-17- > 10-3878452.html I'd blame it on Xubuntu default WM theme, which indeed, scarifies practicality for the look, you can't blame upstream for that sorry.
Grabbing the border should be easier. It is widely discussed and has been for years. The attention it receives should have been a red flag years ago. The idea is the flaw is related to the borders and that may be the correction impediment. The code is currently: "mouse covering border offers resize" The code instead needs to be "mouse within x pixels of window's edge offers resize" The border should not be the equation. Asking the coder for the window system to adjust how the mouse functions may not be productive. Please correct me if I am wrong. My understanding is the problem should be stated: How can the resize behavior be made to rely upon "a quantity of pixels from a window's edge" instead of "directly atop the border's thickness." An alternate solution may be: Can the "mouse offers resize atop the window border" receive code stating "and x pixels outward?"
I agree with sllekonn, though I want to clarify the meaning of "offer". I agree that the user should be able to grab the border if the mouse is within x pixels of the window edge. It would be helpful if the mouse cursor changed when in this region to indicate the option. However, I think it would be okay if it changed only after button-down. FWIW, I suggest x = 1/128 of the screen width (That's about what the Mac has.)
Sorry, what I meant was that the width of the virtual window border should be about 1/128 of the screen width. That makes x = 1/256 of the screen width
Please XFCE people, I'm waiting for 12 years to get this fixed. I was using Cinnamon before, which worked great with 1 pixel border window theme. But this is apparently still not fixed after all these years. Don't start saying I need to use the alt+right click workaround... I really love XFCE due to the lightweight/speed/memory/cpu usage, but I really hope somebody will fix this in xfce itself (no this is NOT a theme issue). I will never adapt my theme to 'fix' this.
(In reply to Melroy from comment #37) > Please XFCE people, I'm waiting for 12 years to get this fixed..... Ps. can the priority and severity be increased due to the big usability impact for the end-users.
Not alarmed? Went to K - makes the run. Regards, Manfred
(In reply to Melroy from comment #37) > Please XFCE people, I'm waiting for 12 years to get this fixed. I'm only waiting for 3 years now, but I feel your pain:-(
> Please XFCE people, I'm waiting for 12 years to get this fixed > I'm only waiting for 3 years now, but I feel your pain:-( I felt the same for 4 years. Now I created this theme. Maybe it's a workaround for a while. https://www.opendesktop.org/p/1290489/
Thanks DarkTrick! for the workaround. I think this ticket is very much underappreciated regarding the impact of the end-user. I think both the priority as well as severity could/should be increased.
It would be sweet if the resize tool simply persisted for more than 16ms when you pass over it!!! It would be perfectly fine that it's 1px if it would simply live long enough to interact with it! (In reply to demiun from comment #4) > > This requires the compositor, which is optional in xfwm4. > > I've seen the compositor is on by default since 4.12, so, could OP's > solution be implemented now? It would be a relief to have this annoyance > gone. It's one of my top gripes with Xfce.
DarkTrick, is there a single configuration option to get the borders larger without taking the whole theme?
Wil: (uneducated guess): I guess it's a processing "problem". Probably not having this feature is one part "making xfce a slim window manager" Martin: As far as I experimented it was not possible. As far as I experienced there is not much time taken into this. One reason for that is, that you have the "ALT"+right-mouse-click-drag functionality for resizing windows. As of my understanding that's one important reason this topic here is underappreciated. ( But I might have misunderstood things ).
Isn't this issue a thing of the past anyway with xfce switching to CSD for 4.16?. You can, for example, set Catfish to CSD already and the resizing area is more than enough (Catfish -> settings -> use CSD). Or maybe try another gnome-app (gnome-calculator, quadrapassel) - you can also set Firefox to use CSD and the resizing issue is gone. Also, making the borders wider in xfwm4 can be done rather quickly - just open all the border elements with pinta/gimp in the xfwm4 theme and add a few pixels. If you want to have a borderless theme - you could just increase the top-left and top-right elements of the titlebar and grab there for resizing.
@Michael: Everything you state are workarounds (?) - Not all apps support CSD - There may be people out there, that prefer non-CSD (maybe because they like to be able to grab a whindow somewhere :D) - "making the borders wider in xfwm4 can be done rather quickly": -- Find out where themes are stores and duplicate them: 15 - 25 min -- open each and every file and change size, so it doesn't look like puke > 60 min -- Don't know, that you only need to resize half the files inside the theme folder: +30min -- if you never touched gimp before: + 60min -- Find the place to save your new theme: 15 min Unfortunately it's neither "quickly" nor "just". ( Perhaps one reason: There seem to be 3 to 4 possible locations to put a custom theme in, but only 1 works.)
@DarkTrick: I get that - I'm sorry if it came across the wrong way. I was trying to say that with Xfce switching to CSD (for some apps just CSD for titlebars - but still) there is no need for xfwm4 themes anymore. I mentioned the gnome apps and Catfish, because with them you can see that the resizing is done differently. No matter if apps support full blown CSD or not - all of them will use CSD at least for titlebars and the resizing behavior will be the same for all of them. I hope I got that right...I could be mistaken... I've only used a custom theme (with all the mentioned tweaks) and it works for me. It may be an issue if you like theme hopping. I don't think this is a workaround, because xfwm4 works that way and according to some comments above (by developers) it's intended to do so. It's a matter of theming xfwm4 functionally. Thanks for your reply and I hope I didn't do too much of a damage :)
-- 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/176. 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