Bug 670173 - Terminal opens as 80x24, then auto-resizes to 33x24
Summary: Terminal opens as 80x24, then auto-resizes to 33x24
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xfwm4
Version: rawhide
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Christoph Wickert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 669692 713055 (view as bug list)
Depends On:
Blocks: F16Blocker-xfce
TreeView+ depends on / blocked
 
Reported: 2011-01-17 12:43 UTC by Horst H. von Brand
Modified: 2012-12-17 22:51 UTC (History)
31 users (show)

Fixed In Version: xfwm4-4.8.2-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-25 03:41:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 649680 0 Normal RESOLVED geometry not work well with non-metacity/mutter 2020-08-17 22:14:20 UTC
Xfce 7445 0 None None None Never

Description Horst H. von Brand 2011-01-17 12:43:49 UTC
Description of problem:
I'm running XFCE, and opened a Terminal via clicking on the background (perhaps it hadn't finished initializing?). The Terminal opened as 80x24, then shrunk to 33x24 (?). I opened another Terminal via ctrl-N in the first one, same result. Now that XFCE is fully functional, the same happens each time I open a Terminal via clicking on the background.

Opening a Terminal from the panel works normally.

Version-Release number of selected component (if applicable):
Terminal-0.4.5-3.fc15.x86_64
xfce4-panel-4.7.7-1.fc15.x86_64

How reproducible:
Has happened once.

Steps to Reproduce:
1. Open a Terminal by right click on the background, --> Open Terminal here
2.
3.
  
Actual results:
80x24 ~~-> 33x24

Expected results:
80x24, and stay that way

Additional info:

Comment 1 Kevin Fenzi 2011-01-17 16:55:33 UTC
Odd. Anything related in ~/.xsession-errors? 

Also, I have noticed a rouge gnome-settings-daemon sometimes starts up. Do you have one running? 
If you kill it, does behavior go back to normal?

Comment 2 Andy Lawrence 2011-01-17 22:47:42 UTC
I do not have gnome-settings-daemon running and have the same issue with the shrinking terminal in XFCE.  Same versions as the OP.

Nothing interesting in .xsession-erros.

Comment 3 Horst H. von Brand 2011-01-18 14:29:26 UTC
(In reply to comment #2)
> I do not have gnome-settings-daemon running and have the same issue with the
> shrinking terminal in XFCE.  Same versions as the OP.
> 
> Nothing interesting in .xsession-erros.

Now, with:

Terminal-0.4.5-3.fc15.x86_64
xfce4-session-4.8.0-1.fc15.x86_64
xfce4-panel-4.8.0-1.fc15.x86_64

Ditto here.

BTW, if I open new tabs in a Terminal window (opened via clicking on the background), it starts shrinking, just like bug 669692 (gnome-terminal).

Comment 4 Horst H. von Brand 2011-01-18 14:36:04 UTC
Oops, just double-checked. What I'm really running is gnome-terminal-2.33.4-2.fc15.x86_64, Terminal itself does behave. My XFCE4 configuration had gnome-terminal as default term. Sorry for the confusion.

Comment 5 Kevin Fenzi 2011-01-18 16:13:23 UTC
Moving over there. ;)

Comment 6 Horst H. von Brand 2011-01-18 20:41:10 UTC
I don't know if comment 2 is really Terminal or gnome-terminal?

Comment 7 Kevin Fenzi 2011-01-18 20:57:15 UTC
Yeah. If it's Xfce's Terminal, I'll be happy to look more...

Comment 8 Andy Lawrence 2011-01-18 23:40:44 UTC
Sorry, Comment 2 is gnome-terminal, my bad.  

Forgot I changed it.

Comment 9 Horst H. von Brand 2011-02-12 22:18:05 UTC
Now gnome-terminal-2.33.5-2.fc15.x86_64, xfce4-session-4.8.0-2.fc15.x86_64, 
xfce4-panel-4.8.1-2.fc15.x86_64.

