Bug 1382869

According to Richard Hughes' comment # 1 in bug 772340 of bugzilla.gnome.org the default is to fullscreen an app if its initial size is very similar to the display size, so the question is: Can you make it to work that way instead?

Any progress on this?

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Is there a specific reason why you need it larger or smaller?

Something like that would ideally be supported in the window manager/compositor, but you’d be hard-pressed to find one that can do it and do it reliably.

(In reply to Ernestas Kulik from comment #4)
> Is there a specific reason why you need it larger or smaller?

The point is, the application should save the last state of the window, for example, if I maximize the window and then close it, the next time I open the app it should appear maximized, there are Gnome apps with the same problem like Gnome Settings, Gparted, Gnome Calculator, and others where the state of the window is not saved after we close it.

No, it shouldn’t. :)

I’m asking for your use case. If you can’t provide that much, we can’t implement it.

I added myself to the cc: of this bug because I also would prefer the window when reporting a bug would stay larger. At the moment, I find myself always resizing (enlarging) the reporting/logging window when reporting a bug. Not a big deal, but still a small annoyance every time I report a bug.

(In reply to Jan Vlug from comment #8)
> I added myself to the cc: of this bug because I also would prefer the window
> when reporting a bug would stay larger. At the moment, I find myself always
> resizing (enlarging) the reporting/logging window when reporting a bug. Not
> a big deal, but still a small annoyance every time I report a bug.

Are you talking about the actual reporting? gnome-abrt only provides the window that gives you the overview of the problems. Once you click “Report”, it’s off to libreport.

> Are you talking about the actual reporting? gnome-abrt only provides the
> window that gives you the overview of the problems. Once you click “Report”,
> it’s off to libreport.

I'm referring to the window once you click "Report". But I think the original reporter meant the window with the overview of the problems.

I tried to test the size at which the overview window opens by default, but it opens always maximized for me. I have a dual display setup. When I open ABRT, the window first appears shortly maximized on my secondary display, and then it jumps maximized to my primary hidpi display that has 125% fractional scaling.

(In reply to Jan Vlug from comment #10)
> > Are you talking about the actual reporting? gnome-abrt only provides the
> > window that gives you the overview of the problems. Once you click “Report”,
> > it’s off to libreport.
> 
> I'm referring to the window once you click "Report". But I think the
> original reporter meant the window with the overview of the problems.
> 
> I tried to test the size at which the overview window opens by default, but
> it opens always maximized for me. I have a dual display setup. When I open
> ABRT, the window first appears shortly maximized on my secondary display,
> and then it jumps maximized to my primary hidpi display that has 125%
> fractional scaling.

How big (in terms of resolution) are your screens? The default is, IIRC, 1024x768.

primary: 3840x2160 (150% scaling)
secondary: 1680x1050 (150% scaling)

I'm mainly using the high resolution screen.

(In reply to Ernestas Kulik from comment #7)
> No, it shouldn’t. :)
> 
> I’m asking for your use case. If you can’t provide that much, we can’t
> implement it.

Everytime I open the app I have to maximize it, why doesn't stay that way? other apps like Nautilus always opens maximized.

Speaking of the second window that appear when I click on report button, why the text inside doesn't stay within the window? there is one part of the text that goes beyond the border of the window and I have to scroll to the right to read what it says, even if I maximize it, the text doesn't adjust to the current window size.

(In reply to Ricardo Ramos from comment #13)
> (In reply to Ernestas Kulik from comment #7)
> > No, it shouldn’t. :)
> > 
> > I’m asking for your use case. If you can’t provide that much, we can’t
> > implement it.
> 
> Everytime I open the app I have to maximize it, why doesn't stay that way?
> other apps like Nautilus always opens maximized.

Deflecting with a question doesn’t help here. Nautilus works that way, because it has settings to control the initial window state.

> Speaking of the second window that appear when I click on report button, why
> the text inside doesn't stay within the window? there is one part of the
> text that goes beyond the border of the window and I have to scroll to the
> right to read what it says, even if I maximize it, the text doesn't adjust
> to the current window size.

That is libreport. File a new bug for it.

(In reply to Ernestas Kulik from comment #14)
 
> Deflecting with a question doesn’t help here. Nautilus works that way,
> because it has settings to control the initial window state.

That's what I'm asking or requesting in this "Bug" report.

This is not going to happen.