Chat about image, image gallery modules, methods

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
aufumy's picture
Start: 
2008-06-30 11:00 - 12:00 Canada/Pacific
Organizers: 
Event type: 
Online meeting (eg. IRC meeting)

Started out as a push from couzinhub to create an Ajax powered image gallery module, an IRC chat was started on June 16th, and has turned into a chat on tools that may be used, as well as different methods for creating image galleries.

Not sure where it is headed, but if you have some ideas to share, join the recurring event on IRC, drupal-image on freenode at 11am PST Mondays.

http://www.timeanddate.com/worldclock/fixedtime.html?month=6&day=30&year...

Comments

Brian@brianpuccio.net's picture

Will there be talk regarding the proposed folding of Image into ImageField (which would then rely upon ImageCache for derivatives) or the proposal to scrap ImageField (and the various other speciality fields) in favor of a FileField (with helpers, such as FileField Image, as necessary)?

I won't be around at the time (work) but would love to see a transcript, if one is produced.

The discussions is on every

couzinhub's picture

The discussions is on every Monday morning (PST), so the subjects are different each time... It started as a discussion on how to create a good image galley module by using other existing modules, but as time goes, it is now more about what we could do to make images handled in a better way and help module maintainers. But I would really like to talk about that image/imagefield/filefield-image issue. It is starting to be a bit confusing, what is going to be the prefered way in the futur ??

The discussions are essentially focused on drupal 6

Lots of news in the last two weeks, with new modules coming along. One of the big topic was the multi upload for images, and as you probably saw already, a new module, Image FUpload, was released few days ago. It basically does most of the things we talked about, like using swfupload (not the module though, just the plug in) to upload several images at once, and generate nodes on the fly. A little downside IMHO, is that it uses the image module, and we are not sure yet of the future of this one...
I tried this module a bit, and combined with tagging and views, you can now create galleries extremely easily. By just adding a taxonomy to the image content type, and creating a views that lists terms, user can then upload several images that will be tagged with the same terms, and this term is then listed in a view, that redirect to the term view and list all the images with this term. Only downside, each image don't really have a relationship with each other, so there is now way to have a pager to go to the next image. A good point is by using multi-tagging, one image can be assigned to several galleries at once.
Also, you could use the image gallery module by default, but then the user cannot create new galleries easily

Also, combined with the multi-upload, using a module like the new Node 2 node module allow you to have relationship between nodes. So if I create a Gallery content type, I can define this gallery to be the parent of images, and then, when creating images (still with multi-upload), I can assign all the images to the gallery. The gallery will list all the related image nodes. I guess that with some node temlpate tweaking, it might be possible to load each image thumbnail... didn't try that yet.
But again, no previous/next link on images... it seams like this function is always the one missing in drupal galleries.. !

Maybe this new module will help ?

So even after trying all these.. I'm not entirely happy, even though I can see the light. I feel like we have all the tools to make something great, and all we need is to make them work together nicely.

Maintainer of Image FUpload

grandcat's picture

Hello =)

I'm the maintainer of the new Image FUpload Module. I read this comment above, and first, I'm very happy about that someone tried out this new module. It's right that I integrated it in image module because I thought that it is quite popular and has a future. It's right that there's no relationship between images, but this should be the task of image module, not mine. Nevertheless, it's true using this configuration, no pager can be set. but is it really necessary for the future because modules like "lightbox2" don't need neither a relation between images nor the image_gallery module to work. Overall, everything seems working with AJAX in future, so I think that it's enough that the images can be assigned to a vocabulary (taxonomy) to be grouped. Isn't it?
It would be very pleasant if somebody could give me an answer.
With my module being new, I can perhaps add also some features to work with "ImageField/ImageCache" or "FileField/FileField Image", but not both.
Yet another point is why I integrated in image module, is that the performance would be better if there were more and more images which have to be administered (more tables / requests by using CCK + ImageField instead of image module)??? Is that right, myself, I'm not really sure ;-)