Opening a gnome-terminal resizes to 29x24, clicking on its lower border to check its size makes it go to 29x2. Quite entertaining ;-)

No messages in the Terminal from where I started it.

Comment 10 Horst H. von Brand 2011-03-16 02:09:17 UTC
(In reply to comment #9)

[...]

> Opening a gnome-terminal resizes to 29x24, clicking on its lower border to
> check its size makes it go to 29x2. Quite entertaining ;-)

If I open a tab in the 29x24 tty, it also resizes to 29x2.

Comment 11 Horst H. von Brand 2011-03-16 21:54:22 UTC
*** Bug 669692 has been marked as a duplicate of this bug. ***

Comment 12 Horst H. von Brand 2011-03-16 21:57:08 UTC
gnome-terminal-2.33.90-1.fc15.x86_64
xfce4-session-4.8.1-3.fc15.x86_64

Now it says:

$ gnome-terminal 

(gnome-terminal:3346): IBUS-WARNING **: org.freedesktop.IBus.InputContext.GetEngine: GDBus.Error:org.freedesktop.DBus.Error.Failed: Input context does have engine.

Still the same resizing mess under XFCE.

Comment 13 Bobby Powers 2011-03-31 06:38:53 UTC
I'm seeing this too, its quite frustrating.

Comment 14 joss.bo 2011-04-18 19:33:52 UTC
I've just updated my system to FEDORA 15, using KDE and getting the same, no matter where I start the Terminal. I've tried to open a new tab, it takes 10 seconds and start to shrink.
But when opening a 3rd tab, then it stays at the same size

Comment 15 joss.bo 2011-04-18 19:35:36 UTC
I've just updated my system to FEDORA 15, using KDE and getting the same, no matter where I start the Terminal. I've tried to open a new tab, it takes 10 seconds and start to shrink.
But when opening a 3rd tab, then it stays at the same size

Comment 16 Adam Williamson 2011-05-05 00:19:36 UTC
After installing F15 TC1 and logging into Xfce, I can confirm the same on a clean config. On launch of gnome-terminal, it resizes itself by shrinking in horizontally from the right-hand side. On opening a second terminal, it shrinks vertically from the bottom, leaving you with a 34x3 terminal. Additionally, I can't actually type anything into it.

In GNOME and LXDE, it behaves itself.

In KDE, it behaves similarly to Xfce, but it shrinks both horizontally and vertically as soon as it's run (no need to open a second tab), and I can type into it, it seems to work mostly normally, bar the ridiculous size.

When running an affected desktop, if you manually resize it back to a sensible size, it shrinks itself again.

I don't see any error messages if I launch gnome-terminal from within Terminal.

Re-assigning to mclasen as he seems to be the one doing all the work on gnome-terminal.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 17 jed-bugzilla.redhat.com 2011-05-12 08:51:01 UTC
FWIW, I am also seeing this on Arch Linux, running gnome-terminal in KDE.

gnome-terminal-3.0.1-2
kdebase-workspace-4.6.3-1

Comment 18 Martin Edlman 2011-05-26 22:27:59 UTC
I have the same problem after upgrading from Fedora 14 to Fedora 15. All packages updated to the latest available version.

gnome-terminal-3.0.1-1.fc15.x86_64
xfce4-session-4.8.1-4.fc15.x86_64
xfce4-settings-4.8.1-4.fc15.x86_64
xfce4-panel-4.8.3-2.fc15.x86_64
xfdesktop-4.8.2-1.fc15.x86_64
xfwm4-4.8.1-2.fc15.x86_64

I noticed other strange behaviour. The Gnome terminal resizes itself even when changing a Style in Appearance settings. Especially when changing to/from he Adwaita style. Maybe it has something to do with change of fonts?

And other think I have noticed is that the look of the Gnome terminal doesn't match the selected Appearance Style. When I select the Xfce-4.6 style with light blue color as a background of a selection and round corners, I see this color and corners in every GTK/GNOME app but not i Gnome terminal where I see dark blue color and sharp corners.

