[45] in bug-owl
Narrowing views, userclue levels, and subscription loading
daemon@ATHENA.MIT.EDU (Mitchell E Berger)
Sat Jun 29 23:05:31 2002
Message-Id: <200206300301.XAA11597@athenaphobia.mit.edu>
To: bug-owl@MIT.EDU
Date: Sat, 29 Jun 2002 23:01:52 -0400
From: Mitchell E Berger <mitchb@MIT.EDU>
Narrowing views
===============
During the discussion which led to jdaniel's suggestion of a "universal"
filter which would be or'd with other tests in dynamically created narrowing
filters (which I think would be great to have also), we realized that there's
a small problem. The advertised behavior of M-n and M-N is to narrow the
view to the current class, or the current class/instance pair. However, that's
only what happens if the class-foo or class-foo-instance-bar filter doesn't
already exist. If it does, owl uses the one that's already there, which could
potentially include additional unwanted zephyrs, or even do something
completely different from what the name implies. We should fix this in one
of a few possible ways:
1 Forcibly reserve part of the filter namespace for owl (perhaps any filter
that starts with the phrase "dynamic-" can't be changed or defined by the
user except to set a color) and then use that namespace for owl's narrowing
filters (maybe also owl-dynamic).
2 Let owl clobber any user-defined class-foo or class-foo-instance-bar filters.
3 Just use owl-dynamic for all narrowed views.
4 Retain the current behavior, but update the help and documentation to clarify
that owl will either narrow or obey the user's definition of particular
named filters.
Personally, I vote for #1. #2 may clobber filters with names people might
actually want themselves, #3 gives a label in the status bar that isn't really
descriptive enough, and #4 seems unnecessarily confusing, especially since I
think Jer's universal filter will take care of any behavior people would want
to exploit #4 for.
Userclue levels
===============
- jdaniel at some point suggested that perhaps having another userclue level
for people who have a .owlconf might be useful. We didn't really hash out
exactly what to use it for yet, though.
- I had been thinking that perhaps a wizard userclue level might be nice for
developers, which would do things like cause the unsupported options or other
in-development things to show up or be enabled.
- In thinking about the "subs to classes" and the "has an .owlconf" levels, I'm
sort of not sure which is above or below the other. I wonder if we should
be able to compare userclue with simple greater-than or less-than tests, or
if it should be a set of bits, and we should be checking for different types
of clue with masks. Actually, it looks like the code is set up for masks
already.
- If you know enough, you should probably be able to force-set your userclue
level. This would be useful for powerusers who have a default setup and
may not subscribe to classes by default to upgrade what owl shows them or
lets them do, and for wizards who are testing things to downgrade to what a
regular user would see. A simple possibility for implementing this would be
to make it an unsupported option; then the infrastructure for getting and
setting it is already there, but you have to know about it to use it.
Subscription loading
====================
Unless I'm missing something, there appears to be a waste of CPU cycles in
the two functions that load zephyr subscriptions - they test for a # at the
beginning of the line, and then for some reason seem to test for a newline at
the beginning of the line TWICE. An easy patch, but I'll wait for the
snapshot.
Mitch
