Camaleón posted on Mon, 02 Aug 2010 11:04:55 +0200 as excerpted: > I'm facing the following problem: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568659 > > (the bug includes an image describing the issue) > > At first, I thought this could be caused by the Pan version that is > included in Debian Lenny (0.132), but I've recently installed Debian > Squeeze (which includes Pan 0.133) and it happens the same. > > Any hints on how to solve/bypass this? It's quite annoying having to > resize and relocate the window every time :-)
[For the record and for those who don't wish to bother checking the link, the complaint isn't with pan's main window, but with the posting window.] FWIW, while pan's in the gnome repo and uses their bugzilla, and back with gnome 1, was a gnome app, since the port to gtk2 back with IIRC 0.12, it has been a gtk2 app, not requiring the full gnome install. So it's not really a gnome app, but a gtk app. This is important for those of us who prefer kde (or other DE than gnome) in general, and wouldn't have pan installed if it were to drag in all those extra gnome dependencies. (The bug implies it's a gnome app, comparing it to "other gnome apps".) Meanwhile, I don't know what window manager you're using, but at least kde's default kwin, has a method by which one can specify specific apps or windows and the non-default behavior one might wish them to have. Years ago, when pan was under active development (it isn't so much any more), I requested and got Charles to properly fill out the window role fields for pan windows, so I could distinguish between the pan main window and the others (posting window, etc) and force the main window to a specific behavior (maximized horizontally, almost but not quite maximized vertically, no titlebar or border, and located just down the display a bit, so other window titlebars would peak out the top and I could switch to them by just clicking the titlebars, and to the pan main window again by just clicking it, since it's horizontally maximized and thus sticking out the side), without forcing all the other pan windows to the same size, location and behavior. So assuming your window manager has the ability to set behavior for specific apps and windows using the window class, role and title characteristics, use that. Pan has supported it for years, due to Charles filling my request. =:^) Beyond that, window placement and sizing is a cooperative effort between the window manager and the window itself. The window can (and often does) request a specific size and location (and other behavior, such as borderless, always-on-top, etc), but that's simply a recommendation to the window manager, which can ignore it and place it wherever it wants, at whatever size, and the window must cope with that, adjusting its internal layout accordingly, or making it hard on the user, when it fails to do so. As for the posting window, I've noticed that its requested width, at least, appears to be determined by the size of the font -- it tries to be wide enough to display a full 80-char normal width line, with comfortable margins on either side. Increase the size of the font, and the posting window should increase its default width accordingly. Decrease the font, and at least down to the size of the toolbar, pan accordingly decreases its requested posting window width. That seems about ideal, to me. Vertically... I too find the posting window size a bit short. Fortunately, recent kwin versions have an option that when active, allows one to drag the window to either side, and it'll tile to maximized vertically, half-width horizontally (slightly larger than the default width, here, so it's fine, folks with smaller displays may find the drag- to-top-to-maximize option more useful, tho I don't like that one and have it disabled). Before that, I had a kwin setting for the posting window size, as well, but I've been able to delete it since the half-width full- height drag-to-side tiling feature of kwin 4.4. Meanwhile, it seems pan saves the geometry of most of its windows, and of the internal panes of the main window, in its preferences.xml file. Unfortunately, the posting window size and possibly location, seems to have been overlooked. I'd call that a bug, but as mentioned above, pan's not really in active development any more. However, there's a guy here in the pan community, K Haley, that has been running his own git repository, collecting the various useful community patches out there, and coding up some of his own. There's a number of other useful patches in his version that aren't yet in an official released version (some are in the official repository, unreleased, some not), as well. If you're upto it, install git if necessary, pull from his repo, and compile pan for yourself. =:^) That's what many regulars in this group are doing. There's no patch to save and use posting window size yet, and I'm not a coder so no guarantees, but it does sound like it should be a reasonably trivial patch, especially since the code is already there and used by other windows, and such a patch does seem to pass the usefulness test, so I'd not be surprised at all to see that feature in khaley's git repo quite soon, now that the request has been made. =:^) "'Sup" to you! Here's the git:// URL. =:^) git://github.com/lostcoder/pan2.git -- 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 http://lists.nongnu.org/mailman/listinfo/pan-users