So it's maybe some problem of .gtkrc or something like that. I tried to rename ~/.config and ~/.gconf, logout and login but it's still the same.

I'm quite disappointed with it. I updated to F15 as I expected it to be better than F14. :-(

I hope there will be a solution very soon.

Comment 19 Wolfgang Rupprecht 2011-05-27 13:25:38 UTC
I see the same thing, gnome-teminal resizes, but to much smaller both horizontally and vertically, also at startup. 

One additional data point, I have maximize-vertically bound to <super>-m (eg. menu-m).  For all other windows this works as expected.  For gnome-terminal it often also causes the auto-shrink instead of maximizing the window.  Maybe gnome-terminal has a bug where window resize commands trigger a string of resizes that results in a shrinkage?

Comment 20 Martin Edlman 2011-06-02 05:52:59 UTC
Additional info regarding the look. I realized that gnome-terminal (and more GTK/Gnome apps) are built on GTK3, while XFCE is built on GTK2. So XFCE settings manager manages GTK2 look.
I'm not sure it this GTK2-GTK3 issue might be the problem of shrinking of gnome-terminal, possibly not.

Comment 21 marty 2011-06-08 07:45:55 UTC
Hi!

I can confirm this for

gnome-terminal-3.0.1-1.fc15.i686
xfce4-session-4.8.1-4.fc15.i686
xfwm4-4.8.1-2.fc15.i686
xfdesktop-4.8.2-1.fc15.i686
xfce4-panel-4.8.3-2.fc15.i686

my gnome-terminal also seems to have no skin and resizes to 80x3 90% of the time, regardless of how i open it(alt-f2 / keybindings / menu). I had the impression that turning off compositing in xfwm-tweaks reduces the phenomenon, but it still happens sometimes.

Comment 22 CronoCloud 2011-06-12 20:45:46 UTC
I'm yet Another Fedora 15 XFCE user who has seen this.

Comment 23 Joachim Backes 2011-06-14 13:47:26 UTC
*** Bug 713055 has been marked as a duplicate of this bug. ***

Comment 24 Jiri Pirko 2011-07-12 08:30:31 UTC
I'm also experiencing this on f15 xfce on my mad run away from gnome :)

Comment 25 Aron Griffis 2011-07-26 13:52:51 UTC
No solution to this, eh? I'm seeing it too.

gnome-terminal-3.0.1-1.fc15.x86_64
vte3-0.28.1-1.fc15.x86_64
xfwm4-4.8.1-2.fc15.x86_64

As other posters have noted:

 * It starts happening as soon as you add a second tab to gnome-terminal.
 * It stops happening as soon as you reduce to a single tab (so the tab bar disappears).

It seems like a cycle between gnome-terminal and the window manager. Gnome-terminal is announcing a new size, the window-manager responds with a slightly different size, gnome-terminal adjusts and announces again, etc.

Comment 26 Seth D. Alford 2011-07-29 06:01:25 UTC
Yet another Fedora user seeing this with XFCE and gnome-terminal.  gnome-terminal opens at the size I specify and shrinks.  Yes, I know about XFCE's Terminal.  I would use XFCE's Terminal, except that I have not figured out how to make each Terminal have its own background and/or color scheme.  Changing one changes them all.

Comment 27 Colin Guthrie 2011-07-29 08:37:07 UTC
I've also seen this problem (not on Fedora here tho' - but I guess this is a common problem). I suspect things work fine under gnome-shell (unrelated issue is giving me problems logging in there right now) so it's likely some issue relating to it being run outside of it's "natural" habitat and just not covering such a case gracefully.

Comment 28 M J 2011-08-03 04:20:23 UTC
This bug needs to be increased in priority since it greatly affects workflow for a large number of users.

