Re: FVWM: Desktop scaling

[Stephen Dennison]

On Sun, Dec 4, 2022 at 3:33 PM Klaus Ethgen  wrote:
>
> Hi,
Greetings.

>
> I have a new laptop with 3840x2400 graphic. Unfortunately, that is too
> much to be visible so I use it with only 1920x1200. Unfortunately, the
> controls are still very small.

I have a similar issue with one of my systems.

> Is there any way to scale all fvwm components by, say, factor 250%?

I can't think of an *easy* way for FVWM to do this for you, but
depending on the method you are using for scaling, there are some
things you can try using xrandr.

If you are only setting the output mode via`--mode`, you still have an
issue with dpi.  You can adjust both to get the desired effect.  See
the `--dpi` argument in the man page.

Or you could use the `--scale` option of xrandr, which should get you
the outcome you're hoping for.  Start with small values and work your
way up, it seems you may not be able to go backwards once you start
making the display smaller (pixels bigger).

None of these are options on the one problem system I have (asahi),
instead I painfully must modify some obscure environment variables
controlling aspect of gtk and qt, but if your issue has to do with
native fvwm element sizes, these wont help you, so I will omit them.

Re: FVWM: how to escape F1?

[Stephen Dennison]

On Fri, Mar 8, 2019 at 6:06 AM Dominik Vogt  wrote:
>
> On Fri, Mar 08, 2019 at 10:59:44AM +0100, Harald Dunkel wrote:
> > Hi Thomas,
> >
> > On 3/8/19 9:53 AM, Thomas Adam wrote:
> > > Key F1 A A --
> > >
> >
> > Apparently thats a misunderstanding. Sorry for my bad English.
> >
> > I would like fvwm to *ignore all key bindings for one keypress*
> > to forward it directly to the app with input focus.
>
> X11 does not have a way to override all grabs for just a couple of
> keystrokes.  If a grab is present, it's always active.  (Unless
> the application grabs the keyboard, but that is not what you're
> looking for.)
>
> So the only way to do that is to put all key bindings in some
> file or function, e.g.
>
>   bind_keys
>
> and to unbind them in another one
>
>   unbind_keys
>
> then "read unbind_keys" when necessary and restore them with "read
> bind_keys" later.  You'll probably be unhappy with the performance
> of this approach if you have mora than just a few bindings.
> (Don't forget to put a binding that reactivates the other bindings
> into unbind_keys.)
>
> > Some kind of
> > "escape" key entered before the actual key.
> >
> > For example, I have
> >
> >   Key F1 A N Switch-Iconic
> >   Key F2 ...
> >   :
> >
> > in my .fvwmrc.
> >
> > Assuming the window "xyz" has input focus: If I press and release
> > some [magic_escape_key], followed by [F1], then "xyz" should *not*
> > be changed to an icon, but [F1] should be sent to "xyz" instead.
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Perhaps I'm misunderstanding the request, but you could also just use a
modifier like the num lock key.  As long as you are *not* ignorning modifiers,
you can press numlock and then the key presses will all go to applications and
fvwm will ignore them.  Then when you want fvwm to pay attention again, just
turn off numlock.

I use this a lot when using nested x sessions to control which window manager
gets a key press.  It works very well.

Re: FVWM: Forcing icon to prior position

[Stephen Dennison]

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.

Re: FVWM: Forcing icon to prior position

[Stephen Dennison]

> 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.

Re: FVWM: Forcing icon to prior position

[Stephen Dennison]

On Mon, Jul 16, 2018 at 2:00 PM, Stephen Dennison  wrote:
> 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.
>
> Double checking my version info:
>
> fvwm 2.6.7 compiled on Jan 16 2017 at 17:52:00
> with support for: ReadLine, RPlay, Stroke, XPM, SVG, Shape, XShm, SM,
> Bidi text, Xinerama, XRender, XCursor, XFT, NLS
>
> Double checked that it behaves with an empty config, too.
>

My apologies for the top-post, gmail outsmarted me.

Previous question still stands, those with a misbehaving xv, did you
see it misbehaving with a clean config file?

Re: FVWM: Forcing icon to prior position

[Stephen Dennison]

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.

Double checking my version info:

fvwm 2.6.7 compiled on Jan 16 2017 at 17:52:00
with support for: ReadLine, RPlay, Stroke, XPM, SVG, Shape, XShm, SM,
Bidi text, Xinerama, XRender, XCursor, XFT, NLS

Double checked that it behaves with an empty config, too.

On Mon, Jul 16, 2018 at 1:55 PM, Glenn Golden  wrote:
> 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]

