Adding a new slideshow style: slider [#752062]

I wrote a contrib module that uses the JQuery slider as the progress indicator and control element for the slider. It is depending on both jquery update and jquery ui. I would like to get commit access and commit this module to contrib if its deemed useful, so i can maintain it.

Attaching the module as a tar.gz, because CVS doesn't allow me to create a diff without write access.

Comment	File	Size	Author
#2	views-slideshow-slider.patch	25.99 KB	snufkin
#2
	views_slideshow_slider.tar_.gz	6.24 KB	snufkin

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

psynaptic CreditAttribution: psynaptic commented 25 March 2010 at 11:08

snufkin worked for us (Freestyle Systems) on this project and I can vouch for his excellent coding skills and willingness to contribute.

I'd very much welcome his inclusion on the dev team for this module.

On a side note: we're going to be building a new pager-style slideshow that will show X items per slide for our current project.

Comment #2

snufkin CreditAttribution: snufkin commented 25 March 2010 at 11:31

File	Size
views-slideshow-slider.patch	25.99 KB

I created a diff using git if that helps to review.

Comment #3

redndahead CreditAttribution: redndahead commented 27 March 2010 at 07:00

I would prefer that you create a new project on d.o. I have done this for http://drupal.org/project/views_slideshow_menu. We can add a link to the module on the views slideshow home page. I would like to keep singelframe and thumbnailhover as the only contrib modules in this package. It will help your module in the long run as you can make releases when you need it and not have to wait for a full release. I started views_slideshow_menu at 2.x so that it would match the views_slideshow version. You might want to do the same.

If you would like to co-maintain views_slideshow then I would suggest submitting patches and working through some of the issues in the issue queue first. We would love to have you, but I'd hate to have a large list of co-maintainers all with 2 commits.

Will this work out?

Comment #4

snufkin CreditAttribution: snufkin commented 27 March 2010 at 10:41

Yeah i can understand that, I just assumed the standard procedure was to put it under the modules contrib folder.

The problem I can see is that views_slideshow.module adds its own CSS only for modules in its contrib folder on line 33:
$contrib = file_scan_directory($module_path . '/contrib', 'views_slideshow_[a-z]*.module');

Comment #5

psynaptic CreditAttribution: psynaptic commented 27 March 2010 at 12:11

I think it would be very beneficial to have snufkin as a co-maintainer of Views Slideshow module. It's much easier to contribute and also greatly motivates one to become part of the devteam for a module.

I see your point about having separate contrib modules and I think that is appropriate for this as it does something most users won't need. I think the next one we build, which will work as a kind of paged slideshow, would be a much better candidate for inclusion in the core module.

Comment #6

redndahead CreditAttribution: redndahead commented 27 March 2010 at 16:54

Status:

Needs review

» Fixed

I committed a change yesterday that changed this. Now all the js and css files are loaded with hook_init() in their respective modules.

I'll go ahead and add you to the co-maintainers list. Just an FYI. I prefer that an issue is created for each commit. So for example I committed a change yesterday that just upgraded jquery cycle to the latest version. I created an issue with the patch for the change and since I knew that there wasn't problems with upgrading it I went ahead and committed it pretty quickly. Usually I like to let them last 24 hours before committing. Just to give a small window for the other maintainers to go "Oh my god no! and this is why." :)

@psynaptic looking forward to the new module