Baby X - new project

[Malcolm McLean]

I've got some time, so I decided to dust off Baby X, a project I worked on a few years back.
Baby X is a "baby" X windows toolkit. It's designed to offer all the
usual features - menus, buttons, popups, scrollbars, edit boxes and the
like, but implemented in a way that is simple - simple to use, simple to
compile, simple to hack into to rewrite or extend. Of course that means pure
C bindings, no C++ class hierarchies, compiler front ends, etc. Just drop the
files into your source directory and type gcc *.c -lX11, and you have all
the functionality.
Given the basic concept of a "baby" toolkit, what design principles would
people like to see?

 

[Johann Klammer]

I've got some time, so I decided to dust off Baby X, a project I worked on a few years back.
Baby X is a "baby" X windows toolkit. It's designed to offer all the
usual features - menus, buttons, popups, scrollbars, edit boxes and the
like, but implemented in a way that is simple - simple to use, simple to
compile, simple to hack into to rewrite or extend. Of course that means pure
C bindings, no C++ class hierarchies, compiler front ends, etc. Just drop the
files into your source directory and type gcc *.c -lX11, and you have all
the functionality.

Is that not pretty much what Xaw does?

 

[Malcolm McLean]

Is that not pretty much what Xaw does?

With something like a toolkit there'll be competitors. But Xaw grabs the main
event loop, for example, which means that it's hard to mix and match with
other code. Baby X won't do this.

 

[Jens Stuckelberger]

I've got some time, so I decided to dust off Baby X, a project I worked
on a few years back.

Back to the 80s then.

 

[Fred K]

Neither Xaw or Motif grabs the main event loop. Your application does that by calling XtAppMainLoop().

You do have to do that - youy can process the events yourself:

XEvent event;

for (; {
XtAppNextEvent(app, &event);
/* do whatever you want with the event here */
}

 

[Fred K]

Arrgh! Hate GOOGLE GROPUPS.
That was supposed to say "You do not have to do that."

 

[James Kuyper]

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.

 

[James Harris \(es\)]

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.

For that reason I stuck with Google Groups for a long time until recently.
Unfortunately their new interface is abysmal and it finally pushed me over
the edge(!) I've long had an Eternal September account for reading Usenet.
Now I use it for posting too and have just to accept the fact that the
newsreader client software is present on just one PC. I still miss the
webability of Google but, for now, between the two evils this seems the
lesser of the two.

James

 

[Keith Thompson]

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.

For that reason I stuck with Google Groups for a long time until recently.
Unfortunately their new interface is abysmal and it finally pushed me over
the edge(!) I've long had an Eternal September account for reading Usenet.
Now I use it for posting too and have just to accept the fact that the
newsreader client software is present on just one PC. I still miss the
webability of Google but, for now, between the two evils this seems the
lesser of the two.

I use Gnus (which runs under Emacs) under a "screen" session. I can ssh
into the system where I'm running it from anywhere (as long as an ssh
client is available) and reconnect to my screen session.

There are other text-based newsreaders out there if you don't like Emacs
or Gnus, and tmux is a popular alternative to screen.

 

[BartC]

I've got some time, so I decided to dust off Baby X, a project I worked on
a few years back.
Baby X is a "baby" X windows toolkit.
....
Given the basic concept of a "baby" toolkit, what design principles would
people like to see?

I know nothing about X (but there's a possibility I will need to use it in
the near future)

What exactly does a toolkit for X do, and why would you need a baby one?
What's wrong with talking to X directly? (Assuming a toolkit is something
that might sit between your application, and X. If not, then my
understanding is even less than I thought...)

 

[Malcolm McLean]

I know nothing about X (but there's a possibility I will need to use it in
the near future)

