To drive home my point about the Mess that is X.<br>On the Todo list for the development roadmap is:<br>"Rewrite the bottom of the rendering layer" -> yeah.<br><br><div class="gmail_quote">On Wed, Mar 3, 2010 at 5:01 PM, Ben DeMott <span dir="ltr"><<a href="mailto:ben.demott@gmail.com">ben.demott@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Nice explanation Michael on X by the way.<br><br>The amount of time it would take me to concisely re-enact a conversation I had at Fosdem a year ago is just not worth it.<br>
<br>Several Large projects have attempted to replace the dependency on X for cases where it's not needed, the abstraction is not needed or wanted.<br>
And they have all failed... Mostly because of a lack of portability, or backwards computability.<br>X isn't even sure about what portions of the user experience standard they are implementing as well as loosely implementing some ISO standards.<br>
<br>X is a mess...<br>Not only from a "They don't know what they are supporting standpoint"<br>But from a general Rendering standpoint.<br><br>Basically lots of people in the industry want to bring a Good OpenGL based rendering platform that is tightly integrated to *GTK and the KERNEL<br>
For lot's of various reasons... argue with them if you want but right now an Open Source equivalent of DirectX will never make it to *nix because of rendering problems to overcome, specifically with X as the source of input and output.<br>
There are huge challenges with X's Frame Buffer and implementation as well as support for legacy software rendering.<br><br>In the framebuffer source code there are entire portions commented out... and at one point there were comments in the source like "What does this do"<br>
I'm told that things have improved since then.<br><br>The original INTENT of X is not workable, or accessible to users today... its hard to get running, and working.<br>If you are reading this you represent the top 10% of the most Technical *Nix users (At least) so it may not seem that way to YOU.<br>
And in general desktop sessions are not realistically portable.<br><br>The thing (being the collection of programs that form the end-user experience) from a non-technical standpoint is a ... "MESS".<br>And the dependency on X is the fuel to the flame.<br>
<br>In my hurry to write my previous post I switched the verbage of X-Server and X-Client, my apologies for the Typo.<br><br>And I commonly throw around the word "Gnome" to mean "The collection of programs that connect to an X-Server and eventually get rendered to the framebuffer", seeing as most people have no idea what the individual components are.<br>
<br><br>Well I apologize this has turned into an X-bashing rant... <br><div><div></div><div class="h5"><br><div class="gmail_quote">On Wed, Mar 3, 2010 at 4:33 PM, Adam Tauno Williams <span dir="ltr"><<a href="mailto:awilliam@whitemice.org" target="_blank">awilliam@whitemice.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On Wed, 2010-03-03 at 15:11 -0500, Ben DeMott wrote:<br>
> X was designed, so applications could run on remote servers, and be<br>
> interacted with graphically on a local client.<br>
> The whole thing is a huge mess...<br>
<br>
</div>I disagree. I see a mess nowhere. There are clear lines of delineation<br>
between components.<br>
<div><br>
> You should be able to attach and run programs on a remote X Server.<br>
<br>
</div>That makes no sense. There is no "remote X server". The server is<br>
local; that is the design of X. The service provided by the server is<br>
display.<br>
<div><br>
> Have the X information piped to an X client and then have Gnome<br>
> attached to the local X client.<br>
> This doesn't however work in my limited experience.<br>
> This is the closest you can get:<br>
> <a href="http://mohanjith.net/blog/2008/01/using-gnome-remotely-via-ssh.html" target="_blank">http://mohanjith.net/blog/2008/01/using-gnome-remotely-via-ssh.html</a><br>
<br>
</div>I'm not sure what his issue is (and the post is a year old). But....<br>
<br>
awilliam@linux-yu4c:~> ssh -X <a href="mailto:adam@workhorse.cis.mormail.com" target="_blank">adam@workhorse.cis.mormail.com</a><br>
Last login: Fri Oct 9 11:54:33 2009 from<br>
fdb5:60da:9b8a:1:219:d2ff:fe42:66b6<br>
Have a lot of fun...<br>
adam@workhorse:~> evolution<br>
<br>
Boom! There is evolution. I'm not sure what you are saying doesn't<br>
work. Automatically started are: dbus, gconfd,<br>
bonobo-activation-framework, evolution-data-server, gvfs-fuse-daemon,<br>
gnome-keyring-daemon, etc...<br>
<br>
<br>
adam@workhorse:~> ps -u adam<br>
PID TTY TIME CMD<br>
11455 ? 00:00:00 sshd<br>
11456 pts/2 00:00:00 bash<br>
11499 pts/2 00:00:58 evolution.bin<br>
11503 pts/2 00:00:00 dbus-launch<br>
11504 ? 00:00:00 dbus-daemon<br>
11506 ? 00:00:00 gconfd-2<br>
11508 ? 00:00:00 gnome-keyring-d<br>
11512 ? 00:00:00 bonobo-activati<br>
11518 ? 00:00:00 evolution-data-<br>
11540 ? 00:00:00 evolution-alarm<br>
11601 ? 00:00:00 notification-da<br>
11604 ? 00:00:00 gvfsd<br>
11610 ? 00:00:00 gvfs-fuse-daemo<br>
11623 pts/2 00:00:00 ps<br>
<div><div></div><div><br>
<br>
_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org" target="_blank">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>