Closed (fixed)
Project:
Brilliant Gallery
Version:
5.x-2.5
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Sep 2007 at 10:45 UTC
Updated:
8 Sep 2008 at 14:26 UTC
Hi.
In our sites we use Greybox 5.5 (because it's one of the few that can render HTML pages in an overlay) so we wished to use your brilliant gallery (in both senses of the phrase :P) with greybox.
Made the following adjustments:
line 119
'#options' => array(
'lightbox' => t('Lightbox'),
+ 'greybox' => t('Greybox'),
'thickbox' => t('Thickbox'),
'none' => t('None'),
),
line 250
switch( $overbrowser ) {
case 'thickbox':
$result .= ' class="thickbox"';
$result .= ' rel="img_' . $setname . '"';
#$attributes['class'] = $link_class;
#$attributes['rel'] = 'img_' . ($node->nid? $node->nid: time()); // 'insert' has no $node->nid
break;
case 'lightbox':
$result .= ' rel="lightbox[' . $setname . ']"';
#$attributes['rel'] = 'lightbox[' . ($node->nid? $node->nid: time()) . ']'; // 'insert' has no $node->nid
break;
+ case 'greybox':
+ $result .= ' rel="gb_imageset[' . $setname . ']"';
+ break;
default:
break;
}
It's a minor change but a functional one :P
Thanks for your time and effort
Remon.
Comments
Comment #1
vacilando commentedWell, good idea - but it did not work with
rel="gb_imageset[' . $setname . ']"When I used
class="greybox"What do you think?
Comment #2
vacilando commentedI mean it worked when I used
class="greybox"What's the difference? Did you test your solution and was it working?
Comment #3
rmpel commentedThe difference is: the first is used by Greybox 5.5, the second is based on greybox redux
And ofcourse I tested my solution :P
Another tip for the programmer; when building your options list, do it like this:
Whereas the greybox_5_5 module is built by yours truly and the greybox redux is available on drupal.org.
Greybox redux requires the following:
Comment #4
rmpel commentedAnd though I'm not here to tell you what to do, i would suggest building a hook system;
Instead of defining the different overlays hardcoded, do a module_invoke to get the overlays.
what I mean is;
1st party: brilliant gallery module
2nd party: lightbox module
2nd party: greybox redux module
Now, create extra modules that depend on brilliant gallery AND lightbox that implements the hook you call in BG.
So in BG you do
to get the options entries, then something like
to get the specific tag.
The module that implements the hook (lets call it the bg_with_greybox module) does;
this way a user cannot activate an overlay (s)he hasnt installed (the dependencies line in the info file makes sure of that)
the options will show only available overlays
3rd party can create extra modules for new overlays without having to alter the original code :)
so for the Greybox 5.5 module I created it would be:
ofcourse, I would, myself, implement this hook in a new version of the module greybox_5_5 to make it brilliant gallery aware :)
Anyways, just thinking aloud here. This is how I would do it, by no means the only way and also absolutely not obligatory :P
Comment #5
rmpel commentedwhoops.... module_invoke in the example here should be module_invoke_all. my bad :P
Remon.
Comment #6
vacilando commentedExcellent tips, thanks. Remon. I'll get back to you on those asap.
But I am still failing to understand one crucial item in this discussion. Where is the greybox_5_5 Drupal module you have been talking about?
Tomas
Comment #7
rmpel commentedI sent it to your e-mail, or rather, I replied in my mail client to the notification of your contact-form-input and sent you the module.
Comment #8
jan.n commentedChanged status to closed due to 10 weeks without any activity