On Mon, Jul 16, 2018 at 1:19 PM, Didier Spaier  wrote:
>
>
> Le 16/07/2018 à 19:10, Michael Großer a écrit :
>> Stephen Dennison wrote:
>>> 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?
>>> Have you tried specifying something like
>>> Style xv NoUseIconPosition ?
>>
>> Hey! This is MY special topic...
>>
>> How about this?
>>
>> ftp://ftp.mowgli.ch/pub/debian/pool/unofficial/x/xv/
>>
>> You are using Debian? Try this:
>> - ftp://ftp.mowgli.ch/pub/debian/pool/unofficial/x/xv/xv-doc_3.10a-27_all.deb
>> - ftp://ftp.mowgli.ch/pub/debian/pool/unofficial/x/xv/xv_3.10a-27_amd64.deb
Yup.
I couldn't satisfy the dependencies.  It wants an older version of
libpng, for example, and it wouldn't take the current one.

>> # dpkg -i xv_3.10a-27_amd64.deb
>> # dpkg -i xv-doc_3.10a-27_all.deb
>>
>> You are using another Linux or Unix? Try this:
>> - ftp://ftp.mowgli.ch/pub/debian/pool/unofficial/x/xv/xv_3.10a.orig.tar.gz
More compile errors.

>>
>> XV is a piece of software that I reglarly use.
>>
>> (But my requirements regarding iconifying are too low to seriously complain 
>> about)
>>
>>
>>
>> :-)
>> Michael
>
>
> Or what Patrick Volkerding uses to make Slackware package::
> http://slackware.uk/slackware/slackware64-current/source/xap/xv/xv.SlackBuild
More compile errors.

>
> Didier
>
>

What version of gcc should I be using to build this?

Also, I loaded up an empty config, iconified stuff, de-iconified, and
still no problem, but again, it wasn't using xv.

Anyone confirm if xv misbehaves with an empty config?

Also, as a workaround, you might be able to specify an IconBox and set
it only for xv.

Re: FVWM: Forcing icon to prior position

[Stephen Dennison]

On Fri, Jul 13, 2018 at 6:58 PM, Glenn Golden  wrote:
> 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?
>

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?
Have you tried specifying something like
Style xv NoUseIconPosition ?

Re: Static Analysis (Coverity Scan)

[Stephen Dennison]

How do we request access to the scan results?

Trying to view the link tells me I'm not authorized to access the page.

On Wed, Sep 21, 2016 at 5:35 PM, Thomas Adam  wrote:

> Hi all,
>
> A while ago, I set up the FVWM repository to hook into Coverity [0], who
> specialise in static analysis and allow open source projects to be run
> against
> their tools for free.
>
> To that end the results are in:
>
> https://scan.coverity.com/projects/fvwm/view_defects
>
> I think it's rather interesting and perhaps alarming since there's quite a
> few
> defects it considers "high".  But hey, FVWM's still working so improving
> those
> is still a good thing.  Note that I haven't really started looking at
> these to
> see how many are false-positives, but a quick scan suggests these are
> legitimate.
>
> So if anyone wants to have a stab at looking at these, now's the time to
> start
> submitting pull-requests!  However, I suspect I'll be the one doing most of
> the work anyway...
>
> Can't hurt to ask, and to make other contributors (potential or otherwise)
> aware.
>
> -- Thomas Adam
>
> [0]  Another good example of why moving to Github was a good idea.
>
>

Re: FVWM: [Draft] New Configuration Format

[Stephen Dennison]

>
> You can find the draft at:
> https://github.com/fvwmorg/fvwm/blob/ta/new-config-format/
> docs/NEW-CONFIG.md
>
>
I read through the draft a bit, below are my questions/comments.

For parsing compatibility, perhaps a special command, comment, or token to
indicate which format is being used so that FVWM (and humans) need not
guess?

Will there be a way to have fvwm yield it's current configuration while
it's running?  If you're going through the effort of redoing the
configuration parser, this seems like a great time to do this and it would
be a huge motivator for using the new syntax.

I'm trying to make sense of the use of comma in the -w option.  It's not
very mini-CLI of it.  Why not allow the -w option to be specified more than
once and in each case it could make use of a different prefix to the
value.  For example, (if I wanted urxvt to be red and xterm to be blue):

Style -w r:x-terminal-emulator -w c:URxvt Colorset 1
Style -w r:x-terminal-emulator -w c:xterm Colorset 2

Though, in retrospect, perhaps duplicating the option and having a special
prefix in the value probably isn't very CLI either.

Do you plan support actual string names of colorsets or are you just sort
of shoehorning the -n name for the number?

The values passed to -t in those focus commands has me confused.  Above,
something else that had -t used the format screen:desk.page but this
doesn't appear to apply to the Focus command.  Could you more explicitly
describe this?

Re: Issues with how fvwm handles certain (3d) applications

[Stephen Dennison]

> I wonder if this is a graphics driver issue.
>

It reminds me of the kind of symptoms you can see when running compiz,
actually.  Though for me the slowdown is with the 3d accelerated program
when compiz is running, not FVWM.