Regs will be familiar with the Baby X resource compiler.
For anyone who is new, Baby X is cross platform GUI / widget set for
Windows and Linux designed for small programs, and the Bayy X resource
compiler packages fonts, audio, text and images into C source so they
can be incorporated into Baby X programs.

However the resource compiler gets more downloads than Baby X itself.
Now the problem with putting things on github is that whilst people will
download the program, they will very seldom get back to you to tell you
what their experience was. So you don't know if it was useful or what it
was used for. But probably people are using it to convert images to C
for non-Baby X programs.

Now Baby X treats all raster images as 32 bit rgbas. There are no other
formats. So the output function is extremely simple. Given 32 bit
binary, just dump as 32 bit C rgba. But if peop;le are using it for
non-Baby X, they may require other formats, like 16 bit images.

So the first question is, is it worth doing? It's the Baby X resource
compiler. Currently there is nothing in the program which is not
intended for use with Baby X. It cannot be all things to all men. Should
I add something which is explictly designed to support non-Baby X
programmers?

The second question is, if I am going to support mre than 32 bit rgba
output, were should I stop? It's pretty clear that the C needs to be
arbitrary. But should I be content with just specifying a 32 bit rgba
value in a slightly different format? Or do I need to supprt conversion
to different colour spaces? Or imterleaved data? Or indexed paletted
images? The problem of reducing a 24 bit rgb image to a paletted image
is te sort of problem that interest me so I am motivated to add this to
the program. But it entails major restructuring. Some of the source
images will already be paletted. Currently they are just converted to 32
bit rgba and passed through. That would need to change. But is there
actually any demand?

So how to approach this? Is it worth doing at all? And how best to
specify the function which converts an image to C source, so that the
user can enter it easily but it remains flexible?

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2024-02-13, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> However the resource compiler gets more downloads than Baby X itself.

Do you know how much of that is humans versus web-scraping robots?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 13/02/2024 23:45, Kaz Kylheku wrote:
> On 2024-02-13, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> However the resource compiler gets more downloads than Baby X itself.
>
> Do you know how much of that is humans versus web-scraping robots?
>
No. It's not broken down. You get a wave of downloads in response to an
update, which must be bots. But otherwise it's hard to tell if a
download is genuine or a bot, and bots will flatter the statistics a
bit. However the projects I would subjectively say are better do get
more downloads, so it's unlikely that everything is bots.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>Regs will be familiar with the Baby X resource compiler.

With the name, perhaps.

>
>Now Baby X treats all raster images as 32 bit rgbas. There are no other
>formats. So the output function is extremely simple. Given 32 bit
>binary, just dump as 32 bit C rgba. But if peop;le are using it for
>non-Baby X, they may require other formats, like 16 bit images.

And again, the answer is netpbm. Don't try to build everything
into a single application - netpbm can convert any image format
to any other image format.

On 14/02/2024 16:05, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> Regs will be familiar with the Baby X resource compiler.
>
> With the name, perhaps.
>
>
>>
>> Now Baby X treats all raster images as 32 bit rgbas. There are no other
>> formats. So the output function is extremely simple. Given 32 bit
>> binary, just dump as 32 bit C rgba. But if peop;le are using it for
>> non-Baby X, they may require other formats, like 16 bit images.
>
> And again, the answer is netpbm. Don't try to build everything
> into a single application - netpbm can convert any image format
> to any other image format.
>
A resource compiler is a recognised type of program that takes usually
binary data and packages it into an executable so that it can be passed
to functions. It's generally provided as single standalone program. The
Baby X resource compiler works in the same way. However because I can't
easily modify the executable to add the data, it converts the data to C
source. Formally C source files. But actually just big arrays and other
data structures described in C.

netpbm would support the use of more image file formats. But you'd have
to ship a lot of programs. And most of those formats are little used.
And the entire system would only deal with one type of data the Baby X
resource compiler handles, though admittedly the most important.

