Re: [Pan-users] Amusing gtk3 bug in latest git :)

[Duncan]

walt posted on Tue, 09 Oct 2012 22:14:15 +0000 as excerpted:

> I deleted all lines from preferences.xml concerning download limits and
> re-started pan.  There was no problem with being 'offline' this time, so
> that particular gotcha is fixed.

Good! =:^)

> But (so far) I see no way to set the download limit or to go offline if
> the limit is exceeded.  Heinrich, is that expected behavior for now?

That was easy and entirely intuitive for me, but after a decade of use, 
it's entirely possible pan's UI has warped my brain a bit, or at least 
what I consider "intuitive".  =:^)

The key (at least in gtk2 pan, I'd suppose gtk3 pan works the same in 
this regard) is to remember the status bar.

If that's not hint enough, note that its various segments are clickable. 
=:^)  

If that's not hint enough, consider: Clicking on the task display segment 
brings up the task list.  Clicking on the log-status icon brings up the 
events log, and clicking on the DL meter brings up... you guessed it. =:^)


That said, it is the case that the other windows can be activated from 
their relevant menu entries as well, and the first place I looked for it 
when the original offline issue happened was pan prefs as I reasoned it 
belonged there, to no avail, but a quick look around pan at where it 
appeared... STATUS BAR!!  <click>  Ta-da!  Intuitive enough for me! =:^)

But I really did expect to find it in preferences.   Actually, tracking 
it per server and making the setting part of server prefs is probably the 
best solution, given pan's multi-server nature and the fact that 
different accounts will almost certainly have differing download caps.

But it's possible per-server tracking isn't easy to code.  Or more 
likely, the thought simply didn't occur to Heinrich and wasn't mentioned 
in the enhancement request bug (which I looked at briefly after seeing it 
mentioned in the git log entry for that commit, but didn't actually read 
well enough to know whether it suggested per-server or not).

> I also have problems with the pan window resizing itself to be too wide,
> and it won't let me narrow the window width again to the size I want it.
> 
> That is (old) gtk3-specific behavior, though.  I've been wondering if
> it's a change in the gtk3 API or just a bug in gtk3.  Anyone else seeing
> this problem?  It's been around since pan first built against gtk3.

I'm building pan against gtk2 so if it is indeed gtk3 I've not seen it.  
But I'm wondering if what you're seeing is related to either/both:

1) The pan prefs dialog suddenly deciding it wants to be extremely tall, 
here, extending WAY offscreen.

FWIW I have two monitors in stacked config, here, with kde/kwin window 
placement and maximization configured to single-monitor.  It appears that 
pan/gtk is taking the full DESKTOP size, across both monitors, 
subtracting any panel/dock-window sizes, and calling that the MINIMUM 
height of pan's pref dialog.  Since the lower monitor is my primary work 
display, and window placement occurs on it when that's where the cursor 
is pointing, the resulting prefs dialog appears on the bottom monitor, 
but extending well offscreen since it's sized vertically to cover both.  
Because that's the MINIMUM size, the window won't resize smaller than 
that.

So I forced it using kwin's window rules, checking force-size and setting 
something arbitrary but much more appropriate.  At first that didn't take 
and I had to both force ignore requested geometry and/or force-disable 
obey geometry restrictions, but after getting it back to a sane forced 
size, I was able to uncheck the latter two and it stayed, but I still had 
to keep the forced size in place.

FWIW it's very nice to have a window manager with per-app and per-window 
override rules like that, and it's a kwin feature I REGULARLY take 
advantage of, with over two dozen individual default-override window/app 
configurations. =:^)


That has to be a bug in gtk, probably due to some bit of pan's prefs 
dialog code being other than what gtk expects and gtk sanity checking 
constraining to desktop size, but choosing the whole desktop instead of 
the maximize-to size, which is just one screen.  There was a git log 
entry that said something about fixing it (I /think/ that's what it was 
alluding to), but I think there was more to the problem than got fixed...


2) See the thread about squished header pane columns.

That one appears to be a race-condition based on a resource (icon, 
apparently) failing to load in the required time.


Your width bug, the column width bug, and my prefs height bug, may well 
be related to the same root gtk bug, or may not be, especially since 
you're on gtk3 and I'm on gtk2.  But presuming its the same folks writing 
the code for both and that they might have backported a new gtk3 feature, 
it's quite possible.

Certainly, they're all rather strange size related bugs, and that's quite 
a run of similarly size related bugs to have in such a short period, if 
at least two of the three aren't related in some way.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman