Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
I've made some late changes to the tabs/layers plugin.
Next change I am thinking of is to rename the plugin "tabs". It made
sense to name it something else while there were only a menu, but
since I added the buttonbar it now looks like tabs. Most end-users
will refere to it as tabs or tabs/layers. We might save us from some
questions by claiming it is tabs. On the other hand.. it feels better
to be upfront on that K-Meleon still opens as many windows as before.
Any comments? objections?
Back to the latest changes: There is a new preference named "catch".
With catch true the plugin will capture window events and use them for
layers. Maybe it should be split into a "catchOpen" and "catchClose"?
Unfortunately this "catch" brings back the massive flickering from the
early days.. It would be useful if someone could look at this anyway
and say whether it catches the right events at the right time. I have
only tested that self.close() and Href+Target both do layers now. Will
work on the flickering later on.
For the rest I am hoping for comments on the preference names and
default values. Will they suit the masses of end-usres who rather not
fiddle with config files?
kmeleon.plugins.layers.rebar Boolean true
kmeleon.plugins.layers.title String "Layers:"
kmeleon.plugins.layers.width Integer 15
kmeleon.plugins.layers.numbers Boolean false
kmeleon.plugins.layers.style Integer 2
kmeleon.plugins.layers.close Boolean false
kmeleon.plugins.layers.catch Boolean false
Again I have put sources and binaries at http://kmeleon.freewebsites.com/
> We might save us from some questions by claiming it is tabs. On the
> other hand.. it feels better to be upfront on that K-Meleon still
> opens as many windows as before. Any comments? objections?
I kinda like "layers". I'd keep it. Besides, naming them as "tabs" just
like Mozilla, people would proabably expect some tab-like behaviour, for
example being able to right-click on them and choose appropriate
functions that apply to that particular tab. Since your plugin does not
allow this (its not needed anyway since we can customize context menus)
it'd create confusion with people referring to your tabs as "broken" or
> Maybe it should be split into a "catchOpen" and "catchClose"?
I don't think it would be neccessary. That'd create confusion why some
events are caught and some are not. Besides, some popups have habit of
calling window.close() as closing function and when close isn't caught
it'd ditch all layers withint current window.
BTW, is it possible with current plugin to gather all open KM windows
into layered one? That is, when I have 3 KM windows open or window with
several popups, could it be possible to gather them all under one window
as layers? That'd be nifty. Or, even more geekier if one could spread
out the layers into separate windows. Not terribly useful though, I
imagine. Heh :)
> anyway and say whether it catches the right events at the right time.
> I have only tested that self.close() and Href+Target both do layers
Seems to be working in casual browsing. It does feel handy already. I'll
do actual testing later today, I'm particulary interested how does this
work with window.moveTo() or window.resizeBy() methods. We'll see what