Light Weight X "clone" - Minix

This is a discussion on Light Weight X "clone" - Minix ; SVGALib sounds like a good starting point. Perhaps part of SDL could also be ported and used for dealing with inputs (keyboard/mouse) if necessary. Would anybody be interested in taking on the challenge of porting SVGALib? ( www.svgalib.org ) From ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 32 of 32

Thread: Light Weight X "clone"

  1. Re: Minix2 GUI (was: Light Weight X "clone")

    SVGALib sounds like a good starting point. Perhaps part of SDL could
    also be ported and used for dealing with inputs (keyboard/mouse) if
    necessary. Would anybody be interested in taking on the challenge of
    porting SVGALib? ( www.svgalib.org ) From there we could begin
    developing a usable graphics API.

    Anyone have any suggestions for a name? Mindows perhaps? ... or
    maybe not.

    waqar wrote:
    > > > > I think Minix does not need an X implementation. A better idea

    > is to
    > > > > design a GUI api from
    > > > > scratch just like the Win32 API. And it should not be client server
    > > > > based like X is

    >
    > Sebastian wrote:
    > > Hello,
    > >
    > > > > [GUI]
    > > > > Can you please tell me which? I am running Minix 2.0.4 (i286/287) ...

    > >
    > > > Take a look at "Mini X revisited" in this news group.

    > >
    > > Thank you.
    > >
    > > Regards,
    > > Sebastian

    >
    > I would again like to say that minix needs a GUI that is standalone and
    > does not support networking. Sombody mentioned in this post that once
    > there existed a project. I think we should start again. The first
    > problem that one is going to face will be SVGA drivers. I think porting
    > svgalib will be a good idea and then build the gui on top of it.



  2. Re: Minix2 GUI (was: Light Weight X "clone")

    Brendan McKenzie wrote:
    >
    > SVGALib sounds like a good starting point. Perhaps part of SDL could
    > also be ported and used for dealing with inputs (keyboard/mouse) if
    > necessary. Would anybody be interested in taking on the challenge of
    > porting SVGALib? ( www.svgalib.org ) From there we could begin
    > developing a usable graphics API.
    >
    > Anyone have any suggestions for a name? Mindows perhaps? ... or
    > maybe not.
    >


    As Lindows ?
    Naming Lindows already was discussed, not in newsgroups in the court.
    However I read somewhere that the X Windows is earlier naming than MS Windows
    X Windows dated with it seams 1983, MS Windows with 1984.

    The problem is not in SVGA "Super Video Graphic Array".
    My own video library in length of over 10Kb on TurboPascal
    perfectly served for page viewing on Hercules (Which I actually had), CGA,EGA
    and VGA. And did it faster than native graph.tpu on 8Mhz i8088 compatible
    processor.

    The problem is exactly in protocol.
    API as also the protocol.
    There are X protocol, Windows API, PDF, Xlib, GTK, QT, ect..
    GTK and QT exit not only for X but for Windows, and it seams for PDF-terminals.

    QT is commercial, and too heavy it has Opera, and Konqueror
    GTK it opensource

    To have both QT, and GTK plus Xlib you need to exactly copy protocol of Xorg.
    Which allows you to run wide variety of application, including Mozila,
    Konqueror, GIMP, multimedia players.

    Problem of X, I guess, not in the network oriented Client Server
    architecture but in revolutionary implemented protocol.
    Which looked good for 1982 DEC graphical terminal,
    but not so for personal computer with video accelerator in 2006.

    Based on the similar principles with X, PDF-terminal
    has more optimized protocol.

    Finally, it is possible to design complete terminal protocol
    with API. But even a usual (character) terminal is a server in Minix3.
    (Which theoretically may be accessed through network.)
    Not Client Server based protocol, will make your API or single tasking,
    or such as in Windows 1 and 2 (where central control program switches
    user between applications),
    or in the best case such as in Oberon.

    Look, when you drow histogram or send pixel by pixel video,
    if with each pixel of 800x600 video array, you also send some information,
    also several headers and initiation of (TCP/IP)
    processing of these information may take more resources then
    cosine transformation (as in JPEG and MPEG) or even fractal transformation.
    But when you send ones entire array through shared memory or even TCP/IP,
    (as in some X implementations) used little resources
    comparing with cosine transformation.
    But when you need interpolation, face filling,
    which may do your video array is not enough just to send picture.
    But PS-terminal first, later PDF-terminal did it somehow.

    Finally it is possible to create some native graphical API of only particular
    OS,
    but who'll made applications for this only API?

    --Quas.co.ua


    > waqar wrote:
    > > > > > I think Minix does not need an X implementation. A better idea

    > > is to
    > > > > > design a GUI api from
    > > > > > scratch just like the Win32 API. And it should not be client server
    > > > > > based like X is

    > >
    > > Sebastian wrote:
    > > > Hello,
    > > >
    > > > > > [GUI]
    > > > > > Can you please tell me which? I am running Minix 2.0.4 (i286/287) ...
    > > >
    > > > > Take a look at "Mini X revisited" in this news group.
    > > >
    > > > Thank you.
    > > >
    > > > Regards,
    > > > Sebastian

    > >
    > > I would again like to say that minix needs a GUI that is standalone and
    > > does not support networking. Sombody mentioned in this post that once
    > > there existed a project. I think we should start again. The first
    > > problem that one is going to face will be SVGA drivers. I think porting
    > > svgalib will be a good idea and then build the gui on top of it.



  3. Re: Minix2 GUI (was: Light Weight X "clone")

    On Tue, 29 Aug 2006, waqar wrote:

    > I would again like to say that minix needs a GUI that is standalone and
    > does not support networking.


    Yeah, it's very important that a system intended at least
    partially for embedded applications not support networking.

    3ch

  4. Re: Light Weight X "clone"

    Quas.co.ua wrote:
    > waqar wrote:
    >
    >>I think Minix does not need an X implementation. A better idea is to
    >>design a GUI api from
    >>scratch just like the Win32 API. And it should not be client server
    >>based like X is.

    >
    >
    > You may not beleive but Minix alredy passed such way of develoment,
    > Minix2 had its own GUI which worked in EGA mode,
    > even not ported for VGA.
    >
    > And Minix3 may not have any subsystem not Client Server based,
    > because of its minimal kernel functionality.
    > Even usual terminal in Minix3 is a server, if it is at all.
    >


    I think there may have been an MGR port at one stage, but I might be
    wrong - it all seems such a long time ago now, and I really can't trust
    my memory.
    I do remember for sure that there was an attempt at a graphics mode
    device way back in MINIX 1.3. A few people managed to get a EGA/VGA mode
    device driver written and were able to display a simple bitmap, but that
    was it. I wasted some time many years back thinking about porting their
    work to MINIX 2.0.0, but the notebook computer I was using wasn't really
    "standard" in a hardware sense and things didn't behave the way they should.


  5. Re: Light Weight X "clone"

    Steve Murray wrote:
    > I do remember for sure that there was an attempt at a graphics mode
    > device way back in MINIX 1.3.


    Those who are relatively new to Minix may not be aware that a Minix-l
    mailing lists exists. It is not very active these days, but for many
    years there was a gateway between the comp.os.minix newsgroup and the
    minix-l mailing list, so most items previous to 1994 or 1995 are
    duplicated.

    As with Google groups, there is an archive. However, in my opinion, at
    least, it is much easier to search the archives of minix-l than the
    Google archives for older items. A quick search led me to numerous
    references to mini-x and some to mgr starting in 1991. Back in those
    early days many people posted source code as uuencoded files or shar
    archives -- the original mini-x code can be found in a series of
    messages.

    The Minix-l archives are at
    http://listserv.nodak.edu/archives/minix-l.html.

    - Al


  6. Re: Light Weight X "clone"

    Steve Murray wrote:
    >
    > Quas.co.ua wrote:
    > > waqar wrote:
    > >
    > >>I think Minix does not need an X implementation. A better idea is to
    > >>design a GUI api from
    > >>scratch just like the Win32 API. And it should not be client server
    > >>based like X is.

    > >
    > >
    > > You may not beleive but Minix alredy passed such way of develoment,
    > > Minix2 had its own GUI which worked in EGA mode,
    > > even not ported for VGA.
    > >
    > > And Minix3 may not have any subsystem not Client Server based,
    > > because of its minimal kernel functionality.
    > > Even usual terminal in Minix3 is a server, if it is at all.
    > >

    >
    > I think there may have been an MGR port at one stage, but I might be
    > wrong - it all seems such a long time ago now, and I really can't trust
    > my memory.
    > I do remember for sure that there was an attempt at a graphics mode
    > device way back in MINIX 1.3. A few people managed to get a EGA/VGA mode
    > device driver written and were able to display a simple bitmap, but that
    > was it. I wasted some time many years back thinking about porting their
    > work to MINIX 2.0.0, but the notebook computer I was using wasn't really
    > "standard" in a hardware sense and things didn't behave the way they should.


    Look, device driver is not what is needed.
    The problem or better say task is in building subsystem,
    which could allow user to work with several applications
    and/or subroutines of each application.
    usage same technical resources.
    And the goal of this system to provide Graphical User Interface
    (GUI) for applications. In most of cases it is windowing based.

    (Formally even a TTY and a teletype is Graphical User Interface devices,
    because before teletype there were special switch lighting panels.
    If you see a letter from the computer is it drawn (graphed).)

    By the way, welcome to my fonts
    page http://www.is.svitonline.com/quas/tec/font.html
    I guess, it is suitable for Minix3 too.

    The windowing system, at least should share same terminal and keyboard,
    between several applications provide resizing, scrolling,
    overlaping/ranging and refresh for each window, switch of keyboard,
    and mouse sharing. There are tasks which just only video
    driver does not fulfill. However, it is also needed.

    --Quas.co.ua


  7. Re: Light Weight X "clone"

    How about thinking taking a look at Framebuffer and DirectFB?


  8. Re: Light Weight X "clone"

    Arindam Roy wrote:
    > How about thinking taking a look at Framebuffer and DirectFB?
    >

    And you're assuming we haven't?

  9. Re: Light Weight X "clone"

    Hello Segin,
    Please accept my apologies.
    I should have kown you must have.
    Arindam Roy
    Segin wrote:
    > Arindam Roy wrote:
    > > How about thinking taking a look at Framebuffer and DirectFB?
    > >

    > And you're assuming we haven't?



  10. Re: Light Weight X "clone"

    What do you think about of http://www.xynth.org/, it's lightweight,
    writen on pure C and has compability APIs for SDL, GTK, take a look at
    features http://www.xynth.org/features.php.


  11. Re: Light Weight X "clone"


    "Segin" wrote in message
    news:LimPg.60086$Tg1.17814@tornado.tampabay.rr.com ...
    > Arindam Roy wrote:
    >> How about thinking taking a look at Framebuffer and DirectFB?
    >>

    > And you're assuming we haven't?


    Who is "we" (just curious)?

    Tony



  12. Re: Light Weight X "clone"


    "intelec" wrote in message
    news:1158703954.234414.222660@k70g2000cwa.googlegr oups.com...
    > What do you think about of http://www.xynth.org/, it's lightweight,
    > writen on pure C and has compability APIs for SDL, GTK, take a look at
    > features http://www.xynth.org/features.php.


    "Incompatible" license. (Yep, I think all things GPL should be avoided like
    the plague).

    Tony



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2