What exactly does a toolkit for X do, and why would you need a baby one?
What's wrong with talking to X directly? (Assuming a toolkit is something
that might sit between your application, and X. If not, then my
understanding is even less than I thought...)

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.
There are problems with all toolkits. Qt is a nice, professionally developed
one. But it's written in C++, and the designers decided that even C++ didn't
provide all the functionality they needed. So they wrote a front end to
C++, and all source files that call Qt functions have to be passed through
that front end. It means that no-one can compile a Qt program unless he
has the Qt tools installed.
Baby X is a "baby" toolkit. It doesn't do anything fancy, just puts up
widgets in response to normal C calls. It;s going to be provided as source
files rather than a library. So you can drop the Baby X files into your
project directory, and the whole thing should compile with gcc *.c -lX11
It's swings and roundabouts. Qt couldn't do the same and still provide the
signal/slot mechanism.

 

[James Kuyper]

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 ...

I have to agree with you about that. Google Groups is an awful way to
search for old usenet messages, but it's far better than any
alternatives that I'm aware of. "awful" and "far better" is a very
annoying combination.

... Google Groups has one big advantage over your
solution: it can be accessed from any PC with a web browser. ...

I don't think there's many PCs with web browsers that Mozilla
Thunderbird couldn't be installed on - except by reason of company
policies that prohibit it.

... 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.

It would be nice to keep my settings synchronized between Thunderbird
sessions running on multiple different systems. Mozilla FireFox allows
that with bookmarks and browsing history, which I've found very
convenient. I wonder when they'll get around to implementing such a
feature for Thunderbird.

However, the single thing I'd most like to synchronize is the list of
newsgroup messages that I've already viewed with Thunderbird. As far as
I know, Google Groups doesn't even keep track of that, much less let me
synchronize it across multiple systems.

 

[Lew Pitcher]

I know nothing about X (but there's a possibility I will need to use it in
the near future)

What exactly does a toolkit for X do, and why would you need a baby one?
What's wrong with talking to X directly? (Assuming a toolkit is something
that might sit between your application, and X. If not, then my
understanding is even less than I thought...)

X11's API is quite primitive; it really only provides the ability to define
and fill drawing areas (called "windows"), and to read information from
mouse and keyboard. Writing GUI programs with this protocol would be a real
headache.

Various "toolkits" (including Xlib, for one) provide APIs that consolidate
window definition and drawing functions into specialized calls, so that the
programmer can code simple calls to draw a "button" or a "text box" or
a "menu", rather than the complex X11 protocol calls that make up these
things.

Other toolkits (like QT or GTK++) abstract the drawing functions even
further, giving the programmer less control over the resulting graphics,
and more control over the abstract entities ("checkboxes", "radio
buttons", "backgrounds", "borders", "handles", etc) that the GUI
application may use

It sounds like Malcolm has written something on the level of Xlib rather
than something on the level of GTK++

 

[James Kuyper]

I know nothing about X (but there's a possibility I will need to use it in
the near future)

What exactly does a toolkit for X do, and why would you need a baby one?
What's wrong with talking to X directly? (Assuming a toolkit is something
that might sit between your application, and X. If not, then my
understanding is even less than I thought...)

He covered that, though not in detail, in his original message. He wants
something that's simpler to use than the alternatives he's familiar
with. In order to convert that into a solid design, he's going to have
to convert the vague term "simple" into a precise list of the
complexities he wants to avoid. Every complexity in the normal methods
of using X corresponds to one or more obscure features of X; to keep his
toolkit simple, he's going to have to leave corresponding features of X
unsupported. He won't be able to make much progress until he's
identified which ones he's willing to drop.

 

[James Harris \(es\)]

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 ...

I have to agree with you about that. Google Groups is an awful way to
search for old usenet messages, but it's far better than any
alternatives that I'm aware of. "awful" and "far better" is a very
annoying combination.

Yes, and while many Usenet providers retain posts going back weeks or months
Google have a truly great archive going back many years (having bought out
Deja News, IIRC).

One thing I did notice before switching to a more conventional system is
that the new Google interface seemed to allow replies to older posts than
they did previously. That could be handy in some cases.

....

However, the single thing I'd most like to synchronize is the list of
newsgroup messages that I've already viewed with Thunderbird. As far as
I know, Google Groups doesn't even keep track of that, much less let me
synchronize it across multiple systems.

