Enlightenment E20 Released With Full Wayland Support (enlightenment.org) 56
An anonymous reader writes: Enlightenment DR 0.20 has been released. The most significant change is full Wayland support where E20 can act as its own Wayland compositor and the whole shebang. Enlightenment 0.20 also has better FreeBSD support, introduces Geolocation support, new screen management, and other changes.
Re: (Score:3)
Even non-programmers can not use something without bitching about the fact that it exists.
Re: (Score:3)
pics (Score:5, Funny)
This thread is worthless without screenshots that include some HR Giger walpaper.
Re: (Score:2)
I think any reasonable scientist could empirically conclude that the GUI is bad for facial hair growth. It's probably due to the increase in photons inhibiting growth of facial hair. There should be a study.
w007 (Score:2)
I'll have to emerge Weston and compile this when I get home. Hopefully it'll compile without systemd as easily as E19 did. Bonus if there's already an ebuild available.
Cue endless bellyaching "oh noes, they'll take my X11 network transparency over my dead body!" comments and "damned kids don't know what they're doing," never mind Wayland exists because the damned kids maintaining Xorg got tired of the cruft.
Can anybody help me understand why rdesktop [wikipedia.org] or similar schlepping bitmaps (I'm pretty sure it can d
Re: (Score:1)
You need to get out more.
Re: (Score:1)
We should have killed off HTTPS entirely because of SSL v3. Because, you know, better to start a new project than just clean up the old one.
Re:w007 (Score:5, Interesting)
X11 primitives are admittedly suboptimal for state of the art, but the concern is that recent state of the art remote desktop implementations have been a bit negligent of the 'seamless' facet.
For example, using X11 remoting, little things like notification area and such 'just happen'. Frequently other strategies say 'remote desktop' and dust their hands of making it seamlessly sit in the local display.
Now X11 itself does not do this fully (audio notably is not in scope) or best (X11 primitives aren't interesting, puts client at risk of crash if network issue...). A better approach is to hook things like NETWM as a window manager and the graphics via compositor (a la xpra). Such a strategy wouldn't care one bit about X11. Once upon a time the argument would have been that the facet of having the communication path be abstracted to be network or other paths was important, but compositing created a convenient interception point to make the concern theoretically moot).
The issue is what is popularized. VNC, RDP, and vanilla X11 are the well known examples. Xpra does it right, but no one has heard of Xpra. Even though Xpra's approach would be fully Wayland compatible, it has 'X' in the name and as-yet hasn't bothered with Wayland compatibility, so the knowledge the approach would be portable is not out there. RDP I believe is more capable, but most commonly people experience RDP to a desktop or a 'normal' server, and as such the seamless case isn't presented. So X11 is the *only* thing that people know as ubiquitous and seamless and as such are understandably skeptical about alternatives.
So what needs to be done is for someone to port Xpra or implement something similar and to popularize it. Right now those who understand the technology know how it *could* be done even better than normal X11, but there's a shortage of actual implementation catering to those concerns. There's a lot of 'well, just use freerdp' or 'real applications should be web enabled anyway for remote use', and not enough 'here's a concrete and authoritative seamless remote strategy that fits in with the strategy'.
Re: (Score:2)
Thanks, this helped. Please mod up.
I've been looking for something like Xpra for quite a while, mostly for torrenting. I used to use Deluge, but if I needed to restart X for whatever reason, it was a minor irritation to fire Deluge back up and wait for it to come back up to speed. I switched to rtorrent instead.
Well, come to think about it, this is even more of a problem for bit/doge/primecoin clients, but I lost interest before learning how to set up a wallet daemon.
Re: (Score:2)
As you've noticed, the real problem is software that needs to run as a daemon to work well, but also needs to have a GUI for easy use. These two should be separated, so you keep the daemon running and fire up the GUI as needed. See aMule/iMule for a good example. (Though incidentally, the daemon didn't always work so well in the past, so I used to run one under Xpra.) Bitcoin and derivatives have provided thorough JSON RPC access from the start and many people use command-line clients to access it (includi
Re: (Score:2)
I used to use Deluge's own client/server model, although it was for a different reason (having it run when the desktop is shut down)
It's exactly what TeknoHog is talking about, a separate GUI and daemon, although there's a twist : the client program (it was deluge-gtk) seems to fully function on its own, so the separate daemon program is not really needed. The daemon program is available in a separate package and is to be used for headless servers and such. But the GUI program can connect to the daemon over
Re: (Score:2)
I'd like to add that all I have ever been able to get Weston+FreeRDP to do is segfault. As far as I can tell remote access in Wayland is only a myth.
Re: (Score:2)
Right, it's one of those things that isn't *as* dire as many X11 proponents would scream in theory, but in practice there's no proof point for all this until someone actually invests the effort in such a compositor/WM.
Re: (Score:2)
What do you mean it isn't dire? In response to me saying that the supposed freerdp support in Weston doesn't really exist? My very point was that the situation IS dire.
Re: (Score:2)
Some think that the architecture is such that a seamless remote application experience is not possible with the architecture. That would be more dire than a seamless strategy being possible, just not done.
I just don't see Weston as a long term thing, KDE/Gnome/Xpra I see as the real world implementations of Wayland compositors longer term. Just like xcompmgr was a reference X compositor that briefly was commonly used before being superseded by Window managers integrating the compositing feature with their
Re: (Score:2)
I miss the days where distros didn't really have default desktop managers. They had a dozen or more desktop/window managers to chose from. If you and I both installed Linux, even from the same CD (different times) our computers would still probably come out unique!
Linux users actually liked to look at other Linux users' screenshots because they didn't all look the same. Sure.. you can still chose to install whatever GUI you want but how many Linux users out there now think that Unity or Gnome just IS the L
Re: (Score:2)
Well the wikipedia article states some things:
https://en.wikipedia.org/wiki/... [wikipedia.org]
But in short, it seems like yes, it's going to be harder for a team that just did a window manager for X11 to do the same thing in Wayland, since Wayland architecture puts the display server, window manager, and compositing roles all mashed together.
Now as to application interoperability, I'm not sure. I would hope like in X11, that there is a set of structured protocols to describe thnigs that is standardized allowing interoper
Re: (Score:3)
Can anybody help me understand why [...] a GTK/QT specific network protocol is unacceptable [...]?
Because there are people who write backends to wayland without using a toolkit like GTK, QT etc? Like the servo people?
https://github.com/servo/servo... [github.com]
So yes, such a protocol would be unacceptable, at least if there is no bitmap fallback for applications that use wayland without a toolkit, or for unsupported toolkits.
Generally I do agree that wayland should come, but tbh, enabling it in fedora? No, they should
Re: (Score:2)
Besides, the practical benefit of a GTK/QT based protocol is relatively low. Increased processor capacity and improved compression algorithms mean that a toolkit level description of a widget wouldn't be that much smaller than an oblivious 'bitmap' based strategy to describe the same thing. To the extent there is a difference, network throughput for residential WAN is faster than LAN of the era that X11 was developed so it's not as critical.
So such a protocol would mean less interoperability, more complex
Re: (Score:2)
never mind Wayland exists because the damned kids maintaining Xorg got tired of the cruft.
Xorg maintainers were not known for quality software engineering, in fact, it was the opposite.
I haven't looked into Wayland enough to know if it is good or bad, but there is no reason to believe these guys just because they maintained Xorg.
Re: (Score:2)
Of course with X11 it's drawing commands rather than bitmaps that are being schlepped across the net, but maybe nowadays it doesn't make much difference.
Re: (Score:2)
Protocol doesn't matter, but the functionality does. I do "ssh -X emacsclient" to my Emacs daemon running "server", and get the Emacs window locally. With this window, I can maximize, tile, resize, raise etc using my local window manager.
How do you do it without X? Xpra gives me artifacts and 100% CPU usage for apparently no reason.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
For Wayland, remoting shouldn't really be in the scope IMO.
The place where it should be in scope is the compositor/window manager. This could manifest in a few ways:
-A dedicated remote-enablement solution that relays and translates the window management contextual data and the graphical data to the respective platform. This would be like 'Xpra'
-Window Managers/Compositors implement their own remoting framework. Notably this could make certain things easier like moving an application from a remote to a lo
Re: (Score:3)
Re: (Score:1)
systemd is de facto standard for Linux now, you can't get away from it without a lot of effort. It would be a bit like saying you want Linux but not g++/libstdc++ (I knew a guy who wouldn't run any software that used c++).
You could theoretically contribute a patch to get EFL working on Wayland without systemd-login. Maybe contribute it to one of the anti-systemd debian forks.
For Arch users, we just accept systemd and go with it instead of making a big fuss over something that isn't terrible critical in our
Awww (Score:2)
Awww, poor Enlightenment. Why would anyone want to do that to you?