On 2023-04-05, Omar Polo wrote:
> Happy to finally see a port for it!  i've been using it since you
> talked about it on #openbsd-gaming :)

I'm happy to know you're using it :)

> One thing that I could never make to work is dmenu: I have it
> installed, but upon ctrl-g I get this error printed on the terminal
> where I started xfiles:
> 
>     X Error of failed request:  BadMatch (invalid parameter attributes)
>       Major opcode of failed request:  62 (X_CopyArea)
>       Serial number of failed request:  69
>       Current serial number in output stream:  70
> 
> but this is not an issue with the port :)

That's a bug on dmenu side.

When asked to be embedded into another window, dmenu creates its own
window directly inside the embedder/parent window, inheriting the
colormap, color depth and visual from it.  However, all the drawing
operations that dmenu does use the default colormap, color depth and
visual from X11's root window.

The error happens because XFiles (the embedder window) and consequenctly
dmenu (the embedded window) have a 32-bit color depth, with alpha
channel for transparency; while the root window has a 24-bit color
depth, without alpha channel.  When commiting the drawing into dmenu's
window with the X_CopyArea request, a BadMatch error occurs (because the
colormap and depth do not match).

A solution for dmenu developers could be to either simply use the
default X11 colormap, color depth, and visual from the root window
(rather than inheriting from the parent); or create the dmenu window
under X11 root window and them reparent it to the embedder.

dmenu's alpha patch may fix this bug, but I have not tried it.

> I'm attaching a diff against your makefile and a fixed tarball that's
> ok op@ to import.

Thanks!
I am attaching a new port with bumped version and updated distinfo.

The newest version fixes a bug that makes for example a directory ending
in ".jpg" to have the icon for image files.  Now glob patterns for icons
do not apply to directories except when the pattern is a full path.

> P.S.: maybe, since xfiles(1) mentions xfilesctl and xfilesthumb we
>       could install them in /usr/local/bin and tell users to put their
>       own modified version in ~/bin if wanted.  It'd be slightly more
>       user-friendly I guess.

The user is encouraged to build their own xfilesctl and xfilesthumb
script, so I think we should install them as examples rather than
installing them on the system.

Lucas de Sena

Attachment: xfiles.tar.gz
Description: application/tar-gz

Reply via email to