Agreed. That would be a big help. The old GG interface 'cauught up' a group
if it was viewed. The new one, IIRC, does that at the thread level - i.e. if
you read one message in a thread it will mark the thread as read. In that
sense it's better than the old one but that doesn't begin to compensate for
the other losses. And it still doesn't allow marking as read individual
messages.

James

 

[Melzzzzz]

There are problems with all toolkits. Qt is a nice, professionally
developed one. But it's written in C++, and the designers decided that
even C++ didn't provide all the functionality they needed. So they wrote
a front end to C++, and all source files that call Qt functions have to
be passed through that front end. It means that no-one can compile a Qt
program unless he has the Qt tools installed.

Not really true. I have written project that didn't use signal/slot
mechanism that qt provides, rather override function that provides
a way to implement own event handling mechanism.
In order to compile one don't need qt tools because qt use
macros.

Baby X is a "baby" toolkit. It doesn't do anything fancy, just puts up
widgets in response to normal C calls. It;s going to be provided as
source files rather than a library. So you can drop the Baby X files
into your project directory, and the whole thing should compile with gcc
*.c -lX11 It's swings and roundabouts. Qt couldn't do the same and still
provide the signal/slot mechanism.

I would be interrested in your project as I like to write assembler and
gtk is pain to use with assembler (heavy usage of macros).
Any c++ toolkit is useless with assembler client program.

 

[Fred K]

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 accessto a proper news server. I use Eternal September,<http://www.eternal-september.org>, which seems to provide good coverage, decent spam filtering, andis 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.

Unfortunately I do this fromwork,and my employer does not allow
downloads to company computers, even i9f they are free.

 

[Les Cargill]

Unfortunately I do this fromwork,and my employer does not allow
downloads to company computers, even i9f they are free.

Then your employer knows what they want, and deserves to get it good and
hard*.

*paraphrasing Mencken.


Iron Mountain provides escrow services; that may be able to be
used to "launder" the open-sourceness of things. I don't know if it
will work in your case or not.

 

[Siri Cruise]

I've got some time, so I decided to dust off Baby X, a project I worked on a
few years back.
Baby X is a "baby" X windows toolkit. It's designed to offer all the
usual features - menus, buttons, popups, scrollbars, edit boxes and the
like, but implemented in a way that is simple - simple to use, simple to
compile, simple to hack into to rewrite or extend. Of course that means pure
C bindings, no C++ class hierarchies, compiler front ends, etc. Just drop the
files into your source directory and type gcc *.c -lX11, and you have all
the functionality.
Given the basic concept of a "baby" toolkit, what design principles would
people like to see?

A window manager is a widget that can write to the entire screen and receives
events from the operating system.

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.

 

[Jens Thoms Toerring]

Baby X is a "baby" toolkit. It doesn't do anything fancy, just puts up
widgets in response to normal C calls. It;s going to be provided as source
files rather than a library. So you can drop the Baby X files into your
project directory, and the whole thing should compile with gcc *.c -lX11
It's swings and roundabouts. Qt couldn't do the same and still provide the
signal/slot mechanism.

According to what you wrote, especially in combination with

But Xaw grabs the main
event loop, for example, which means that it's hard to mix and match with
other code. Baby X won't do this.

it sounds as if your "Baby X" will only do the drawing of the
widgets. As far as I can see without "grabbing" the event queue
it won't be able to react reliably to e.g. mouse clicks on but-
tons etc. So it would seem that the user will have to deal with
the pletora of events all by him/herself. I guess that could be
a show-stopper for most people since you then need to under-
stand the Xlib in all the gory details. Or am I missing some-
thing?

BTW, feel free to have a look at XForms (the X toolkit, not
the XML XForms format stuff, they stole the name - it's a
relatively simple toolkit in C only, not a "baby" but more
of a "teenager" in comparison to e.g. Qt Don't expect too
much - while I am the current maintainer there are lots of
things I'm not happy with (and, since it's such an old toolkit,
are hard to change without breaking too many applications).

Regards, Jens