This is directed to Geoff as I think he has a vision for what he’d like
to see Avogadro do but anyone is able to coment.
In trying to figure out the “correct” way to setup the Engine API, we’ve
already been through quite a few different changes. I most recently
made a change I thought made sense, and still does, but am kinda second
guessing myself. This is concerned strictly with multiple GL views of
the same molecule. At this point I think it’s safe to say that we will
implement some sort of “Engine Duplication” interface where users can,
for instance, make a copy of the ball and stick engine and tweak some
settings so that they have two different engines, and as a result they
will be similar but different options (maybe say detail or color). I
have come up with a few different options (i use the term ‘view’ to
mean GLWidget);
Option #1 (current): From one view, we can duplicate this view, but
changes made to either view are independant from each other. This also
means that if one GLWidget duplicates an engine and tweaks it, the other
will have no knowledge of this newly created engine. I believe this is
nice, not only from a coding standpoint, but from a user standpoint.
Also, this means that if in a certain view you select certain atoms to
be rendered by a certain engine, in the other view you can select
different engines for those atoms. But again, any changes made to an
engine belonging to one GLWidget (view) will no impact other views of
the same molecule.
Option #2: GLWidget’s share engines between molecules. This means that
changes to an engine in one widget will impact the other widgets, but
users can still choose which engines they want to render what
primitives. This seems like the best option but i’ve been tossing it
around in my head and while the coding wouldn’t be that bad, the truth
is that the user interface for actually setting up the views could be
very confusing quick.
Easier to understand description: in both options engines have settings
on “how” to render. in option 1 the engines manage their own lists of
"what" to render. in option 2 the GLWidget has to manage a list of
"what" to render for each engine. in option 1 this means that “what” to
render becomes a property of the engine itself which is easy for users
to understand and also means that engines can become more optimized
(they have better knowledge of the “what”). in option 2 “what” becomes
a property of the engine for that specific view and thus engines only
know “what” when they are called apon to render it.
So yeah, I just needed to see what kinda feedback you guys have. What’s
best for chemists?
-Donald
On Apr 23, 2007, at 3:27 AM, Donald Ephraim Curtis wrote:
Option #1 (current): From one view, we can duplicate this view, but
changes made to either view are independant from each other. This
also
means that if one GLWidget duplicates an engine and tweaks it, the
other
will have no knowledge of this newly created engine.
I think this fits the law of “least surprise.” If you create a new
view, the idea is that you can show data in a new way, for example
highlighting a different part of the molecule or a different style.
I like proteins for examples. Let’s say the user wants to show the
protein helix shape in one view, but focus on the active iron atom in
another.
But again, any changes made to an engine belonging to one GLWidget
(view) will no impact other views of
the same molecule.
That’s not necessarily true. Maybe there’s a command for “sync views”
to copy the settings from one view to others on demand.
I think “option 1” fits the best cases. If a user creates a new view,
it starts out looking identical to the old one, right? They can
customize the new view if they want. They can perform an on-demand
“sync” if we add such a command. So it’s what most users will expect
and want.
Why should a new view automatically update the others? If so, what
benefit does adding a new viewport bring, besides another camera
location? Seems like that can be reproduced with option 1 as well –
just don’t change the rendering options in the new view.
Cheers,
-Geoff
(Tue, Apr 24, 2007 at 11:05:18AM -0400) Geoffrey Hutchison geoff.hutchison@gmail.com:
On Apr 23, 2007, at 3:27 AM, Donald Ephraim Curtis wrote:
Option #1 (current): From one view, we can duplicate this view, but
changes made to either view are independant from each other. This also
means that if one GLWidget duplicates an engine and tweaks it, the other
will have no knowledge of this newly created engine.
I think this fits the law of “least surprise.” If you create a new view, the
idea is that you can show data in a new way, for example highlighting a
different part of the molecule or a different style.
I like proteins for examples. Let’s say the user wants to show the protein
helix shape in one view, but focus on the active iron atom in another.
But again, any changes made to an engine belonging to one GLWidget (view)
will no impact other views of
the same molecule.
That’s not necessarily true. Maybe there’s a command for “sync views” to
copy the settings from one view to others on demand.
I think “option 1” fits the best cases. If a user creates a new view, it
starts out looking identical to the old one, right? They can customize the
new view if they want. They can perform an on-demand “sync” if we add such a
command. So it’s what most users will expect and want.
Right, ok.
Why should a new view automatically update the others? If so, what benefit
does adding a new viewport bring, besides another camera location? Seems
like that can be reproduced with option 1 as well – just don’t change the
rendering options in the new view.
Well, in option #2 a new viewport would allow you to select different
things to get rendered. Remember that a user could duplicate BSEngine
to UserBSENgine (in Avo) then tweak some settings. If i do so with
option #1 that new UserBSEngine will not be copied to my other views.
With option #2 it would be and then i could goto my new view and select
different things to be rendered. But the more i think about it (and
yes, it’s been on my mind the last three days) it’s confusing to think
about option #2, shared “settings” between engines, but not shared
“what” (being what atom gets what engine).
Another way to think about it is asking the question: “Are the
primitives that an engine is rendering, part of it’s settings or part of
the GLWidget settings?”