Hi, thanks for the great

couzinhub's picture

Hi,
thanks for the great work. I see your point of view, and you're right, it's more the work of the image module than yours, as yours is only about uploading images. I wonder if we ever even added a feature request for image ? :)
Will you be able to join us on mondays ?

Chat at the evening

grandcat's picture

I'm sorry but 11 am in the morning is too early, I have no time left during this time span. If there was a chat in the evening, that would be much better.
I am also interested in the point why such a lot people prefer using CCK + Filefield + Filefield Image + ImageCache to create their galleries. Wouldn't it be easier to simply use image module? And what's about the performance? What do you think about?
It's clear that image module doesn't provide all these great features at the moment, but I find it's faster and not so DB intensive like the other construct. It's clear that some features are missing but why does nobody create a feature request? I would help with patches if necessary.
Perhaps, you wonder why I ask such a lot questions, it's simple to explain:
If there's really no interest in image module any more (but I don't think so, I really like it), I could eventually adapt my module to work with CCK, but this means a lot of more work =)

Looking forward to your answering

the reason I think you will find

KerrySanto's picture

that more people are using CCK and image its because its easier to create galleries, I spent 3 weeks trying to install a successful version of the image module to my site, i uninstalled it and reinstalled it about 10 times and also had a go at rebuilding the site about 5 times to get a proper image gallery, as I was excited abou the image module but when I tried to get the images in to the galleries they wouldnt go, I even tried installing Gallery2 but couldnt get that to work either, I think a lof of us who dont know php found it easier to create galleries with CCK and imagefield as there was actually video tutorials you could watch to see exactly how things were supposed to be. I would have loved to have the image module installed on mysite as I wanted to install the webcomic module which runs with image but had to abandon that idea, As I couldnt find the answers or anyone to help with the problem and I did actually try and read through all the long posts about the same problem but didnt have the php skills to fix that, and didnt want to ruin the rest of the site.

I don't think that there is

couzinhub's picture

I don't think that there is no interest in the image module anymore, but I think that the community would like to fusion image and imagefield into one module, to clean up the way drupal manage images. The future of image modules in 6-7 is pretty uncertain, as there is no preference yet, but I agree that if image module had more cool feature, it would become very powerfull.

But the good thing about imagefield / filefield-image is that these module makes it more flexible to create a node type with an image, and promote an extensive use of CCK. And I think that 's a good thing.

IMHO, drupal misse a set of smaller modules that would 'glue' these modules toogether by adding smaller functionnalities, like browsing / re-arranging / thumbs ...

Maybe we could have a second session in an evening so we could gather the other side of the planet :) to talk about this ? I'll submit the idea.

If you need any help for your module, you could definitelly find someone durings these talks. It's always good to have help ;)

Brian@brianpuccio.net's picture

I agree, there is plenty of interest in image due to it's history and simplicity. However, if you ever want to do more than just an image gallery, a CCK method (whether it is ImageField/ImageCache or FileField/FileField Image, that's another story) is needed. Can you do a simple gallery with a CCK method? Sure. Do people use image because of its simplicity and history? Pretty much, those are the big reasons.

I think there are several advantages to dropping image in favor of a CCK method (as opposed to having two ways to handle images):

  • Less code to maintain
  • More options (simple or complex if you need it)
  • Chance of getting image in core
    • CCK is becoming more and more popular and is becoming a key strength of Drupal and is shifting towards core, if image was included, it might go with it one day as a field type (not to say that add on modules for galleries wouldn't be needed, but maybe look to views for that)
    • If there is one way to do images and the effort is spent on this and it becomes polished, that is more likely to become a candidate than one of several solutions

Of course, anything could happen, when push comes to shove in OSS, code is gold.

$0.02

Totally agree, along all the

couzinhub's picture

Totally agree, along all the projects I've been working on, NONE of them used image, and ALL of them used cck + imagefield +Imagecache.
We are even starting to work internally on a module to create galleries from imagefield nodes, using CCK + imagfield/cache + view + taxonomy... Hopefully if we can provide some help to GrandCat, this could have multi upload for these kind of solution. :)

