[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] RE: UI Status followup
|
Randy,
I agree that this would be the best approach. But there's one drawback:
assume n (let n be huge) plug-ins provide a feature which can be
enabled/disabled and fine tuned via ruler context menu but you (and
probably myself) only really use 3 of them. We wouldn't like the bloat in
the context menu from the other n-3 plug-ins. Maybe the solution is to have
the following entries:
- options for enabled feature(s)
- disable enabled feature(s)
- Customize...
The latest entry allows to configure all feature for the current context.
Dani
Randy Hudson
<hudsonr@xxxxxx.c
om> To
Sent by: platform-ui-dev@xxxxxxxxxxx
platform-ui-dev-a cc
dmin@xxxxxxxxxxx
Subject
Re: [platform-ui-dev] RE: UI Status
18.11.2004 22:27 followup
Please respond to
platform-ui-dev@e
clipse.org
My main complaint about the preference dialog is that I have to use it.
For example, for editor quick-diff settings, I should be able to
right-click on the java editor's ruler, select "Quick Diff..." and edit
preferences *only* for quick diffs. If the use of the global prefrence
dialog were discouraged, the complexity/scalability wouldn't be so
important. I thought this was a goal of the preference swat team.
-Randy Hudson
"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by:
platform-ui-dev-admin@xxxxxxxxxxx To
<platform-ui-dev@eclips
e.org>
11/18/2004 03:53 PM cc
Subject
Please respond to [platform-ui-dev] RE:
platform-ui-dev UI Status followup
Michael suggested I follow up here. The prototype looks pretty busy to me
with navigation across the top, down the left side, and in the content area
in the form of tabs.
It's always struck me as a usability problem that some preferences pages
are heavily into tabs and some aren't and some use a combination of tab
pages and tree nodes on the left. I know that different components have
different numbers of preferences but this is pretty confusing to even
experienced users. If the preferences dynamic team can straighten all that
out it would be very welcome.
Two interesting models that I think demonstrate some fresh, good ideas for
preferences UI are the Options dialog in Firefox (
http://www.mozilla.org/firefox) and both the main interface and options
dialog of the MySQL Administrator (
http://dev.mysql.com/downloads/administrator).
I suggest a data-driven approach. You already have the concept of field
editors and preference categories. Go a bit further, and instead of having
preference page designers painstakingly build up an SWT composite by hand,
let us give the preferences UI engine enough info so it could generate the
whole interface on the fly
For example, look at the Workbench > Search preferences. You have some
boolean options, you have a color option, you have a text option that can
be disabled, and you have an option that takes a value out of a list. This
could all be described in some simple XML. With a few exceptions I'll bet
almost all the preferences could be handled that way.
You list height/width problems as an issue - dynamically generating the
pages would help address that wouldn't it? There's a bugzilla open for
filtering/searching, and having metadata for all the preferences would help
that too. It would help capabilities as individual options could be visible
or hidden based on the capabilities, not just whole preference pages. It
would help making the presentation of the preferences common across all
plug-ins (rather than everybody doing their own rendering as currently). It
would eventually allow alternate UI presentations for the preferences
(future versions could render it differently, and some RCP apps might
prefer tree representions, some might want to do the whole thing in Swing,
and some might want a long scrollable list, etc.).
Also it would reduce developer time trying to squeeze in an option in a
preference page here or there, and reduce the opportunities for error
cutting and pasting all the boilerplate get/set/default code that's
currently needed. That's probably why many preferences that exist in the
code aren't surfaced in the UI; it's too much of a pain.
________________________________
From: eclipse-dev-admin@xxxxxxxxxxx
[mailto:eclipse-dev-admin@xxxxxxxxxxx] On Behalf Of Michael Van Meekeren
Sent: Thursday, November 18, 2004 10:50 AM
To: eclipse-dev@xxxxxxxxxxx
Subject: [eclipse-dev] UI Status followup
As a followup to the status note about preferences, a
sample image has been linked to the Preferences Dynamic team page.
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_1/dynamic_teams/dynamic_teams.html#preferences
click here to go directly to it, note that it is just a
prototype:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_1/dynamic_teams/pref_snapshot.PNG
/michael
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
