Phoenix: another new X server, written in Zig

Wayland creator

"Kristian Høgsberg who formerly worked for Red Hat had joined Intel back in 2009"

Guest what
"Lennart Poettering..red hat?"

See the line? Bullshi#

Red hat was great in their times,but in
Some point started to liked the money baby!!
 
blackbird9 said:
I think he's just talking about the different ways that the word 'complete' can be used in english. A lot of words in english can have multiple meanings with subtle differences, depending on context. So in my original sentence, I meant 'complete' in the 'drop-in' sense rather than 'pin compatible', by the analogy with hardware, so Mer's explanation is correct. Even native english speakers can be confused by this stuff.

This is the kind of thing that stops english being used in a lot of standards documents...
Click to expand...
If wayland is complete depends on what it claims to be. I don't know.
 
It's just that the English language can be ambiguous sometimes. Saying something is a "complete replacement" is a colloquialism or 'figure of speech' that means its a drop-in or 'wholesale' replacement, it does not imply 100% functional equivalence (ie pin compatible in the hardware analogy) to the thing being replaced. It's a little hard to explain!
Well, it's quite possible that I've got it wrong too. 😂 Anyhow, we don't need to worry about it. :-)
 
T-Aoki said:
I don't think Wayland to be a "complete" replacement for X11.
If so, CJK inputs like fcitx{4|5}, scim, ibus, uim, XIM, ... SHALL work perfectly with 100% same comfiguration as in X11 (XFree86, Xorg, XLibre, ...) at least XWayland is isntalled. In this case, XWayland SHALL honor both ~/.xinitrc and ~/.xsession to pick what were configured for X11. But it doesn't at least for me.
With the above, I consider Wayland to be pre-pre- ... -pre Alpha stage to be a complete replacement for X11. Even not reached to pre-Alpha stage.
Click to expand...
T-Aoki, Qt and GTK support IMEs now. I don't know the status of the standard Wayland protocol for IMEs, but those work. Regarding the rest of what you said, I don't think that's a goal of the project. It's not a drop-in replacement, and it's not meant to emulate X11, it's meant to supplant it.

blackbird9 said:
[...], Wayland is more like a single-seat, single-machine architecture, like windows. Is that correct?
Click to expand...
blackbird9, it isn't single-seat, but yes.

While I admire these attempts to keep X11 alive, I can't help but think they're focusing on the wrong goal. The problem isn't that X11 is broken, and if you fix it, people will come back. Xorg server will continue to work. The problem is that GTK and many desktop environments will no longer work with X11. The unfortunate fact is that GTK does not like X11 and are glad to remove it. Having a new server is not going to change that.

In my opinion, the only thing that will keep X11 thriving is someone taking on the unenviable task of making an alternative implementation of GTK once it stops supporting X11.
 
Well, having a good widget set has always been the problem. Motif/Xt/Xlib was way over-complex for writing programs with. I remember writing for win32 and os2/pm, both were much nicer to work with than motif, which requiired you to know 3 different API's.. motif itself, then Xt, and also xlib... and then you had to add motif resources into the mix. The damn oreilly books were like a 6-thick-volume set. So along comes gtk and qt to fill the void. And there were other efforts... Tk, some other C libraries, wxwidgets, etc. So qt is fine. IF you are happy using their dialect of C++. But if you want to work in C, it's gtk. So yes, if gtk goes away, there's a hole, and the problem starts all over again. You have raised a good point!
 
scottro said:
T-Aoki, I've said this in other threads, but in case someone wanting Japanese input finds this. With the labwc window manager, you can put the needed variables, XMODIFIERS, QT_IM_MODULE, and such in a file in $HOME/.config/labwc/environment. The only other Wayland window manager I've used is dwl, and with that, Japanese input is something I can sometimes get to work, but a lot of times it doesn't. When it does work, I've done something like
Code: 
 export XMODIFIERS=@im=fcitx urxvt
I've not gotten it to work in alacritty, firefox, or any QT app. The only terminal I've gotten working with it is urxvt. This is for dwl, in labwc, everything works.
With RedHat Linux, though, if I use their default Gnome and ibus I can get Japanese to work as it will in xorg. However, in RH, when I've managed to install labwc, I can't get Japanese working, whether I use fcitx5 or ibus. And of course, I have to spam my page, so I have a bit more detail at https://srobb.net/jpninpt.html#wayland
Click to expand...
Even if single compositor works, it's not at all sufficient to say Wayland is complete.
ALL COMPOSITORS RUNNING ON WAYLAND SANELY WORK (means, Wayland itself mutually support sane work) ON ALL ENVIRONMENTS RUNNING WAYLAND is the prerequisite to say Wayland is complete. Like xim is still supported on most toolkits and works (with limitations on UI, though).

Text inputs should be considered mutual part and should assured to be the protocol itself. Otherwise should not at all attempt to change from working things.
 
T-Aoki said:
Even if single compositor works, it's not at all sufficient to say Wayland is complete.
ALL COMPOSITORS RUNNING ON WAYLAND SANELY WORK (means, Wayland itself mutually support sane work) ON ALL ENVIRONMENTS RUNNING WAYLAND is the prerequisite to say Wayland is complete. L
Click to expand...
I agree with you. Even though *my* use of (in this case) Japanese is minimal, Wayland can't do it all. I believe there are some other things that X can do, that Wayland can't, but as it's not that important to me at present, I haven't really paid attention. I hope that X will be around for awhile, even if RH dropped it.
 
X11's original claim to fame was the network transparancy. You could sit at one screen and run apps on multiple remote machines and have their guis all on the screen in front of you. Or you could have a lab full of graphical X-terminals which were all running programs on a central server. In the days before web technlogy, when PC's were in the MS-DOS and windows 3 era, that was ground-breaking stuff. In order to achieve the network transparency, other areas were sacrificed, like sophisticated desktop graphics, latency (important for gaming) and security. It's much easier to write a powerful widget set when you only have to worry about displaying on the screen in your local frame buffer, and not be concerned with sending protocol requests across the network to draw pixels on a remote screen.

But now that most UI's are written for the web, using web technology... and embedded web servers are the norm... perhaps the X11 network transparency model is redundant. You get the network transparancy over web protocols, via a browser. So I guess that brings us back to the localised GDI-type graphics layer model, ie wayland, or something similar.
 
blackbird9 said:
I am also under the impression (perhaps incorrectly) that while X11 is a network protocol and was designed from the bottom up to support network window systems, ie transport of an application's GUI over the network to a remote display server (eg, an X-station), Wayland is more like a single-seat, single-machine architecture, like windows. Is that correct?
Click to expand...
In early days, complete Unix computers were too expensive to deploy all over the departments of a (not so rich) organizations. So computers had multiple text terminals.
When computer graphics (including drawing graphs graphically, not similar with "ASCII arts") came true, needs for displaying them on each (or limited) user's terminal was wanted, thus, cheap graphical terminals that can display graphics was needed. If I understand / recall correctly, initial X protocol was designed for this purpose as one of candidates.
Splitting host computer that does intensive computings / storing data (X displaying client) and smaller computers specialized for drawing actual images but does no intensive computings havind no storage other than {P}ROMs and VRAMs (X display server, that serves drawing only) was mature at the era and because X is designed as a network window system.

After that, EWSs (Engineering Work Stations) / GWSs (Graphics Work Stations) appear as the "mid range" of host and X server terminal and got popular, and current PC Unix-like systems are the successors of them using much cheaper PCs as infrastructures.
 
jwillia3 said:
Qt and GTK support IMEs now.
Click to expand...
At least on X11, they provide immodules (bundled or as separate ports) to glue X11 and itself. What's not working would be the corresponding ones for Wayland. Lost track with, but when I've searched before, Wayland had 3 different, not (enough) backward compatible "versions" (not simple additions to previous) of text input protocols, which is clearly silly implementation strategy and making things difficult to properly implement immodules for Wayland.
 
T-Aoki said:
At least on X11, they provide immodules (bundled or as separate ports) to glue X11 and itself. What's not working would be the corresponding ones for Wayland. Lost track with, but when I've searched before, Wayland had 3 different, not (enough) backward compatible "versions" (not simple additions to previous) of text input protocols, which is clearly silly implementation strategy and making things difficult to properly implement immodules for Wayland.
Click to expand...
Well in that case it doesn't sound like wayland is even stable, if they have multiple different definitions of its features...
 
MG said:
If wayland is complete depends on what it claims to be. I don't know.
Click to expand...
It won't ever be complete in the way that normal users want because there's stuff that they refuse to implement themselves and refuse to accept patches to implement. It's stuff like the lack of support for multiple monitors making it a bit of guessing game as to which monitor the windows are going to be on when you return from a break. There are ways of addressing it, but they're down to the compositors and users to do, which may or may not be consistent.

I like the way that FreeBSD is handling it in that we get a choice as to whether or not to use it. Hopefully if Phoenix proceeds far enough to be viable, we'll get the option of installing that and whatever winds up best becomes the default of sorts.
 
blackbird9 said:
[...] So I guess that brings us back to the localised GDI-type graphics layer model, ie wayland, or something similar.
Click to expand...
Wayland does not have a graphics API. You can only use shared memory or OpenGL/Vulkan buffers.
GDI does have a graphics API and you could make it network transparent serialised through Enhanced Metafiles.
 
You must log in or register to reply here.
Back
Top