FVWM: FVWM2: Test if windows has title bar
Hello, how is it possible to test if a window has a title bar (i.e. an equivalent to the test if a windows has resize handles with "ThisWindow (HasHandles)")? Carsten
Re: FVWM: FVWM2: Test if windows has title bar
On Thu, Aug 13, 2020 at 08:41:10PM +0200, Carsten Kunze wrote: > Hello, > > how is it possible to test if a window has a title bar (i.e. an equivalent to > the test if a windows has resize handles with "ThisWindow (HasHandles)")? No. But I'm reminded of this: https://xteddy.org/fvwm/patches.html#toc2 In lieu of that, you could write a function which used State to track this if you know whether a window is going to have a title or not, as in: Style foo, State 0 Style somethingElse, !State 0 DestroyFunc Foo AddToFunc Foo + I ThisWindow (State 0) DoSomethingForTitleOnWindow + I TestRc (NoMatch) DoSomethingForNoTitleOnWindow -- Thomas
Re: FVWM: Microsoft Teams
On Thu, Aug 13, 2020 at 05:50:36PM +0100, Klaus Ethgen wrote: > So I endet more than one time now, typing password into teams where it > should never ever been. > > I already have !FPFocusByFunction and !FPFocusByProgram set but it > doesn't work. Teams might be implicitly using XSetInputFocus() although it's an Electron App, so it's unclear. You could certainly use `xprop -spy` on the window. Speaking of helping things, read this and double-check you're applying these things to Teams: https://www.fvwm.org/Wiki/Tips/FocusStealing/ -- Thomas
Re: FVWM: Microsoft Teams
Anno domini 2020 Thu, 13 Aug 19:53:55 +0100 Thomas Adam scripsit: > On Thu, Aug 13, 2020 at 05:50:36PM +0100, Klaus Ethgen wrote: > > So I endet more than one time now, typing password into teams where it > > should never ever been. > > > > I already have !FPFocusByFunction and !FPFocusByProgram set but it > > doesn't work. > > Teams might be implicitly using XSetInputFocus() although it's an Electron > App, so it's unclear. You could certainly use `xprop -spy` on the window. If that's the case you can build a preloaded library that interceps the function call. nik > > Speaking of helping things, read this and double-check you're applying these > things to Teams: > > https://www.fvwm.org/Wiki/Tips/FocusStealing/ > > -- Thomas > > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
Re: FVWM: Microsoft Teams
On Thu, Aug 13, 2020 at 09:27:10PM +0200, Dr. Nikolaus Klepp wrote:
> If that's the case you can build a preloaded library that interceps the
> function call.
I mention it on that wiki page. So...
Save this as ~/pl_xsetinputfocus.c
-
#include
#include
/* Compile with:
*
* gcc --shared -fPIC pl_xsetinputfocus.c -o disable_xsetinputfocus.so
*
* Then use:
*
* LD_PRELOAD=/path/to/disable_xsetinputfocus.so some_application
*/
int XSetInputFocus(Display *d, Window w, int i, Time t)
{
return 0;
}
-
-- Thomas Adam
Re: FVWM: FVWN on a high density System76 screen
On Wed, Aug 12, 2020 at 07:58:59PM -0400, Dan Espen wrote: > We had a French developer working with us for many years. > Right now I can't recall his name, I used to fix up all the > documentation he wrote. He offered to fix up the comments but > never got around to it. Olivier Chapuis, most likely? Really clever chap. Ended up going on to form Metisse, as I recall. > I also had a plan to add boxes to FvwmForm. The idea being > you'd put fields in lines, lines in boxes, then boxes in the form. > Relief lines around the boxes would be optional. > Just an idea, I never started that. I think that's a nice visual que, and the same could be applied to creating tables as well. > I wanted to do the widgets first. This is definitely an area where FvwmScript has the upperhand, although I admit I've never looked too deeply at how FvwmScript implements the widgets it offers. > Okay, at least you know something is missing. One of many things. :) > > If you have a list of things which could be moved in to FvwmScript from > > FvwmForm, I'd be interested in seeing that. One of the things I liked about > > FvwmForm (I did used to use it, BTW) was it could be told to grab the > > XServer. > > So I wrote a FvwmForm instance to do just that in StartFunction to go in to > > Work or Home mode, which would open certain applications, etc. Although I > > don't have a need for that now, the ability to grab the XServer would still > > be > > useful. > > Not sure I understand. I was referring to FvwmForm's "GrabServer" option. I used to make use of that a lot in the FvwmForms I used to use. > If you look at the comments I left in FvwmForm, I had some idea about > it sitting around as a form display server to make it even faster. > > I'm not sure about FvwmScript but I don't think it has the same capability > to save and reuse what you last entered as FvwmForm does. Oh, almost certainly not. > Since we are blue skying here, I also had an idea that you could use > FvwmForm to design new FvwmForms. It would need the ability to display > tables. Could you expand on this a bit? I'm happy to bring FvwmForm back (to Fvwm3) if the overlap with FvwmScript is to minimal. But I'd like to still explore in which direction an amalgamation between FvwmScript <-> FvwmForm should go. If I've overlooked this in the wrong direction with how things are now, I'm happy to stand corrected! Kindly, Thomas
FVWM: Microsoft Teams
Hi folks,
Lets send that mail again after setting dmarc to quarantine instead of
reject. This Mailinglist does not work with dmarc.
I need to use Microsoft Teams for some reason. My problem is, that when
I get a notification, that notification gets shown in the lower right
side of the screen and direct after that, I get relocated onto the
Screen where Teams is running, independent on what other screen I am
currently and what I do.
So I endet more than one time now, typing password into teams where it
should never ever been.
I already have !FPFocusByFunction and !FPFocusByProgram set but it
doesn't work.
`xev -id 0x481 -event expose -event visibility -event structure
-event substructure -event focus -event owner_grab_button | awk
'{now=strftime("%F %T%z\t");sub(/^/, now);print}'` gave me the
following:
2020-08-12 10:25:12+0100
2020-08-12 10:25:12+0100VisibilityNotify event, serial 18, synthetic
NO, window 0x481,
2020-08-12 10:25:12+0100state VisibilityPartiallyObscured
2020-08-12 10:25:12+0100
2020-08-12 10:25:12+0100Expose event, serial 18, synthetic NO,
window 0x481,
2020-08-12 10:25:12+0100(0,0), width 1804, height 666, count 2
2020-08-12 10:25:12+0100
2020-08-12 10:25:12+0100Expose event, serial 18, synthetic NO,
window 0x481,
2020-08-12 10:25:12+0100(678,666), width 1126, height 515, count
1
2020-08-12 10:25:12+0100
2020-08-12 10:25:12+0100Expose event, serial 18, synthetic NO,
window 0x481,
2020-08-12 10:25:12+0100(678,1181), width 846, height 1, count 0
2020-08-12 10:25:12+0100
2020-08-12 10:25:12+0100ConfigureNotify event, serial 18, synthetic
YES, window 0x481,
2020-08-12 10:25:12+0100event 0x481, window 0x481,
(116,18), width 1804, height 1182,
2020-08-12 10:25:12+0100border_width 0, above 0x140da85,
override NO
2020-08-12 10:25:12+0100
2020-08-12 10:25:12+0100Expose event, serial 18, synthetic NO,
window 0x481,
2020-08-12 10:25:12+0100(0,666), width 678, height 516, count 0
2020-08-12 10:25:12+0100
2020-08-12 10:25:12+0100FocusIn event, serial 18, synthetic NO,
window 0x481,
2020-08-12 10:25:12+0100mode NotifyNormal, detail NotifyNonlinear
Anybody an idea how to get rid of that very annoying behaviour?
Its the most extreme focus grabbing I ever seen; Not even firefox is
that extreme.
Regards
Klaus
--
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
signature.asc
Description: PGP signature
Re: FVWM: detecting "continuous" keyboard modifier
On Tue, Jun 23, 2020 at 11:57:45AM -0400, Paul Fox wrote: > Hi -- > > Is there a way in fvwm to distiguish these two sequences? > alt tab alt tab > ^tab and alt keys both released here > and > alt tab tab > ^ only tab key released here > > I don't recall seeing anything about this in the docs -- but that > doesn't mean it's not there! :-) This is not possible at the moment. Kindly, Thomas Adam
Re: FVWM: FVWM on a high density screen -> FvwmForm
Thomas Adam writes: > On Wed, Aug 12, 2020 at 07:58:59PM -0400, Dan Espen wrote: >> We had a French developer working with us for many years. >> Right now I can't recall his name, I used to fix up all the >> documentation he wrote. He offered to fix up the comments but >> never got around to it. > > Olivier Chapuis, most likely? Really clever chap. Ended up going on to form > Metisse, as I recall. Yep, that's him. >> I also had a plan to add boxes to FvwmForm. The idea being >> you'd put fields in lines, lines in boxes, then boxes in the form. >> Relief lines around the boxes would be optional. >> Just an idea, I never started that. > > I think that's a nice visual que, and the same could be applied to creating > tables as well. > >> I wanted to do the widgets first. > > This is definitely an area where FvwmScript has the upperhand, although I > admit I've never looked too deeply at how FvwmScript implements the widgets it > offers. > >> Okay, at least you know something is missing. > > One of many things. :) > >> > If you have a list of things which could be moved in to FvwmScript from >> > FvwmForm, I'd be interested in seeing that. One of the things I liked >> > about >> > FvwmForm (I did used to use it, BTW) was it could be told to grab the >> > XServer. >> > So I wrote a FvwmForm instance to do just that in StartFunction to go in to >> > Work or Home mode, which would open certain applications, etc. Although I >> > don't have a need for that now, the ability to grab the XServer would >> > still be >> > useful. >> >> Not sure I understand. > > I was referring to FvwmForm's "GrabServer" option. I used to make use of that > a lot in the FvwmForms I used to use. Ah, slipped my memory. >> If you look at the comments I left in FvwmForm, I had some idea about >> it sitting around as a form display server to make it even faster. >> >> I'm not sure about FvwmScript but I don't think it has the same capability >> to save and reuse what you last entered as FvwmForm does. > > Oh, almost certainly not. Well, then it's really inferior to FvwmForm then. At least for the uses I was putting it to. If you want to manage data with a form, you need to be able to read it and save it. >> Since we are blue skying here, I also had an idea that you could use >> FvwmForm to design new FvwmForms. It would need the ability to display >> tables. > > Could you expand on this a bit? I had a lot of experience with IBM ISPF panels. I wanted to model FvwmForm along those lines. That's were the data reading and saving came from. For tables, ISPF lets you say something like here is a line but the line is a model for a table. So, when you design an ISPF table it's a lot like FvwmForm's LINE. You put a bunch of fields on a line with the understanding that the data determines how many times the line is repeated when displayed. With FvwmForm, you'd say, here is a line that should be displayed in a box 10 lines high. So, for example, with FvwmForm's implementation of FvwmTalk, where it shows the last error line, instead you'd say I want to show up to the last 10 error lines. ISPF itself handles things like scrolling the data if the data is bigger than the display area. So, that's the table part. I had the idea that FvwmForm could display a table of lines, let you add or delete lines, or select a line. When you select a line you'd see another table of the fields on the line. You might be able to see where I thought I needed boxes too. > I'm happy to bring FvwmForm back (to Fvwm3) if the overlap with FvwmScript is > to minimal. But I'd like to still explore in which direction an amalgamation > between FvwmScript <-> FvwmForm should go. If I've overlooked this in the > wrong direction with how things are now, I'm happy to stand corrected! Glad to hear it. Fvwm is still pretty far from being able to configure itself. I did some work along those lines with FvwmAnimate and FvwmForm-Form but didn't get far enough. > Kindly, > Thomas A pleasure. -- Dan Espen
Re: FVWM: FVWM on a high density screen -> FvwmForm
On Thu, Aug 13, 2020 at 05:44:10PM -0400, Dan Espen wrote: > I had a lot of experience with IBM ISPF panels. > I wanted to model FvwmForm along those lines. > That's were the data reading and saving came from. That's amazing! I really don't know anything about IBM's early software. The closest I ever got was Rational Rose, back when RUP was popular (early 2000s i when I was exposed to that at University). Needless to say I've not been involved with any commercial companies which have used IBM. I've just watched a Youtube video which highlighted ISPF Panels. I can now really appreciate why you were going down that route. What a lot of fun! > For tables, ISPF lets you say something like here is a line but the line is a > model > for a table. So, when you design an ISPF table it's a lot like > FvwmForm's LINE. You put a bunch of fields on a line with the > understanding that the data determines how many times the line is > repeated when displayed. Right -- I think I understand this. I'm basing a lot of this from this video: https://www.youtube.com/watch?v=eA3rvZwU7e8 Is this what you're referring to, Dan? > With FvwmForm, you'd say, here is a line that should be displayed in > a box 10 lines high. So, for example, with FvwmForm's implementation > of FvwmTalk, where it shows the last error line, instead you'd say > I want to show up to the last 10 error lines. OK. > ISPF itself handles things like scrolling the data if the data is > bigger than the display area. > > So, that's the table part. It's really interesting. Just on the mentioned video above, the style looks similar to a lot of terminal libraries which golang has (one such example would be: https://github.com/gizak/termui). I appreciate we're talking about X11 here, but it's still not to see that in 2020, people are becoming more invested in the terminal and CLIs than they perhaps used to. > I had the idea that FvwmForm could display a table of lines, > let you add or delete lines, or select a line. > When you select a line you'd see another table of the fields > on the line. I really like this idea. I wonder though how heavy this would be on window resize? It might flicker through redraws if we're not careful. > Glad to hear it. > Fvwm is still pretty far from being able to configure itself. > I did some work along those lines with FvwmAnimate and FvwmForm-Form > but didn't get far enough. Well, it's back: https://github.com/fvwmorg/fvwm3/commit/6e65b85d127de9b18022c8073974c2f3745b14a1 Kindly, Thomas
Re: FVWM: FVWM on a high density screen -> FvwmForm
Thomas Adam writes: > On Thu, Aug 13, 2020 at 05:44:10PM -0400, Dan Espen wrote: >> I had a lot of experience with IBM ISPF panels. >> I wanted to model FvwmForm along those lines. >> That's were the data reading and saving came from. > > That's amazing! I really don't know anything about IBM's early software. The > closest I ever got was Rational Rose, back when RUP was popular (early 2000s i > when I was exposed to that at University). Needless to say I've not been > involved with any commercial companies which have used IBM. > > I've just watched a Youtube video which highlighted ISPF Panels. I can now > really appreciate why you were going down that route. What a lot of fun! Yes, it actually was a lot of fun. But that presentation was painful to watch. First, DTL is crap, you really want to use ISPF as it was originally designed. You create a text image of the screen using punctuation to mark input and output fields. Second, he says you have to restart ISPF to be able to access your changes. But that start command he was issuing does not restart ISPF and he showed himself going to option 7. Once you go to option 7 you no longer have to exit ISPF to be able to use your panel changes. Option 7 puts ISPF in test mode. Any competent ISPF developer would be starting ISPF in test mode anyway. (Test mode just makes ISPF always read the panel definitions instead of using a cached copy.) At work I had a base of about 300 users. I put them all in test mode because I liked to make changes all during the day. Third, there's zero reasons to write REXX for a menu, the panel itself can do the entire job. There's no reason to compile panels. I did tests, you just give ISPF the source and it displays panels fine and just as fast as the compiled panels. On and on. I could probably create a list of 50 things that guy wasn't doing right. I hope you got a feel for it. He showed the TBADD function followed by TBDISP that's the gist of it. You can do all your data verification right in the panel. TBADD is just like creating an array in a unix shell. So you build up an array then in the panel your name for the array. The panel figures out how big the array is and displays as many occurances as it can fit on the screen. A lot of the tables you saw being displayed as he was working are the development panels from IBM. They're totally uninspired, I had a lot of fun creating replacements. I once ran a help desk for a large herd of UNIX C programmers forced into working with ISPF. They pretty much hated the environment. I unleashed a bunch of panels I had written on them and they were converted on the spot. I never used Rational Rose. >> For tables, ISPF lets you say something like here is a line but the line is >> a model >> for a table. So, when you design an ISPF table it's a lot like >> FvwmForm's LINE. You put a bunch of fields on a line with the >> understanding that the data determines how many times the line is >> repeated when displayed. > > Right -- I think I understand this. I'm basing a lot of this from this video: > > https://www.youtube.com/watch?v=eA3rvZwU7e8 > > Is this what you're referring to, Dan? Yep. I wish I could show you some of the stuff I did, but of course that belonged to my employers so I left it behind. >> With FvwmForm, you'd say, here is a line that should be displayed in >> a box 10 lines high. So, for example, with FvwmForm's implementation >> of FvwmTalk, where it shows the last error line, instead you'd say >> I want to show up to the last 10 error lines. > > OK. > >> ISPF itself handles things like scrolling the data if the data is >> bigger than the display area. >> >> So, that's the table part. > > It's really interesting. Just on the mentioned video above, the style looks > similar to a lot of terminal libraries which golang has (one such example > would be: https://github.com/gizak/termui). I appreciate we're talking about > X11 here, but it's still not to see that in 2020, people are becoming more > invested in the terminal and CLIs than they perhaps used to. termui might be close. If you've done table views with QT or tables in GTK they are similar too. >> I had the idea that FvwmForm could display a table of lines, >> let you add or delete lines, or select a line. >> When you select a line you'd see another table of the fields >> on the line. > > I really like this idea. I wonder though how heavy this would be on window > resize? It might flicker through redraws if we're not careful. Well, I did have a plan to make FvwmForm persistent so you wouldn't be reloading the module for every redraw. >> Glad to hear it. >> Fvwm is still pretty far from being able to configure itself. >> I did some work along those lines with FvwmAnimate and FvwmForm-Form >> but didn't get far enough. > > Well, it's back: > > https://github.com/fvwmorg/fvwm3/commit/6e65b85d127de9b18022c8073974c2f3745b14a1 Good, I think you made the right choice and it should save you s
FVWM: When will fvwm3 be ready to start trying out?
I've been using fvwm2 for a while, but I do find the syntax a bit hard to follow. I've also had problems getting many example configs to work right. Which means I'm pretty open to trying fvwm3 out. I've cloned the git, but I haven't had a chance to look at the code yet. I'm using OpenBSD. I'm defintely no pro, but I don't have any problems with trying to compile it. Thanks for the hard work! Chris Bennett
