from:"Matthew D. Fuller"



On Sat, Mar 06, 2021 at 07:26:32PM +0100 I heard the voice of
Maxime Soulé, and lo! it spake thus:
> 
> I take advantage of your message to remind the list about 2 small patches
> that does not seem to be integrated:
> 
> https://github.com/maxatome/ctwm-mirror/commit/6f0f08ca4aea429424a3b3abf455a84c4022a778
> (Matthew told us on 12th, July 2020 it is committed, but I don't see it in
> master branch)

It was, in r673.


> https://github.com/maxatome/ctwm-mirror/commit/ee70936830720992ba63cd29ef3220331c663e95
> (related problem in same mail thread)

Makes sense; up in r677.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: SloppyFocus



On Thu, Mar 04, 2021 at 11:07:29PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> I've been wondering about the use of SynthesiseFocusIn().
> SetFocus() does mostly the same as what HandleFocusOut() followed by
> HandleFocusIn() does, plus an actual call to XSetInputFocus(). And
> those are the exact functions that get called to handle the
> synthetic focus messages.  It would be cleaner perhaps to have
> either one method or the other but not both.

Well, we need the handling of HandleFocusX() because we may not always
be the initiators of focus changes, but we need to react to them.
Now, there is a fair measure of semi-duplicated code there, and
certainly the path through the event handlers is...   I mean, does
that even qualify as a path?   :>

It's probably not entirely unreasonable to imagine that all the "react
to focus change" things like decorations etc should be purely in
HandleFocusX, and SetFocus either (a) should just achieve them via the
synthesized events, or (2) should call a shared function for them.

But, the details of just what X actually sends are surprisingly
surprising; I spent a while tracking focus and enter stuff a while
back when working on somethingorother, and all my dreams of "this is
The Way X Will Always Signal This, so we can stop half-implementing
parts of it scattered all over different events" were dashed pretty
hard, and I decided it was simplest to assume it all worked perfectly
and pretend I never saw any of that code   :|


> I re-ordered it like below, and the results are a lot better.
> 
> if(!Scr->TitleFocus) {
> if(Tmp_win->wmhints->input) {
> SetFocus(Tmp_win, ewp->time);
> }
> if (Tmp_win->protocols & DoesWmTakeFocus) {
> SendTakeFocusMessage(Tmp_win, ewp->time);
> }
> }

This seems facially reasonable, in light of

> I'm also uncertain about what is meant with "both locally & globally
> active clients".

This is the ICCCM focus stuff:
https://www.x.org/releases/X11R7.7/doc/xorg-docs/icccm/icccm.html#Input_Focus

DoesWmTakeFocus is our indicator that it's one of the
{Locally,Globally} Active cases.  So the point of the comments is that
the Locally Active case should get a SetFocus() call, but Globally
shouldn't.  And both Locally and Globally should get the
SendTakeFocusMessage().

But with the matrix as is, we only need the two orthagonal checks;
Passive and Locally Active would both have wmhints->input set, and
those are the only cases where we'd want to SetFocus().  And only the
*Active's will have DoesWmTakeFocus, and only they should get the
SendTakeFocusMessage().  So the existing comments are correct-ish,
though probably slightly misleading in that they suggest a diff
between Locally Active and Passive, in a place where there isn't
one...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: SloppyFocus



On Wed, Mar 03, 2021 at 10:56:15PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> I do (sometimes, depending on mouse speed it seems) that the focus
> remains on the previous window if I move into xload.

Now, note that xload _does_ set WM_HINTS, and explicitly says it
doesn't take input focus, so we _do_ obey that and don't focus over to
it.  Though I believe that's a change; I vaguely recall that earlier
versions disregarded that, and focused it anyway; was in the same
4.0.0 changes where we chose to focus with no hints at all.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: SloppyFocus



On Wed, Mar 03, 2021 at 08:18:59PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> With the ctwm included in 9.1 (still with SloppyFocus), xev did get
> mouse events, but its window did not get the focus decoration
> change.  Keyboard events went to the previous window (which had the
> focus decoration). I'd say that this is a bug compared to later
> versions.

Well, I dunno what version that is, though
https://man.netbsd.org/NetBSD-9.1/i386/ctwm.1 lists 3.7.  Yow.

But anyway, xev doesn't set any WM_HINTS, so it'd be 4.0.0 before we
started forcing focus onto it anyway.  So, one _could_ argue that, as
a program that's there to monitor events, and probably wants keyboard
events, it's a bug that it doesn't ask the WM for keyboard events
too...  but yeah, current version would be always giving it focus
anyway.



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Manual page: Exiting CTWM without session manager



On Wed, Oct 21, 2020 at 03:48:48PM +0200 I heard the voice of
Michael Siegel, and lo! it spake thus:
> 
> > This program is usually started by the user’s session manager or
> > startup script. When used from xdm(1) or xinit(1) without a session
> > manager, ctwm is frequently executed in the foreground as the last
> > client. When run this way, exiting ctwm causes the session to be
> > terminated (i.e. logged out).
> 
> That last sentence should be re-written because:

Hm.  Little tricky; in a little mental wandering I haven't come up
with anything great for it.  Seems like what it actually means is
either Obvious(tm) to you at a casual mention ('cuz you know how all
these pieces fit together, and this just reminds you), or requires
paragraphs of discussion...


>   a) The session getting terminated here is the current X session.
>   b) This does not log the user out of the shell session in which CTWM
>  had been running.

I think it's written to mean the X session is logged out, and so e.g.
all the xterms you have are logged out too.  I note that it's word for
word unchanged from twm's man too (apart from s/twm/ctwm).

But I guess we can at least do a little tweaking to make it harder to
misread; up in r676.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Some small cleanups

2021-03-05 Thread Matthew D. Fuller



On Fri, Mar 05, 2021 at 02:09:08PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> They are in my "small beer" branch: lp:~rhialto/ctwm/smallbeer
> 
> If there are no objections I will merge these to trunk in a few
> days.

Mostly LGTM.  I don't have any deep knowledge or strong feelings about
the touched code, so it's a fairly surface review.  And all the tests
still pass, so it must be flawless, right?   :>

Couple random notes and one slightly bigger:

- r676, "Add a missing break statement."  By my reading, this doesn't
  _functionally_ change anything (except maybe a doubled up weird
  error message if you mess up your config somehow), just makes the
  code flow more proper?

- The NULL check removals in the ring manglement funcs.  Sounds
  reasonably in general, but wanted to be sure you checked it in edge
  cases; e.g., if there's nothing in the ring or the like, might we
  have NULL's snuck in somehow?

- r681: WindowIsOnRing() should be static?


And the one slightly bigger:

- AddWindowToRing() and friends should probably live somewhere other
  than functions_internal.c, since they're used from code not related
  to functions.  Pulling in functions_internal.h in non function*.c
  files smells a bit.  Maybe win_utils.[ch]?  's a bit of a dumping
  ground, but maybe it's the right dumping ground?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: unicode fonts, and firefox hogging focus

2020-10-17 Thread Matthew D. Fuller



On Tue, Oct 13, 2020 at 05:26:41PM + I heard the voice of
nia, and lo! it spake thus:
> 
> My understanding is that ctwm does not use freetype or fontconfig at all,
> it just takes XLFDs which only work with bitmap X11 serverside fonts?

Correct (hopefully not forever; it _is_ one of the things on my todo
list.  Of course, it looks like about half the world is currently also
on the list keeping it company...)

I don't use any explicitly unicode fonts, but I don't have a problem
seeing all sorts of characters I can't type or draw in menus, titles,
icon managers, etc.  My font specifiers are pretty genericized:

IconManagerFont "-adobe-helvetica-bold-r-normal--*-100-*-*-*"
MenuFont"-misc-fixed-bold-r-normal--*-140-*-*-*"
TitleFont   "-misc-fixed-medium-r-normal--*-130-*-*-*"

etc

Unfortunately, my experience is figuring out what went wrong when
XLFD's don't do what you expect is...fun.  Let's go with fun.
It's totally inaccurate, but it's a safe word, right?


> Upgrading is blocked on the Firefox regression in newer versions.

That is somewhat curious.  I use FF every day, and haven't seen any
behavior like that.  All the focus related issue we've fixed are in
releases.  The _NET_FRAME_EXTENTS stuff is still unreleased in trunk,
but I don't see how that could affect focus; AFAIK we only saw it in
positioning of form filler dialogues, menus, etc.

I'd be sure to try the compiled-in default config, just to be sure you
haven't hit some odd interaction with your other options.  The next
place I'd start looking is at EWMH stuff, since that's a big
post-3.8.2 way clients get to ask more things directly of us.  Trying
a 4.0.3 or trunk build with USE_EWMH disabled is a quick way to check
that.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Start ctwm in linux run-level 3 or 5?

2020-07-18 Thread Matthew D. Fuller



On Mon, Jul 13, 2020 at 04:00:43PM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> E.g. I use XFCE and haven't bothered to arrange for ctwm to be started
> properly, so every time I log in I have to do the funny dance:
> 
> pkill xfwm4; ctwm&

A quick glance at the code suggests that xfwm4 handles the ICCCM
window manager selection stuff, so `ctwm --replace` seems like it
could work.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Fix for overflowing titles when using TitleJustification center

2020-07-18 Thread Matthew D. Fuller



On Wed, Jul 15, 2020 at 02:00:30AM +0200 I heard the voice of
Carl Svensson, and lo! it spake thus:
> 
> [...] but gives very funny results if the title string is longer,
> the main issue being that the title bar covers any window gadgets to
> the right of it (such as resize).

It doesn't overwrite them for me (though it does _under_write them,
which looks a little wacky, but whatevs (as the kids say nowadays)).
It also does extra wacky things with the hilite windows, if your
config uses such.

If you accidentally look too close, there are all sorts of "hmm,
that's funny"'s in titlebar setup.  With center justification, for
instance, you notice that the padding on the left vs right between the
title text and the hilite windows looks weird, or that the padding on
right-justified titles doesn't seem to push it far enough from
titlebar buttons...   don't look too close!  That way lies madness!


> I've concocted a small fix for this, [...]

Probably don't want to do it quite that way, since it messes up the
fallthru from the TJ_UNDEF case (which shouldn't ever be possible to
hit; config parsing and defaulting should always leave something
there, but hey, Murphy...).  I think the simplest way is just decide
whether to override before we switch(); fix up in
https://bazaar.launchpad.net/~ctwm/ctwm/trunk/revision/675


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Title bars much too tall after reinstalling linux on laptop



On Sat, Jul 11, 2020 at 01:26:53PM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> The problem Tadziu describes seems to indicate that either my hack
> isn't working any more, or that some other problem is at play (maybe
> the height of each char is itself wrong?).

Yeah, my best guess for Aaron's issue is that it's just a matter of
what fonts are available/chosen.  Some weird stuff can happen down in
the X libs when picking a font for a given XLFD.


> `bzr` itself has been moribund for quite some years now :-(

Indeed.  I'm using brz for most day to day stuff, but I do still have
to step back to bzr for a few plugins like bookmarks that aren't
ported over (I keep bugging the devs  ;)


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Start ctwm in linux run-level 3 or 5?



On Sat, Jul 11, 2020 at 09:56:30PM +0100 I heard the voice of
Aaron Sloman, and lo! it spake thus:
> 
> One benefit of starting in Level 3 that surprised me is that firefox
> now detects the difference and adds useful extra buttons at the top
> right, mentioned in a previous message:

I would assume that this is just the presence of some other random
"desktop service" that is getting started in 5 but not in 3, and thus
available to firefox.  Maybe dbus or something?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Bug found in bugfix :-)



> I'll see what I can dig up...

In some experimentation, I haven't managed to trigger any
ConfigureRequest's at all in popping up the context menu (or any
menus).  i.e., a fprintf(stderr) at the top of
HandleConfigureRequest() doesn't even happen.

I'm on FF 78; maybe there was some weird behavior in 77?  Don't recall
seeing it here, though.  Anybody have ideas on how the event might get
triggered?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Fix bad shift when squeezing with 3D borders disabled



On Thu, Jul 09, 2020 at 06:33:05PM +0200 I heard the voice of
Maxime Soulé, and lo! it spake thus:
> 
> The fix: 
> https://github.com/maxatome/ctwm-mirror/commit/6f0f08ca4aea429424a3b3abf455a84c4022a778

Yep, looks right.  Committed.


> It is weird (but probably historic?) that frame_bw and frame_bw3D
> fields have the same meaning for the user (the border width, but one
> for flat design and the other for 3D), but are not used equally in
> the code.

This is trickier than it seems like it should be because of how the
borders work.  The 2d border is an X border (setup in the
XCreateWindow() for the frame, add_window.c:1524), which is on the
outside of our frame window.  The 3d border is a drawing we do
_inside_ the frame.  So, with 2d borders, the left side of the
internal window is at X coordinate 0 relative to the frame, whereas
with 3d it's a ->frame_bw3D.

See also the comment in win_decorations.c:1527.  That's why we're
often doing things like -frame_bw (because it's "outside" of our
stuff), but +frame_bw3D (because it's "inside").


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Bug found in bugfix :-)



On Fri, Jul 10, 2020 at 12:36:51AM +0200 I heard the voice of
Carl Svensson, and lo! it spake thus:
> 
> After a bit of fiddling around, I managed to narrow it down to
> UseThreeDBorders and found this little chunk of code in
> event_handlers.c:
> 
>   /* Workaround for Java 1.4 bug that freezes the application whenever
>* a new window is displayed. (When UsePPosition is on and either
>* UseThreeDBorders or BorderWidth 0 is set.)
>*/
>   if(!bw) {
>sendEvent = true;
>   }
> 
> When commenting out that little if-statement and recompiling, the
> Firefox context menu works as expected again.

(I assume you mean commenting out the whole thing, so sendEvent
doesn't get set, rather than commenting just the conditional, so
sendEvent _always_ gets set)

First off, sentEvent essentially winds up controlling whether we send
a ConfigureNotify[0] on down to the window the event happened in.  So
why would FF come up with "Oh, my main window may have moved or
resized, that must mean you clicked somewhere in the new context menu
window"?  Wacky wacky.  I mean, even on the scale of wacky things
we've seen FF do...

The if(bw) thing seems weird too.  From context, I guess that's just a
obsure way of expressing "if 3dborders"?  I'll see what I can dig
up...


> Not sure how to approach this - it seems to be a fix for something
> else already, although I suspect Firefox is a more common
> application than Java 1.4 (which I think is from 2002 or something).

The origin seems to be in r79, which lists it among the other things
it pulled in as

* Andys java fix
  http://tigerdyr.wheel.dk/ctwm-archive/1151.html

archive.org to the rescue!


https://web.archive.org/web/20051031140029/http://tigerdyr.wheel.dk/ctwm-archive/1151.html

I did a little poking around Java's bug history, but couldn't find
anything.  Maybe Oracle re-proprietorized it.




[0] 
https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#ConfigureNotify_Events


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Title bars much too tall after reinstalling linux on laptop THANKS



On Fri, Jul 10, 2020 at 12:30:07AM +0100 I heard the voice of
Aaron Sloman, and lo! it spake thus:
>
> I later decided that just a function key is is too risky, e.g. if I hit F4
> instead of F3 by mistake, ...
>
> So "delete window" now requires a modifier key + F3.

I double up to Ctrl-Shift:
"F5"= c|s : title|window|iconmgr : f.delete
"F6"= c|s : title|window|iconmgr : f.destroy


> The modifier is CTRL for now, partly because there are CTRL buttons on
> both sides of the keyboard -- though I always swap the left CTRL with
> CapsLock, which is used much less often.

As a sensible person, I also do the same.  Well, I don't _swap_, I
just _add_.  I can just set something heavy on the shift key if I ever
need capslock for something.  Actually, I recently (-ish) went a step
further, and starting using xcape to let it be both Esc and Ctrl.  Not
without some negatives, but works pretty well for me.


On Fri, Jul 10, 2020 at 02:59:18PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
>
> The solution I found is that my shortcut key opens a pop-up menu with
> just one entry, and I have to select that option before it really
> deletes the window.
>
> "w" = HRDWNDWMETA : window|title|icon : f.menu "closemenu"
>
> menu "closemenu" {
> "Close Window (W)" ("white":"red") f.delete
> }

Think it's come up before, but I do similar things with f.quit in my
menus.  Including a nop line to make me have to move the mouse, as
extra buffer against accidents.  Totally not because I accidentally
hit it twice one day, no sir.

[... some menu ...]
"Exit   "f.menu "exit"

menu "exit"
{
"Exit?  "f.title
"   "f.nop
"Yes, dammit"f.quit
}



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Title bar problem by-passed, perhaps permanently!

> On Tue, 7 Jul 2020 17:03:41 +0100
> Aaron Sloman  wrote:
> > 
> > Likewise using mouse/keypad Button3 to invoke f.resize and two
> > buttons for fullzoom and (vertical) zoom.

Another possibility is that you can do mouse button bindings in the
context of the window frame, so just clicking on the border puts you
in resize mode.

On Tue, Jul 07, 2020 at 12:12:46PM -0400 I heard the voice of
Steve Litt, and lo! it spake thus:
> 
> There's one thing you could add to the preceding: A function to toggle
> the title-bar, [...]

Functionality for that sort of thing is floating around my list, ever
since the RANDR multimonitor support made it easy to see what a gross
thing we do with fullscreenzoom.  It's not _quite_ as trivial as you'd
think at first (especially if you want toggling it to visually add the
titlebar to the top, vs shifting the whole window down by the TB's
height), but it's probably not too bad, especially if you're willing
to toss "maintains state across restarts" overboard.

-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Title bars much too tall after reinstalling linux on laptop



On Thu, Jul 09, 2020 at 09:19:41PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> I think there was even some code change somewhere in ctwm to compensate
> for this, but I'm now trying very hard to remember where that was...

I believe that was in with some of the stuff from Stefan you merged
just after 3.8.2 (r298), so it'll be in everything 4.x.


> (and currently `bzr qlog` has broken on my system... claiming it
> can't find a module named sip, even though I have sip for both
> python 2.7 and 3.7...)

Yeah, qbzr hasn't seen any work in a long time.  It's never been
updated to QT5, never mind catching up to py3 etc, and I'm sure even
with old QT and py2 it's broken with breezy anyway   :|


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Questions about contributing

2020-05-17 Thread Matthew D. Fuller



Hi Carl,

> I recently discovered CTWM as an alternative to TWM.

Welcome to the party   :)


> I did notice a few snags during my first days of usage, one of which
> is that icon names overpaint their containing borders in the icon
> manager. I've searched this mailing list but couldn't find anything
> current pertaining to this issue.
[...]
> For now, I forked the github repo and pushed my change there:

With a little experimentation to figure out where the problem comes
from, and why this fixes it, it looks right to me.  I'll go ahead and
get it in, thanks!


> but before I do anything stupid, I'd like to know if there's
> anything I should pay special attention to.  Formatting and coding
> conventions, review prodecures, what have you.

There are vague scribblings in the direction of a developer's manual
in doc/devman/ in the tree, which includes a bit about code style.
The README tells how to build the HTML output, though it's just
AsciiDoc, so it's easy enough to read the source.  Review procedure is
generally just "bring it up on the list", so you're there.

The git conversion for the mirror isn't really round-trippable, so
pulling changes from that mostly decays to patch application.  For
larger or multi-step changes, it'd be preferable to be able to merge
them with history and attribution etc intact, so it'd be better to
have them in bzr (or brz, nowadays), but for simple stuff there's not
much difference getting a git commit or even just an attached diff.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: MenuBorderColor, MenuBorderWidth?

2020-05-02 Thread Matthew D. Fuller



On Tue, Apr 28, 2020 at 11:29:59AM -0400 I heard the voice of
Caleb Malchik, and lo! it spake thus:
> 
> TWM has the settings MenuBorderColor and MenuBorderWidth.  [...]
> 
> CTWM lacks these settings.  Is there some other way to configure the
> menu border color and width?

Doesn't look like it, no.  The border color is the menu foreground
color, and the width seems to be fixed (though different on 3D vs not
menus).

A little investigation suggests twm went from roughly what we still
have to its current scheme in XFree86 4.3.99.16; the git history seems
to have lost the granularity of the CVS changes, so it's a bit mixed
with other stuff in e51f25fbe75b222b24f4628b2408e899fa4748d7.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: m4 error at startup

2020-02-15 Thread Matthew D. Fuller



So, I took a little time to give this a fresh look over...

On Wed, Oct 23, 2019 at 11:01:44AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> So the test encounters the same problem yet it passes.

The root of this is that "test passing" is "our test process exited
0", and we don't watch m4's exit code.  Whether we _should_ is another
question...


> 3: /usr/bin/m4: syscmd subprocess: No child processes
> 3: /usr/bin/m4:/tmp/monnier/ctwmrc.XXAiGjku:31: cannot run command 
> `/bin/rm /tmp/monnier/ctwmrc.XXAiGjku': No child processes
> 
> BTW, an interesting detail: there's no /tmp/monnier/ctwmrc.* file left
> over, despite that message!

What's interesting here is that, in some testing, I couldn't make
anything fail this way, even using GNU m4 (which I assume you're
using, and matches those messages).  And those messages seem to point,
not at "can't run rm" (which it apparently does, and is why the file
is gone), but more along the lines of "can't reap rm process"; the 'No
child process' seems to be a perror() you can get from a failure in
waitpid(), when SIGCHLD is being ignored.

So, maybe the m4 process is inheriting our SIG_IGN there, and isn't
prepared for that to be the case?  You could try commenting out the
ignore in signals.c and see if that makes a diff (don't run your
desktop with a ctwm like that, of course, but for testing and/or using
the test_m4 like above...  :)



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Patch for crash in combination with QMMP

2020-02-15 Thread Matthew D. Fuller



Hi Kbamba,

Sorry for the delay looking into this; busy day^Wmon^Wyea^Wlife...

> When starting QMMP (I'm on FreeBSD), ctwm crashes in ewmh.c . It
> appears that vs->wsw->currentwspc isn't occupied as expected. The
> following patch fixes the crash.

So, I don't see any obvious way vs->wsw could be NULL.  However,
->currentwspc could be, for the case where you have no WorkSpaces in
your config.  That triggers it for me (only way I found in a little
fiddling), so I'm guessing that's your config.  I'd guess that that's
a somewhat uncommon ctwm config, and QMMP is also relatively uncommon
in sending _NET_WM_DESKTOP messages, so hitting the bug takes the
(somewhat + relatively) intersection of those sets.

So I'd suggest the slightly simpler

--
=== modified file 'ewmh.c'
--- ewmh.c  2019-10-19 01:58:57 +
+++ ewmh.c  2020-02-15 23:03:49 +
@@ -1623,7 +1623,7 @@
occupation = twm_win->occupation;
 
/* Remove from visible workspace */
-   if((vs = twm_win->vs) != NULL) {
+   if((vs = twm_win->vs) != NULL && vs->wsw->currentwspc != NULL) {
occupation &= ~(1 << vs->wsw->currentwspc->number);
}
 

--

variant.  You could also work around it by just having a defined
workspace (or 10 :).  I don't unsuspect that we have more similar bugs
hiding around the codebase assuming there are workspaces...


I wonder if we should change things to synthesize a single workspace
when none is given in the config.  Might be some downstream
simplification that could add.  We'll wait 'till next week to talk
about the simplification from killing the ->vs bit of the equation  :p



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Firefox field autocomplete drop-down menu annoying problem

2019-10-18 Thread Matthew D. Fuller



On Thu, Oct 17, 2019 at 06:22:17PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> Maybe they mean that _NET_FRAME_EXTENTS is meant to be set only
> *after* a window is mapped, and _NET_REQUEST_FRAME_EXTENTS can
> request that it happens earlier.

My best reading is something like that.  Or, alternately, that we're
talking about 2 separate features (EWMH is nicely full of those); one
where the WM sets the property to pass along the information, and one
where the client sends the message to request a guess about the info
before the WM really knows it to set.

So, I think we can go ahead and implement the first feature, and
continue to ignore the heck out of the latter.  I think it's actually
in the category of things we'd have to advertise in _NET_SUPPORTED,
and the client shouldn't send it if we don't anyway.

In fact, trying to support that would be a pretty sizable change.  We
don't AddWindow() until a window _is_ mapped, so that would be
starting to listen to and interact with windows we currently
completely ignore the existence of.  Tweaked Max's code a little and
merged.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Firefox field autocomplete drop-down menu annoying problem

2019-10-18 Thread Matthew D. Fuller



On Thu, Oct 17, 2019 at 11:23:58AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> AFAICT, that doesn't explain why this is needed for Firefox's
> popups.

It's because the form autofill popups[0] are separate windows
positioned by FF on top of it.  That is, they're not _children_ of the
main FF window; they're separate root-level X windows.  That's
necessary in the context menu's case, because it may need (well, want)
to extend outside the main FF window, for instance.

Now, I think in the abstract, the toolkit could use
XTranslateCoordinates() to figure out where to position [absolutely]
the new window, so that it's in the proper place relative to the
action it's trying to perform inside the window.  So, in some strict
sense, maybe it's a FF (or probably GTK, maybe) laziness bug.  But,
whatever...



[0] Also visible in some other cases, like the right-click context
menu; it _should_ come up with the top-left corner at the pointed,
but winds up with the mouse a titlebar-height down into it.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: m4 error at startup

2019-10-17 Thread Matthew D. Fuller



On Thu, Oct 17, 2019 at 01:37:13PM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> It's not just "often enough", it's "every time".

So much the better; easier to track down and verify a fix   :)


> That's my question.  When I try to run `m4` manually with
> 
> /usr/bin/m4 -s ~/tmp/foo.m4 -

Check the output of the build, or the generated build/ctwm_config.h,
to see what M4CMD wound up being; maybe it's running a different one.
e.g.,

-- Enabling m4 support (/usr/bin/m4).


Or, maybe there's some trivial different in the syscmd() invocations?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: fullscreen not quite using all the screen

2019-07-30 Thread Matthew D. Fuller



On Mon, Jul 29, 2019 at 10:36:57AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> FWIW, I haven't tried to use f.fullscreenzoom, instead I'm using F5
> in `evince` which AFAIK sets the FULLSCREEN hint.
> 
> I assume ctwm handles both cases in the same way, but I just wanted
> to clarify.

Yeah, it does.

EwmhClientMessage()
  -> EwmhClientMessage_NET_WM_STATE()
 With fullscreen flag, sets it and then calls
  -> EwmhClientMessage_NET_WM_STATEchange()
 with EWMH_STATE_FULLSCREEN -> set window zoom to F_FULLSCREENZOOM

So it's identical to calling f.fullscreenzoom yourself from ctwm's
side.

Now, it also then winds up going out via EwmhSet_NET_WM_STATE() and
passing back an EWMH message to the window saying "hey, you're
fullscreen'd".  So it's possible some apps might act a little
differently if you tell it directly to fullscreen so that _it_ sends
the 'state=FULLSCREEN' message itself, vs it just getting a
'state=FULLSCREEN' message from ctwm.  But how it gets sized up and
positioned on the screen is probably going to be exactly the same[0].



[0] Unless the app then putzes with its own size/position or something
afterward.  But who'd write an app that tries that hard to screw
with the WM and the user, anyway?



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: fullscreen not quite using all the screen

2019-07-28 Thread Matthew D. Fuller



On Wed, Jul 24, 2019 at 10:12:29AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> For some reason, ctwm obeys this setting not only for normal windows
> but also for fullscreen windows.  [...]
> 
> That seems like a bug to me.

It's probably a matter of definition, what _should_ happen there.  I
don't know fd.o stuff well enough to know offhand whether there's
specified behavior or not.

It doesn't seem unreasonable to make a distinction between the
behavior of reserved spaces in the f.fullscreenzoom case, vs.
f.fullzoom and the other *zoom's.  Really, fullscreenzoom needs some
work in general anyway, to deal with how it treats the window
decorations.  Now that we have the RLayout stuff, the cheat it does is
no longer quite as clever, and often amusingly (if you're feeling
charitable) visible.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: 4.0.3 release announcement

2019-07-28 Thread Matthew D. Fuller



On Wed, Jul 24, 2019 at 10:51:03PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> I saw something about forcing focus on unwilling windows.
> I also noticed that my xload windows don't get focus any more (the title
> bar doesn't show it, and my keyboard shortcuts for depth manipulation
> don't work on it). I guess the second is not intentional, given the
> first?

The only focus thing in 4.0.3 was some dealing with applications that
_re_set WM_HINTS at runtime; I don't see how that would affect things.
And 4.0.3 is just trunk as of last fall before the RANDR changes, plus
the OTP crashfix, so it's probably code you've been running a while
anyway.

For that matter, 4.0.2 only had the focus tweak that affected firefox
menus and the like; the last big readjustments we did were in 4.0.0.
So, I guess the question is the time span of "any more".


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

4.0.3 release announcement

2019-07-21 Thread Matthew D. Fuller




Welcome to the world, CTWM 4.0.3 release.

This is a minor bugfix update to 4.0.2 release.  It includes a couple
of minor bugfixes done following 4.0.2, and a fix for crashes in OTP
triggered by fullscreen windows with transients.  See CHANGES in the
tarball or on the website for details.


The release is available now in the website as both .tar.xz and
.tar.gz.  The .xz is meaningfully smaller, the .gz may be useful on
systems lacking xz support.

ctwm-4.0.3.tar.xz:
  MD5: 545baf676d93250fe2ab8399dd355b72
  SHA256: 2e4b475a0168cb799723fd693b359e188179e51ce476ab453689db8fcdfc800c

ctwm-4.0.3.tar.gz:
  MD5: dcf833dff76992a48d1a12ac86532acb
  SHA256: ddecd4530fd1efa2d19d594d9803e6e9f15788396f891c3195d5ad232052e017


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Binding a function to key+mousebutton

2019-07-14 Thread Matthew D. Fuller



On Mon, Jul 08, 2019 at 01:31:51PM +0200 I heard the voice of
Frank Steiner, and lo! it spake thus:
>
> Now with that Ungrab commented out, [...]
>
> This is correct, of course, because the left mouse button is still
> hold and then xvkbd "executes" the right mouse button, [...]
>
> Thus, the XUngrabPointer in the f.exec allows the command that is
> executed by f.exec to simulate mouse clicks even if f.exec was
> started by a mouse click. This makes sense with my xvkbd example.

Sounds like a reasonable analysis.


> So the bug is somewhere else: Looking at xev, the first click of the
> mouse button bound to the f.exec  shows the ButtonRelease event, as
> it should.

This is where the wheels fall off.  It _shouldn't_.  xev only sees the
Release event because we UnGrab'd, which is why ctwm doesn't.  If you
comment out the UnGrab, xev _won't_ see it anymore, because ctwm gets
it and handles the Release.

With the ungrab in place, ctwm never gets the release event, which is
why xev sees it.  The second time you click, we hit the error path in
HandleButtonPress(), which specifically Grab's the pointer and
subscribes to ButtonPress/Release events (and then _doesn't_ proceed
to the f.exec which Ungrab's), which is why we see the release the
second time.   (see long stuff at the end of mail for instrumentation
results)

Now, when running from a menu, we're already in the Release handler
when we f.exec.  So when the exec finishes, we already know we're
Release'ing, so we do all the cleanup.  So that's why _that_ works as
expected.


(In case you're skimming; the below patches are all fun things to mess
with to see why things are happening; none of them are solutions to
the problem, or even things you should run with in production!)


So, we can work around that by re-Grab'ing after executing the
function, Just In Case(tm) we ungrab'd in the process (patch below).
That's not actually a solution though, since we it's only in _that_
case that we should re-grab.  For instance, with the following patch,
try doing a Press-related action (like moving a window by clicking the
titlebar), then notice that a click anywhere acts as a click on the
root (e.g., pulling up a menu).

And we don't want to re-grab inside the f.exec handler itself unless
we know we should have been grabbed beforehand, since we might not get
there as a result of a ButtonPress/Release anyway; what if it were a
keybinding?  So, we probably need to get even extra smartererer about
knowing whether we _should_ ungrab in f.exec, and if so, how we should
re-grab afterward.  Unfortunately, there's no
XPlzToTellMeMyCurrentPointerGrabbingStatus().  Mmmlech.  Just what we
need, another random magic-state-tracking global var...


---
=== modified file 'event_handlers.c'
--- event_handlers.c2019-07-11 02:13:12 +
+++ event_handlers.c2019-07-15 00:55:47 +
@@ -2995,6 +2995,10 @@
 #endif /* EWMH */
ExecuteFunction(func,
Action, 
Event.xany.window, Tmp_win, , Context, false);
+XGrabPointer(dpy, Scr->Root, True,
+ ButtonReleaseMask | ButtonPressMask,
+ GrabModeAsync, GrabModeAsync,
+ Scr->Root, None, CurrentTime);
}
}
}

---




The following is just a dump of some of the extra verbose bits I went
through along the way, leading to the above analysis.  It doesn't add
anything much, except for how I got to the above.

I added little instrumenting (trivial patch below) of DispatchEvent()
to describe every event we see.  When I captured the below, I also had
extra lines on the Press/Release handlers (left over from previous
iteration; doesn't add anything here).  I tested mappings with f.beep
and a f.exec.  I was using an xev window, so I could see both sides at
once.  Here I'm only including the ctwm outputs.  The f.whatever
execution would be happening within the HandleButtonPress() call.

With f.beep, when pressing the button, you see:

DispatchEvent(LeaveNotify) on 'Event Tester'
DispatchEvent(EnterNotify) on 'Event Tester'
DispatchEvent(ButtonPress) on 'Event Tester'
HandleButtonPress()
DispatchEvent(LeaveNotify) on 'Event Tester'
DispatchEvent(EnterNotify) on '(nowin)'

And then you release, and get:

DispatchEvent(ButtonRelease) on '(nowin)'
HandleButtonRelease()
DispatchEvent(EnterNotify) on 'Event Tester'
DispatchEvent(EnterNotify) on 'Event Tester'
  DispatchEvent(FocusIn) on 'Event Tester'
DispatchEvent(PropertyNotify) on '(nowin)'


OK, about what you expect.  Now let's try f.exec.  Press:

DispatchEvent(LeaveNotify) on 'Event Tester'
DispatchEvent(EnterNotify) on 'Event Tester'
DispatchEvent(ButtonPress) on 'Event Tester'
HandleButtonPress()
DispatchEvent(LeaveNotify) on 'Event Tester'
DispatchEvent(EnterNotify) on '(nowin)'

OK, exactly the same.  Now we release:

(  ...  crickets  ...  )

No events at

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-07-14 Thread Matthew D. Fuller



On Thu, Jul 11, 2019 at 08:15:36PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> I do notice that SetFocus() duplicates a lot of work that the
> FocusIn and FocusOut event handlers do.

Yeah.  Almost-duplicated code makes me a bit grumpy.  I spent a minute
or two thinking about how to collapse them together the other way
around and didn't come up with anything I loved.  Should probably go
on the "cleanup-someday" list.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-07-14 Thread Matthew D. Fuller



On Thu, Jul 11, 2019 at 11:16:31PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> but I did find some other scenario that does weird things :-(

[...]

> so maybe that is a sign of a loop in ctwm indeed. It might be
> getting confused while getting the OTP stack in order with now 3
> windows that have the wrong priority. (Maybe restacking needs to
> happen by first removing all transients, then re-adding them all,
> instead of one by one??)

I think it turns out to be more banal than that.  xine helpfully
positions the panel and nav controls bumped right up against each
other, which means with the borders we add there's actually a
single-pixel overlap.  I can trigger it just to by kicking to
fullscreen with things positioned right, and then there's this weird
visible flickering right at the intersection between the two
transients.  Ahah.

We start from the bottom of the OWL stack.  When we find a transient,
we move it up to the top of the stack, then move on to the window that
was previously right above it.  Which actually meant that we moved the
transient up _twice_; once when we found it in the middle of the list,
then again when we found it at the top.  But the second time, the
window previously right above it was NULL, so, fine, we're done.  Now,
if we have *two* (or presumably >2) transients that we move to the top
of the list...  whoops.  Totally not my fault.  The mailing list is
obviously inserting bugs in patches as they pass through it.

So we have to just build up the list of transients during the pass
through the list, then move them after we've completed the search.

Fixed up, and landed the stack of changes in trunk.  If we don't hit
any new surprises with it, I'll plan to try backporting it to before
the RLayout/RANDR changes and make a 4.0.3 in a week or so.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-07-08 Thread Matthew D. Fuller



On Mon, Jul 08, 2019 at 11:08:25AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> > Actually, what we obviously need to do is get rid of TwmWindow
> > structs wholesale, just embed SQLite, and store our runtime data
> > there; then the indexes will find them for us!
> 
> I don't follow.  Wouldn't a hash-table work just as well?  SQLite
> seems like a rather expensive way to implement a hash-table.

I mean, I'm actually assuming an _array_ would work better than
either.  But if I can't dream up insane anti-solutions that would
_technically_ work, what's the point of weekends anyway?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-07-08 Thread Matthew D. Fuller



On Mon, Jul 08, 2019 at 11:04:10AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> Hmm... so is it because we changed PRI(owl) without changing the
> OtpWinList accordingly, [...]

Yes[0].  The PRI() of the transient changed when the main window
gained focus, but it's still down among the normal windows where it
was prior.

We don't _move_ the transient to a new priority; it's just THERE as
soon as its master has focus.  's why the solution I wound up with was
that we just needed OTP entry points that explictly say "do {un,}focus
stuff", rather than the previous "restack this window", so it knows it
needs to explicitly handle already-unsorted stuff as part of the
action.


> IIRC we already had code doing something along those lines, more
> specifically code that raises its transients when we raise a normal
> window (see RaiseSmallTransientsOfAbove).

Yes, but that has two issues.  One, it only does _Small_ transients,
so misses larger one.  And the other (and the reason I couldn't just
use TryToMoveTransientsOfTo()) is that it embeds assumptions about how
to find the transients, which aren't effective since it's not where
its priority would indicate in the list (heck, if it were, we wouldn't
be eating the assertion fail, either...).


> I missed this change.  I'm not very familiar with FULLSCREEN.  Why
> do we need to change the OTP depending on focus?

https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER

   * [on the top of everything] focused windows having state
 _NET_WM_STATE_FULLSCREEN


> Can you point me to the code which changes the "OTP" in response to
> focus change?

That happens in OwlEffectivePriority() (which PRI() is just a call
to).

https://bazaar.launchpad.net/~ctwm/ctwm/trunk/view/head:/otp.c#L1654




[0] In my case.  I'm still going with the assumption that Olaf's is
closely related, except his seems to happen on _un_focus rather
than focus, but we haven't managed to verify it yet.



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-07-07 Thread Matthew D. Fuller



On Sun, Jul 07, 2019 at 10:35:01PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> An obvious change here would to link all transients for a window to
> that window.

Well, we have a link that direction, via TwmWindow->transientfor
(though that's more expensive than ideal, since it has the Window, not
the TwmWindow).  It's going the other way we lack, short of checking
everything.  I'm of a mind to remedy that...  though, that'd be more
of a Step 2 sort of thing, so that a fix for our current bugaboo is
easily backportable.

Actually, what we obviously need to do is get rid of TwmWindow structs
wholesale, just embed SQLite, and store our runtime data there; then
the indexes will find them for us!


> The code for OtpFocusWindowBE() could avoid a copy of
> TryToMoveTransientsOfTo() [...]

There are enough differences that we'd probably have to chop it up
pretty bad.  Especially now that it's searching in a whole different
way, through the whole OWL, to be able to actually find the
transients.  Or alternately, we could easily just use it, all we'd
have to do is rewrite it.  That's more like Step 3...

(also, that whole OwlRightBelow()->above idiom to find "bottom of
layer X" gives me a headache every time I read it.  I wonder if we
should just have "struct OtpWinList *bottomowl[17]" in Screen instead
and just treat each layer individually...)


> Since it calls PRI(owl) several times, and that is more expensive
> than it looks,

Eh, it's not too bad.  The function call itself probably costs more
than the couple dozen simple ops it does.  Except for when it's run on
a transient window and has to go find the master, but...   well, now
we've looped back up to the top of the mail:)


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-07-07 Thread Matthew D. Fuller



On Sun, Jul 07, 2019 at 09:05:02AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> From what I remember of the time I wrote and debugged OTP, these
> problems were invariably due to things like calling RaiseWindow
> instead of OtpRaiseWindow.

That would lead to assertion failures where it compares against the X
window stack.  These troubles are triggering a bit earlier, on the

assert(PRI(owl) >= priority);

e.g., the priority isn't monotonically increasing from the bottom->top
of the OWL.  This got trickier with the _FULLSCREEN stuff, where the
effective OTP of a window now depends on whether it has focus or not,
so it has to get reshuffled as a side effect of the focus change,
rather than an explicit raise/lower or OTP change.

And, in this case, DOUBLE tricky, because its transients have to move
with it; when a _FULLSCREEN window is focused, it transients are
jumped up with it, and when it's unfocused, they have to move down
too.  So any given window's OTP isn't even dependent solely on whether
_it_ has focus, we get to worry about its "family tree", too.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-07-06 Thread Matthew D. Fuller



> See if you can work out how to reproduce it at will and try it
> against the new patch.

   (... and now that I carefully planned to add the following before
   I sent the mail, and then completely didn't...)

The MonitorLayout config var I just landed may be helpful in this; a
hardcoded variant was the only way I managed to track down my crash in
the first place.  By using it to turn a Xnest into two side-by-side
monitors, I could easily "fullscreen" an app, and have the other half
of the nest easily visible to focus into/out of.  Being able to flit
the focus around like that, to the desktop or to other visible
windows, makes it a lot easier to track down.

As did being able to do it in a controlled environment like that, not
by trying to crash the WM I'm actually having to _use_.  Not just in
not disrupting my work, but also having the debug output somewhere
easy to fiddle with after it bombs out.


(I also have this dream, that MonitorLayout can give us all the excuse
we need to take VirtualScreens out back of the woodshed and shoot it
in the head...)


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-07-06 Thread Matthew D. Fuller

On Mon, Jul 01, 2019 at 07:36:23PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> Intersting! My theory so far was that *during* the change of focus,
> the window depths might be inconsistent. But after
> OtpRestackWindow()ing the newly focused window, it should be
> finished, and all consistent and happy. That was consistent with my
> crash between the two calls to OtpRestackWindow(). My change was
> also based on that idea.

So, the crash isn't necessarily about where the window is in the X
stacking order, it's about where it is in the OtpWinList chain.  (I'm
going on the assumption here that your crash is the same situation as
mine, just triggered differently.)  And what causes the actual blowup
is that the transient has the new level's priority, but hasn't been
moved from its previous position in the OWL list, and so the
consistency check craps itself.

Of course, the crash isn't "between" the Restack calls, since the
Restack is what calls the consistency check that crashes; it's _in_
one or the other.  Mine is always in the second one, because my
trigger is on focusing _from_ a non-FS-focus window _into_ one that
is; my current theory is that your crash is in the first one, because
you're hitting it when focusing _away_ from one that is, into one
that's not.  In those cases, I never make the first call (since the
window I'm focusing away from isn't OtpIsFocusDependent()), and you'd
never make the second for the same reason, so there's only one place
either of us _could_ crash.

On that theory, my guess is that your patch could fix your case, since
you'd be crashing on a mis-placement of the old focus'd win's
transient in the list, it being lowered down to normal since the focus
has moved away.  And whether ->Focus is NULL or the new window won't
make any difference to that.


Now, I _can_ cause a crash on leaving the old.  I do that by having a
transient up of the focus/fullscreen, _and_ having another window
that's in a + OTP layer (e.g., an xterm in +2), then moving out of the
fullscreener.  Great.  And with my patch, that...  also crashes.  In a
new way.  Crap.

Sigh.  The whole way we look for the transients is wonky, because of
the assumptions it makes about where they already are.  So we just
have to expand it and search the whole thing.  So, new iteration: the
attached.  With this, I can't provoke a crash in my old or new tests
anymore.  (it still has some slightly subideal cases, but they aren't
correctness related, so I'm ignoring them for now).


> So far I haven't turned on debugging to print all restacking
> operations, but maybe it is time for that... and we might find out
> that everything is different...

It's plenty verbose   :p

I actually found it mostly less helpful than I'd hoped, due to details
of how the crashes happened and were provoked.  I wound up having to
add some of my own fprintf's to dump out the important details.  Now I
sorta wanna spent some time reworking how all that debug goes together
and outputs stuff.  Well, on the list...

See if you can work out how to reproduce it at will and try it against the
new patch.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
=== modified file 'otp.c'
--- otp.c	2018-08-19 22:50:13 +
+++ otp.c	2019-07-07 04:23:24 +
@@ -1579,6 +1579,99 @@
 }
 
 
+
+/**
+ * Focus/unfocus backend.  This is used on windows whose stacking is
+ * focus-dependent (e.g., EWMH fullscreen), to move them and their
+ * transients around.  For these windows, getting/losing focus is
+ * practically the same as a f.setpriority, except it's on the calculated
+ * rather than the base parts.  And it's hard to re-use our existing
+ * functions to do it because we have to move Scr->Focus before the main
+ * window changes, but then it's too late to see where all the transients
+ * were.
+ *
+ * There are a number of unpleasant assumptions in here relating to where
+ * the transients are, and IWBNI we could be smarter and quicker about
+ * dealing with them.  But this gets us past the simple to cause
+ * assertion failures, anyway...
+ */
+static void
+OtpFocusWindowBE(TwmWindow *twm_win, int oldprio)
+{
+	OtpWinList *owl = twm_win->otp;
+
+	// This one comes off the list, and goes back in its new place.
+	RemoveOwl(owl);
+	InsertOwl(owl, Above);
+
+	// Now root around for any transients of it, and
+	// nudge them into the new location.  The whole Above/Below thing is
+	// kinda a heavy-handed guess, but...
+	//
+	// This is nearly a reimplementation of TryToMoveTransientsOfTo(),
+	// but the assumption that we can find the transients by starting
+	// from where the old priority was in the list turns out to be deeply
+	// broken.  So just walk the whole thing.  Which isn't ideal, but...
+	//
+	// XXX It should not be this freakin' hard to find a window's
+	// transients.  We should fix that more globally.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-06-30 Thread Matthew D. Fuller



> The change (or lack thereof) in SetFocus() makes no difference at
> all in either case for me.  Which seems a strange; a fairly small
> amount of thinking on the matter _does_ suggest it's a thing that
> should be needed, but somehow...  isn't?  I'll have to think more on
> that.

FWIW, I figured this out; a little experimentation showed that my
crash happened on the OtpRestack on the _new_ focused window, not the
_old_ being-unfocused window.  So it was because of the transient that
wasn't pre-raised to where it was expected.  So maybe if your crash
was on the way down, you may also have crashed in that second (when it
wasn't lowered right), in which case the Focus NULL'ing wouldn't make
a different.  Or maybe you crashed in the first one somehow, in which
case it would have?  Mmph.  Lot of moving parts, to keep in the head,
trying to guess...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

2019-06-30 Thread Matthew D. Fuller

On Sat, Jun 29, 2019 at 03:02:30PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> Looking at my test case (Xine), it has indeed a small window with
> playback controls, and it is also a transient of the main window
> (fullscreenable).

Ah, well, see?  If you just stuck with mpv or mplayer like me, you
wouldn't have a transient, and wouldn't have these problems   :p


> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_TOOLBAR
> 
> which sounds weird to be, but it definitely complicates window
> stacking!

Well, luckily, we don't know or care anything about TOOLBAR, so it
doesn't hurt anything itself.


> I didn't get a reliable way to get the crash. I just noticed it mostly
> seemed to occur if I was switching to another workspace while the
> main window fullscreened, or when switching away from fullscreen mode.
> I didn't take notice of any other windows. I guess I'll experiment a bit
> more.

Interesting.  In both cases, that sounds like you're finding the crash
when the window is on its way _down_, whereas my method hits it on the
way _up_.  Interesting.  Now, apart from the fullscreen thing, I don't
think I ever have any windows with OTP != 0; maybe if you've got
something at e.g. +2, that the FS window and its transient have to
pass in both directions...?


> My first impression, after reading your description, was that we have
> found different problems. But now that my Xine Panel window turns out to
> be transient as well, maybe it's the same one, or at least more related
> than I thought. It is a fairly small window. But when taking focus away
> from the main window, it also changes the calculated proper position of
> the panel window.

Yeah.  The trickiness apparently is that a window and its transients
really need to move around as a group.  I mean, conceptually they
don't, but with our OTP implementation, I think it's probably way more
troublesome if they don't.  And that winds up mostly being the case,
but there are a few edge cases where I think you can probably wind up
with them in different places (f.setpriority on a transient itself,
frex, or _ABOVE/_BELOW flags, etc).  All the OTP code dealing with
transients seems to assume they're always on the same effective level
as the main window, but that's not actually enforced anywhere.  I'll
bet you'll cause a _lot_ of trouble, if you arrange those
situations...

The focus handling has been calling OtpRestackWindows(), which calls
InsertOwl().  Which seemingly assumes that all of the window's
transients are on the top of the current OTP layer, copies in the
current base priority, and then...   raises all the small transients
above all the windows below the last one that loop found?  And then
puts this window right below them.  The logic is kinda odd, but
apparently that's purely handling TransientOnTop stuff (which is why
cranking TOT lets me hack around my crash).

But for our case, we want to act more like f.setpriority, in that we
need to assume all our transients are shifting to the new layer with
us.  I did a little noodling around the tree below
OtpRestackWindows(), but I couldn't come up with any good ideas that
didn't have obviously wacky side effects.  So I think we just need to
adjust what the focus handlers call.

I came up with the attached patch, which does fix my crash.  The major
side effect is that the window's transients all always wind up back on
top of it when it moves up/down.  That's not ideal, but it's better
than a crash, and putting them all below it doesn't sound any better.

Really, the whole interaction of the transients + fullscreen/focus is
wonky and needs some rethinking.  Actually, one reason I haven't
already added a StopDoingOTPCrapOnFullscreenFocused setting is 'cuz
I'd probably just set it and never think about the things that really
need fixing in it...


So, give the attached a whirl.  Especially if you can find a way to
trigger the crash at will, so we can actually know whether it's
addressing the matter.  If it succeeds, I'd like to go back to just
before the RLayout/RANDR changes, apply it there, and cut a 4.0.3 with
that and the few other little things that happened early enough; 'd be
good to get that fix out in a point release.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
=== modified file 'otp.c'
--- otp.c	2018-08-19 22:50:13 +
+++ otp.c	2019-06-30 22:47:26 +
@@ -1579,6 +1579,104 @@
 }
 
 
+
+/**
+ * Focus/unfocus backend.  This is used on windows whose stacking is
+ * focus-dependent (e.g., EWMH fullscreen), to move them and their
+ * transients around.  For these windows, getting/losing focus is
+ * practically the same as a f.setpriority, except it's on the calculated
+ * rather than the base parts.  And it's hard to re-use our existing
+ * functions to do it because we have to move Scr->Focus before the main
+ * window changes, but

Re: Binding a function to key+mousebutton

2019-06-30 Thread Matthew D. Fuller



On Sat, Jun 29, 2019 at 12:29:03AM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> FWIW, I think keeping the mouse pointer grabbed all the way until
> the exec'd command terminates seems like an awful long time.

Well.  Maybe...

OTOH, remember that we also have ctwm frozen up all the way until the
exec'd command terminates too.  So even if that did cause some sort of
problem, it would only be in the case that we exec something
long-running, that somehow expects mouse actions we can't give it, but
also doesn't need the WM to do anything like map or border it.  That's
a pretty edge case.

And don't forget, ctwm didn't have it 'till 3.5.  twm doesn't have it
to this day.  Neither does vtwm.  The 3.5 diff is pretty big, so
eye-reading with finite time is fraught.  Still, I don't see anything
leaping out at my that would obviously justify it.  There are only 2
XGrabPointer's added in that diff; one is involved in moving windows,
and the other is in f.hypermove.  Neither would result in calling
f.exec...

Too, "Grab Pointer" isn't just the way we take over control of hearing
mouse movements.  It's also the mechanism by which we don't do any
taking over at all, but just change the cursor shape.  We do in fact
XGrabPointer() early on in function dispatching (functions.c:216) for
all but a few funcs just to set the stopwatch cursor.


So, my guess is that there isn't any reason for it, and maybe never
was.



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Binding a function to key+mousebutton

2019-06-28 Thread Matthew D. Fuller



On Fri, Jun 28, 2019 at 09:48:26AM +0200 I heard the voice of
Frank Steiner, and lo! it spake thus:
> 
> So currently it's not possible to use f.exec for any kind of mouse
> button binding, right? f.exec would need to know if the ungrab is
> neccessary or not but I guess it can't.
> 
> Do you have any clue why we see the ButtonRelease event only on
> every second click? Does ctmw remember a button state somehow?

My guess would be that we get there Grab'd when f.exec is run from a
menu.  Though I wonder a little why that wouldn't be a problem for
twm, if it does cause a problem.  Maybe something odd with things
using $redirect?  Well, if that were the case, it would move me from
THIS --><-- close to removing that crap to THIS <-- -->
close to removing it.

I'd suggest commenting out the Ungrab call and running with it.  See
what happens   :)


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Binding a function to key+mousebutton

2019-06-27 Thread Matthew D. Fuller



On Thu, Jun 27, 2019 at 10:34:57AM +0200 I heard the voice of
Frank Steiner, and lo! it spake thus:
> 
> But as soon as I define
> Button1= c:window :f.exec "true"

Ah!  This turns out to be the key.  It doesn't have to do with the
key+button; it has to do with f.exec.  Bind it to just Button1, it'll
act the same.

It appears to be because of the XUngrabPointer() call in the f.exec
handler (functions_misc.c:347 in head); if I take that out, I can't
trigger it anymore.  The similar code in twm (menus.c:1987-94 in their
head) doesn't ungrab.

That seems to have come in with ctwm 3.5, in 1997.  A look at CHANGES
doesn't turn up any obvious suspects.  The closest may be the added
handling of $redirect and $currentworkspace in f.exec's arg; maybe
that uncovered some behavior that necessitated the ungrab?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Binding a function to key+mousebutton

2019-06-26 Thread Matthew D. Fuller



On Tue, Jun 25, 2019 at 09:58:12AM +0200 I heard the voice of
Frank Steiner, and lo! it spake thus:
> 
> The 3rd/5th/7th...ctrl+left mouse button click it will work again,
> the 4th/6th... will show the icon.

In a little testing, I can't reproduce it here; always seems normal
for some Ctrl- bindings for me.  You could try playing with
xev and see if the second click has a different state flag; maybe your
environment is doing something surprising?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Firefox and mouse coordinates (also gtk focus)

2018-12-02 Thread Matthew D. Fuller



On Thu, Nov 15, 2018 at 04:50:06PM + I heard the voice of
Yumekui Neru, and lo! it spake thus:
>
> Eitherway, it appears somewhere the information that the ctwm
> titlebar has a certain height is lost or ignored, and the
> scroller-icon is created 20-30 pixels above where the cursor was
> when MB2 was pressed,
>
> [...]
>
> On the topic of gtk applications I also have an issue with
> thunar-1.8.2 on gtk-3.24.1, where in the sidebar that contains
> shortcuts to e.g "~/Documents/" and "~/Desktop/", hovering one of
> the items causes the cursor to start blinking rapidly between the
> "standard" pointer-cursor and the X-shaped cursor that usually
> appears when the cursor is over the background of ctwm, I guess
> because (whatever gtk calls it) the tooltip that appears in a
> textbox does something unexpected with the focus

They both do seem like they could be consequences of the app
forgetting to take into account the positioning of itself inside the
frame.  I've seen a similar behavior that only started fairly recently
(~past few months), in that form field autofill selection boxes now
mostly cover the form field, making it really annoying to try and use.
Probably a safe assumption that it comes from the same place.

Just for kicks, a trivial patch to not move the window down inside the
decorations (so it still start at the "normal" height, and covers up
the titlebar) causes it to come up "right".  e.g., :

-
=== modified file 'win_decorations.c'
--- win_decorations.c   2018-03-27 11:04:50 +
+++ win_decorations.c   2018-12-02 23:33:02 +
@@ -343,7 +343,7 @@
 * whole?
 */
XMoveResizeWindow(dpy, tmp_win->w, tmp_win->frame_bw3D,
- tmp_win->title_height + tmp_win->frame_bw3D,
+ 0,
  tmp_win->attr.width, tmp_win->attr.height);
}
 

-



So, I'd say it's probably a FF or GTK bug.  I look first more at GTK,
since (a) you mention similar symptoms in another app, and (2) if
somebody would have to go into FF code to fix it, we're screwed
forward.  I don't see anything obvious in scanning a few likely
keywords in GTK's bugtracker.  It may take writing a minimal GTK app
to demonstate it, to be able to characterize and get it fixed...  :|



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: UseThreeDMenus text alignment

2018-12-02 Thread Matthew D. Fuller



Wayne,

> Did you ever get the time to see if the title bar exhibits the same
> behavior as the menus did?  If so are their any plans to correct it?

I'm not aware of anywhere else in specifically the same case.  The
menu situation was a visible *bug*.  It wasn't using the calculated
text height in sizing the menu entry; that is, it was _doing_ the
calculation (just like on the 2d menu side), but then ignoring the
result (not like on the 2d menu side).  That's just an obvious oops in
the feature implementation.

Every other place I've seen, though, doesn't do that; it uses the
calculated value.  This tends to give slightly different results (a
pixel or three) than the prior behavior that just used the full height
value for setting sizes and baselines, but that's out of the realm of
"bug" and into "could be better feature".  So, not really a thing you
can "fix", so much as something that maybe someone could spend time
contemplating and come up with a better heuristic for.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Buried shovel in ctwm

2018-11-11 Thread Matthew D. Fuller



On Thu, Oct 12, 2017 at 06:29:58AM -0500 I heard the voice of
Matthew D. Fuller, and lo! it spake thus:
> On Tue, Oct 10, 2017 at 01:17:29AM -0400 I heard the voice of
> Steve Litt, and lo! it spake thus:
> > 
> > I suggest that ctwm be modified so that if --cfgchk is the only
> > argument, it outputs the errors to stdout whether or not X is
> > running, and that it not error out because X isn't running.
> 
> It's probably not impossible to make at least a fair approximation
> at, but it wouldn't be easy.

In fact, it's stupendously not easy.  Not only do we need the X
connection to find out a lot of stuff to do the setup for parsing the
config, but the config parsing itself does a lot of interaction with X
to setup colors and fonts, as well as sundry other fun bits.  So
without talking to X, there are things we can't even actually check.

However, code just landed in trunk can now do most of the checking
without X, if necessary.  And with a somewhat cleaner process, to
boot, so running it with X won't pollute your running session as much.
And will check multiple-Screen multi-configs.  It only took 1200+
lines of adjustment...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Maximum window size initialization

2018-11-11 Thread Matthew D. Fuller



On Sun, Nov 11, 2018 at 09:43:13AM -0500 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> Why do we even have such a limit?

Considering its longevity, it's obviously an Act Of Tom;-)

I do love removing code.  But MaxWindowSize as a config param is
perfectly sensible, so it's gotta have _some_ default.  X's inherent
32767 by itself would be another possibility.  But, what was there has
been there for decades, and you pointed out reasonable logic to what
it was doing.  So I went with just tweaking it slightly for the case
of non-(0,0) roots, and being sure it didn't absurdly shrink away to
nothing on gigantic desktops.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: CFT: RandR-ization

2018-11-10 Thread Matthew D. Fuller



> I've done a reasonable bit of testing, including a little with 2
> monitors, and I'm typing this on a system running it, so it's at
> least a good imitation of stable.

Landed in trunk.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Maximum window size initialization

2018-11-10 Thread Matthew D. Fuller



> I wonder if it's a sensible default.
[...]
> they probably should factor in x/y too, [...]

Updated to consider x/y, and arbitrarily[0] chose 4096x4096 as a floor
to keep it from getting really silly on giant desktop sizes.



[0] I mean, obviously not arbitrarily.  It's a power of 2, so you
_know_ it was chosen for Good And Proper reasons, and isn't just a
random number that some joker pulled out of his hat...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: Maximum window size initialization

2018-11-08 Thread Matthew D. Fuller



On Wed, Nov 07, 2018 at 09:35:37PM -0500 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> My reading of this code says that the reason why it's written that
> way it's to ensure that the position of all four corners will be
> <=32767, as long as one of the corners is within the root window.
> IOW this is the maximum size which still allows the user to place
> the window anywhere within the root window.

Ah, that hadn't occured to me.  Good catch.

I wonder if it's a sensible default.  If you're a long way from the
limits (as a "normal" setup would still be today), it's effectively
the same as unlimited.  And if you're pushing the limits, it seems
like it would hurt more than it helps.  To keep me from having to
wonder why I can't push a window as far off the right of the rightmost
monitor as I might want, I'm prevented from making it the full width
of the leftmost.

Of course, a given MaxWindowSize completely overrides it too.  Those
are initial defaults, not bounds on later changes.  I guess if kept,
they probably should factor in x/y too, since they'd be wrong for that
purpose if the root didn't start at (0,0).



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Maximum window size initialization

2018-11-07 Thread Matthew D. Fuller

I'm doing some cleanup/refactoring, came across some interesting code,
and wondered if anybody had a good reason why it might be right. It
sure doesn't seem to be.

We have values stashed up for the maximum window width and height.
You can configure them via MaxWindowSize, but they need some value
even if you don't set it, so we initialize it during startup. We do
that here[0].

X (the window system, not the axis) coordinates are signed 16-bit
ints, so 32767 is the max possible in either direction. That makes
sense. Then we subtract from that... the screen width/height?
That... what? Apart from some field renaming and trivial
whitespacery, those lines are unchanged in our history, exist just the
same in twm to this day[1], and are also untouched in vtwm[2].

What the heck? The bigger our screen gets, the smaller the maximum
window size is? "4k" monitors tend to be 3840 pixels wide, so if you
had 8 of 'em laid out side by side for your desktop (a ridiculous and
impractical, but nowadays no longer impossible setup[3]), your x
coordinate would go up to 30720, which means you couldn't have a
window wider than 2047 pixels (half a monitor)! There's no way that
can be right.

My theory that what's _actually_ desired here is not subtracting the
width/height of the root window, but the x/y coordinate, since the
root window isn't necessarily at (0,0). e.g., if you have multiple
Screen's (:0.0 and :0.1, say), one of them probably starts to the
right of or under the other, so has a positive x or y coordinate for
the origin. And so the limit of the window size actually has to be be
reduced by that amount in that direction.

If it _is_ incorrect as it stands, it's a little surprising that it's
gone unnoticed everywhere for this long, but I guess 2**15-1 is still
a big enough number as desktop resolutions go that nobody's hit it in
practice...

[0] https://bazaar.launchpad.net/~ctwm/ctwm/trunk/view/641/ctwm_main.c#L424

[1]
https://cgit.freedesktop.org/xorg/app/twm/tree/src/twm.c?id=777236e942ae85bcacfdc2e086944a42cfed5b45#n500

[2]
https://sourceforge.net/p/vtwm/code/ci/70991cca915cdd7b5da1f78d18fb97d5bc7dff96/tree/twm.c#l602

[3] 8 "5k" monitors is over 40k pixels, so is actually bigger than the
X protocol can handle. 4 "8k" (which do exist now) are almost at
the limit too. I guess after 31 years, we're finally gonna need
to move to X12...

--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

Re: CMake linking errors [ctwmlib]

2018-10-31 Thread Matthew D. Fuller



On Thu, Nov 01, 2018 at 03:22:52AM + I heard the voice of
Yumekui Neru, and lo! it spake thus:
> 
> This does make the build successful too.

Excellent.  Landed in trunk.


> My understanding from when I asked around for help with the issue
> was that ctwm used to depend on ${CTWMLIBS} but it is now the new
> ctwmlib that directly depends on them and that they should go there
> during linking (hence the suggested replacement).

It's still ctwm that needs them; ctwmlib is just a mild hack in
building to roll up all the actual objects in one ball, to then link
with a thoroughly trivial main() into the actual binary.  That way we
can just use the lib for building unit tests as well, which makes them
easy [to compile, anyway].

The better solution is probably to use cmake's "Object Libraries"
(which are just an internal rollup of the .o's) instead of making a
real static library.  However, doing that means we'll have to start
requiring cmake 3.1.  Which we probably can and should (we claim 2.6+,
but I wouldn't be surprised if we'd managed to break <2.8 at least,
and maybe <3+ by now), but I figured I'd wait 'till we had some other
big argument to tire everybody out before I brought that up   :)



-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: CMake linking errors [ctwmlib]

2018-10-31 Thread Matthew D. Fuller



On Thu, Nov 01, 2018 at 02:31:37AM + I heard the voice of
Yumekui Neru, and lo! it spake thus:
> 
> The build fails when built using an ebuild with the portage package
> manager, though is successful if built "manually" with make (and in
> portage after changing the aforementioned line).

Iinteresting.  So that the failure is in fact happening when
trying to link ctwm, not the libctwmlib.a.  My guess is that it's
because the ebuild has

-Wl,--as-needed

as a linker flag, and doing it manually doesn't; I see some refs to
ebuild forcing that in LDFLAGS.  And --as-needed is neat, but also
really stupid, because it ignores libs it doesn't need, where "doesn't
need" is defined as "no object file I've seen yet in the command line
needs those symbols".  And since libctwmlib.a comes after the -l flags
for the shared libs, it decided it didn't need any of them before it
even got there, and then found a bunch of symbols it couldn't resolve.

So, the _real_ solution is to fix ld(1) to be less stupid...


A more likely and practical solution would be to try swapping around
the order of the libs.  e.g.:


=== modified file 'CMakeLists.txt'
--- CMakeLists.txt  2018-10-22 00:02:28 +
+++ CMakeLists.txt  2018-11-01 02:51:09 +
@@ -126,8 +126,8 @@
 # with access to all our internal funcs.
 add_library(ctwmlib STATIC ${CTWMSRC})
 add_executable(ctwm "ctwm_wrap.c")
+target_link_libraries(ctwm ctwmlib)
 target_link_libraries(ctwm ${CTWMLIBS})
-target_link_libraries(ctwm ctwmlib)
 
 # This doesn't really serve much purpose at the moment, so it's not even
 # documented, but the code exists.  So make it buildable.


so the .a is before the -l's, and see if that whips it into shape.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: CMake linking errors [ctwmlib]

2018-10-31 Thread Matthew D. Fuller



On Tue, Oct 30, 2018 at 03:38:59PM + I heard the voice of
Yumekui Neru, and lo! it spake thus:
>
> I have been running into linking errors when trying to build
> versions after the inclusion of ctwmlib.  The credit for this (fix?)
> is not mine, though it should be because of the linking of
> $(CTWMLIBS) to ctwm instead of the new ctwmlib:

That is...very strange.  How is it even meaningful to "link" a
shared lib into an archive?  Can you run a build with VERBOSE=1 so we
can see exactly what it's trying to do that fails?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: CFT: RandR-ization

2018-10-28 Thread Matthew D. Fuller



> I've done a reasonable bit of testing, including a little with 2
> monitors, and I'm typing this on a system running it, so it's at
> least a good imitation of stable.  Give it a whirl!

Second call.  It hasn't much moved, and it hasn't blown up on me day
to day.  I'm not habitually multi-mon'ing though.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: [Branch ~ctwm/ctwm/trunk] Rev 632: Fixup dryrun and improve error on signal.

2018-10-22 Thread Matthew D. Fuller



On Mon, Oct 22, 2018 at 07:27:13PM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> Nice! The first thing I did was to add /usr/X11R7/include
> /usr/pkg/include to the default @INCDIRS.

Well, that's what -I is there for   ;>


> All 16 combinations built without complaints.

In the randr branch, with its option added to the matrix, we're now up
to 64 possible builds, all clean for me.  I'm pretty sure it also
means I was the first person to try some of those combinations; I
mean, how many people will have ever built with RANDR, EWMH, and
RPLAY, but not JPEG, XPM, or M4?

It's too bad exponential growth is exponential.  If we add many more
options, I'll have to content myself with running the standard build
of just testing on/off each instead of the full matrix.  Either that,
or dig up a spare 128-core system...


(if it weren't for how we've had people showing up here quite
recently talking about rplay configuration, I'd swear there
couldn't possibly be any reason we should keep that code around in
the first place...)


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: CFT: RandR-ization



> Give it a whirl!

Here's a thing we might consider; the little window we show with
dimensions or locations for resize/moving windows.  Historically,
there are 2 locations for it; the default is top-left of the screen,
or CenterFeedbackWindow sticks it in the middle of the screen.  With
the current randr code, CenterFeedbackWindow now sticks it in the
middle of the monitor you're doing the thing on.

But the default location is still the top left (of the first monitor,
which is probably _usually_ the left/top most, but wouldn't
necessarily be).  Should we make it go to the top left of the
appropriate monitor as well, instead of always showing on the same one
no matter where the window is?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: The one improvement I'd like on ctwm



On Fri, Oct 12, 2018 at 12:19:06AM +0200 I heard the voice of
Rhialto, and lo! it spake thus:
> 
> MAYBE if we can link an event to "letting go of ALT", that could be
> bound to a new action that modifies the ring to behave like a stack.
> But I haven't looked yet how easy or hard that would be.

Yeah, we start extending the altkeymap-ish functionality even further
to having whole different modes.  Well, modal editors are Obviously
Correct(tm), so I guess it makes good sense for WM's too   :-)

Sounds like something a lot of parts of the code would need to know
about, though...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: UseThreeDMenus text alignment



> So that at least points a good finger at where the problem is.

And, tracked what seems to be the source.  Should be fixed in trunk
now.


On Thu, Oct 11, 2018 at 08:48:46PM -0400 I heard the voice of
lists-c...@useunix.net, and lo! it spake thus:
>
> BTW, what is the significance of MF4839?

Once upon a time, it was my NIC handle.  I mean, it might still be,
but since they don't use/expose NIC handles anymore...  well, who
wants to spend time editing .sig's?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.

Re: focus issues with XVile