On Wed, May 20, 2009 at 4:53 AM, Anselm R Garbe wrote:
> I have a completely new WS in mind, design-wise with no X
> dependency, just an X legacy support layer instead.
> ... , we want a different WS, not a state-machine WS like X.
Do you envision including xcb style asynchrony?
/john
On Wed, May 20, 2009 at 09:53:30AM +0100, Anselm R Garbe wrote:
> 2009/5/20 Jacob Todd :
> > On Tue, May 19, 2009 at 04:08:07PM +0200, pancake wrote:
> >>
> >
> > Seems interesting, but instead of reinventing the wheel, why don't we just
> > clean
> > up X.org and submit patches back upstream
2009/5/20 Jacob Todd :
> On Tue, May 19, 2009 at 04:08:07PM +0200, pancake wrote:
>>
>
> Seems interesting, but instead of reinventing the wheel, why don't we just
> clean
> up X.org and submit patches back upstream? Rewriting/implementing X.org seems
> li
> ke more work than it's worth, but
Hi pancake,
2009/5/19 pancake :
> I have been looking a bit for an alternative for X11, and I found nano-X
> quite interesting,
> but it is currently an abandoned project. 8000 LOCs, there's an abstraction
> library to wrap
> libX11 and there's support for some many IO devices (tty, gpm, ..) It ru
On Wed, May 20, 2009 at 2:39 AM, Jacob Todd wrote:
> On Tue, May 19, 2009 at 04:08:07PM +0200, pancake wrote:
>>
>
> Seems interesting, but instead of reinventing the wheel, why don't we just
> clean
> up X.org and submit patches back upstream? Rewriting/implementing X.org seems
> li
> ke m
On Tue May 19, 2009 at 08:39:56PM -0400, Jacob Todd wrote:
> On Tue, May 19, 2009 at 04:08:07PM +0200, pancake wrote:
> >
>
> Seems interesting, but instead of reinventing the wheel, why don't we just
> clean
> up X.org and submit patches back upstream? Rewriting/implementing X.org seems
>
On Tue, May 19, 2009 at 04:08:07PM +0200, pancake wrote:
>
Seems interesting, but instead of reinventing the wheel, why don't we just clean
up X.org and submit patches back upstream? Rewriting/implementing X.org seems li
ke more work than it's worth, but cleaning up Xorg would be better for e
ry to
use less the browser, so
for low memory and resource usage a nanox with dwm-nanox and some
nanoxterms somewhere would
be nice.
There's little movement in the mailing list nowadays, but the last
release is from 1999. So I
can think that the project is dead.
Here's the last rel
