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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
