@bamboombibbitybop @lfa it tells me it's a project I wouldn't want to join. I still wouldn't mind to see anything technically good come out of it, although I don't expect that. It would be great to see some general progress. The #Xrender / #Glamor bug I reported quite a while ago was confirmed very quickly and then nothing else happened... ๐Ÿ˜ž

Oh please someone keep #X11 alive. Sure, preferably not the "make X great again" way ๐Ÿ™ˆ

@thomasadam @peppe Thanks for that! I totally forgot about the decorations topic, which is of course very relevant, it means even jumping through the hoop and implementing a #wayland compositor, you can only deliver part of the functionality (and almost none of the looks) of your window manager.

But even with that issue solved, I would really dislike wayland's design. Although I *do* think that most of #X11 core drawing is obsolete and useless (mostly for the missing alpha channel), I think a display server should offer drawing facilities. Replace X with something dropping lots of cruft (indexed palettes, COMPOUND_TEXT, etc), instead incorporate extensions that everyone needs these days, extend #XRender (now as part of core) to offer more drawing primitives, etc ... you could have a replacement for X11 that's worth dealing with. And window managers could still be separate clients.

@peppe To be clear about that, I don't question the fact that #X11 is full of old cruft that's mostly useless nowadays. It became more than clear to me while implementing my #xmoji tool, which uses almost exclusively #XRender requests for rendering (an *extension* to X11, not part of the core protocol), because X core drawing requests are really designed for 1990es hardware, supporting color palettes with limited entries, but no alpha channel whatsoever. Similar goes for font support in the X11 core protocol, it's useless supporting only bitmap fonts with no antialiasing etc, so I use client-side rasterizing (with freetype) and XRender only for compositing the result. There are more silly examples, like the "Compound Text" encoding monstrosity, because the core design predates Unicode, and so on....

In a nutshell, a major rework of what the X core protocol supports would be necessary.

But then, you can *still* dislike a suggested solution. I think #wayland is taking the "simplicity" much too far, so now both compositors and clients (rendering windows) have to do the same stuff over and over again. It's a pointless exercise trying to create a wayland client without huge libraries (such as e.g. cairo for client-side rendering, better yet use a full-blown toolkit like Qt or GTK that already makes use of cairo), while this is perfectly possible for X.

Ok, first reaction (confirming my suspicion that #glamor causes the bug) was super quick, I'm impressed! Let's see whether anyone jumps in soon to actually analyze the root cause. ๐Ÿ˜Ž

JFTR, it's the bug I already probe for in #xmoji to enable a silly workaround when necessary, applying a transformation to the source picture.

#X11 #Xorg #XRender #development

Well, I really like #X11 (#Xorg) ... and my son loves #PeppaPig. Which gives me a stupid idea. I could write something called #Xchicken. Make some chicken lay some eggs with mouse clicks on some #XRender surface.

Rough roadmap:
- Draw some chicken and eggs, probably as SVG?
- Reuse code from #Xmoji, add special widget supporting some "layered canvas"
- Implement game logic
- Add sound? (Hm, gotta look into #OSS and maybe #sndio, cause #FreeBSD ... #Linux weirdness maybe later)
- ....?

I'll probably never start though ๐Ÿ™ˆ

I want to finally resume work on #Xmoji. Starting with a bit of house-keeping, I factored out a function probing for a weird #XRender (presumably only with #glamor) bug, so it doesn't distract from the normal X client startup, and took the opportunity to also document it:

https://github.com/Zirias/xmoji/blob/7d617cd74813590c08182bf963c622d219842b17/src/bin/xmoji/x11adapter.c#L623

If anything is really wrong with #X11 or #XOrg, it's bugs like this ๐Ÿ˜” ...

xmoji/src/bin/xmoji/x11adapter.c at 7d617cd74813590c08182bf963c622d219842b17 ยท Zirias/xmoji

Plain X11 emoji keyboard. Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub
A major blocker could be that it relies on my "poser" project: https://github.com/Zirias/poser ... it's a small lib, so you could certainly integrate the parts needed, but I didn't do it, I just made #Xmoji build with a bundled (statically linked) #poser by default instead. Another blocker could be that it does quite some trickery to force #xcb into an #async model with #events and registered event-handlers (provided by poser), so it integrates well with a generic event loop built on #select (which poser does, anything else based on file descriptors like #poll, #epoll, #kqueue would work as well). It abuses xcb functions meant for tracing/debugging for that purpose. ๐Ÿ™ˆ

And then, of course, it's very different from #Xt. It strictly requires #XRender, using its "picture" objects as the primary drawing handle, and just offering the core X11 "drawable" on demand. It strictly requires a "true color" visual. It has NO support whatsoever for core drawing primitives and core (bitmap) fonts. It doesn't create a window for every widget but instead manages widgets fully client-side ... all these are probably not "blockers" but just how you'd design a GUI toolkit for X11 nowadays ๐Ÿ˜‰
GitHub - Zirias/poser: POsix SERvices framework for C

POsix SERvices framework for C. Contribute to Zirias/poser development by creating an account on GitHub.

GitHub
Haha, well, I'd stick to putting "#toolkit" in quotes only. For once, it's entirely non-portable to anything other than #X11 (with #XRender) via #xcb (like e.g. #wayland or #GDI) ... xcb types/interfaces are hardwired practically everywhere. And then, although it might be possible to extend it to some "generic" toolkit specifically for that platform, I have no plans doing so. I strictly only implemented what was necessary for #Xmoji's GUI. ๐Ÿ˜‰
You might have noticed development of #Xmoji slowed down a bit. My time is currently very limited, but another reason is slowly closing in on a version 1.0, and I want to give it some time for proper testing.

I need your help, please! ๐Ÿ˜

Xmoji 0.8 introduced an important part for #i18n, translations. But I'm not exactly fluent in many languages. Please, if you can, help me translate! The process is documented in https://github.com/Zirias/xmoji/blob/master/TRANSLATE.md . If there are any issues with these instructions, please let me know.

Xmoji aims to be the "best" tool to input emojis with "pure" X11:

  • Written in plain #C, with minimal dependencies
  • Uses #Xrender for its UI, communicates with the X server using #xcb
  • Offers two methods for input: Faked keyboard events or the "primary selection"
  • Has a search tab and a list of recently used emojis
  • Customizable appearance using X resources
  • Several options to configure key injection and the search method

Roadmap to V1.0:

  • Optional single-instance mode
  • Optional tray icon

#X11 #emoji #keyboard
xmoji/TRANSLATE.md at master ยท Zirias/xmoji

Plain X11 emoji keyboard. Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub
@krausedw I wonder whether I should try to create a "toolkit" (that would ONLY work with #X11 and #Xrender) out of the small collection of "widgets" I created in #C / #xcb for #Xmoji, just to publish more stuff intentionally incompatible with #Wayland... ๐Ÿ˜