[fpc-pascal]Re: working with bitmaps

[Marco van de Voort]

> On Mon, 20 Oct 2003, Marco van de Voort wrote:
> | > a.) this new FPC classes (again) will not use this libraries but do all
> | >     this data fiddleing together by themselves. :-/
> | > b.) be therefore much more unstable because the self-knitted code has to
> | >     be tested again, what is already finished with this C libraries.
> |      (headers also need testing)
> |
> |   c.) keeps the dependancies down.
> 
> Possibly you are right.  But it helps nothing when dependences are kept such
> low that there exists only some trivial sub-sets but nothing useful. Wouldn't
> it be better to supply something basic which is working in poorest
> environments before doing something high sophisticated?

We usually depend on extern initiatives. We can only choose to integrate it
with the core distro, or refer to the contributed units page.

> | We only have the tool that was used for the windows unit translation.
> 
> Wrong OS. I only develop for Linux.

I for FreeBSD. Problem is that Unix headers are dirtier than Microsoft
headers, they use more macro's, and an awfully large amount of conditional
code. Michael succeed in a libc translation recently.

> | > Mostly required will be those functions which reading/writing images
> | > from/to files and putting them somewhere unpacked into memory for further
> | > manipulation, but even this is not really available.
> |
> | There is pasjpg, there is a libpng header, some bmp fiddling.
> 
> Great.  'pasjpg' does not even compile on Linux. And as you already said:
> There is some **fiddleing**, but nothing of it is really useful. Some
> strength should be made here to build/extend the graphics unit (or add
> another unit, let's say "imagefile", which should allow and supply a
> standardized set of procedures/functions for both: Windoze and Linux.
> Nothing in OOP/CLASS style, only very basic functions which can also be
> used/embedded later within/into Delphi style classes, but they must work
> procedural, too.

When you've  made this, please add it to the contributed units page, and maintain
it. Preferably support multiple OSes.

The core team is chronically short on manpower, and has no time for an
active role in this kind of sideways related stuff if we want to release 2.0
this decade.

> TIFF, ... in all flavours. I am sure they are not supported directly, because
> there are so many minor variations and therefore it is very complicated. So
> why not offer interfaces which act as wrappers to standard libjpeg.so
> libtiff.so, .... instead?

We didn't get them submitted. 

> Most C programs interface with these libraries, so they should be
> relatively standard. Isn't it? So it would save a lot of work when a
> wrapper is made, instead of re-inventing not the wheel, but the complete
> car.
 
The "reinventing the wheel" phrase is the most overused phrase in IT, please
don't fall for that trap. 

In the real world, taking a new part is easier than fixing the old. Why would
it be different in IT ? :-)
 
> I decided to develop in Pascal at CP/M times, because this gave me the
> possibility to write programs without any need to do low-level things. At DOS
> this continued and allowed simple graphics, too. The logical next step would
> be that the same should be available on Linux, too, and there FPC is my
> "TurboPascal for Linux".

It is. There are some things lacking (personally I would like to see the
textmode IDE get a new maintainer and see it make fundamental progress), but
all are manpower related.

It is not that we don't know these things. However we have to make choices,
and that means that some things will end up at the bottom line of a A0 format
to-do list. We make these choices based on 7 years day-in day-out experience
with the project AND our own needs.

> Some years ago I had the hope that FPC would become a 100% replacement for
> TP/BP for DOS/LINUX/..., where I could do basically the same on every
> platform without any code modification. But I still see that Linux is not very
> well supported in some parts, especially graphics.

Like everywhere, most users (and so contributions) focus on the GUI. 
Lazarus is quite far on *nix. 

> Why is there still no graph-unit available which does the same as TP.GRAPH
> /DOS? 

A combination of being not directly needed for the core system and not getting
external submissions. 

> Is it really such complicated to make some code into the graph unit which
> opens one X11-Window and paints there as a DOS program paints on a VGA
> screen?

I don't know, but I think using a widget set (GTK) would be easier. Trying
it yourself is the easiest way of answering this.

> I hear the answers in advance: This will not be satisfying, this
> is causing dependices, ... -- Ok, but X11 is a standard on any graphical
> Unix.

Yes, but "graph" is a console program. OTOH win32 also uses the GUI
subsystem for graph. So I guess the lack of submissions remains
as cause again.

> And there is still some option to possibly allow to choose between using
> X11 and some kind of svgalib for direct access to the graphics card. 

There is no problem if we had a unit as you described. I don't have 
a fundamental grudge about a X11 dependancy. 

Except maybe that I'd reserve the "unit graph" unitname for the most
compatible and generic one. But there is no such choise to make since
we don't have multiple TP compatible Linux graph units. 

> I do not want to start now with low-level things to be able to do simplest
> things which were absolutely no problem with TP/BP. It is hard enough to
> accept that even the graph unit is not existing to me, because it does not
> work on Linux, and I see that FPC goes more and more into a direction which
> does not make life very easy.

The problem is that FPC is mainly driven by a couple core developpers, and
an crowd of 10-30 people that regularly submit bugs, units and/or made and
maintain FPC packages on the contributed units page. (which I always call
the "outer core" by myself). And of course there is lazarus.

We don't have fulltime employees like some linux distributions and projects,
and no thousands of submitters like the larger volunteer driven Open Source
projects. This is not a FPC problem. All middlesize projects suffer from
this. (too little people with long term commitments)

The core's  schedule is pretty full, they are all volunteers, so they work
on what they need themselves, or what they see as really hard needed
improvements. If you want to see what happened to the core system after 1.0,
see http://www.freepascal.org/future.html

For the rest we rely on external submissions, which are
(except from that wellknown longterm bug and code submitting "outer core",
most of which are regulars on this list) low to very low.

If you want change, a constructive way would be to create it and submit it.