X Window System - Plan9

This is a discussion on X Window System - Plan9 ; What would be the difficulties if someone wishes to port X to Plan 9 and wants to see it running independently of rio? Any ideas, from technical point of view?...

+ Reply to Thread
Results 1 to 8 of 8

Thread: X Window System

  1. X Window System

    What would be the difficulties if someone wishes to port X to Plan 9
    and wants to see it running independently of rio? Any ideas, from
    technical point of view?

  2. Re: [9fans] X Window System

    I has already been done.

    Look for it in "sources"...

    (But I don't see a good reason to use it/ do it again)

    Cheers!

    On 9/24/07, pavlovetsky@gmail.com wrote:
    >
    > What would be the difficulties if someone wishes to port X to Plan 9
    > and wants to see it running independently of rio? Any ideas, from
    > technical point of view?
    >



  3. Re: [9fans] X Window System

    On Mon, Sep 24, 2007 at 09:14:14AM +0000, pavlovetsky@gmail.com wrote:
    > What would be the difficulties if someone wishes to port X to Plan 9
    > and wants to see it running independently of rio? Any ideas, from
    > technical point of view?


    This is not a technical advice but more a theoretical one. I'm actually
    rewriting the 2D interface for KerGIS programs with an eye on want I
    want/need: a distributed system with computing (may be heavy in the
    KerGIS case) on CPU nodes, and interface handling (exclusively
    arithmetic i.e. only ALU intrusctions) on terminals (the connection
    between the terminal and the CPU being exclusively 1D commands, i.e. the
    graphical interface is only a graphical mean to select commands and
    data, there is only one version of the computing programs with a
    text/line oriented language [batch]).

    With this is mind, one sees that X is the wrong answer since the
    interface handling (the menu abstraction, the heavy stuff done by the
    toolkits) is not on the terminal but on the CPU (if one uses the
    "distributed" nature of X). This is not its place, and its really "old"
    conception: a mainframe with dumb terminals.

    I hope the main idea is clear enough, I mean IMHO providing a "toolkit"
    plan 9 based would be far better and probably in terms of work
    far easier than porting the whole X world to Plan 9.

    In my case, with a huge beast---but that is becoming lean since with the
    principles above I suppress tons of redundant spaghetti code---,
    rewriting the graphical interface is a benefit on Unix/X11 and will
    allow porting to pure plan 9 absolutely easily (with there the full
    benefit of "distributed"; it will be the same on Unix, but not
    delegating "distribution" to X, but taking care at it by the
    architecture of the code).

    On another side, the X11 people want now to include the graphical server
    in the OS and wonder about the X protocol (but AFAIK haven't identified
    that the "distribution"/connexion is not done in the right place). That
    is, the future of X11 is more towards plan 9 concepts so "following" X11
    is a bit weird

    I hope these thoughts have some interest for what you have in mind.

    Cheers,
    --
    Thierry Laronde (Alceste)
    http://www.kergis.com/
    Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

  4. Re: X Window System

    On Sep 24, 12:11 pm, lorenzobiv...@gmail.com (Lorenzo Fernando Bivens
    de la Fuente) wrote:
    > I has already been done.
    >
    > Look for it in "sources"...
    >
    > (But I don't see a good reason to use it/ do it again)
    >
    > Cheers!
    >
    > On 9/24/07, pavlovet...@gmail.com wrote:
    >
    >
    >
    >
    >
    > > What would be the difficulties if someone wishes to port X to Plan 9
    > > and wants to see it running independently of rio? Any ideas, from
    > > technical point of view?- Hide quoted text -

    >
    > - Show quoted text -


    Yes, I know that the port exists and it is running inside rio, isn't
    it?

    You can't compile it nowadays:

    making all in programs/Xserver/Xext...
    rm -f shape.o
    cc -c -O -I../include -I../../../X11 -I../../../include/extensions -
    I../../.. -DBRAZIL -DOBJTYPE$objtype -D_BSD_EXTENSION -
    D_RESEARCH_SOURCE -DSHAPE -DFUNCPROTO=11 shape.c
    /sys/src/X11/programs/Xserver/Xext/shape.c:485[stdin:25175]
    incompatible type: "VOID" for op "DOT"
    /sys/src/X11/programs/Xserver/Xext/shape.c:497[stdin:25187]
    incompatible type: "VOID" for op "DOT"
    cc: cpp: 8c 226911: error
    *** Error code 1

    Stop.

  5. Re: [9fans] Re: X Window System


    > Yes, I know that the port exists and it is running inside rio, isn't
    > it?


    it runs inside rio if you start it inside rio, start it instead of rio and
    it will use the whole display (as would acme, sam or catclock :-).

    > You can't compile it nowadays:


    I last compiled it against the 3rd edition but this should not make
    any real difference; from memory the only real changes in the compiler since
    then are the option of link time type checking and improvements to 64bit
    int support. I suggest you explore the 'incompatible type: "VOID" for op "DOT"'
    error, it may simply be somthing in your ape environment is not
    set up as x11 needs, (though it may be somthing less tractable of course).

    The biggest problem with this package is the limited plan9
    driver - only 8bit pixmaps are supported and use on plan9 displays with
    depths other than 8bits is very slow. This could be fixed but it would
    probably be more sensible to update the port to the current X11 release.

    -Steve

  6. Re: X Window System

    So, if not X, then how about some higher (or eperhaps lower?) layer
    libraries (qtk? Qt? Gecko?) ported so that porting the 10 (or 100)
    best known FOSS packages (whatever they are) would become more
    possible?

    How about a project to take something like Firefox and restructure the
    whole sw so that best modules would be kept and other modules re-
    implemented /dev/draw way and Rio way?

    Or is the real problem really the GUI? Or something else, like the GNU
    toolchain needed to compile a typical FOSS project?

  7. Re: [9fans] Re: X Window System

    app wrote:

    >So, if not X, then how about some higher (or eperhaps lower?) layer
    >libraries (qtk? Qt? Gecko?) ported so that porting the 10 (or 100)
    >best known FOSS packages (whatever they are) would become more
    >possible?
    >
    >

    Go! look at these 100 best known programs... Look at the code and the
    dependencies... its not that easy/beauty.

    >How about a project to take something like Firefox and restructure the
    >whole sw so that best modules would be kept and other modules re-
    >implemented /dev/draw way and Rio way?
    >
    >

    That gets you the same big old programs lunix has... In the end, you dont
    port the programs to Plan9 but the other way arround... and then you
    are where anything started.

    >Or is the real problem really the GUI? Or something else, like the GNU
    >toolchain needed to compile a typical FOSS project?
    >
    >

    No, its not just the GUI.
    One of the strongest thinks of Plan9 are the simple and small libraries.
    The small code makes it possible for a small comunity to maintain it.
    Even a single person can read and understand most of the code.
    In contrast to the GNU userland. Here are thousands of programers out
    here to
    fix and hack on these zillion-lines-always-changing GNU code. Here are huge
    dependency graph for all that stuff. Its mutch work to port, fix,
    maintain...
    I doubt a single person/small comunity can do it... And what do you get
    if you are done?
    Firefox? Just a webbrowser for all that?
    Here is abaco... its very small, fast and has a nice UI. It has
    limitations but why not
    improve it then? Its small... you can actually understand and fix the
    code or
    ask the author.
    Its mutch more fun to make native Plan9 applications. If that gets you
    to implement
    some kind of UI(-library) that turns out to be usefull in other programs
    that will
    be great.
    IMHO... If you are serious with Plan9... eat Plan9 dogfood... start
    using it on
    daily basis... see what missing for YOU... start writing your programs
    yourself with
    the tools that Plan9 gives you. In many cases... this will result in
    programs
    that are mutch more simpler and smaller.
    If you do it you will note what Plan9 lacks and maybe provide a solution
    that
    further programers can profit of.

    cinap


  8. Re: [9fans] Re: X Window System

    it's ironic that the object-oriented guys have such
    a tangled web of external dependencies.

    - erik


+ Reply to Thread