How do I unsubscribe??? I followed the instructions at: http://gnome-apps.13852.n7.nabble.com/mailing_list/MailingListOptions.jtp?forum=22338. But I continue to receive messages from the Pan mailing list.
On Fri, Jul 3, 2015 at 2:22 AM, Duncan <1i5t5.dun...@cox.net> wrote: > walt posted on Thu, 02 Jul 2015 08:34:34 -0700 as excerpted: > > > About once a year I get bored enough to try to fix this ancient bug in > > pan's behavior and every time I conclude that gtk is a horrible mess, > > designed by the devil to torture innocent soft- ware developers. > > > > Anyway, here's the behavior that I consider to be wrong: > > > > When pan displays an image (typically a jpeg) in the body pane, > > if the image is is too large to fit properly then the body pane somehow > > manages to enlarge the entire pan window enough so that it's too big to > > fit on my monitor screen. > > > > I think, in general, that a child window should never resize a top-level > > parent window under any circumstances, so this should be fixed. I keep > > looking at the code but I don't understand it enough to fix it myself. > > > > Anyone else have any clues? > > > > Thanks. > > > > BTW, note that the body pane already has a scroll-bar to allow the user > > to view the entire image, so resizing the top-level window is completely > > unnecessary in any case. > > What OS/window-manager are you using, and do you have pan's main window > setup with any custom rules? And do you have pan set to size images to > fit by default, or not? > > I ask because I've /never/ seen pan behave like that, here, running kde4/ > kwin4. I do have some custom window rules setup for pan's main window, > but I'm not forcing height, tho I am forcing width. > > (The following takes my usual long, "scenic route" approach, to the reply > at hand. Just sit back and enjoy the scenery. We'll get there > eventually! =:^) > > While most of the time I don't do binary groups, mainly only some > primarily textual technical mailing lists like this one via gmane's > list2news service, I did sign up for a huge 1 TB (10-power) block from > astraweb for $50 a couple years ago, so I have binary access, and I do > use it occasionally, tho at my usage it could last me well over a decade, > perhaps even several... my lifetime (which is why I went big, despite low > general use, for $50 it doesn't expire, and I may well never have to > worry about buying more access ever again, even if I live several more > decades!). > > Between the occasional binary/images groups usage and the occasional > screen shot on the technical groups, I get enough images that if the pan > main-window-resizing was a problem, I'm sure I'd have seen it, but I > haven't... > > FWIW, here's my relevant settings: > > Pan: view > body pane > size pictures to fit : checked > > (But IIRC, last I used the toggle with a large image, it gave me scroll > bars as expected.) > > KWin window rules: > > Match tab: > > Window class: substring match: "pan pan" > Window role: exact match: "pan-main-window" > Window type: normal window > Window title: substring match: "Pan" > > Size & Position tab (see explanation): > > Position: apply initially: 0,2180 > Size: apply initially: 1920,1060 > Maximized horizontally: force: yes > Initial placement: force: no placement > > (Nothing set on the other tabs.) > > Explanation: > > My desktop consists of three full-hd monitors, 1080x1920 resolution, > logically stacked for 1920x3240 total resolution. The two lower > monitors, my normal working space, are actually big-screen TVs, a 48-inch > (122 cm) on the bottom, with a 42-inch (106 cm) above it, logically in > the center. That's actually the wall at the foot of my bed. =:^) > Logically above them but physically off on the right side wall, is my > third monitor, actually left over from before my big-screen upgrade; > while the same resolution, it's only a 21-inch. > > The small top (actually right) monitor is my system status dashboard, a > superkarumba theme with real-time per-second-sampled line graphing per- > core multi-category cpu usage (user/system/nice/io-wait/total), multi- > category RAM usage (app/buffer/cache/total), voltage/fan/power/temp > readouts, network usage, and displaying top apps by cpu and memory usage > and the last 20-ish general syslog entries. > > That superkaramba theme display window is full-width, almost full height > of that monitor, "almost", because if I have the other two monitors full, > sometimes the narrow bit at the bottom of that monitor is the only bit of > the actual desktop I can access, I have plasma set so vert-scrolling the > desktop changes vertical desktops, and that's the usual way I do so (tho > I also have hotkeys for it), so I need access to at least a /small/ bit > of the desktop in ordered to switch desktops. > > The two big-screen monitors, then, are my normal workspace. Actually, > the bottom one is, with the middle one (the 42-inch) being aux/overflow. > Often, I'll have youtube playing full-screen on the 42-inch middle > monitor, while I actually work in the bottom (48-inch) one. > > FWIW, here's a screenshot (which I've posted here before, IIRC), now a > couple years dated but it'll give you an idea. Just imagine the top > third off to the side, on a normal size computer monitor, while the > bottom two thirds are my main workspace on the wall in front of me. In > it, pan (open to a kde list/group on gmane) is on the middle monitor, > with my claws-mail feeds instance open on the bottom monitor, with > firefox/aurora open behind it, half-width. > > http://wstaw.org/m/2013/05/11/duncan-fullscreen.png > > > OK, now that you have a general picture of my desktop in mind, I can > better explain the kwin size and position settings I use for pan... > > In general, I want pan open at full width (horizontal maximized), but > not /quite/ the full height of the monitor, with it starting on the > bottom monitor. In the screenshot, the claws feed instance, with firefox > open behind it, illustrates the reason behind the _almost_ but _not_ > _quite_ full height. I use a mouse policy of (sloppy) focus follows > mouse, click-to-raise. With pan (or claws in either feeds or mail mode) > in three-pane-mode, I need full-width to get all three panes on-screen > without crimping on header or body display area. The /almost/ full- > height, bottomed on the monitor, leaves just enough room for a title-bar > to stick out above. That arrangement, with vertically maximized (to > monitor) half-width browser, compose-window, and terminal (konsole) > windows, combined with window transparency set just so, lets me work with > upto three windows visible on the monitor at once. In particular, I can > have the almost-maximized window in front, with another half-width window > or two behind, set so I can make any of the three active and type into > them, while still viewing the others. At a click I can bring any of the > three to the top, and as long as I don't bring both half-width windows to > the top at the same time thus hiding the full-width window, I can > continue to work with all three at once. > > Of course, this is usually on the bottom monitor, leaving the middle one > for either more reference windows (normally full-height, half-width, so > two, side-by-side), or for that full-screen youtube or the like. > > So, a pan size, applied initially, of 1920x1060, with horizontally- > maximized forced on, and position, applied initially, of 0x2180, sizes > and positions pan exactly as you see claws positioned in the screenshot, > at the bottom of the bottom/primary-working monitor, with just enough > room above pan for the titlebars of two full-height, half-width windows > to stick out. > > The applied-initially on the (vertical) size and position let me move pan > to the aux monitor if desired, or, occasionally if I'm browsing the > images groups, expand pan vertically to cover both working monitors, > which if I toggle the groups pane off, gives me full 1920 width for image > display, with a tall enough (2160 px) window I can still have a few > headers showing in the headers list, while leaving the rest for image > display. I can then either have the body pane taking the full bottom > monitor with the middle one for headers, giving me full-HD resolution > image viewing in landscape mode, or, if some images are portrait mode, > increase the body pane size a bit further at the expense of shrinking the > number of headers displayed, to give portrait mode images a bit more room > to display. > > Meanwhile, the forced horizontal-max means my header column widths don't > get screwed up as pan is always full-display-width. =:^) And the forced > no-placement avoids the smart-window-placement that could otherwise > override the apply-initially positioning. > > (We'll forget about, for now, the other pan/gtk bug where it sometimes > initializes column widths to zero, my guess being that it has to do with > a gtk-icon resource loading race. That always screws up column widths. > Unfortunately, I'm not enough of a coder to fix it properly, but > fortunately, I've scripted a workaround for it that patches the zeroed- > out column config, such that when it happens, I only have to shutdown and > restart pan, and it automatically fixes the problem for me.) > > > So... Obviously I occasionally deal with images larger than my standard- > size body pane, or I could simply set the size to forced instead of > apply-initially. Equally obviously, I'm not seeing pan resize itself > displaying those images, because if it were to do so, I'd have been > annoyed enough to set kwin to force size anyway, thereby stopping the > problem. The fact that I've not done so confirms my memory of never > having that happen, thereby provoking the annoyance that would have lead > to setting kwin to force the size. > > > So... it's not happening here. Possible explanations/solutions: > > 1) It's some weird interaction between your window manager and pan. > > S: Try a different window manager, or configure your window manager to > avoid that interaction or force the size. > > 2) If pan is maximized, at least horizontally, the bug doesn't trigger. > > S: Set pan maximized, at least horizontally. Consider configuring your > window manager to force it, if necessary. If your window manager lacks > such configurability, consider switching window managers to something > that has it. > > 3) If pan's size, likely width, is over some minimum, the bug doesn't > trigger. Various people have reported issues with pan when run on > extremely low resolution, typically under 1280 or 1024 px width, > screens. One problem, I believe now fixed, was that pan wouldn't resize > smaller than its toolbar width. Given the number of icons in the toolbar, > it was wider than 1024 px, and people on netbooks with displays narrower > than that really had problems. Perhaps it can be resized smaller than > that now, but certain conditions, including large images, triggers a > resize larger, once again. > > S: Configure the window manager to force width. See #2's solution if > your window manager can't be so configured. > > 4) It doesn't trigger if pan is set to size images to fit. > > S: This one's easy to check, and to use as a workaround if it helps. > Simply toggle that setting, as mentioned above, in the view menu, body > pane submenu. =:^) > > 5) It's a gtk3 problem. While pan has nominally been ported to build and > use gtk3 instead of gtk2 for many years now, a gtk2-based build is still > very much recommended as there continue to be various strange and > unresolved bugs reported by folks running pan built against gtk3. Of > course the bugs remain unresolved because the users with enough knowledge > to fix them simply build pan against gtk2 as recommended when the find > such a bug, instead of bothering to trace it down and develop and submit > a patch for it, but there you have it. > > If you're running a gtk3-based pan-build, this is very likely one of > those "strange and unresolved" gtk3-related bugs! I'd definitely call > this the prime suspect if your pan is gtk3 based. > > S: Build pan against gtk2, not gtk3. Or either find and fix the gtk3 > related bug, submitting a patch as appropriate, or file it with your > distro building it against gtk3 so hopefully they will either find and > fix the bug and submit a patch, or switch back to building against gtk2. > > (FWIW, firefox being in the position it's in, even if chrome/chromium is > gaining share, with it still gtk2-based by default, few distros will > remove gtk2 entirely, tho they might well deprecate it, building what > they can against gtk3 and making gtk2 a dependency only installed if > firefox or other remaining gtk2-based packages are installed to pull it > in.) > > 6) Something else I didn't think of? > > -- > 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 >
_______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