I'm running Fedora 15 x86_64 with XFCE as the desktop environment and I'm seeing this effect as well. 

It's worth noting that when using the pywo window placement program (http://code.google.com/p/pywo/) this effect also occurs after you place a window using the pywo move/resize key combinations.

Comment 29 Seth D. Alford 2011-08-03 05:13:51 UTC
I _may_ have a workaround.  It's somewhat kludgy, but workarounds often are.

Open a gnome-terminal.  Resize it manually.  Click Edit > Profiles... > New > [make up some name for it] > Create.  

I called my new profile beigeblack, because it's got black print on a beige background.  The edit-the-profile window opens. In the General tab, make sure you check the "Use the system fixed width font" and uncheck the "Use custom default terminal size" box.  Use the other tabs to edit the color scheme.  Close the edit-the-profile window.  Close the Profiles window.

In another terminal, run gnome-terminal with your new profile and your desired geometry.  _And_ add a --zoom factor.  E.g.:

gnome-terminal --profile=beigeblack --geometry=80x45 --zoom=0.98

This gives a slightly smaller gnome-terminal than without the zoom factor.  I  experimented a little bit with zooms of 1 and greater.  Anything between 1.0 and something less than 1.75 gives a larger gnome-terminal that shrinks.  Somewhere just below 1.75 and above, I get a larger gnome-terminal with a stable size.  I don't know where the exact cutoff is and I didn't feel like writing a script and opening a couple of dozen gnome terminals to see which zoom factor stopped the shrinkage.

Comment 30 Erik De Rijcke 2011-08-26 21:11:00 UTC
I think know the cause of the bug.

What happens is that gnome-terminal sends a request to the wm for a resize.
The wm does not fully respect this resize (for whatever reasons) and gives gnome-terminal a new size that it did not request. Instead of accepting this (as it should), gnome-terminal sends a new size request to the wm and the whole cycle continues.

I noticed this behaviour while writing my own wm. Gnome-terminal would ask a size, my wm would (incorrectly) assume that only multiples of the prefered increment size given by gnome-terminal are valid sizes. My wm would thus give gnome-terminal a size it did not request which triggered a new resize request of gnome-terminal. As soon as I fixed this bug in my wm solved the problem.

Comment 31 Matthew Miller 2011-09-15 16:53:48 UTC
I swear this was reported as an earlier bug, but I can't find it now. (And not the currently-marked duplicate.)

It used to happen on first window open, but that appears to be fixed. Now it mostly stays correct, but still does the funny shrinking act if you, for example, use the keyboard shortcuts to increase or decrease the font size.

Comment 32 Christoph Wickert 2011-09-19 18:52:12 UTC
The bug is actually in xfwm4, not in gnome-terminal. I am seeing the same with roxterm 2.x built with gtk3/vte3. The GNOME folks only accept is as a bug against GTK3 if you see the same with metacity/mutter, see
https://bugzilla.gnome.org/show_bug.cgi?id=649680

The bug was reported against Xfwm4 at
https://bugzilla.xfce.org/show_bug.cgi?id=7445

I have tested the fix mentioned in that report and it works. Taking over.

Comment 33 Fedora Update System 2011-09-19 19:46:13 UTC
xfwm4-4.8.1-3.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/xfwm4-4.8.1-3.fc16

Comment 34 Fedora Update System 2011-09-19 19:46:52 UTC
xfwm4-4.8.1-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/xfwm4-4.8.1-3.fc15

Comment 35 Joachim Backes 2011-09-20 01:51:55 UTC
> xfwm4-4.8.1-3.fc16 has been submitted as an update for Fedora 16.
> https://admin.fedoraproject.org/updates/xfwm4-4.8.1-3.fc16

