[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[mylar-dev] moving highlighters from the sandbox
|
I want to focus discussion about hightligters on practical aspects.
So, lets use new thread for this.
There is also ancient bug report. So, please don't hesitate to comment
and vote for it.
107091: provide task highlighters and a preview on the corresponding
preference page
https://bugs.eclipse.org/bugs/show_bug.cgi?id=107091
> SDK have feature to use background-based highliting for CVS stuff.
> So, bad excuse you have. :-P
This is not enabled by default and I am arguing that it is a bad idea
to have something like this enabled by default for views that have
sufficiently high fidelity decorators and are frequently visible.
Part of this argument comes from experience, since I have worked for
weeks with a Package Explorer that had foreground highlighting.
You have total right to argue that, and yet there was some customer
request for that feature, which is also implemented by other IDEs. Some
wanted it, so there it is...
Also, let's agree to not talk about highlighting in the Package
Explorer. I think we already agreed that we don't need higlighting in
there. So, main point of this discussion is to hupport highlighting in
the Task List view.
> It depends. Monotonous views are hard to deal with and hard to
> pickup tasks from list of >10 if those tasks have orthogonal
> characteristics to any sorting or grouping mechanisms provided by
> Task List view. That is why I and few other users found
> highlighters quite handy to make those tasks more noticeable.
Yes, highlighters are great at making these orthogonal properties
that don't participate in sorting and grouping jump out immediately.
But they are extremely expensive visually because they drown out the
other visual annotations that we use to indicate these properties.
Not necessarily. Of course if you'll use dark colors they will be
heavily intensive, but light colors work quite well and don't really
interfere with other decoration, which is almost literally orthogonal
(vertically alligned columns vs. horizontal colored rows).
For example, we can now instantly pick out which bugs are marked
major. with the icon overlays, or which ones are overdue. In my
usage experience that gets drowned out in the presence of
highlighter.
Again, it is just your usage. I can only speak for myself, but for
some reason "major" markers never worked for me and I barely look at
those decorations. But I do use my "orthogonal" highlighting to mark
other bugs as my own "major" ones.
The only statement I know of on record about a user other than you
needing highlighters boiled down to problems with other parts of the
pre 1.0 UI. The user's statement (Oct 18, 2006 newsgroup post) was:
I was actually referring to several complains about missing
hightlighters when upgrading from some old version of Mylar.
This and other points they brought up have either now been addressed
or will be addressed via other improvements. So I am again left to
conclude that you are projecting your opinions and needs onto those
of others. That's *not* to say that we will never have a reason to
add highlighters, just that the current state is that we don't have
one.
The Mylar UI will never be optimized for you and me. It needs to be
optimized for intermediates (one of Alan Cooper's axioms that I
deeply believe in). I have always taken every one of your
suggestions to heart. But if you project something that you are
convinced of to be something that others need you make it harder for
me to do so.
Very interesting. Maybe I do that, but I thought that my use of
higlighters is fairly generic and can't be substituted by other features
that Mylar provides. Basically it is like local planning, but not planning.
Ideally, the way I think hightlighters should work is that each of
them should have some tag and multiple tags could be assigned to any
local issue. So, user can build some local classification that can't be
represented or don't make sense on issue tracking repository. Then those
tags could be visualized/rendered with configured backgrounds in the
task list and should also allow quick filtering in the search. This
can't be completely substituted by the working sets and other grouping
models.
regards,
Eugene
