Baby X - new project

[Malcolm McLean]

A widget is a process that can write to the portion of a screen and
receives events from a superwidget. It contains zero or more subwidgets
which can receive events from the widget and write portions of the screens
contained in the widget.

That would mean a widget library would
(1) Have a way to receive events.
(2) A way to create/send events.
(3) A way to draw a pixel on the screen.
(4) A way to get information about the widget.

You could make that the BabyX interface.

The user can then define their own libraries which add this set or that
set of events to a widget, and/or create more elaborate drawers in terms
of simpler drawers.

Once you can draw individual pixels, you can use that implement a quadratic
(Quickdraw), cubic (Postscript), OpenGL, etc. And of course the libraries
could also use hardware shortcuts if they can find them.

And then define more libraries which use those libraries, and so on.

The absolute basic interface would go something like

int openwindow(int requestwidth, int requestheight, int *givenwidth, int *givenheight);
void drawpixel(int x, int y, int r, int g, int b);
int querymouse(int *x, int *y, int *buttons);
int querykeyboard(KEYBOARD *pressed)
int iskeypressed(KEYBOARD *keys, int ch);

It might be an idea to provide that, and then build eveything else on top of it.

 

[Ian Collins]

xlib is the low-level interface to the X server. The X server can be thought
of as an abstract graphical device. xlib provides routines to open windows,
draw text and a few graphics primitives on them, and get keyboard presses
and mouse clicks.
However most programmers want graphical items like buttons, edit boxes,
message boxes. There's no "create button" function in xlib. You have to
open a window, draw the button on it, and intercept the mouse click
yourself. So obviously, there's a demand for libraries which provide
buttons. A toolkit is such a library.

So you are aiming at the same level as XT?

The best by fay C only X toolkit was (and still is!) XView. I think I
learned more bout software design (especially OO in C) form working with
XView than just about anything else. It was made open source in the
latter part of the last century. The excellent O'Reilly XView
programming manual is also available for free download
(http://oreilly.com/openbook/openlook/).

 

[Malcolm McLean]

Malcolm McLean wrote:

So you are aiming at the same level as XT?

No, Xt provides containers and such like, but no actual user-level
objects. BabyX has functions with names like "button" which put a button
on the screen. Currently it's always grey, with a 3d effect, it always
has a centred text label, it doesn't visibly respond as you press it
(but that'll probably change, I'm putting in the functionality now and
leaving the frills until later)

The best by fay C only X toolkit was (and still is!) XView. I think I
learned more bout software design (especially OO in C) form working with
XView than just about anything else. It was made open source in the
latter part of the last century. The excellent O'Reilly XView
programming manual is also available for free download

It's important to avoid the "15th standard" effect. The situation is that
we've got 14 toolkits, all incompatible with each other, so to resolve that
we try to provide a unified system. The result can only be fifteen standards,
all incompatible with reach other.

 

[Ian Collins]

It's important to avoid the "15th standard" effect. The situation is that
we've got 14 toolkits, all incompatible with each other, so to resolve that
we try to provide a unified system. The result can only be fifteen standards,
all incompatible with reach other.

Isn't that what you are developing?

XView is the one true standard

 

[Malcolm McLean]

Malcolm McLean wrote:

The best by fay C only X toolkit was (and still is!) XView. I think I
learned more bout software design (especially OO in C) form working with
XView than just about anything else. It was made open source in the
latter part of the last century. The excellent O'Reilly XView
programming manual is also available for free download

(http://oreilly.com/openbook/openlook/).

I'm sure it's a great toolkit, but the manual is 327 pages.
That's what I'm trying to avoid.

 

[Ian Collins]

I'm sure it's a great toolkit, but the manual is 327 pages.
That's what I'm trying to avoid.

Which is less than half the size (and better written) than the Xlib
programming manual! It's also about a third of the size of the Motif
manual (which frequently refers the the XT manual) and you definitely
don't want to go down that path!

 

[James Harris \(es\)]

The absolute basic interface would go something like

int openwindow(int requestwidth, int requestheight, int *givenwidth, int
*givenheight);
void drawpixel(int x, int y, int r, int g, int b);
int querymouse(int *x, int *y, int *buttons);
int querykeyboard(KEYBOARD *pressed)
int iskeypressed(KEYBOARD *keys, int ch);

It might be an idea to provide that, and then build eveything else on top
of it.

A drawpixel function? Nooooo! If you include that someone will only go and
use it!.A macro, possibly, but not a function. Better, IMHO, how about a way
to call the drawing routine and pass it a list of commands, some of which
can be single, individual, isolated, one-at-a-time pixels if absolutely
necessary.

Mice can generate scroll events as well as x and y movements.

A given human can generate mouse and keyboard events and expect them to be
processed in order even if the GUI is delayed for a moment. And humans can
interact with other devices too. A human-interface packet format might be
better.

Your iskeypressed routine sounds appropriately low level. A keyboard is
fundamentally a lot of switches. But I'm not sure about the int ch part. Not
all keys generate characters. Further, a number of languages look for key
down and key up messages.

James

 

[BartC]

The absolute basic interface would go something like

int openwindow(int requestwidth, int requestheight, int *givenwidth, int
*givenheight);
void drawpixel(int x, int y, int r, int g, int b);
int querymouse(int *x, int *y, int *buttons);
int querykeyboard(KEYBOARD *pressed)
int iskeypressed(KEYBOARD *keys, int ch);

It might be an idea to provide that, and then build eveything else on top
of it.

Yes, that's the sort of thing I used to do on top of Win32/GDI etc, and have
been trying again to get something so simple!

So, at the basic level:

- create top-level window

- create child window (although this can be dispensed at this level, the
user of this library will have a bit of extra work to achieve the same
functionality without it. Also system-supplied child windows can do useful
clipping which is harder otherwise)

- basic draw functions (I wouldn't rely on drawing single pixels, it's far
too slow). You will need access to system-supplied clear, fill and text
functions too.

- wait for next event (mostly keyboard/mouse ones, but also those from the
underlying windows system)

However if you wanted to have the menus, buttons and dialogs you mentioned,
you will need an extra layer on top of this. Designing something that does
everything someone might want, or allows ways to do so, is difficult! And it
will likely still look like something from the 1990s (not quite the 80s
someone mentioned).

 

[Malcolm McLean]

Yes, that's the sort of thing I used to do on top of Win32/GDI etc, and have
been trying again to get something so simple!

So, at the basic level:

- create top-level window

- create child window (although this can be dispensed at this level, the

user of this library will have a bit of extra work to achieve the same
functionality without it. Also system-supplied child windows can do useful
clipping which is harder otherwise)

- basic draw functions (I wouldn't rely on drawing single pixels, it's far

too slow). You will need access to system-supplied clear, fill and text
functions too.


- wait for next event (mostly keyboard/mouse ones, but also those from the
underlying windows system)

However if you wanted to have the menus, buttons and dialogs you mentioned,
you will need an extra layer on top of this. Designing something that does
everything someone might want, or allows ways to do so, is difficult! And it
will likely still look like something from the 1990s (not quite the 80s
someone mentioned).

I've implemented a canvas.

The interface I've provided is simply getrgba, which returns a buffer, and
a flush, which draws the image to the screen.
I know Open GL can be targetted to write to a memory buffer. But I don't know
if this puts it into a slow software rasterising mode. Whilst the interface
effectively decouples Baby X from any graphics primitives, it's not
as efficient as it looks. The image is held in a rgba buffer whilst being
composed. Then it needs another buffer in X format, with which to respond
to redraw requests. Then the X server probably buffers the window pixmap.
Finally there's video memory itself. So tons of buffering going on.

However it's certainly OK for small images, like icons.

I've got most of the low-level widgets working. I've got a file open dialogue,
a scroll bar, a line editor, a menu bar and so on. They don't look nice, but
the functionality is there. The hard part now is to decide what to do for
the container system.

 

[Siri Cruise]

if this puts it into a slow software rasterising mode. Whilst the interface
effectively decouples Baby X from any graphics primitives, it's not
as efficient as it looks. The image is held in a rgba buffer whilst being

It means you can make a reference implementation with the defined interface and
then provide an alternate, faster implementation hidden in the library.

 

[Phil Carmody]

On 07/25/2013 03:22 PM, Fred K wrote:
...

a) get a proper news reader. Mozilla Thunderbird is my personal
favorite, available for a wide variety of platforms, and is free.

b) sign up for access to a proper news server. I use Eternal
September,<http://www.eternal-september.org>, which seems to provide
good coverage, decent spam filtering, and is also free.

c) configure your news reader to connect to your news server.

You now have something that almost certainly works much better than
Google Groups. It's hard, but feasible, to serve news more poorly than
Google Groups does.

[OT] Apart from its archive Google Groups has one big advantage over your
solution: it can be accessed from any PC with a web browser. So a user can
access the same account from work, from any PC at home and from an internet
cafe or friend's house while travelling, all with the same client settings
(as the Usenet client is the Google service). No one else I have found
offers the same for free.

All news servers. Via the mechanism of SSH and screen.

Phil

 

[blmblm]

On 07/25/2013 03:22 PM, Fred K wrote:
...
Arrgh! Hate GOOGLE GROPUPS.

a) get a proper news reader. Mozilla Thunderbird is my personal
favorite, available for a wide variety of platforms, and is free.

b) sign up for access to a proper news server. I use Eternal
September,<http://www.eternal-september.org>, which seems to provide
good coverage, decent spam filtering, and is also free.

c) configure your news reader to connect to your news server.

You now have something that almost certainly works much better than
Google Groups. It's hard, but feasible, to serve news more poorly than
Google Groups does.

[OT] Apart from its archive Google Groups has one big advantage over your
solution: it can be accessed from any PC with a web browser. So a user can
access the same account from work, from any PC at home and from an internet
cafe or friend's house while travelling, all with the same client settings
(as the Usenet client is the Google service). No one else I have found
offers the same for free.

All news servers. Via the mechanism of SSH and screen.

Um, doesn't that presuppose the existence of a suitable target for the
SSH? (I'm thinking shell account on a suitable system, but maybe there
are other possibilities.)