Re: [SM-PLUGINS] new hook

[Brad D. <buc...@us...>]

John B. said:
>
> Perhaps a good place for a frame would be the very top of the
> right_main screen.  Get the compose, addresses, folders and all of
> that stuff out of the refresh and into the static area.  That would
> be less info that would have to be republished each time the page is
> loaded.
>
> Does this sound like a good idea?  It would take some time to do.

That's close to what I did.

In webmail.php, right after the echo of "</head>" I have code like this:

$custom_frames = do_hook('webmail_frames');
if ($custom_frames == '') {

...

// the rest of the code stays the same as there was no plugin result
// until right before the next do_hook call for the webmail_bottom hook.

} else {
    echo $custom_frames;
}
do_hook('webmail_bottom);
...


Now it should be said that any potential plugin using the webmail_frames
plugin should behave well enough to adjust for $location_of_bar and make sure
to keep the frame names the same as they are now, at least for the two frames
that do exist.

The rest of the code seems to works well with custom frames installed. I only
had to make a modification for one plugin so far that didn't specify the frame
to use when calling displayInternalLink.

I can send around a suggested patch, but first, any comments on doing things
like this???

Brad

> John
>
> Brad Donison said:
>> p dont think said:
>> [snip]
>>>> Thanks. I'd prefer to stick with the official SM then. So then
>>>> the
>>>> question: are there plans to support icons in the menu bar any
>>>> time
>>>> soon?, if not, why?. Some ppl think the icons look cool
>>>> (particularly
>>>> I don't mind, while SM works :-) ).
>>>
>>> It's in the works.  There is possibility of more graphical hacks
>>> ala
>>> plugins in the near future, but what you'll really want to look
>>> out for
>>> is when we template the whole thing, although that is going to
>>> take a
>>> while.
>>
>> And while we're on that topic;-) For one of the plugins I'm working
>> on, I
>> added a new "frames" hook. I know this is an interm solution until
>> templates
>> are in, but it seems to be usefull for me anyways. Rather than
>> forcing a
>> specific frame layout, it will allow plugins to define the number of
>> frames
>> for the app and where the are located. Though for things to work you
>> still
>> need to remember to use the current names for each of the two main
>> frames.
>>
>> That combined with making some of the current hooks more consistent
>> in where
>> they are called from and passing some more info also afford good
>> extensions
>> for an interm solution. Personally, I don't prefer the "waiting"
>> game for
>> templates and so I'm tweaking code, adding hooks and creating
>> plugins myself.
>> But I digress...
>>
>> So does the idea of a new "frames" hook sound like something that
>> would be
>> benefitial in SM or should it remain a patch.
>>
>> All the BEST,
>>
>> Brad

--
cat /dev/null > mybrain