It's not the answer. Though the program ppmtoargbtxt does contain a
pixel vaue to text converter which is capable of outputting C source and
customising it. Which provoked my original post. And many thanks for
bringing it to my attention. However the program itself seems pretty
trivial and it would be easy to copy the specification format and
incorporate it into the resource compiler, which seems a better way of
proceeding than abandoning the resource compiler and trying to set
something up with netpbm and pipelines to achieve the same thing.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 14/02/2024 16:05, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> Regs will be familiar with the Baby X resource compiler.
>>
>> With the name, perhaps.
>>
>>

>netpbm would support the use of more image file formats. But you'd have
>to ship a lot of programs. And most of those formats are little used.
>And the entire system would only deal with one type of data the Baby X
>resource compiler handles, though admittedly the most important.

All babyX needs to do is link with the libpbm dll. Those programs
are just wrappers around the library for use from the command line.

On 14/02/2024 19:22, Malcolm McLean wrote:
> On 14/02/2024 16:05, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> Regs will be familiar with the Baby X resource compiler.
>>
>> With the name, perhaps.
>>
>>
>>>
>>> Now Baby X treats all raster images as 32 bit rgbas. There are no other
>>> formats. So the output function is extremely simple. Given 32 bit
>>> binary, just dump as 32 bit C rgba. But if peop;le are using it for
>>> non-Baby X, they may require other formats, like 16 bit images.
>>
>> And again, the answer is netpbm.  Don't try to build everything
>> into a single application - netpbm can convert any image format
>> to any other image format.
>>
> A resource compiler is a recognised type of program that takes usually
> binary data and packages it into an executable so that it can be passed
> to functions.

A resource compiler might do that. Or it might take text data and put
it into binary form. It might produce a binary data file, text files in
some format, an object file ready for linking, C source ready to be
compiled, lots of files, a single file, a zip of lots of files, or all
kinds of other things. I don't think there is any specific pattern.
About the one thing I normally would /not/ expect is for the output to
be executable code.

> It's generally provided as single standalone program.

That is completely and utterly arbitrary.

> The
> Baby X resource compiler works in the same way. However because I can't
> easily modify the executable to add the data, it converts the data to C
> source. Formally C source files. But actually just big arrays and other
> data structures described in C.

That's fine.

>
> netpbm would support the use of more image file formats. But you'd have
> to ship a lot of programs. And most of those formats are little used.

Yes. So? Lots of developers already have netpbm programs - or at least
have them easily available. You don't have to ship them - you just have
to list them as a requirement for using the program - just like you
might say you require a particular OS version, or particular dotnet
libraries, or whatever. It can be /convenient/ to have fewer
requirements, but it is certainly not a show-stopper.

Personally I would not recommend netpbm for this task. It is rather
old-fashioned and not particularly Windows-friendly.

Two obvious choices are imagemagick for stand-alone image conversion
utilities, and Python PIL. Your entire resource compiler could probably
have been written in a couple of hundred lines of Python, with the
dependencies being simply and easily installed on any reasonable
development computer. People could then run the resource compiler
whether they use Windows, Linux, a Raspberry Pi, or whatever they like.

I do all my resource compiling for my systems using Python scripts -
some general, some application-specific.

On 14/02/2024 19:44, David Brown wrote:
> On 14/02/2024 19:22, Malcolm McLean wrote:
>>
>> It's generally provided as single standalone program.
>
> That is completely and utterly arbitrary.
>
For most resource compilers, yes. It comes packaged with the IDE and so
ships with a suite of related programs, so if it ran one of those it
would scarely matter. However in fact resource compilers rarely do so
and are single, self-contained programs which can be run independently,
and the Baby X resource compiler therefore has the conventional design.
For Baby X, this does matter, because Baby X has no dedicated IDE.
>
>>
>> netpbm would support the use of more image file formats. But you'd
>> have to ship a lot of programs. And most of those formats are little
>> used.
>
> Yes.  So?  Lots of developers already have netpbm programs - or at least
> have them easily available.  You don't have to ship them - you just have
> to list them as a requirement for using the program - just like you
> might say you require a particular OS version, or particular dotnet
> libraries, or whatever.  It can be /convenient/ to have fewer
> requirements, but it is certainly not a show-stopper.
>
It's not a show stopper. But it starts to dilute the point. Baby X is a
baby GUI system. Everything is meant to be easy. And babies don't have
dependents. The user is not meant to fiddle about with specific versions
of libraries. I have to link to xlib on Linux. But I tried to add audio
to Baby X on Linux and this was one of the serious problems. You just
can't get hold of an audio library which is guaranteed to be there and
will allow you to submit stereo ppm samples to standard speaker. >
> Personally I would not recommend netpbm for this task.  It is rather
> old-fashioned and not particularly Windows-friendly.
>
> Two obvious choices are imagemagick for stand-alone image conversion
> utilities, and Python PIL.  Your entire resource compiler could probably
> have been written in a couple of hundred lines of Python, with the
> dependencies being simply and easily installed on any reasonable
> development computer.  People could then run the resource compiler
> whether they use Windows, Linux, a Raspberry Pi, or whatever they like.
>
The vast majority of the code is not specific to the resource compiler
and is highly resusable loaders or parsers for common file formats. And
Python went from Python 2 to Python 3 in 2008. So it broke. But the
Baby X resource compiler won't break because it is written in a
conservative subset of C which is stable. And it has no dependencies
other than the standard library. Everything you need is there, and can't
need an update. It will work for as long as C is available as a
development language.
>
> I do all my resource compiling for my systems using Python scripts -
> some general, some application-specific.
>
Sure. But your job is to write the program, so you can set up the Python
scripts and customise them, and it's all part of what you do. But my
users just write one xml script. They're not going to be writing Baby X
programs for their job, but to get a short program which needs graphics
up and running quickly, and then to be able to move it between Linux and
Windows. And yes, writing the Baby X resource compiler is rather an
extravagant way to save a few minutes, when they could write a Python
script to get binaries into the executable. But making it just that bit
easier makes all the difference.

However Baby X is bit much to chew, and in fact I don't know what people
are using the resource compiler for. Whilst Baby X is usable, it needs
someone to choose the fonts and polish the widgets and make it look
nice, and I don't have those skills. So most of the resource compiler
downloaders are either using it for something else, or they just want to
mine it for source. Which I specifically invited them to do, so I can't
complain. Or maybe they are just bots.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 14/02/2024 22:26, Malcolm McLean wrote:
> On 14/02/2024 19:44, David Brown wrote:
>> On 14/02/2024 19:22, Malcolm McLean wrote:
>>>
>>> It's generally provided as single standalone program.
>>
>> That is completely and utterly arbitrary.
>>
> For most resource compilers, yes. It comes packaged with the IDE and so
> ships with a suite of related programs, so if it ran one of those it
> would scarely matter. However in fact resource compilers rarely do so
> and are single, self-contained programs which can be run independently,
> and the Baby X resource compiler therefore has the conventional design.
> For Baby X, this does matter, because Baby X has no dedicated IDE.

You are just making stuff up - pulling "definitions" and "conventions"
out of thin air.

I realise you want your "resource compiler" to be a single stand-alone
program. Okay, that's your choice and your preference. But stop
pretending it is something "general" or "conventional".

For the most part, people want tools that do what they need them to do,
and that work in a way that is convenient to them. They should be easy
to install, but that counts much less than being easy to use - you
install once, and use often. They might want there to be a clear way to
copy or back up the tools for archive purposes. Other than that, I do
not believe many people care at all whether programs are big, small,
self-contained, multi-filed, or what dependencies and requirements they
have as long as these are easy to fulfil.

>>
>>>
>>> netpbm would support the use of more image file formats. But you'd
>>> have to ship a lot of programs. And most of those formats are little
>>> used.
>>
>> Yes.  So?  Lots of developers already have netpbm programs - or at
>> least have them easily available.  You don't have to ship them - you
>> just have to list them as a requirement for using the program - just
>> like you might say you require a particular OS version, or particular
>> dotnet libraries, or whatever.  It can be /convenient/ to have fewer
>> requirements, but it is certainly not a show-stopper.
>>
> It's not a show stopper. But it starts to dilute the point. Baby X is a
> baby GUI system. Everything is meant to be easy.

