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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)