Re: What Linux lacks : better in-kernel user interface - X

This is a discussion on Re: What Linux lacks : better in-kernel user interface - X ; After a long battle with technology, u9526@yahoo.com (Saturday7), an earthling, wrote: >> there's a _reason_ SVGAlib isn't maintained and that new programs >> don't use it. > > Which is? Because by the time you have created the infrastructure you ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Re: What Linux lacks : better in-kernel user interface

  1. Re: What Linux lacks : better in-kernel user interface

    After a long battle with technology, u9526@yahoo.com (Saturday7), an earthling, wrote:
    >> there's a _reason_ SVGAlib isn't maintained and that new programs
    >> don't use it.

    >
    > Which is?


    Because by the time you have created the infrastructure you need,
    you'll have recreated X, badly. (Which is arguably "saying
    something.")

    I remember when people came by weekly to ask "When's someone going to
    create a web browser for SVGAlib?"

    They expected this to somehow lead to them having something smaller
    than X.

    Reality is that by the time you throw in:

    - Font rendering
    - Widgets
    - Managing windows
    - Having some multiplexing system so you can run more than one
    application at a time

    You'll have something relatively comparable to X.
    --
    output = ("cbbrowne" "@" "acm.org")
    http://www3.sympatico.ca/cbbrowne/xbloat.html
    Why don't sheep shrink when it rains?

  2. Re: What Linux lacks : better in-kernel user interface

    Here in comp.os.linux.x,
    Christopher Browne spake unto us, saying:

    >I remember when people came by weekly to ask "When's someone going to
    >create a web browser for SVGAlib?"


    A nice graphical browser that doesn't use X is Links 2.1... :-)

    The DamnSmallLinux "live CD" distribution uses that browser to very
    good effect as it's quite lightweight compared to X + an X browser.

    --
    -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
    OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
    WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
    The Theorem Theorem: If If, Then Then.

  3. Re: What Linux lacks : better in-kernel user interface

    Centuries ago, Nostradamus foresaw when rsteiner@visi.com (Richard Steiner) would write:
    > Here in comp.os.linux.x,
    > Christopher Browne spake unto us, saying:
    >
    >>I remember when people came by weekly to ask "When's someone going to
    >>create a web browser for SVGAlib?"

    >
    > A nice graphical browser that doesn't use X is Links 2.1... :-)
    >
    > The DamnSmallLinux "live CD" distribution uses that browser to very
    > good effect as it's quite lightweight compared to X + an X browser.


    Actually, it will use X...

    Interesting; I'm running that now.

    What on earth does Links2 use to render fonts? Its handling of text
    is remarkably _good_, and it looks as though it's, I don't know, using
    Ghostscript or something to render them?

    I'm very impressed by the font rendition (on X).

    I guess that if you can wait ten years, some impossible things _can_
    happen.
    --
    "cbbrowne","@","cbbrowne.com"
    http://www3.sympatico.ca/cbbrowne/postgresql.html
    "When I was a boy of fourteen, my father was so ignorant I could
    hardly stand to have the old man around. But when I got to be
    twenty-one, I was astonished at how much the old man had learned in
    seven years." -- Mark Twain

  4. Re: What Linux lacks : better in-kernel user interface

    Christopher Browne wrote in message news:<2pq35aFn1j41U1@uni-

    > Reality is that by the time you throw in:
    >
    > - Font rendering
    > - Widgets
    > - Managing windows
    > - Having some multiplexing system so you can run more than one
    > application at a time
    >
    > You'll have something relatively comparable to X.


    That's just not true.
    I've got a very simple widget system that is 50kB.
    I've written a windowing system -- not that I would ever put that
    in a kernel -- that was less than 200kB.
    Font rendering is a single function that is at most 5kB.
    Multiplexing is nothing special.

    Whether your response is FUD or ignorance readers will have
    to decide.

  5. Re: What Linux lacks : better in-kernel user interface

    u9526@yahoo.com (Saturday7) writes:

    > Christopher Browne wrote in message news:<2pq35aFn1j41U1@uni-
    >
    >> Reality is that by the time you throw in:
    >>
    >> - Font rendering
    >> - Widgets
    >> - Managing windows
    >> - Having some multiplexing system so you can run more than one
    >> application at a time
    >>
    >> You'll have something relatively comparable to X.

    >
    > That's just not true.
    > I've got a very simple widget system that is 50kB.


    That's it. Very simple sometimes isn't good enough.

    > I've written a windowing system -- not that I would ever put that
    > in a kernel -- that was less than 200kB.


    Define a windowing system. Drawing a few windows might be simple, but
    doing many of the things lots of programs do all the time with X does
    require some amount of code.

    > Font rendering is a single function that is at most 5kB.


    Does it do pcf, type1 and truetype fonts? Antialiasing?

    > Multiplexing is nothing special.


    More special than not multiplexing.

    --
    Måns Rullgård
    mru@mru.ath.cx

  6. Re: What Linux lacks : better in-kernel user interface

    After a long battle with technology, u9526@yahoo.com (Saturday7), an earthling, wrote:
    > Christopher Browne wrote in message news:<2pq35aFn1j41U1@uni-
    >
    >> Reality is that by the time you throw in:
    >>
    >> - Font rendering
    >> - Widgets
    >> - Managing windows
    >> - Having some multiplexing system so you can run more than one
    >> application at a time
    >>
    >> You'll have something relatively comparable to X.

    >
    > That's just not true.
    > I've got a very simple widget system that is 50kB.
    > I've written a windowing system -- not that I would ever put that
    > in a kernel -- that was less than 200kB.
    > Font rendering is a single function that is at most 5kB.
    > Multiplexing is nothing special.
    >
    > Whether your response is FUD or ignorance readers will have to
    > decide.


    Ah, right. It would surely be impossible to be _right_, would it?

    When Jim Gettys and Keith Packard (whose names ought to be pretty
    familiar in relation to X) did the X port to the Itsy, they got the
    client and server libs down to about 1.3MB in size.

    X clearly does NOT need to be large.

    "There are certainly some very bloated X toolkits out there; there
    are also some reasonably small ones.

    For most servers, backing store and save unders rapidly dominate
    memory usage: with 32 bit deep displays, a screen full of memory is
    4 megabytes. It doesn't take all that many apps, particularly with
    some fragmentatation of the memory pool in the server, to cause the
    virtual address space of an X server to get large. So backing store
    and save unders dominate memory usage on most displays people use
    today (and/or any pixmaps the clients save at the server); the X
    server itself is hardly "bloated", though there is code around I
    question the need for from time to time...

    Note that this is the nature of the beast; some other window system
    that also implements backing store and save unders would use
    similar amounts of memory for this purpose.

    On itsy, of course, the display size is 320x200x4bits, so even
    backing store doesn't take much memory (about 1/100'th of the
    memory that a current 32 bit frame buffer would take).

    But this is virtual space; so long as you aren't actively paging,
    what matters is that the working set be in memory."

    -- Jim Gettys
    --
    select 'cbbrowne' || '@' || 'acm.org';
    http://www.ntlug.org/~cbbrowne/spiritual.html
    "Windows 98 Roast Specialty Blend coffee beans - just like ordinary
    gourmet coffee except that processing is rushed to leave in the insect
    larvae. Also sold under the ``Chock Full o' Bugs'' brand name..."

  7. Re: What Linux lacks : better in-kernel user interface

    Måns Rullgård wrote in message

    > > That's just not true.
    > > I've got a very simple widget system that is 50kB.

    >
    > That's it. Very simple sometimes isn't good enough.


    People who want bloat can use X.

    > > I've written a windowing system -- not that I would ever put that
    > > in a kernel -- that was less than 200kB.

    >
    > Define a windowing system. Drawing a few windows might be simple, but
    > doing many of the things lots of programs do all the time with X does
    > require some amount of code.


    Creating windows, handling rectangles due to overlap, allowing
    windows to be moved. Basic stuff.

    X -> bloat
    !bloat -> !X

    > > Font rendering is a single function that is at most 5kB.

    >
    > Does it do pcf, type1 and truetype fonts? Antialiasing?


    And you point is?

  8. Re: What Linux lacks : better in-kernel user interface

    Here in comp.os.linux.x,
    Christopher Browne spake unto us, saying:

    >Centuries ago, Nostradamus foresaw when rsteiner@visi.com
    >(Richard Steiner) would write:
    >
    >> Here in comp.os.linux.x,
    >> Christopher Browne spake unto us, saying:
    >>
    >>>I remember when people came by weekly to ask "When's someone going to
    >>>create a web browser for SVGAlib?"

    >>
    >> A nice graphical browser that doesn't use X is Links 2.1... :-)
    >>
    >> The DamnSmallLinux "live CD" distribution uses that browser to very
    >> good effect as it's quite lightweight compared to X + an X browser.

    >
    >Actually, it will use X...


    Yes, X is provided an as option on some platforms, but I tend to use it
    without X almost everywhere. The OS/2 version of Links 2.1pre14 will
    only use PM for its GUI, though, and won't run it as an X client.

    >Interesting; I'm running that now.
    >
    >What on earth does Links2 use to render fonts? Its handling of text
    >is remarkably _good_, and it looks as though it's, I don't know, using
    >Ghostscript or something to render them?


    I'm not sure. I tend to run it in text mode under OS/2 unless I really
    need to see pretty pictures, though. The font that my video card uses
    in 80x33 mode is quite clear as well! :-) :-)

    >I'm very impressed by the font rendition (on X).
    >
    >I guess that if you can wait ten years, some impossible things _can_
    >happen.


    Yes. Now all I need is a fullscreen version for OS/2. :-)

    --
    -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
    OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
    WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
    The Theorem Theorem: If If, Then Then.

  9. Re: What Linux lacks : better in-kernel user interface

    Christopher Browne wrote in message

    > When Jim Gettys and Keith Packard (whose names ought to be pretty
    > familiar in relation to X) did the X port to the Itsy, they got the
    > client and server libs down to about 1.3MB in size.
    >
    > X clearly does NOT need to be large.


    To my taste, 1.3 megs is very large.
    Taste != right/wrong.

  10. Re: What Linux lacks : better in-kernel user interface

    u9526@yahoo.com (Saturday7) writes:

    > Måns Rullgård wrote in message
    >
    >> > That's just not true.
    >> > I've got a very simple widget system that is 50kB.

    >>
    >> That's it. Very simple sometimes isn't good enough.

    >
    > People who want bloat can use X.


    I don't want bloat, search the archives for evidence. However, I do
    want many of the features X provides, such as hierarchical windows,
    well-working event model, pixmaps just to name a few.

    >> > I've written a windowing system -- not that I would ever put that
    >> > in a kernel -- that was less than 200kB.

    >>
    >> Define a windowing system. Drawing a few windows might be simple, but
    >> doing many of the things lots of programs do all the time with X does
    >> require some amount of code.

    >
    > Creating windows, handling rectangles due to overlap, allowing
    > windows to be moved. Basic stuff.
    >
    > X -> bloat
    > !bloat -> !X


    You must be confusing X with the horribly bloated things called KDE
    and GNOME.

    >> > Font rendering is a single function that is at most 5kB.

    >>
    >> Does it do pcf, type1 and truetype fonts? Antialiasing?

    >
    > And you point is?


    A want a font rendering engine to do those things, and I don't think
    they can be done with a single 5kB function. Please correct me if I
    am mistaken.

    --
    Måns Rullgård
    mru@mru.ath.cx

  11. Re: What Linux lacks : better in-kernel user interface

    begin Saturday7 wrote:

    > Måns Rullgård wrote in message
    >
    >> > That's just not true.
    >> > I've got a very simple widget system that is 50kB.

    >>
    >> That's it. Very simple sometimes isn't good enough.

    >
    > People who want bloat can use X.
    >
    >> > I've written a windowing system -- not that I would ever put that
    >> > in a kernel -- that was less than 200kB.

    >>
    >> Define a windowing system. Drawing a few windows might be simple, but
    >> doing many of the things lots of programs do all the time with X does
    >> require some amount of code.

    >
    > Creating windows, handling rectangles due to overlap, allowing
    > windows to be moved. Basic stuff.
    >
    > X -> bloat
    > !bloat -> !X
    >
    >> > Font rendering is a single function that is at most 5kB.

    >>
    >> Does it do pcf, type1 and truetype fonts? Antialiasing?

    >
    > And you point is?


    His point is that doing "basic" windowing stuff is fine and dandy. And not
    nearly enough, not by a very far stretch of imagination.
    Except you are proposing letting the individual apps handle this all by
    themselves. *Then* you have bloat.
    --
    "Outside of a dog, a book is a man's best friend: and inside a dog,
    it's too dark to read." -- Groucho Marx


  12. Re: What Linux lacks : better in-kernel user interface

    Måns Rullgård wrote in message

    > I don't want bloat, search the archives for evidence. However, I do
    > want many of the features X provides, such as hierarchical windows,
    > well-working event model, pixmaps just to name a few.


    Hierarchical windows in the kernel is unwise, imho. For instance,
    how would you give the window manager process control over placement?

    > You must be confusing X with the horribly bloated things called KDE
    > and GNOME.


    It's a matter of taste. 15-20MB memory usage feels like bloat
    to me. As does 1-2MB.

    > A want a font rendering engine to do those things, and I don't think
    > they can be done with a single 5kB function. Please correct me if I
    > am mistaken.


    I stand corrected, it's 2kB. Keep in mind, this is only for
    horizontal, left-to-right rendering of 8-bit PCF fonts. So no rendering at
    45 degrees, no anti-aliasing, no Unicode.

  13. Re: What Linux lacks : better in-kernel user interface

    u9526@yahoo.com (Saturday7) writes:

    > Måns Rullgård wrote in message
    >
    >> I don't want bloat, search the archives for evidence. However, I do
    >> want many of the features X provides, such as hierarchical windows,
    >> well-working event model, pixmaps just to name a few.

    >
    > Hierarchical windows in the kernel is unwise, imho. For instance,
    > how would you give the window manager process control over placement?


    That is one good reason to keep windowing systems in userspace. I
    have never advocated anything else.

    >> You must be confusing X with the horribly bloated things called KDE
    >> and GNOME.

    >
    > It's a matter of taste. 15-20MB memory usage feels like bloat
    > to me. As does 1-2MB.


    It all depends on what's done with those megabytes.

    >> A want a font rendering engine to do those things, and I don't think
    >> they can be done with a single 5kB function. Please correct me if I
    >> am mistaken.

    >
    > I stand corrected, it's 2kB. Keep in mind, this is only for
    > horizontal, left-to-right rendering of 8-bit PCF fonts. So no rendering at
    > 45 degrees, no anti-aliasing, no Unicode.


    If that's all it does it's little more than a bitmap blitter. I
    thought we were talking about fonts here.

    --
    Måns Rullgård
    mru@mru.ath.cx

  14. Re: What Linux lacks : better in-kernel user interface

    Måns Rullgård wrote in message news:...
    > u9526@yahoo.com (Saturday7) writes:


    > > Hierarchical windows in the kernel is unwise, imho. For instance,
    > > how would you give the window manager process control over placement?

    >
    > That is one good reason to keep windowing systems in userspace. I
    > have never advocated anything else.


    Except personally I don't believe in windowing systems
    in userspace either. Overlapping windows do not impress me.
    In my experience panes work better.

    > > I stand corrected, it's 2kB. Keep in mind, this is only for
    > > horizontal, left-to-right rendering of 8-bit PCF fonts. So no rendering at
    > > 45 degrees, no anti-aliasing, no Unicode.

    >
    > If that's all it does it's little more than a bitmap blitter. I
    > thought we were talking about fonts here.


    Oh, and is PCF not a font?

  15. Re: What Linux lacks : better in-kernel user interface

    u9526@yahoo.com (Saturday7) writes:

    > Måns Rullgård wrote in message news:...
    >> u9526@yahoo.com (Saturday7) writes:

    >
    >> > Hierarchical windows in the kernel is unwise, imho. For instance,
    >> > how would you give the window manager process control over placement?

    >>
    >> That is one good reason to keep windowing systems in userspace. I
    >> have never advocated anything else.

    >
    > Except personally I don't believe in windowing systems
    > in userspace either. Overlapping windows do not impress me.
    > In my experience panes work better.


    Use whatever works for you, I'll stick with X.

    >> > I stand corrected, it's 2kB. Keep in mind, this is only for
    >> > horizontal, left-to-right rendering of 8-bit PCF fonts. So no rendering at
    >> > 45 degrees, no anti-aliasing, no Unicode.

    >>
    >> If that's all it does it's little more than a bitmap blitter. I
    >> thought we were talking about fonts here.

    >
    > Oh, and is PCF not a font?


    PCF is a simple font. I want antialiased scalable vector fonts, such
    as truetype.

    --
    Måns Rullgård
    mru@mru.ath.cx

  16. Re: What Linux lacks : better in-kernel user interface

    Måns Rullgård wrote in message

    > > Oh, and is PCF not a font?

    >
    > PCF is a simple font. I want antialiased scalable vector fonts, such
    > as truetype.


    You wanna put patented technology in the Linux kernel?

  17. Re: What Linux lacks : better in-kernel user interface

    u9526@yahoo.com (Saturday7) writes:

    > Måns Rullgård wrote in message
    >
    >> > Oh, and is PCF not a font?

    >>
    >> PCF is a simple font. I want antialiased scalable vector fonts, such
    >> as truetype.

    >
    > You wanna put patented technology in the Linux kernel?


    I'm pretty sure I said these things belong in userspace? Please show
    me one post where I have advocated adding things to the kernel. And
    for the record, patents are not the issue, doing things where they are
    best done is. Graphics and fonts are best done in userspace.

    --
    Måns Rullgård
    mru@mru.ath.cx

  18. Re: What Linux lacks : better in-kernel user interface

    On 3 Sep 2004, Christopher Browne moaned:
    > What on earth does Links2 use to render fonts? Its handling of text
    > is remarkably _good_, and it looks as though it's, I don't know, using
    > Ghostscript or something to render them?


    It has a collection of built-in bitmap fonts, stored inconveniently as a
    bunch of PNGs embedded in the font_data variable defined in
    `font_include.c'.

    I don't know where these fonts originate, but they *do* look like
    GS had a hand in their rendering somewhere.

    --
    `The copyright file is for everyone. That we make it available in
    plain-text, uncompressed form rather than in spinning, throbbing
    OpenGL-rendered 3D text over a thumping dance music soundtrack is a
    feature, not a bug.' --- Branden Robinson


  19. Re: What Linux lacks : better in-kernel user interface

    In the last exciting episode, Nix wrote:
    > On 3 Sep 2004, Christopher Browne moaned:
    >> What on earth does Links2 use to render fonts? Its handling of text
    >> is remarkably _good_, and it looks as though it's, I don't know, using
    >> Ghostscript or something to render them?

    >
    > It has a collection of built-in bitmap fonts, stored inconveniently as a
    > bunch of PNGs embedded in the font_data variable defined in
    > `font_include.c'.
    >
    > I don't know where these fonts originate, but they *do* look like
    > GS had a hand in their rendering somewhere.


    I suppose it would be slightly more amusing if they were rendered in
    Computer Modern Roman, Computer Modern Sans, and such :-).
    --
    "cbbrowne","@","linuxfinances.info"
    http://linuxfinances.info/info/sgml.html
    Idiosyncratic indentations, double-spacing, capitalization, etc., while
    stamps of individuality, leave one an easy target for parody.
    -- from the Symbolics Guidelines for Sending Mail

+ Reply to Thread