And how many people did you say were actually /using/ Baby X ? If users
are interested in your "resource compiler", but not Baby X, then any
characteristics of Baby X itself are irrelevant to what people want in a
resource compiler.

Just so that I know what you are talking about here, can you provide a
brief summary of what your "resource compiler" actually does? I
understand that it converts some binary file formats into arrays in C
syntax. But is it just a binary to hex converter? Does it convert
formats in some way? Does it organise multiple source files in some
structure? What does it give users that they can't get from "xxd -i" ?

A /brief/ summary here - perhaps part of the output of "--help" - would
be useful, along with a link to the man page and documentation.

> And babies don't have
> dependents.

There is a difference between "dependents" and "dependencies". Babies
have a /lot/ of dependencies.

> The user is not meant to fiddle about with specific versions
> of libraries.

No one is asking them to.

> I have to link to xlib on Linux. But I tried to add audio
> to Baby X on Linux and this was one of the serious problems. You just
> can't get hold of an audio library which is guaranteed to be there and
> will allow you to submit stereo ppm samples to standard speaker.

>> Personally I would not recommend netpbm for this task.  It is rather
>> old-fashioned and not particularly Windows-friendly.
>>
>> Two obvious choices are imagemagick for stand-alone image conversion
>> utilities, and Python PIL.  Your entire resource compiler could
>> probably have been written in a couple of hundred lines of Python,
>> with the dependencies being simply and easily installed on any
>> reasonable development computer.  People could then run the resource
>> compiler whether they use Windows, Linux, a Raspberry Pi, or whatever
>> they like.
>>
> The vast majority of the code is not specific to the resource compiler
> and is highly resusable loaders or parsers for common file formats. And
> Python went from Python 2 to Python 3 in 2008. So it broke.

You can still use Python 2 today. And unless you are taking advantage
of new features, it's usually not /that/ hard to make code that runs the
same in Python 2 and Python 3. But I do agree that the jump from Python
2 to Python 3 can lead to compatibility issues and can definitely be an
inconvenience - while in comparison C places backwards compatibility far
higher in its priorities.

> But the Baby
> X resource compiler won't break because it is written in a conservative
> subset of C which is stable. And it has no dependencies other than the
> standard library. Everything you need is there, and can't need an
> update. It will work for as long as C is available as a development
> language.

That's all great - except it doesn't work for what people want, if it
doesn't support what they need. If people have images in other formats
and want these "compiled", they either have to ask you and wait 6 months
for you to write support in C, or they have to use external converter
tools anyway.

>
>> I do all my resource compiling for my systems using Python scripts -
>> some general, some application-specific.
>>
> Sure. But your job is to write the program, so you can set up the Python
> scripts and customise them, and it's all part of what you do. But my
> users just write one xml script.

You think there are developers and C programmers who would rather write
an xml script than a Python script? I have yet to meet such a person.

> They're not going to be writing Baby X
> programs for their job, but to get a short program which needs graphics
> up and running quickly, and then to be able to move it between Linux and
> Windows. And yes, writing the Baby X resource compiler is rather an
> extravagant way to save a few minutes, when they could write a Python
> script to get binaries into the executable. But making it just that bit
> easier makes all the difference.
>
> However Baby X is bit much to chew, and in fact I don't know what people
> are using the resource compiler for. Whilst Baby X is usable, it needs
> someone to choose the fonts and polish the widgets and make it look
> nice, and I don't have those skills. So most of the resource compiler
> downloaders are either using it for something else, or they just want to
> mine it for source. Which I specifically invited them to do, so I can't
> complain. Or maybe they are just bots.

On 15/02/2024 08:32, David Brown wrote:
> On 14/02/2024 22:26, Malcolm McLean wrote:
>>
> Just so that I know what you are talking about here, can you provide a
> brief summary of what your "resource compiler" actually does?  I
> understand that it converts some binary file formats into arrays in C
> syntax.  But is it just a binary to hex converter?  Does it convert
> formats in some way?  Does it organise multiple source files in some
> structure?  What does it give users that they can't get from "xxd -i" ?
>
> A /brief/ summary here - perhaps part of the output of "--help" - would
> be useful, along with a link to the man page and documentation.
>
It's hosted on github. The documentatiin is reasonable but of course not
up to commercial standards.