Yes, help wouldn't be bad at

grandcat's picture

Yes, help wouldn't be bad at all, thats clear. If there's a chat in the evening next time, please are wiling to inform me =)
Yes, there's another point I wanted to mention: Actually, I'm working on a solution to cooperate with CCK + Filefield Image, but this is much more complicated than I thought, a bit confusing.
@ couzinhub: I saw that you had created an issue in image module, this is a good idea I think, but it seems that the developers don't have any time or motivation to add such new changes, but we will see.
@ KerrySanto: Oh, I have never had any problems with image module, I'm wondering. At that time, I founded it too complicated to create a gallery out of CCK + Filefield Image and so on. But of course, this is a good reason to change to another "gallery module". But it's clear that the cck construct is more powerful than image module. I remember the days when image module didn't even provide the ability to "crop and scale" images, only the option "scale" was available first in D5. Then, I applied a patch for image module to make that possible and to share with other people at the same time. But this is a bit of "off topic" now, I'm sorry =)

But perhaps, there are also some more reasons why you changed to CCK + Filefiled Image or similar constructs. Please give me some more, so I will get more and more motivated to additionally add a sub project for mass uploading images to Filefield Image.
I really want to maintain a quality module for Drupal Generations if possible ;-)

about filefield image...

couzinhub's picture

Please do not invest any time in filefield image, it is bound to disapear fairly quickly in favor of imagefield.
see related discussions from the two module maintainers :

http://drupal.org/node/281614#comment-922005

"current developments indicate that this module will disappear with its guts being merged back to imagefield"

Valuable Information

Brian@brianpuccio.net's picture

Valuable information, I didn't catch that. Now it looks like there is more of a direction with image handling.

ImageField or Filefield_image?

grandcat's picture

Now, I'm a bit confused. I don't know which construct I should support additionally: Imagefield (as soon as it gets ready) or filefield_image. But you said that image_field will be based on filefield, does this mean that it depends on filefield? It's really important to know, or is this case also not sure?
What do you think about?
But there's one thing I can't realize: If everybody used imagefield in the past (like me for Drupal 5), they had to use filefield_image in Drupal 6 because there wasn't any imagefield for D5 yet! But now, we should change again the module, but this change isn't as easy as it sounds, a lot of problems can be the result in the end. I don't like this idea very much.

I really like to integrate the CCK construct in my module, but I am not sure at all what should to be included. I already changed the structure of my module, so that I can easly integrate our CCK construct, but now this!
I need again your help, should I now wait for imagefield being developped?

UPDATE

Ah, now I found following text in CVS of ImageField:

imagefield is now a reliant extension of filefield... It's widgets use filefield_widget_*
and other field type's can leverage this...

even more exciting... filefield will be able to freely use imagefield's widgets with a few
more tweaks, or any other similarly designed fields widgets...

Does that mean that ImageField now depends on Filefield, right?

looks like it depends on filefield

couzinhub's picture

looks like it depends on filefield :), and that makes more sense... I wonder if that would bring any limitation.. ?
I think you shouldn't work too much on it until there is an actual release of imagefield for d6. At least then we will be sure how to proceed.

The discussion are now set

couzinhub's picture

The discussion are now set to 3pm vancouver time on mondays.

http://www.timeanddate.com/worldclock/fixedtime.html?month=7&day=14&year...

The chat room is now different, it is now on #drupal-dojo.

I'll be posting a new project outline soon.

Fly On The Wall

Brian@brianpuccio.net's picture

Great, I'd love to be a fly on the wall at the very least and this time works great for me since it is after business hours on the east coast of the US.

Are you guys still doing

jjjames's picture

Are you guys still doing this image gallery chat?

nope

couzinhub's picture

nope

Image

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: