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.