Re: FVWM: Menu selection when hotkey is unique to a particular item
Thomas Adam writes: > > > > Way cool dudeski, thanks! > > What about now with the attached patch? > Yep. Checked both settings of the option, and the behavior seems to toggle appropriately. Thanks again for your responsiveness on this. This option now allows even more mimic-compatibility with my old favorite WM, olvwm. :) I have a minor beef with the way it's documented though. I'll send a suggested wording change diff later this evening, but have to run out for a few hours now. Btw, there's a subtle side-effect of the new mode; not a problem at all, just something to be aware of: In the original (now default) mode, if a hotkey is uniquely associated with a submenu entry, then as soon as that hotkey is pressed, the submenu pops and the pointer warps to the top entry of the invoked submenu. Thus, since the pointer has warped to the submenu, subsequent hotkey presses "automatically" apply to the submenu, so to speak. In the new mode (i.e. !HotKeyActivates...) the submenu pops, but the pointer remains over the original menu entry (and sensibly so, since in the new mode, the item hasn't yet been invoked) and thus subsequent hotkey presses apply to the original menu, not to the just-popped submenu. I'm not implying there's anything wrong with this; just pointing it out, because it confused me a little when I was testing it and toggling back and forth between the two modes. It's entirely consistent with the change in selection semantics for the subcase of a uniquely associated hotkey.
Re: FVWM: Mysterious invocation of fvwm-menu-desktop
-- Thomas Adam [2011-08-22 18:20:50 +0100]: > > How are you getting on with this? > Have still been extremely busy. But honestly, also a little concerned about your response to my prior message, and because of that, somewhat lacking in enthuisiasm for the task. I'll write you a letter sometime this coming weekend and explain. Did you receive "Teddy-the-Bear" yet?
Re: FVWM: FAO: Thomas Adam - list attitudes and unveiling the person behind email
-- My 2c, as a relatively new list member. I too think highly of Thomas; he's generally quite helpful on the list, and capable of being a very nice and warm fellow. He seems to be extraordinarily dedicated to the project. But in my interactions with him on the list and off, he has also occasionally exhibited some behavior that I find objectionable, enough so that it has made me think twice about becoming involved as a contributor (which was part of my original intent when I joined the list a few months back). It's possible to like and respect someone, yet be leery of wishing to work directly with them. Thomas is aware of my beefs with him; we've discussed it frankly. In fact, we've been exchanging emails recently, discussing (among other things) alternative ways that I might be able to contribute that would put me less in the "line of fire" of the behaviors that I find troublesom. It's been a respectful, constructive discussion. We'll see what happens. Glenn
Re: FVWM: FAO: Thomas Adam - list attitudes and unveiling the person behind email
-- Hi Dr. Klepp, Mag. Dr. Nikolaus Klepp [2011-09-01 09:19:16 +0200]: > > You may like it or not: This list is professional. > Agree in general, but there have been occasional excursions. >From time to time, I've participated in (and occasionally chaired) various professional working groups with technical mailing lists similar to this one (IEEE 802, ancient CCITT). Some of the sarcastic/dogmatic language that has occasionally been encountered on the FVWM list would probably have raised hackles in those venues, and resulted in chastising of the moderator by the chair. > > If you look for tender loving care you will not get it. > That's right; this is a technical forum, not a place to come for warm and fuzzy peer approval. But there's another point to be made here, and I hope you'll hear it. Most people coming to this list are doing so to have problems solved; and for those people, if they encounter a bit of Thomas' occasionally abrasive language during that process, well that's just too bad. Just as you said, TLC isn't on the menu here. It's the price one pays for having received Thomas' technical attention and assistance. Thomas is who he is, a bit of a curmudgeon sometimes, and if you want his usually excellent help, you have to accept this. On the other hand, someone coming to the list with an eye toward contributing has a bit of a different view. They must ask themselves: Do I want to work on a regular basis with a person who, even though they may be a lovable curmudgeon, nevertheless has a penchant for dogmatically judgemental, pedantic behavior? And do this on weekends and spare time because we enjoy it? :) The answer in my case was "probably not". But Thomas and I are trying to figure out a way to turn that around, at least partly. Let's see what happens. Glenn
FVWM: Post-popup pointer positioning issue with tall menus
-- FVWM version: 2.6.5 Minor consistency issue regarding the behavior of relatively tall menus, when invoked via a mouse button. Example: Mouse 3 R A Menu fooMenu Mouse -20p -10p When Button 3 is clicked, if fooMenu fits vertically within the available space between the pointer and the bottom of the root window, then the menu pops up with the pointer located over the top menu item (suitably offset as specified by -20p -10p) and with that item highlighted, as desired. This is a nice convenience because it allows invocation of the first menu item by simply clicking Button 3 then hitting . But if Button 3 is clicked when there isn't enough space for the entire fooMenu to fit vertically downward from the present pointer position, then it pops up instead with its bottom edge aligned with the bottom of the root window, and in this case the pointer winds up positioned over (and highlights) the menu item that happens to have been beneath it vertically. This breaks the nice idiom of "B3 = invoke top root menu item". I did spend time studying the "Menu" and "MenuStyle" sections of the man page, but could not come up with a means to accomplish the desired behavior in a way that is independent of initial pointer position. This is certainly not a big deal, but otoh, the existing behavior does seem to conflict with the definition of the "Mouse" context-rectangle of the Menu command, at least as I interpreted it. That definition does not mention conditionality on initial pointer position; it seems to imply that the menu pops unconditionally with its top-left corner at the present pointer position (modulo any specified offsets.) There is a catch-all warning later that not all context-rectangle definitions may apply under all circumstances, but I would opine that if the present behavior is indeed the desired behavior, then it would be nice to document the initial-position conditionality explicitly in the "Mouse" subsection of the context-rectangle definitions. Since I'm whining though, let me at least offer something constructive in the way of suggestions on how this might be addressed, if it is even considered to be worth addressing and not simply due to my missing how to accomplish it as-is: a. Expand the "Mouse" context-rectangle definition so that it agrees with existing behavior (i.e., states that the popped menu position is conditional on the present pointer position and vertical extent of the menu) and then add a new context-rectangle type (say "MouseSloppy") which first attempts to act just like "Mouse", but if there is insufficient vertical space, then it pops the menu anchored to the bottom of the root window and warps the pointer to the top left corner of the menu (modified by any specified x and y offsets, just as now). b. Add an option which allows root menus to pop partially offscreen, and then modify the documentation of "Mouse" context-rectangle so that it states that its behavior depends on this new option. c. Just make the behavior strictly agree with the present "Mouse" context- rectangle definition in the man page, and perhaps even explicitly state that this behavior implies that tall menus may pop up partially offscreen, depending on initial pointer position. The first two (a, b) seem like they would be more or less backward compatible approaches. The last one would treat the issue as a bug fix (against the documentation) and might surprise users accustomed to the present behavior. Anyway... just trying to be helpful while complaining. Thanks in advance for any assistance.
Re: FVWM: Post-popup pointer positioning issue with tall menus
-- Dominik Vogt [2013-06-30 17:31:50 +0100]: > > That should be > > Mouse 3 R A Menu fooMenu WarpTitle > > of course. > Thanks, Dominik, that does indeed work. Honestly though, the man page sows a good deal of confusion on this topic. Permit me to grouse a bit. First, there is some syntax ambiguity: In fvwm.1, the synopsis for the "Menu" positioning parameters is given as [context-rectangle] x y [special-options] with WarpTitle listed under "special-options". Based on this synopsis, the expectation would be that if one wishes to specify a special-option, it must be preceded by at least "x y" and optionally by a context-rectangle as well. But the last sentence in the "Menu" section says Note that the special-options do work with a normal menu that has no other position arguments. which contradicts the synopsis. If the synopsis were changed to [ [context-rectangle] x y ] [special-options] this would bring it into agreement with that final sentence (and really eliminate the need for that sentence at all). Second, there is some ambiguity regarding the functionality of WarpTitle. The subsection describing WarpTitle seems to imply that it applies only to submenus, not to root menus. This was also evidently Thomas' understanding too, at least in FVWM 2.6.0. The following thread (pertaining to 2.6.0) http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/4458 contains this comment: Thomas Adam | 6 Jan 2010 22:52 > > WarpTitle only works on submenus, not the root menu. > Has the functionality been changed since 2.6.0? I quickly looked thru the release notes for subsequent versions, but didn't see anything on this, though perhaps I missed it. In any case, the present (2.6.5) man page certainly gives the impression that it [still?] applies only to submenus. Also, the name "WarpTitle" seems to be a misnomer, since it implies that the pointer is warped to a title. In your reply, you gave an alternative interpretation > > [WarpTitle] warps the pointer to the first menu item. > But neither appears to be accurate. The functionality I observed in a few quick experiments is that the pointer is warped to the top position of the menu, regardless of whether that position is occupied by a title or by a selectable menu item. Even in the case where a menu contains a Title, but that Title is not located at the top, it still ignores the Title and warps to the top menu entry. In short, as far as I was able to determine, the "warping" that is performed by this option has nothing to do with any notion of "title". In view of this behavior, a name like "WarpToTop" might be more appropriate. On a slightly different topic: You mentioned that the code embeds the requirement that menus must always pop in a position such that the entire menu is visible on the current page. I have no argument with that constraint, it seems entirely reasonable. But I would opine that it is not necessarily "obvious" that one obtains this behavior in view of the documentation, per your comment: > > If you click on the bottom pixel line of the display, you'll obviously > want the menu visible and not sticking downwards into the next page. > To me, the only thing that is "obvious" is that the code behavior and the documentation should agree. Presently the documentation makes no mention of this "entirely visible" constraint, and therefore one could just as well opine that the reader's expectation is "obviously" that the menu will be placed where he specified it to be placed. A straightforward but effective improvement to the positioning language might be to simply state explicitly that the position information supplied for Menu and Popup commands should be interpreted strictly as hints or requests, since in many common cases it winds up being overridden by the "entirely visible" constraint (and not just in the "tall" case that I had come across.) Summary of all the above: The documentation for menu positioning could really use some rework for clarity. Perhaps I'll take this on later in the summer. In any case, despite the grousing, an earnest "thank you" for pointing out the solution to my issue. Very happy to have that behavior back again. Small detailed abilities like this are what make FVWM a pleasure to use.
Re: FVWM: Forums and Wiki need new maintainers/homes
-- Jaimos F Skriletz [2013-09-06 13:11:35 -0600]: > On 09/06/2013 12:06 PM, Bert Geens wrote: > >Thomas Adam writes: > > > >>Hi Dan, > >> > >>On Thu, Sep 05, 2013 at 09:58:36PM -0400, Dan Espen wrote: > >>>Thomas Adam writes: > >>> > Hi all, > > Given my diminishing work on FVWM, I need to think about handing over the > FVWM Forums [1] and the FVWM Wiki [2]. I cannot devote the time needed > for > their maintenance, nor do I want to act as a point of contact for them > anymore. > >>> From my point of view, I'd have no problem with closing them down. > >>>If you could direct users to the mailing lists, that would be a good > >>>thing. > >>That'd be the simplest solution, yes. But I'm unclear how many users of > >>FVWM and the forums would welcome that. I was always in favour of closing > >>it down, but it exists _because_ it's what people wanetd, and still do, from > >>what I can tell. They're certainly a lot busier than fvwm@ in terms of > >>questions. > >> > >The barrier to sending questions to mailinglists certainly is a lot > >higher for most people than posting to a forum (whether this is is an > >imaginary barrier or not is, in the end, irrelevant), which is the > >main reason I set up the Fvwm forums back then. > > > >If need be I will take over maintaining the forums again. The software > >is relatively low maintenance (certainly compared to the horror that was > >phpBB2). It would be nice if there would be some more knowledgeable > >moderators, my personal use of Fvwm is, to say the least, pretty basic. > > > >While I don't foresee a repeat of the issue that forced Thomas to take > >over maintaining the forum software it would certainly be nice if > >hosting could remain somewhere where more people have access to it in > >case of emergency. In other words, if Jaimos doesn't mind it would be > >nice if the forums could stay where they currently are. > >> > >>The wiki is less important, but there's a lot of documentation which I feel > >>should make it in to the man pages somewhere if someone is wanting to do > >>that. > >> > >It would be a shame to lose the information stored in the wiki, I find > >it often more to the point that having to distill that same information > >form the manpage (assuming it's in there at all). > > For the time being I see no reason I cannot keep hosting the forums > and host the wiki as well. This could change in the future (but I > don't foresee such an event) and I would prefer to host if someone I > have known via #fvwm or in the fvwm community for a while took > charge of what little maintenance there is on the admin side. As for > getting some more moderators for the forums themselves that could be > useful and moderators do not need any access to the servers. > > I could help Bert with anything on the admin side of the server and > keeping phpBB3 up and secure, but I too only use the very basic > features of fvwm and don't want to be a moderator on the forums. > > One thing that could be useful on my end to save a small issue we > had when I changed servers was having control of the domain names. I > consider them part of the fvwm community but if I end up keep > hosting the forums and the wiki it just saves time and hassle if I > can access and control them directly instead of waiting for the > owner of them to update DNS records and the likes. > Not sure if this is of any help, but will offer it anyway. I use a commercial-grade webserver for my private use, website and email (paid service.) It's been very reliable, almost zero downtime in my experience. Under the terms of service, I'm permitted to use it for just about anything other than very high-traffic or paid commerical use. So I'd be more than happy to create a website under my personal account -- the site naming is flexible, it could be something like fvwm.foo.bar or or foo.bar.fvwm, or variations like that -- and host any of the present FVWM informational services (Wiki, etc.). I'm already paying for the service, so it's no cost increment to me. The caveat is that there is almost no ability to actually administer the files served, other than perhaps editing CGI scripts. I know zilch about Wikis and about what capabilities would be required in order to administer one effectively, so maybe this is a silly and useless offer. But, if it is of any value to simply have a more or less passive but high-quality server, just let me know. Btw, if someone has time, please educate me (and others) as to what capabilities are needed in order to perform the necessary administration. Glenn
Re: FVWM: fvwm frees invalid pointer
-- Schaaf, Jonathan P (GE Healthcare) [2013-09-16 21:28:46 +]: > > I'll keep tinkering with this in my spare time, and I'll see what I can > figure out. > Fwiw, perhaps nothing: If you have valgrind available, might want to try building fvwm with -g and then $ valgrind --leak-check=yes --log-file=/tmp/foo.log \ /usr/bin/fvwm -f ~/.fvwm/config 2> ~/.fvwm/FVWMERRS; where the second line is whatever you normally use to launch fvwm from your .xinitrc (or whatever). The plus side is you'll almost certainly find the problem and get a usable backtrace if you can tickle it during your normal workflow. The downside is that valgrind runs the target executable under a synthetic CPU with something like 25x speed penalty. I've have run fvwm under it though (on a 7 year old Thinkpad T-43 with 1.8 GHz single-core x86) and while it was noticeably slow, it was still entirely usable. The caveat is that my fvwm setup is very simple, and a more complex setup may make it intolerably slow to use for normal workflow until it fails. I claim no expertise with valgrind, just a casual user of it, but it has been been helpful on many occasions. It seems significantly more anal than some other memory fault diagnosis tools I've tried from time to time, and it's easy to use, and pretty well documented. Glenn
Re: FVWM: mvwm - documentation
Thomas Adam [2014-08-23 23:40:17 +0100]: > On Sat, Aug 23, 2014 at 09:36:38PM +0100, Michael Treibton wrote: > > On 23 August 2014 17:30, Thomas Adam wrote: > > > On Sat, Aug 23, 2014 at 04:36:47PM +0100, Michael Treibton wrote: > > >> Hi, > > >> > > >> taking a look at the mvwm repository, i notice that the documentation > > >> is using xml. is this still the case? it looks like some of the > > >> documentation hasn't changed given some changes to the functionality > > >> in mvwm??? > > > > > > Have a read of this thread: > > > > > > http://thread.gmane.org/gmane.comp.window-managers.fvwm.devel/5886 > > > > so i have to learn this 'roff' is it? why not use asciidoc which means > > you can use plain language - theres a lot of syntax markup with > > mdoc/groff - that makes writing documentation harder. > > So, I think the point here is to fundamentally appreciate the difference > between the roff family (groff, nroff, and troff) and what mdoc > provides. > > Back in the '60s, roff (RUNOFF) came about as a means of a > typesetter---a way of formatting text. Fast forward some forty years > and the essence of that survives, in terms of the GNU implementation of > roff (groff). nroff (new-roff) and troff (AT&T-derived formatting; > includes things like eqn, tbl, etc.) are all variants/extensions of the > same thing. In fact, in terms of troff, TeX actually stole some of > those techniques (c.f. eqn for instance). > > What mdoc provides is a sort of subset of roff---it's designed from the > ground-up, and focuses on the ability to write man pages in it > (BSD-licenced; OpenBSD has been using it for the last four years). It's > not as feature-rich as roff, and I've heard some dyed-in-the-wool types > moan that for GNU/Linux this has some impact in terms of what's rendered > in man pages, etc., although I personally consider that a red-herring. > I've yet to come across a man page where there's a reliance on some > troff extensions, for example. > > So with mdoc you have at your disposal a well-engineered back-end system > which can be used to create just man pages, with the added bonus of > rendering out other types as well (including (X)HTML/stylesheets). I > was only on the periphery of the work done by Scott Smedley when Docbook > was introduced, but even since that point, the way in which > documentation culminates is horrendous. It's horrific and I for one > never want to work with it again. I know I'm not alone in thinking > that; and that's not to imply the work done by those to introduce > docbook was ever in vain; far from it. It's just something where there > was not enough discussion and the benefits didn't outweigh the > replacement, unfortunately. > > Of course since that point, there's been an explosion of > markup/markdown/hidden-markup type things where you can try and write > all these things in plainer-looking English and hope the parser can > render it down appropriately. That's what Asciidoc claims to do, and a > few years ago, I started to define a switch to it, to try and alleviate > a need to know shitty XML. As it happens, although that kind of worked, > Asciidoc itself is not stable, in my opinion, and you're left at the > mercy of things changing too frequently, not to mention a sizeable > build dependency. > > So when you come down to it, the benefits to not writing in *roff are: > > * Can be abstracted away; the syntax is irrelevant; > * Lower learning-curve as the text can be written more in "plain >English" > > But the downsides are: > > * Inflexibility with the abstraction not providing the lower-level >macros for text-formatting; > * Larger dependencies to compile a document; > * Sometimes an overhead to learning the abstracted syntax > > When you put this on-balance, along with the documentation's history to > date, going back to the wire, and enforcing mdoc (roff) as a markup > language brings more benefits to my eyes, than anything else. It's > verbose, sure, but for a reason. It is what it is, and requires no > additional packages, etc. It's the lowest common denominator. > > > That seems wasteful to me > > See above. Anything else I can do for you, let me know. > > -- Thomas Adam Fwiw: As a guy who started at Bell Labs in 1979 (now retired) and wrote gawd knows how many hundreds of documents in troff [-mm, -man, -metc etc] I heartily agree with every point Thomas has made. Imo, his brief overview above should be required reading for anyone contemplating a large doc project. The learning curve, though somewhat (but not terribly) steeper than the various more modern "plain English" markups, is well worth the trouble. Even today, when I write the occasional paper (-mm) or man page (-man), it's invariably in troff. Ancient perhaps, but even today, nothing beats it, IMO. (The TeX/latex family seems to be the only serious competitor, and colleagues over the years familiar with with both seem to like them about equally.) I would offe
Re: FVWM: mvwm - documentation
Michael Treibton [2014-08-24 00:41:19 +0100]: > On 24 August 2014 00:09, Glenn Golden wrote: > > I would offer the following encouragement to Michael: Every person (without > > exception that I recall) who over the years I've badgered, browbeaten, > > encouraged, or required to use *roff has been very happy that they took the > > plunge. You may laugh that it's 40+ years old, but so are cat, ls, od, > > sort, > > uniq, > > ok - but i don't see any other alternatives being offered here. if > asciidoc is that bad, how comes other projects including Git use it > and have well structured man pages? they do ok out of using asciidoc, > so why wouldnt mvwm? > I'll leave critique of alternatives to those more familiar with them. Regarding your observation that asciidoc is capable of generating decent man pages and other documents, I would offer the analogy that programs like WordStar, FrameMaker, WordPerfect, DisplayWriter, ElectricPencil, Interleaf, [insert dozens more here]... were also capable of rendering decent-looking documents. But how many source documents written in those languages would it even be possible to render today at all, in any form whatsoever? To be fair, asciidoc (due to its simplicity) may not die as quickly and thoroughly as did all the above. But still, I would opine that 40 years from now, it will have been supplanted. Otoh, I suspect that professional- grade low-level tools like troff and TeX (upon which are built numerous macro packages for ease of use, mdoc being one of them) will survive indefinitely, just as they have survived (and even flourished, among documentation professionals) for the past 40 years, and for the same reasons: The underlying substrate is very high quality, and they perform a single function very well. The Unix philosophy. The same reason cat, ls, sort, are still around. > > If you don't watch this decision it will look like the same thing as > docbook did - that it is here for no reason. > You may be right, Michael. But imo, the opposite is more likely: Documents written for heavily worked over low-level tools like troff and using well- known macro packages (like -man, -mm, -mdoc, etc.) are more likely to survive the test of time. Anecdotally: A few years ago I was asked to reproduce a paper I'd written in the early 90's. It was in troff, using Bell Labs' "Memorandum Macros" package. With about 15 minutes googling for a modern equivalent of that package, and perhaps another hour or so of dorfing around with small style details, I was able to re-render the paper in camera-ready PDF form at 1200 dpi (including numerous images). I would not be surprised to be able to do pretty much the same thing 20 years from now, other than personal impediments like senility or being dead, which are problems of another sort. But I bet troff will outlive me. Just my 2c. But to this point, I think history backs up that view. Anyway, to end on an encouraging note: "Try it, you'll like it". Regards, Glenn
Re: FVWM: mvwm - documentation
Michael Treibton [2014-08-25 14:48:41 +0100]: > > i received an email from Glenn Golden who seems to know lots about > mdoc - maybe he can help? > I'll be glad to if I can. mdoc(7) is probably a decent place to start, if somewhat terse like most man pages. I did some fairly detailed rework on a few existing man pages a few years back, and was able to learn enough just from mdoc(7) to get the job done. (But to be fair, I also was familiar with the 'mm' and 'an' macro packages already, so perhaps mdoc.7 is not really the best place to start for a newcomer.) There's a tutorial man page too, mdoc.samples(7), which looks pretty decent, though I've not read it in detail. But certainly, working from an existing man page as a basic template is probably the best way to start. I'd suggest choosing a fairly complex one, so you can see how to some of the more detailed formatting and style stuff is accomplished. Another tip is to use gs(1) with the "monitor file state" option enabled to provide near-instantaneous re-rendering in realtime. So as you make changes in the file, you can see the result immediately as soon as you groff(1) it (which you can of course invoke from within any ATE.) Pseudo-WYSIWYG! :) > > although he seems to dislike you intently!! > Wow, all I can say is: Oyoyoy... no good deed goes unpunished! The obvious intent of my note to you was to un-discourage you from taking Thomas' dogmatic "this conversation is over" too seriously and decide not to help with the doc. I really winced that you chose to (mis)characterize my feelings toward him in public here on the list, since my note to you was obviously private. In any case, it's certainly not true that I dislike Thomas, intensely or otherwise, only that he's a bit of a conundrum, a force for Good and Evil on the list: Technically excellent and always helpful, but occasionally also disruptive due to his language habits. (And in view of your angry initial reply to him, telling him that he ought to "leave the list", it certainly seemed as though you were offended, hence it seemed a worthwhile effort on my part to try to calm the situation a bit.) Btw, you forgot to mention that I also said of Thomas: "...he's a highly skilled developer, and has been nothing short of extraordinarily helpful to people coming here with questions and problems. He's also written a good deal of the code and doc. On a technical level, I find myself in agreement with most of his views, not only about fvwm per se, but about coding and doc in general. IMO, he is a top-notch programmer and has his technical head on straight." And after offering a critical opinion of his occasionally curt manner on the list, also added "On the other hand, I do think that behind the gruff and sometimes offensive exterior, he's truly a nice and decent fellow." How you got from the above to "intensely disliking" him, I don't know, but just for the record, it's absolutely not true. Thomas is who he is, and if you don't like his manner -- and honestly, I don't sometimes -- then you can either interact with the list read-only, as I mostly have, or just get used to it. He's who he is, and isn't going to change. Hth, Regards, Glenn
FVWM: Title toggling behavior in 2.6.5
When WindowStyle is toggled from Title to !Title, the upper edge of the window remains where it is and the bottom edge shifts up to make up for the space lost by removing the title bar. Is there any style option (or other trick) that would allow this convention to be reversed, i.e. so that the window remains bottom-anchored rather than top-anchored when the Title is toggled? --- version info - $ fvwm --version fvwm 2.6.5 compiled on May 15 2014 at 22:21:15 with support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS --
Re: FVWM: Title toggling behavior in 2.6.5
Thomas Adam [2016-03-21 18:41:29 +]: > > On 21 Mar 2016 17:06, "Glenn Golden" wrote: > > When WindowStyle is toggled from Title to !Title, the upper edge of the > > window remains where it is and the bottom edge shifts up to make up for > > the space lost by removing the title bar. Is there any style option (or > > other trick) that would allow this convention to be reversed, i.e. so that > > the window remains bottom-anchored rather than top-anchored when the Title > > is toggled? > > No, I'm afraid not. It's up to you to write a complex function which should > determine if the window needs repositioning after you've toggled the title. > OK, seems to work. It's fast enough not to be visually disturbing too, so it's a nice clean solution, thanks.
Re: FVWM: Survey: Are you affected by disappearing Firefox menus?
Michael Großer [2016-03-30 06:12:07 +0200]: > > +---+ > | Does anybody of you is confronted during day-to-day work with | > | issues that Firefox menues disappear when you are about to| > | open a sub menu or another menu? | > +---+ > I don't run Firefox, but have frequently seen behavior that sounds at least superficially similar to what you're describing, with a java-based application that I use all day long. However, since it occurs only with that app, and since that app is java -- the original Mr. Doesn't Play Well with Others -- my careless assumption has always been that java was probably the cause, not FVWM or some interaction between the two. (I've never run this app under any window manager other than FVWM, so can't supply any comparitive info.) I would be glad to know if there is some config tweak within FVWM that could work around this issue, it's a pita. More detail on my app behavior if it is of interest, just ask and I will describe the behavior in more detail. Glenn
FVWM: Interactions between FVWM, xterm, and giant tortoises
What follows is a long-winded question about a puzzling (to me) interaction between fvwm, xterm, and libxcursor pointer-theming. Not suggesting this is a bug or even a problem at all, just seeking an education as to what's going on. Version info: fvwm --version: fvwm 2.6.5 compiled on May 15 2014 at 22:21:15 with support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS. (Config file is pretty straightforward, will post if needed.) xterm -v: XTerm(324) Distro: Arch, synched to repos a few days ago. So... "Reference case": Under raw X (no WM), start up an xterm like this: $ xterm -ms COLOR where COLOR is some color specifier. Behavior as expected: Mouse pointer shape is the usual X "I beam", with color COLOR. (And the same expected behavior is obtained via the associated X resource "pointerColor", as set via "-xr" option, xrdb, etc.) In particular, the pointer shape and workingness of "-ms" are not affected by any of the libxcursor theming parameters in the system-wide default/index.theme file, or the per-user default/index.theme file, or by the $XCURSOR_THEME envar. This is also as expected (by me, anyway) since xterm 324 doesn't use libxcursor (at least, afaict according to ldd). But: Under fvwm (no DE), xterm pointer behavior seems to depend on how the xterm is started: * An xterm started via an fvwm menu item, e.g. "xterm (blue pointer)" Exec exec xterm -ms blue behaves as it does under raw X. And this is again true regardless of theming parameters in index.theme files or the (exported) value of $XCURSOR_THEME in fvwm's environment. * But: An xterm manually started from the commandline within another xterm (which in turn was launched via an fvwm menu item, like above) _is_ evidently affected by the libxcursor theming stuff: For example, if $XCURSOR_THEME is set to a theme name other than "core", or if one of the default index.theme files "Inherit"s a theme other than "core", then the manually-started xterm will have the themed pointer shape (and the -ms COLOR will be ignored). I understand that xterm can't color a non-core pointer, so it's not that I'm expecting -ms to work in the manually-launched case where (for whatever reason) xterm is paying attention to the theme stuff. The question is: Why does xterm pay attention to the theme stuff in the manually-launched case but ignores it when Exec'ed from a fvwm menu? Afaict, the environments and X resources in both cases seem to be essentially identical. History (if it matters): This behavior difference began about a year ago when Arch changed their libxcursor packaging to include a system-wide default/index.theme file which inherits a giant tortoise: [Icon Theme] Inherits=Adwaita (Adwaita is also the name of a GNOME pointer theme, but it's more fun to think of it as a giant tortoise.) Anyway, prior to that change, xterm pointer behavior was identical in both fvwm cases (i.e., non-themed, and color per "-ms") evidently because there was no non-core default theming, so the difference never appeared. But with the tortoise in there, if you want xterm -ms to work with manually-started xterms you have to explicitly set XCURSOR_THEME=core (or set up your own user default/index.theme file with "Inherits=core" (or just "Inherits="). Again, no big deal, just would like to understand why the two cases differ. I have a feeling the explanation is very simple and staring me in the face but can't see it.
FVWM: Forcing a window to remain on a specific page
Is it possible to force a given window to appear and remain only on a particular page? (Effectively, something like "StartsOnPage", except it would really be "StaysOnPage", i.e. the page assignment holds for all time, not just upon initial mapping.) The need for this arises as follows: I'm running xv with the -poll option, in order to periodically update the display of an image as the underlying image file changes. Desired behavior is that the image only ever appears on fvwm page (x,y). When I try to obtain this behavior via: Style myxv StartsOnPage x y, SkipMapping and then invoking xv as $ xv -name myxv -poll [myfile] it starts on page (x,y) as desired, but then later, when the image file changes, the 'new' (i.e., updated) window always pops up on the current page. (NOTE, fwiw: The updated window(s) seem to maintain the same 'name' and 'Window ID' as the originally-mapped window, as reported by FvwmIdent.) Thanks! -- FVWM --version info: fvwm 2.6.7 compiled on Nov 30 2016 at 13:19:18 with support for: ReadLine, Stroke, XPM, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS
Re: FVWM: Forcing a window to remain on a specific page
Thomas Adam [2017-04-12 17:21:55 +0100]: > On Wed, Apr 12, 2017 at 09:47:54AM -0600, Glenn Golden wrote: > > Is it possible to force a given window to appear and remain only on a > > particular page? (Effectively, something like "StartsOnPage", except it > > would really be "StaysOnPage", i.e. the page assignment holds for all time, > > not just upon initial mapping.) > > > > The need for this arises as follows: I'm running xv with the -poll option, > > in order to periodically update the display of an image as the underlying > > image file changes. Desired behavior is that the image only ever appears on > > fvwm page (x,y). When I try to obtain this behavior via: > > > > Style myxv StartsOnPage x y, SkipMapping > > > > and then invoking xv as > > > > $ xv -name myxv -poll [myfile] > > > > it starts on page (x,y) as desired, but then later, when the image file > > changes, the 'new' (i.e., updated) window always pops up on the current > > page. > > You'd have to use FvwmEvent to do this. Listen on the new_page event and > either iconify or deiconify the window as appropriate. > Thanks! I will take a shot at it with that approach, thank you. Glenn
Re: FVWM: Forcing a window to remain on a specific page
Dominik Vogt [2017-04-12 20:56:42 +0100]: > On Wed, Apr 12, 2017 at 09:47:54AM -0600, Glenn Golden wrote: > > > > [ ... ] > > > > (NOTE, fwiw: The updated window(s) seem to maintain the same 'name' and > > 'Window ID' as the originally-mapped window, as reported by FvwmIdent.) > > Yeah, you can forbid the program and/or the user to move the > window with > > Style myxv FixedUSPosition, FixedPPosition > Byooteeful. That works out of the box and seems like the simplest approach. Thanks Dominik!
FVWM: Forcing icon to prior position
"They kill, they maim, and they call information for numbers they could easily look up in the phone book." - Woody Allen, 'What's up Tiger Lily?', 1966 -- Here is a simple sounding question that probably been answered many times, but after googling and wikiing awhile, still haven't found quite what I'm after. When iconifying a window, how to force the icon to exactly the same screen position it occupied the last time it was iconified? I don't use any icon manager or icon organization scheme, and don't want to. Typical example: 1. Start xv, do "something" [see below] 2. Iconify xv. It iconifies to a position I don't like, call it A 3. Move the icon to position I do like, call it B 4. Later, click the icon to open xv and do another thing. 5. Iconify xv. It returns to A, not B. It seems the above behavior is also influenced by what the "something" in Step #1 is. If "something" is nothing at all -- i.e. just start xv and immediately iconify it and reposition the icon to B -- then opening xv in Step 4 and re-iconifying it returns the icon to B not A. But if "something" is (say) doing a screen capture or opening the image editor, then iconifying after that returns the icon to position A. What's going on with this? Can the icon position be forced?
Re: FVWM: Forcing icon to prior position
Version info: fvwm 2.6.7 compiled on Nov 30 2016 at 13:19:18 with support for: ReadLine, Stroke, XPM, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS Glenn Golden [2018-07-13 16:45:36 -0600]: > "They kill, they maim, and they call information for numbers they could > easily look up in the phone book." > > - Woody Allen, 'What's up Tiger Lily?', 1966 > > -- > > Here is a simple sounding question that probably been answered many times, but > after googling and wikiing awhile, still haven't found quite what I'm after. > > When iconifying a window, how to force the icon to exactly the same screen > position it occupied the last time it was iconified? > > I don't use any icon manager or icon organization scheme, and don't want to. > > Typical example: > > 1. Start xv, do "something" [see below] > 2. Iconify xv. It iconifies to a position I don't like, call it A > 3. Move the icon to position I do like, call it B > 4. Later, click the icon to open xv and do another thing. > 5. Iconify xv. It returns to A, not B. > > It seems the above behavior is also influenced by what the "something" in > Step #1 is. If "something" is nothing at all -- i.e. just start xv and > immediately iconify it and reposition the icon to B -- then opening xv in > Step 4 and re-iconifying it returns the icon to B not A. But if "something" > is (say) doing a screen capture or opening the image editor, then iconifying > after that returns the icon to position A. > > What's going on with this? Can the icon position be forced?
Re: FVWM: Forcing icon to prior position
Stephen Dennison [2018-07-16 12:31:28 -0400]: > > I was unable to find a copy of xv to test it, but everything else I > iconify honors the new position. Maybe xv is doing something odd? > If so, and if the cause can be identified I'll take a shot at fixing it. But probably I've not enough expertise to track it down myself in the sources. If anyone wants to take a stab at it, I'll be glad to provide sources (or a pointer). My version of xv is a slightly modified form of the highly-patched version of 3.10 that's been floating around in the wild for a while (3.10a-jumboFix+Enh dated 20070520) > > Have you tried specifying something like > Style xv NoUseIconPosition ? > I recall experimenting with !UseIconPosition a while back (the "No" version of that option seems deprecated in 2.6.7) but no help. At your suggestion though, I tried it again just now (via FVWM console, not changing it in my config file) but no help. Still behaves as previously reported.
Re: FVWM: Forcing icon to prior position
Michael Großer [2018-07-16 19:10:37 +0200]: > > XV is a piece of software that I reglarly use. > Yeah, xv is a true classic, even legendary. Sure hope Bradley made a little coin off it, it's really an astonishingly excellent piece of work. Simplicity, intuitive interface, attention to detail in every way. Even 25 years later, beats the pants out of most of what's out there for basic image manipulation. Imo, xv and fvwm are both in the same rarefied class of superbly useful, well designed, documented, and maintained work.
Re: FVWM: Forcing icon to prior position
Stephen Dennison [2018-07-16 14:00:40 -0400]: > > I managed to build xv, when I run it it iconifies and deiconifes and > re-iconifies back to where its icon was moved. Or more simply, it > behaves as expected. > Hmm. Can you try this specific sequence: 1. Start xv 2. Iconify it. Call that position A 3. Manually move the icon to some other position, B 4. Click the icon to open it, then do a grab (^G) of some arbitrary window. (To do the grab, just click button 1 in the targer window). 5. Then iconify xv again. For me, it returns to position A. I will try it a little later with an empty fvwm config as you suggested, see wha' hoppen. Thanks for your time on this. Glenn
Re: FVWM: Forcing icon to prior position
Stephen Dennison [2018-07-16 14:19:55 -0400]: > > That's essentially the process I follow. My config contains just a > call to FvwmConsole and I accomplish each step by typing in the > command and then carrying out whatever mouse action. > > > For me, it returns to position A. > > I did it again, just to be sure, empty config, no issues. > OK, I just tried it with an empty config too, and came across something new that I'd never noticed before, which may be a clue: The problem seems to be related to whether or not the "hide xv windows" checkbox is selected before doing the grab. When it is not selected, the problem did not occur. When it is selected, it occurred every time. Here's the recipe I followed 4-5 times in a row in bare fvwm, talking to FvwmConsole manually, to get it to happen: 1. start xv 2. In xv, do a grab (^G) and click the "hide xv windows" checkbox. 3. Do the screengrab using button 1 (window) or button 2 (swept region) 4. Iconify # Goes to position A 5. Move# Manually move icon to position B 6. Iconify # De-iconify 7. Do another grab exactly as done in step 2 8. Iconify # Goes to position A Maybe the act of "hiding the xv windows" also somehow whispers in fvwm's ear to discard the prior icon position? Just guessing out loud...
Re: FVWM: Forcing icon to prior position
Stephen Dennison [2018-07-17 09:49:39 -0400]: > On Tue, Jul 17, 2018 at 9:40 AM, Stephen Dennison wrote: > >> OK, I just tried it with an empty config too, and came across something new > >> that I'd never noticed before, which may be a clue: The problem seems to be > >> related to whether or not the "hide xv windows" checkbox is selected before > > I had not selected that previously. This seems to be key. > > > >> doing the grab. When it is not selected, the problem did not occur. When it > >> is selected, it occurred every time. > > I get that to. > > > >> > >> Here's the recipe I followed 4-5 times in a row in bare fvwm, talking to > >> FvwmConsole manually, to get it to happen: > >> > >> 1. start xv > >> 2. In xv, do a grab (^G) and click the "hide xv windows" checkbox. > >> 3. Do the screengrab using button 1 (window) or button 2 (swept > >> region) > >> 4. Iconify # Goes to position A > >> 5. Move# Manually move icon to position B > >> 6. Iconify # De-iconify > >> 7. Do another grab exactly as done in step 2 > >> 8. Iconify # Goes to position A > > > > This recipe does, indeed, recreate the problem. When that box is > > checked, it iconifies to the default position instead of where it was > > last iconified. The window is unmapped. I've never programmed this > > sort of thing, maybe someone else can step forward and describe what > > the correct behavior is here, but in xvgrab.c, line 64, it invokes > > XUnmapWindow, where I imagine it should instead be using > > XIconifyWindow? Maybe FVWM considers unmapped windows to be > > forgettable? I don't know how to get the current display number, > > otherwise I imagine you could just replace this unmap with a call to > > iconify it... > > > > (Note: source from here: > > ftp://ftp.mowgli.ch/pub/debian/pool/unofficial/x/xv/xv_3.10a.orig.tar.gz) > > > >> Maybe the act of "hiding the xv windows" also somehow whispers in fvwm's > >> ear > >> to discard the prior icon position? Just guessing out loud... > > I'm not qualified to even guess. Maybe an fvwm dev can chime in, as > > I'm over my head. > > Apparently if I had spent 30 seconds more at the googles I would have > come to this solution, replace the line I mention above with this: > > if (mainW && dispMode==RMB_WINDOW) XIconifyWindow(theDisp, mainW, > DefaultScreen(theDisp)); > > And then the app behaves. But keep in mind that the second dialog > that pops up is a new window, so you will want to iconify that and > move it around, then uniconify it to see that it really did remember > the new position. Then successive grabs still remember the previous > icon location. > > So, in conclusion, XV shouldn't be unmapping the window but asking to > be iconified. But I still don't know the wider ramifications of > asking to be unmapped. > OK, thanks for your time and effot on this Stephen, much appreciated. I've been swamped since your post above, haven't had a chance to even think about it or try what you suggested (or even fully understand it.) But will do so eventually, and report what I find to the list, in case it may be useful to other xv-ers.
FVWM: Canceling window placement via user-defined key
Is it possible to cancel a Move operation via a user-specified key binding? The built-in bindings to Space and Return work fine for that, but I'd like to define a key other than (or in addition to) those, if possible. >From the doc, I thought 'CancelPlacement' might be a general function for that purpose, but seems like it is available for use only with the Mouse command. Version info: fvwm 2.6.8 compiled on Jun 14 2018 at 12:44:24 with support for: ReadLine, Stroke, XPM, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS Thanks!
Re: FVWM: Canceling window placement via user-defined key
Hi Elliot, Thanks for your suggestions. (Replying to list since my original post may have been confusing.) elliot s [2018-12-29 14:00:27 -0800]: > > I use Esc to kill moves in progress. > > If key bindings can work while move in progress, maybe you can hit a > key to remember old position and then hit it again to move window back. > Actually, what I meant by 'cancel placement' is to terminate the placement operation, not to return the moved window to its original position. It was my mistake to use the word 'cancel' rather than 'terminate' in my post, because now that I read the fvwm man page more carefully, the way you have interpreted 'cancel' -- returning the window to it's pre-moved position -- seems to be what the man page means too. I didn't appreciate that when I first read about CancelPlacement. Anyway, the idiom I'm seeking to implement is this: 1. Tap Control_R with pointer inside a window to begin 'Move' operation 2. Use arrow keys to reposition the window 3. Tap Control_R to terminate the 'Move' operation So Step 3 just leaves the window where it was when Control_R is tapped the second time. It's easy to implement the above with a trivial function and key binding, but Step 3 is the problem: DestroyFunc MoveOrTerminateMove AddToFunc MoveOrTerminateMove + I ThisWindow (!State 6) Move + I ThisWindow ( State 6) <> + I State 6 toggle Key Control_R W N MoveOrTerminateMove The 'Return' and 'Spacebar' keys have built-in bindings that terminate a Move operation, and they work fine. But I'm lazy and would like to be able to use Control_R instead, because on my keyboard, Control_R happens to be located right next to the group of arrow keys. So this would allow a handy and compact way to do small detailed repositionings mouselessly.
Re: FVWM: Canceling window placement via user-defined key
Dominik Vogt [2018-12-30 01:11:13 +0100]: > On Sat, Dec 29, 2018 at 04:29:00PM -0700, Glenn Golden wrote: > > Anyway, the idiom I'm seeking to implement is this: > > > > 1. Tap Control_R with pointer inside a window to begin 'Move' operation > > 2. Use arrow keys to reposition the window > > 3. Tap Control_R to terminate the 'Move' operation > > All the keyboard shortcuts for moving and resizing windows, > dragging the viewport and execution of complex functions are hard > coded in libs/Target.c. I.e. this won't work without changing the > sources. > I'm not quite understanding what you mean, can you explain a little more? The above already does work, by just binding Control_R to 'Move', except that the Move operation has to be terminated by 'Space' or 'Return'. Do you mean that the definition of the terminating key events (i.e. Space or Return) is hardwired to those particular two keys in Target.c?
Re: FVWM: Forcing icon to prior position
Stephen Dennison [2018-07-17 09:49:39 -0400]: > On Tue, Jul 17, 2018 at 9:40 AM, Stephen Dennison wrote: > >> OK, I just tried it with an empty config too, and came across something new > >> that I'd never noticed before, which may be a clue: The problem seems to be > >> related to whether or not the "hide xv windows" checkbox is selected before > > I had not selected that previously. This seems to be key. > > > >> doing the grab. When it is not selected, the problem did not occur. When it > >> is selected, it occurred every time. > > I get that to. > > > >> > >> Here's the recipe I followed 4-5 times in a row in bare fvwm, talking to > >> FvwmConsole manually, to get it to happen: > >> > >> 1. start xv > >> 2. In xv, do a grab (^G) and click the "hide xv windows" checkbox. > >> 3. Do the screengrab using button 1 (window) or button 2 (swept > >> region) > >> 4. Iconify # Goes to position A > >> 5. Move# Manually move icon to position B > >> 6. Iconify # De-iconify > >> 7. Do another grab exactly as done in step 2 > >> 8. Iconify # Goes to position A > > > > This recipe does, indeed, recreate the problem. When that box is > > checked, it iconifies to the default position instead of where it was > > last iconified. The window is unmapped. I've never programmed this > > sort of thing, maybe someone else can step forward and describe what > > the correct behavior is here, but in xvgrab.c, line 64, it invokes > > XUnmapWindow, where I imagine it should instead be using > > XIconifyWindow? Maybe FVWM considers unmapped windows to be > > forgettable? I don't know how to get the current display number, > > otherwise I imagine you could just replace this unmap with a call to > > iconify it... > > > > (Note: source from here: > > ftp://ftp.mowgli.ch/pub/debian/pool/unofficial/x/xv/xv_3.10a.orig.tar.gz) > > > >> Maybe the act of "hiding the xv windows" also somehow whispers in fvwm's > >> ear > >> to discard the prior icon position? Just guessing out loud... > > I'm not qualified to even guess. Maybe an fvwm dev can chime in, as > > I'm over my head. > > Apparently if I had spent 30 seconds more at the googles I would have > come to this solution, replace the line I mention above with this: > > if (mainW && dispMode==RMB_WINDOW) XIconifyWindow(theDisp, mainW, > DefaultScreen(theDisp)); > > And then the app behaves. But keep in mind that the second dialog > that pops up is a new window, so you will want to iconify that and > move it around, then uniconify it to see that it really did remember > the new position. Then successive grabs still remember the previous > icon location. > > So, in conclusion, XV shouldn't be unmapping the window but asking to > be iconified. But I still don't know the wider ramifications of > asking to be unmapped. > OK, finally -- six months later! -- got around to trying your fix above. Works for me too, just as you describe. No problems noted so far re iconification vs. unmapping. Thanks for all the time you spent on this earlier, much appreciated! - Glenn
Re: FVWM: FvwmForums: Change of engine and help with theming
Lucio Chiappetti [2019-06-05 11:59:15 +0200]: > On Wed, 5 Jun 2019, Thomas Adam wrote: > > > On Tue, Jun 04, 2019 at 07:46:02PM -0400, Dan Espen wrote: > > > Sorry, no inclination to follow a forum. Wish we'd go back to > > > exclusively email. > > > I personally don't disagree -- but you know what the old maxim says: "Give > > the people what they want". It seems the y00fh of today prefer forums. > > God knows why, but they do. > > Think that an usenet (nntp) newsgroup would give both the benefits of e-mail > and forums (in terms of asynchronous access, and of each user choosing the > interface one prefers ... which could mimic e-mail in full). > +1 for plain old nntp, with a digest option added too, as Lucio suggested. Gratuitous rambling: One source of resistance to email-based groups among today's y00fh may be lack of experience with (and the slow disappearance of) the convention of composing decently formatted emails in a text editor. (Which in turn imposes the terribly inconvenient requirements of, y'know, manually inserting line breaks, indenting and outdenting properly to maintain context, and other nasty stuff). Curious if anyone agrees or has similar musings.