Works for me: terminal no more shrinks.(In reply to comment #33)

Comment 36 Fedora Update System 2011-09-20 19:02:39 UTC
Package xfwm4-4.8.1-3.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xfwm4-4.8.1-3.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/xfwm4-4.8.1-3.fc16
then log in and leave karma (feedback).

Comment 37 Mike C 2011-09-20 20:20:46 UTC
Yes xfwm4-4.8.1-3.fc16 fixes the issue for me - great!

Comment 38 Christoph Wickert 2011-09-20 20:45:12 UTC
How about you all give feedback in the updates system at
https://admin.fedoraproject.org/updates/xfwm4-4.8.1-3.fc15 or
https://admin.fedoraproject.org/updates/xfwm4-4.8.1-3.fc16
to get the update pushed to stable faster?

Comment 39 Mike C 2011-09-20 20:58:45 UTC
Already done in my case for f16...

Comment 40 Martin Edlman 2011-09-21 14:06:21 UTC
I've upgraded to xfwm4-4.8.1-3.fc15 from updates-testing repo and gnome-terminal works as it did in Fedora 14. Wow, that's great. Thank you all guys who fixed it.

Comment 41 Wolfgang Rupprecht 2011-09-21 14:20:02 UTC
xfwm4-4.8.1-3.fc15 is buggy in a worse way.  It fixed the gnome-terminal auto-resize but broke the intentional resize when using window-manager keystrokes to resize horizontal size, vertical size or both to fullscreen.

Go to preferences -> window-manager -> keyboard
set the following:
Maximize window horizontally -> <super>h
Maximize window vertically -> <super>v
Maximize window-> <super>f

Under all previous xfwm4 versions on f15 the keystrokes worked to toggle the window size from the small window to fullscreen in the desired directions (h, v, or both).  Under xfwm4-4.8.1-3.fc15 this is broken.  The window grows to the max size as requested, but never shrinks back to the original size on the second keypress.  This is a worse bug than before.  One can always use a different terminal emulator, but not being able to resize windows quickly with a keystroke is a real pain in the posterior.

Comment 42 Martin Edlman 2011-09-21 14:40:51 UTC
I can confirm what Wolfgang Rupprecht noticed.

Vertical and horizontal maximize doesn't work. The window stays maximized on second and successive key presses (Ctrl-F9 for vertical and Shift-F9 for horizontal maximize in my case). Normal maximize (Ctrl-Shift-F9 for me) works as expected.

I noticed this behaviour on V/H maximize: on first key press window extends itself to nearly full width/height of the screen. Not full w/h as real w/h is calculated from increments I assume. The maximize/restore icon on top right corner stays "Normal". On the second key press windows extends itself to full width or height of the screen and icon changes to "Maximized". On the third key press window resizes back to the "nearly full" and icon changes to "Normal". From then successive key presses switch from "nearly full" to "full".

Full maximize maximizes the window to "full" screen (ignoring increments?), icon changes to "Maximized" and restore restores the window and icon to its normal size as expected.

I tried V/H maximize on non terminal application (gmpc), both work as expected, window is resized to full width/height, icon changes to "Maximized". On second key press the window and icon are restored to normal as expected.

Comment 43 Christoph Wickert 2011-09-21 14:56:05 UTC
(In reply to comment #41)
> Under all previous xfwm4 versions on f15 the keystrokes worked to toggle the
> window size from the small window to fullscreen in the desired directions (h,
> v, or both).  Under xfwm4-4.8.1-3.fc15 this is broken.  The window grows to the
> max size as requested, but never shrinks back to the original size on the
> second keypress.

I am using Alt+F10 for "Maximize Window" and I cannot confirm this: For me it toggles fine, vertically, horizontally and fully. Just to be clear: You press each key twice, you are not using the key for maximize to minimize a window that has been maximized horizontally/vertically, right? In this case the window shrinks back to it's initial size and I consider this the correct behavior.

Comment 44 Erik De Rijcke 2011-09-21 14:58:22 UTC
I'm not a xfce user myself, thus I don't encounter the bug directly. I do however know a thing or two about X and how clients are supposed to communicate with a window manager.

First of all:

A client that does not want to work with the size as set by the window manager by issuing a new configure request is *unacceptable* behaviour on the client's (gnome-terminal in this case) side.

I client should be able to give hints to the window manager about it's size, increments, minimum size. But in the end should cope with every possible size, even if that means displaying a text "I'm too small to display anything".
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.3

Btw, this is not me talking out of my ass, this is the ICCCM and EWMH talking.
http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.4

"Clients must not respond to being resized by attempting to resize themselves to a better size. If the size is impossible to work with, clients are free to request to change to the Iconic state."

And that's exactly what gnome-terminal is doing (So it's not an xfce bug perse)


I do realise the it is sometimes impossible to convince other dev teams of their wrongdoing but I hope that for a change they do the right thing istead of others implementing workarounds for other peoples *ahem* failing.

Comment 45 Wolfgang Rupprecht 2011-09-21 15:07:38 UTC
(In reply to comment #43)
> I am using Alt+F10 for "Maximize Window" and I cannot confirm this: For me it
> toggles fine, vertically, horizontally and fully. Just to be clear: You press
> each key twice, you are not using the key for maximize to minimize a window
> that has been maximized horizontally/vertically, right? In this case the window
> shrinks back to it's initial size and I consider this the correct behavior.

Yes, I'm starting with a small window that I'm trying to temporarily increase in size and then decrease again by pressing the exact same key a second time.  This behavior was observed with both the xfce native terminal (/usr/bin/Terminal) and gnu emacs.

Comment 46 Martin Edlman 2011-09-22 07:37:20 UTC
> First of all:
> 
> A client that does not want to work with the size as set by the window manager
> by issuing a new configure request is *unacceptable* behaviour on the client's
> (gnome-terminal in this case) side.
> ....

That's what I think too. The client should (or must) accept size assigned to it by WM. And I think that it's g-t issue it asks for different size repeatedly.

I observed the same maximize/restore problem with Terminal and xterm under xfwm4-4.8.1-3.fc15. First V/H maximize maximizes the window to "near full" size according to increments (calculated from font size?) but the window isn't marked as maximized (icon is "Normal"). Second maximize maximizes to "full" screen width or height instead of restore. And empty unused space appears on the right between the last column and window frame. And that's wrong.
I've reverted to xfwm4-4.8.1-2.fc15 to see how V/H maximize behaves there. It works as expected. Tested on Terminal and xterm (g-t sucks there). On maximize the window is resized to "near full" size according to increments, but is marked as maximized (icon is "Maximized"). On second key press the window is restored to its original size. I've tried to change font size and maximize/restore, it's always working right.
My conclusion is that xfwm4-4.8.1-2.fc15 works perfectly with standards conforming clients but not with g-t. I'm staying with xfwm4-4.8.1-2.fc15 and Terminal.

Comment 47 Christoph Wickert 2011-09-22 08:07:04 UTC
Hold on: So you have the problem that an application no more shrinks (this means the second keystroke no longer works) only with gnome-terminal? I have to admit I didn't test this one since I don't use it. All other apps I tested work fine and for me xfce4-4.8.1-3 works just like xfce4-4.8.1-2. If it is only this particular application that is still causing problems, then we indeed see a bug in gnome-terminal.

Comment 48 Martin Edlman 2011-09-22 10:57:28 UTC
(In reply to comment #47)
> Hold on: So you have the problem that an application no more shrinks (this
> means the second keystroke no longer works) only with gnome-terminal? I have to
> admit I didn't test this one since I don't use it. All other apps I tested work
> fine and for me xfce4-4.8.1-3 works just like xfce4-4.8.1-2. If it is only this
> particular application that is still causing problems, then we indeed see a bug
> in gnome-terminal.

No I see this V/H maximize bug in all terminals (g-t, Terminal, xterm, ...) maybe it affects other apps which hint increments to xfwm4. Other apps maximize/restore normally. So it's indeed a bug introduced to xfwm4-4.8.1-3 by last changes.

Comment 49 Colin Guthrie 2011-09-22 11:01:30 UTC
FWIW, I've seen this same problem (g-t shrinking) on KDE as well, so it leads me to believe that the problem is indeed in g-t. Not tested in the last few months (and not on fedora either), but it seems to me like an issue outside of xfce.

Comment 50 Martin Edlman 2011-09-22 11:10:23 UTC
That's right, g-t has the problem in other WMs. It may not shrink in Metacity, but from what I know it's the only WM where it works. Maybe there is a workaround in Metacity or even a bug which eliminates/negates the g-t bug. 
I think the problem is in g-t and not xfwm4. And as Erik pointed g-t dev team shoud take care of it and don't blame other dev teams.

Comment 51 Christoph Wickert 2011-09-22 11:47:39 UTC
(In reply to comment #50)
> And as Erik pointed g-t dev team
> shoud take care of it and don't blame other dev teams.

Best way to achieve this is to add your comments to 
http://bugzilla.gnome.org/show_bug.cgi?id=649680

Comment 52 Fedora Update System 2011-10-03 18:07:03 UTC
xfwm4-4.8.1-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 53 Fedora Update System 2011-10-06 00:04:02 UTC
xfwm4-4.8.1-3.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 54 Martin Edlman 2011-10-06 06:55:32 UTC
Was it pushed to stable repository regardless of the problem with vertical/horizontal maximize?
I don't like this approach - pushing problematic update with known bug to stable repo it a bad way. I don't want my xfwm4 to be updated to this bugged version. 
According to gnome bugzilla it seems that whole problem with window autoresize is in gtk3. I hope they'll fix it asap. 
I'd rather use current xfwv4 with working V/H maximize and avoid using g-t and other gtk3 apps which hint increments to the WM.

Comment 55 Wolfgang Rupprecht 2011-10-06 07:07:07 UTC
Why was this buggy program pushed to stable?  Does fedora no longer have rules to forbid this sort of thing?

Comment 56 Christoph Wickert 2011-10-06 07:32:37 UTC
(In reply to comment #54)
> Was it pushed to stable repository regardless of the problem with
> vertical/horizontal maximize?

Because several people, one of them being a proven tester and one of them the package owner, could not reproduce the problem.

> According to gnome bugzilla it seems that whole problem with window autoresize
> is in gtk3. I hope they'll fix it asap. 

So did you speak up in their bugzilla?

BTW: The fact that you are having problems with *all* terminals, e.g. with Terminal, too, means that your logic cannot be correct. Terminal uses neither gtk3 not vte3.

Comment 57 Martin Edlman 2011-10-06 08:22:18 UTC
> Because several people, one of them being a proven tester and one of them the
> package owner, could not reproduce the problem.

Did they try using various font sizes? Did they try it on various screen resolution? In Terminal I use DejaVu Sans Mono Book font, size 9. screen resolution 1600x900. The V/H problem arises (possibly) because first V maximize in my case don't fit to 1600px but (let's say 1594px) and from then successive maximize/restore switch between 1600px and 1594px.

> So did you speak up in their bugzilla?

Yes I did report it, see https://bugzilla.gnome.org/show_bug.cgi?id=649680

> BTW: The fact that you are having problems with *all* terminals, e.g. with
> Terminal, too, means that your logic cannot be correct. Terminal uses neither
> gtk3 not vte3.

No, the problem is *only* with g-t and other gtk3 apps which hint the WM. There is no problem with Terminal and other gtk2 apps. And I wrote this several time in this thread...

Comment 58 Fedora Update System 2011-10-15 14:31:19 UTC
xfwm4-4.8.1-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/xfwm4-4.8.1-4.fc16

Comment 59 Fedora Update System 2011-10-15 14:32:08 UTC
xfwm4-4.8.1-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/xfwm4-4.8.1-4.fc15

Comment 60 Christoph Wickert 2011-10-15 14:38:48 UTC
(In reply to comment #57)
> Did they try using various font sizes? Did they try it on various screen
> resolution? 

No, because you didn't tell them to do so. If you want people to reproduce your problems, please give detailed instructions.

I still think that my decision to push 4.8.1-3 was right. It fixed more problems than it caused. This is what both the testers and upstream say.

Meanwhile upstream released another fix (after I spoke up, not you) and the latest updates should fix your problems. Please test them ASAP because the final change deadline for F16 is only a few days away.

Comment 61 Martin Edlman 2011-10-17 06:39:36 UTC
(In reply to comment #60)
> (In reply to comment #57)
> > Did they try using various font sizes? Did they try it on various screen
> > resolution? 
> 
> No, because you didn't tell them to do so. If you want people to reproduce your
> problems, please give detailed instructions.

Ok, maybe it was my fault, but I (wrongly) supposed that when I described the behaviour that the developers would try various settings which might cause the problem.

> Meanwhile upstream released another fix (after I spoke up, not you) and the
> latest updates should fix your problems. Please test them ASAP because the
> final change deadline for F16 is only a few days away.

I have updated to xfwm4-4.8.1-4 and these are my observations:

- Terminal (and hopefully other GTK2 increment hinting apps) - everything seems fine. V/H maximize/restore works as expected. There is only one glitch. When I do V max, then H max I have full max which is ok, but when I then H restore I get original size, not V maximized. But this is not a big issue and I can live with it.
- Gnome-terminal (and possibly other GTK3 increment hinting apps) - there is still problem. 
  1. open g-t - OK
  2. V maximize to width1 (w1) which looks right - OK
  3. V restore - FAIL. Doesn't restore the width of the window but decrements the height of the window by one line. Repeating V restore decrements the height until it's 3 lines. 
  4. Next V restore stops decrementing height and maximizes to width2 (w2) which is bigger than w1 and max/restore icon changes to Maximized.
  5. Next V restore "restores" the width to width3 (w3) which is lesser then w1 and max/restore icon changes to Normal.
  6. Next V restore maximizes from w3 to w1 (icon stays Normal), then from w1 to w2 (icon Maximized), then from w2 to w3 (icon Normal) and again...

Same with H maximize. As I stated before, I still think that it's the problem of GTK3 as suggested by others in gnome/gtk bugzilla.

Tested on 1600x900, g-t 3.0.1, font Monospace 9.

Comment 62 Christoph Wickert 2011-10-22 20:41:28 UTC
I propose this bug for F16-accepted because it annoyed quite some people as you can see in this bug report.

Comment 63 Adam Williamson 2011-10-25 01:43:07 UTC
it should make the final pre-freeze stable push without being declared nth, but I vote +1 anyway. it's an annoying bug which can be hit in live boots.

Comment 64 Fedora Update System 2011-10-25 03:41:09 UTC
xfwm4-4.8.1-4.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 65 Danilo Marcucci 2011-11-09 11:56:09 UTC
I have installed yesterday the Fedora 16 and try the same problems. After that i have lunched the Terminal from "K" Menu --> System --> Terminal this started width 80x24 and immediately shrunk to 35x4
On this Fedora there is installed xfwm4-4.8.1-5.fc16.i686.rpm.

There isn't problem to use "terminal emulator" /usr/sbin/Terminal

Comment 66 Christoph Wickert 2011-11-09 12:47:26 UTC
(In reply to comment #65)
> After that
> i have lunched the Terminal from "K" Menu --> System --> Terminal

If you started it from the K- Menu, you are using KDE. Please file a bug against kwin in the kdebase-workspace package.

> There isn't problem to use "terminal emulator" /usr/sbin/Terminal

There is no such thing as /usr/sbin/Terminal, it's /usr/bin/Terminal.

Comment 67 Fedora Update System 2011-12-11 21:54:28 UTC
xfwm4-4.8.2-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.