GD2-specific functions should be moved to image.gd2.inc [#19611]

The new image handling tools in core have a lot of GD2-specific logic, making image.inc overly cluttered and complicated. If gd2 were just treated like another toolkit (though the only one included by default), then the image.inc code would be much cleaner and more easily maintained.

This patch removes all the GD2 stuff from image.inc and puts it into image.gd2.inc. The _settings hook is now doing what it sounds like it should, return settings for the toolkit. I've added a _check hook which will tell if the PHP functions needed are available. If _check fails, then the toolkit will not be listed on admin > settings and an error will be logged in watchdog.

I've also update image.gd1.inc, image.imlib.inc, and image.imagick.inc with the same logic.

Comment	File	Size	Author
#12	system-image_0.patch	6.82 KB	junyor
#4	image.imlib.inc	2.07 KB	junyor
#3	image.imagick.inc	2.19 KB	junyor
#2	image.gd1_0.inc	1.8 KB	junyor
#1	image.gd2.inc	3.07 KB	junyor
	system-image.patch	6.8 KB	junyor

Comments

Comment #1

junyor commented 28 March 2005 at 22:08

Status	File	Size
new	image.gd2.inc	3.07 KB

Comment #2

junyor commented 28 March 2005 at 22:09

Status	File	Size
new	image.gd1_0.inc	1.8 KB

Comment #3

junyor commented 28 March 2005 at 22:09

Status	File	Size
new	image.imagick.inc	2.19 KB

Comment #4

junyor commented 28 March 2005 at 22:10

Status	File	Size
new	image.imlib.inc	2.07 KB

Comment #5

gordon commented 28 March 2005 at 23:44

I am not too sure if the gd tool kit should be split into 2 tool kits. Now I am only speaking from a debian pov, but the php4-gd package is linked against gd2. Also from a Drupal POV, the difference between gd1 and gd2 are so minor that having them as they have always been, as effectively 1 tool kit has alway made sence from a maintenance POV.

Also the standard php extension is just called gd.

-1 on dividing gd1 and gd2 into separate tool kits.

Comment #6

junyor commented 28 March 2005 at 23:51

@Gordon: They already are separate toolkits. There's *no* GD 1 processing in core at all. This patch separates all the GD 2 specific functions from the general toolkit handling functions. The GD 1 toolkit attached here was provided by Stefan.

Comment #7

gordon commented 29 March 2005 at 00:22

You have missed what I am saying. In php there is no gd1 or gd2, where is just gd. which libary you use all depends on which one you link the gd extension against.

So in the case of core, I think it was a bad move to remove all the gd1 code as it means that we require the gd module to linked against gd2 and will not work if it is not linked against gd1.

Comment #8

walkah commented 29 March 2005 at 01:57

Junyor : the gd support that is "bundled" with image.inc is meant only as a minimal "typical case" support for gd2 - so that image.inc will work out of the box in most installations (keep in mind that gd2 has been bundled with php 4.3 and that drupal 4.6 will require 4.3.3+).

extra / additional toolkits are on an as-needed basis, and have already begun development - including a "gd2 advanced" that will make additional options available.

the current behaviour, however, is very much by design (in fact, it was originally separated in my sandbox).

Comment #9

junyor commented 29 March 2005 at 08:36

@Gordon: image.inc specifically checks to make sure GD 2 is installed. It does not work with GD 1 as is. That's why Stefan had to make a separate GD 1 toolkit.

@Walkah: GD 2 can still work out of the box with my design. We'd include image.inc and image.gd2.inc in the Drupal bundle, with the other toolkits available elsewhere. This change makes image.inc more future-proof, cleaner, and smaller. I don't see why that's a bad thing. In other words, this may be by design, but I think it's a bad design.

Comment #10

chx commented 29 March 2005 at 08:42

junyor, yesterday night Steven has fixed a very irritating bug in image module (variable_get...'gd2') so your system-image.patch won't apply. Please reroll.

Comment #11

Stefan Nagtegaal commented 29 March 2005 at 08:52

I tend to agree here..
We should separate api and code as much as possible, the same as text and markup.
Imo this is a +1 from me, though I did not (yet) test this patch nor took a look at the coding styles...

Comment #12

junyor commented 29 March 2005 at 10:22

Status	File	Size
new	system-image_0.patch	6.82 KB

Synched with HEAD.

Comment #13

walkah commented 29 March 2005 at 21:19

well, i'll give Dries final word on this (as he has final say anyway) ... but it was also his idea to keep a "works for most cases" implementation in a single file.

i like the _check idea, though what do usability guys say about not showing them? wouldn't it be more helpful to have them appear, but disabled with a message as to why they don't work?

originally, the _settings was intended to do this kind of stuff in the form of form_set_error() -- and only for the selected toolkit (i.e. if you have other toolkits that are installed but don't work - who cares?).

Comment #14

junyor commented 29 March 2005 at 22:14

I thought about having the radio buttons visible, but disabled, though I couldn't figure out how to selectively disable the radio buttons. The current implementation shows an error after selecting a toolkit that won't work. I'd rather not show it at all (and show an error in the logs).