https://github.com/MalcolmMcLean/babyxrc

But fonts are a problem for a GUI toolkit like Baby X. So I decided to
rip fonts and embed them to make the Baby X font rasteriser easier to
write, and to avoid "font not present" errors. So I had to provide the
font ripper to the user to allow him to add his own fonts. it was
natural to add images and then audio, and that became the Baby X
resiurce compiler.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 14/02/24 00:29, Malcolm McLean wrote:
> Regs will be familiar with the Baby X resource compiler.
> For anyone who is new, Baby X is cross platform GUI / widget set for
> Windows and Linux designed for small programs, and the Bayy X resource
> compiler packages fonts, audio, text and images into C source so they
> can be incorporated into Baby X programs.
>
> However the resource compiler gets more downloads than Baby X itself.
> Now the problem with putting things on github is that whilst people will
> download the program, they will very seldom get back to you to tell you
> what their experience was. So you don't know if it was useful or what it
> was used for. But probably people are using it to convert images to C
> for non-Baby X programs.
>
> Now Baby X treats all raster images as 32 bit rgbas. There are no other
> formats. So the output function is extremely simple. Given 32 bit
> binary, just dump as 32 bit C rgba. But if peop;le are using it for
> non-Baby X, they may require other formats, like 16 bit images.
>
> So the first question is, is it worth doing? It's the Baby X resource
> compiler. Currently there is nothing in the program which is not
> intended for use with Baby X. It cannot be all things to all men. Should
> I add something which is explictly designed to support non-Baby X
> programmers?
>
> The second question is, if I am going to support mre than 32 bit rgba
> output, were should I stop? It's pretty clear that the C needs to be
> arbitrary. But should I be content with just specifying a 32 bit rgba
> value in a slightly different format? Or do I need to supprt conversion
> to different colour spaces? Or imterleaved data? Or indexed paletted
> images? The problem of reducing a 24 bit rgb image to a paletted image
> is te sort of problem that interest me so I am motivated to add this to
> the program. But it entails major restructuring. Some of the source
> images will already be paletted. Currently they are just converted to 32
> bit rgba and passed through. That would need to change. But is there
> actually any demand?
>
> So how to approach this? Is it worth doing at all? And how best to
> specify the function which converts an image to C source, so that the
> user can enter it easily but it remains flexible?
>

Chances are good that people using the Baby X Resource Compiler outside
of Baby X know it's a hack. If you want, you can provide them an image
compiler which doesn't have any relation to Baby X.

You don't have to make one program which is all things to all people.
Indeed, that is a path to overcomplication - it's the same thing that
often underpins the second system effect. There is elegance in striking
a balance between flexibility and simplicity (see: just about any Unix
program).

If you decide to have a program that handles 24-bit RGB images, it
probably makes sense for it to handle 16-bit RGB and 32-bit RGBA images.
Nobody uses 384-bit or 17-bit images, and very few people use 48-bit or
3-bit images. Unless you have a particular reason to support those, you
don't have to.

Paletted images are different from true-colour images. There is no
reason to assume that a tool which handles true-colour images should
also handle paletted images with palettes.

You might choose to make it convert paletted image data without
converting the palette, since the conversion works the same as for
true-colour image data. If you do this, someone will probably ask you to
make it also convert the palette. Or you might choose to make it not do
that, so that people will be directed to use a different tool to deal
with paletted images.

Likewise, images with (I think you mean) NON-interleaved data and
non-sRGB colour spaces are quite unusual in the arena of user
interfaces. I presume you only care about supporting user interface use
cases and not, say, medical radiography.

On Github, if someone wants a feature, they will usually tell you by
opening an issue. Even if the feature they want is something that really
shouldn't be in that piece of software. Even if they don't know how to
use the shift key to write capital letters.