I succeed to compile pasjpeg with -dWindows compiler option in Linux and few changes in sources :)
Pavel Kanzelsberger On Mon, 2003-10-20 at 12:12, Marco van de Voort wrote: > > 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. > > > _______________________________________________ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Secundum Artem - www.pixel32.sk E-Mail: [EMAIL PROTECTED] Phone: +421-905-462611 ICQ: 20990633 _______________________________________________ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
