toscanaj-developers — Discussion forum for developers of ToscanaJ (not Toscana systems)

[Toscanaj-developers] Source Docu

[Peter B. <pb...@me...>]

Hello,

I set up Doxygen-generated source docu here:

  http://meganesia.int.gu.edu.au/~pbecker/toscanaj/sourcedoc

This should be updated nightly (Brisbane time). It already showed me a
small issue with a double link to an Interface ;-)

  Peter

Re: [Toscanaj-developers] Diagram History

[Peter B. <pb...@me...>]

"J . Hereth" wrote:
[...]
> > > Displaying the concept may be easier in a graphical fashion
> > > (thumbnails?).
> >
> > Sure, thumbnails would be cool. Probably they are even quite easy to
> > get. But let's start with the text-only version -- you know: syntax is
> > trivial ;-)
> 
> Sure. But eye-candy is soo nice :-)

I think (mis)using the tooltips for this might be cool: whenever the
mouse hovers on a diagram you get a small preview of it. The preview for
visited diagrams could use highlighting, the one for forthcoming
diagrams could apply the current filter. The latter could be done for
the upper list, too.

This is the design idea. I tried to figure out how to use tooltips in
Swing and as usual it is more complicated than one would expect. They
seem to be strongly focused on single lines of text, and I couldn't get
even this to work on a listview -- but I guess I just miss some weird
call you have to do before you can use ToolTips at all, I already call
the ToolTipManager to include the DiagramHistoryView but this is not
enough. More tomorrow or even later....

Anyway: what do you think about the design idea? This would allow to use
pretty large previews, maybe 100x100 pixel without wasting lots of
screen real estate.

  Peter

Re: [Toscanaj-developers] Diagram History

[J . H. <jh...@us...>]

On Wed, Oct 10, 2001 at 03:01:39PM +1000, Peter Becker wrote:
> "J . Hereth" wrote:
> [...]
> > > There should be another listview for all diagrams above it where the
> > > user can add new diagrams at the end by double-clicking. Double-clicks
> > > on the history view could be mapped to these functions:
> > >
> > > Past: go back (undo one or more steps)
> > > Current: ?
> > > Future: leap forward (like zooming into the top in each intermediate
> > > step, which can be seen as skipping the diagrams in between since the
> > > filter won't be changed)
> > >
> > > Additionally a button or context menu entry (or both) on the history
> > > should allow removing entries -- either only in the future or on all
> > > diagrams. The latter might give unexpected results when removing a
> > > diagram in the past: this would change the filter for the current
> > > diagram. Removing the current diagram probably should imply a single
> > > step undo.
> > 
> > With those semantics an undo-redo combination wouldn't yield the same
> > diagram in general. 
> 
> Sorry, I don't understand what you mean here. That the semantics of
> double-clicking on a future diagram has not the same semantics as a
> redo? Or do you refer to the removal of the current diagram?

I don't talk about doubleclicking. But, if you don't store which concept
has been selected in a previous step, I can't see how an redo-undo would
come to the same diagram again.

> 
> > I think the selected concept should be stored and
> > displayed too, defaulting to the top node if not selected otherwise by
> > the user.
> 
> When should the selected concept be stored? Selected as in
> "double-clicked" or in "highlighted"?
> 
> > Displaying the concept may be easier in a graphical fashion
> > (thumbnails?).
> 
> Sure, thumbnails would be cool. Probably they are even quite easy to
> get. But let's start with the text-only version -- you know: syntax is
> trivial ;-)

Sure. But eye-candy is soo nice :-)

jo

> 
> Steve and I implemented the second listview and the basic operations on 
> it today -- check it out. No double-clicks on the history yet and the
> connection to the diagram is missing but the layout should be finished
> and the buttons work.
> 
>   Peter
> 
> _______________________________________________
> Toscanaj-developers mailing list
> Tos...@li...
> https://lists.sourceforge.net/lists/listinfo/toscanaj-developers

Re: [Toscanaj-developers] Persistent label movements

[J . H. <he...@ma...>]

On Wed, Oct 10, 2001 at 02:58:30PM +1000, Peter Becker wrote:
> "J . Hereth" wrote:
> [...]
> > > What's your prefered option:
> > > 1) keep it as is: position changes are persistent for the session
> > > 2) back to the old version: whenever a new diagram is viewed we reset
> > > the positions
> > > 3) make it an option (what is the default?)
> > > 4) something else (what?)
> > 
> > At least 1) - that's what many people requested here at Darmstadt too.
> > Optionally it should be possible to save the new offset (for this scale)
> > in the file.
> 
> Saving the new offset was something I was thinking about, too. But I
> don't think that is a good idea because this would introduce real (but
> very limited) editing capabilities into Toscana and it would enable
> people to break more than just their session ;-)

Agreed. I think I get used to some of the nice features of Toscana3
(which has editing capability). Maybe it's due to the fact we still lack
an editor.

But from a design point of view I agree that Toscana should be viewer
only.

jo

> 
> I think Toscana should be kept as what it is: a plain viewer. Keeping
> changes persistent during a session makes sense, but changing files
> breaks the concept. Design is as much about what you not do as it is
> about what you do, and I think changing anything in the file breaks the
> design of Toscana.
> 
> So I'd propose we just keep (1) -- we have it anyway.
> 
>   Peter
> 
> _______________________________________________
> Toscanaj-developers mailing list
> Tos...@li...
> https://lists.sourceforge.net/lists/listinfo/toscanaj-developers

Re: [Toscanaj-developers] Diagram History

[Peter B. <pb...@me...>]

"J . Hereth" wrote:
[...]
> > There should be another listview for all diagrams above it where the
> > user can add new diagrams at the end by double-clicking. Double-clicks
> > on the history view could be mapped to these functions:
> >
> > Past: go back (undo one or more steps)
> > Current: ?
> > Future: leap forward (like zooming into the top in each intermediate
> > step, which can be seen as skipping the diagrams in between since the
> > filter won't be changed)
> >
> > Additionally a button or context menu entry (or both) on the history
> > should allow removing entries -- either only in the future or on all
> > diagrams. The latter might give unexpected results when removing a
> > diagram in the past: this would change the filter for the current
> > diagram. Removing the current diagram probably should imply a single
> > step undo.
> 
> With those semantics an undo-redo combination wouldn't yield the same
> diagram in general. 

Sorry, I don't understand what you mean here. That the semantics of
double-clicking on a future diagram has not the same semantics as a
redo? Or do you refer to the removal of the current diagram?

> I think the selected concept should be stored and
> displayed too, defaulting to the top node if not selected otherwise by
> the user.

When should the selected concept be stored? Selected as in
"double-clicked" or in "highlighted"?

> Displaying the concept may be easier in a graphical fashion
> (thumbnails?).

Sure, thumbnails would be cool. Probably they are even quite easy to
get. But let's start with the text-only version -- you know: syntax is
trivial ;-)

Steve and I implemented the second listview and the basic operations on 
it today -- check it out. No double-clicks on the history yet and the
connection to the diagram is missing but the layout should be finished
and the buttons work.

  Peter

Re: [Toscanaj-developers] Persistent label movements

[Peter B. <pb...@me...>]

"J . Hereth" wrote:
[...]
> > What's your prefered option:
> > 1) keep it as is: position changes are persistent for the session
> > 2) back to the old version: whenever a new diagram is viewed we reset
> > the positions
> > 3) make it an option (what is the default?)
> > 4) something else (what?)
> 
> At least 1) - that's what many people requested here at Darmstadt too.
> Optionally it should be possible to save the new offset (for this scale)
> in the file.

Saving the new offset was something I was thinking about, too. But I
don't think that is a good idea because this would introduce real (but
very limited) editing capabilities into Toscana and it would enable
people to break more than just their session ;-)

I think Toscana should be kept as what it is: a plain viewer. Keeping
changes persistent during a session makes sense, but changing files
breaks the concept. Design is as much about what you not do as it is
about what you do, and I think changing anything in the file breaks the
design of Toscana.

So I'd propose we just keep (1) -- we have it anyway.

  Peter

Re: [Toscanaj-developers] Diagram History

[J . H. <jh...@us...>]

On Tue, Oct 09, 2001 at 04:47:01PM +1000, Peter Becker wrote:
> Hello,
> 
> I just added model and view for managing the diagrams as one list of
> visited, currently displayed and forthcoming diagrams. The term
> "history" thus refers to past, present and future here. Currently just
> all diagrams in the schema are displayed in order, the list should
> contain only selected diagrams later (with the option of having
> duplicates) and the bold entry will move with every zooming operation
> (when using nested diagrams we will have multiple bold entries). Try
> looking in MainPanel for "history.next()" and adding more of them to see
> how it should look. The layout is currently of course only a hack.
> 
> There should be another listview for all diagrams above it where the
> user can add new diagrams at the end by double-clicking. Double-clicks
> on the history view could be mapped to these functions:
> 
> Past: go back (undo one or more steps)
> Current: ?
> Future: leap forward (like zooming into the top in each intermediate
> step, which can be seen as skipping the diagrams in between since the
> filter won't be changed)
> 
> Additionally a button or context menu entry (or both) on the history
> should allow removing entries -- either only in the future or on all
> diagrams. The latter might give unexpected results when removing a
> diagram in the past: this would change the filter for the current
> diagram. Removing the current diagram probably should imply a single
> step undo.

With those semantics an undo-redo combination wouldn't yield the same
diagram in general. I think the selected concept should be stored and
displayed too, defaulting to the top node if not selected otherwise by
the user. Displaying the concept may be easier in a graphical fashion
(thumbnails?).

Generally, I like this approach.

jo

> 
> Any comments? Do you think this combination of the three T2/3 lists
> (protocol, list in top left corner of diagram, scale manager) is
> superiour to the old approach (or at least equivalent)?
> 
> Regards,
>   Peter
> 
> _______________________________________________
> Toscanaj-developers mailing list
> Tos...@li...
> https://lists.sourceforge.net/lists/listinfo/toscanaj-developers

Re: [Toscanaj-developers] Persistent label movements

[J . H. <jh...@us...>]

On Tue, Oct 09, 2001 at 02:29:13PM +1000, Peter Becker wrote:
> [Alternative subject: "Oops! We implemented a feature."]
> 
> Hello all,
> 
> I was just wondering (a) if we should make changes to the label
> positions persistent and then (b) if we might have done it already,
> which turned out to be true. ToscanaJ remembers the changes to the label
> offsets during a session: you can move labels, switch the diagrams and
> when you come back to the old one the positions are still changed. This
> is of course a direct consequence of our new design using the MVC
> approach: the movement of the LabelViews ends in a change in the model
> to reflect this move.
> 
> Do we consider this as a feature? I think we should -- in fact this
> feature was requested by people for Toscana 2 and Cernato while I was
> working at NaviCon. Otherwise we need something like a second offset on
> LabelView, so we can keep the offset in the model while changing the one
> in the view. Shouldn't be hard to do. 
> 
> Technically both ways are doable and both should result in nice code --
> no hacks needed. We could even turn it into a configuration option by
> either keeping the LabelView offset to (0,0) all time and changing the
> model or by keeping the model offset and changing the view offset on
> movements. But configurable options are not necessarily the best way to
> go -- it creates inconsistent GUIs.
> 
> What's your prefered option:
> 1) keep it as is: position changes are persistent for the session
> 2) back to the old version: whenever a new diagram is viewed we reset
> the positions
> 3) make it an option (what is the default?)
> 4) something else (what?)

At least 1) - that's what many people requested here at Darmstadt too.
Optionally it should be possible to save the new offset (for this scale)
in the file.

jo


> 
> Regards,
>   Peter
> 
> _______________________________________________
> Toscanaj-developers mailing list
> Tos...@li...
> https://lists.sourceforge.net/lists/listinfo/toscanaj-developers

[Toscanaj-developers] Diagram History

[Peter B. <pb...@me...>]

Hello,

I just added model and view for managing the diagrams as one list of
visited, currently displayed and forthcoming diagrams. The term
"history" thus refers to past, present and future here. Currently just
all diagrams in the schema are displayed in order, the list should
contain only selected diagrams later (with the option of having
duplicates) and the bold entry will move with every zooming operation
(when using nested diagrams we will have multiple bold entries). Try
looking in MainPanel for "history.next()" and adding more of them to see
how it should look. The layout is currently of course only a hack.

There should be another listview for all diagrams above it where the
user can add new diagrams at the end by double-clicking. Double-clicks
on the history view could be mapped to these functions:

Past: go back (undo one or more steps)
Current: ?
Future: leap forward (like zooming into the top in each intermediate
step, which can be seen as skipping the diagrams in between since the
filter won't be changed)

Additionally a button or context menu entry (or both) on the history
should allow removing entries -- either only in the future or on all
diagrams. The latter might give unexpected results when removing a
diagram in the past: this would change the filter for the current
diagram. Removing the current diagram probably should imply a single
step undo.

Any comments? Do you think this combination of the three T2/3 lists
(protocol, list in top left corner of diagram, scale manager) is
superiour to the old approach (or at least equivalent)?

Regards,
  Peter

[Toscanaj-developers] Persistent label movements

[Peter B. <pb...@me...>]

[Alternative subject: "Oops! We implemented a feature."]

Hello all,

I was just wondering (a) if we should make changes to the label
positions persistent and then (b) if we might have done it already,
which turned out to be true. ToscanaJ remembers the changes to the label
offsets during a session: you can move labels, switch the diagrams and
when you come back to the old one the positions are still changed. This
is of course a direct consequence of our new design using the MVC
approach: the movement of the LabelViews ends in a change in the model
to reflect this move.

Do we consider this as a feature? I think we should -- in fact this
feature was requested by people for Toscana 2 and Cernato while I was
working at NaviCon. Otherwise we need something like a second offset on
LabelView, so we can keep the offset in the model while changing the one
in the view. Shouldn't be hard to do. 

Technically both ways are doable and both should result in nice code --
no hacks needed. We could even turn it into a configuration option by
either keeping the LabelView offset to (0,0) all time and changing the
model or by keeping the model offset and changing the view offset on
movements. But configurable options are not necessarily the best way to
go -- it creates inconsistent GUIs.

What's your prefered option:
1) keep it as is: position changes are persistent for the session
2) back to the old version: whenever a new diagram is viewed we reset
the positions
3) make it an option (what is the default?)
4) something else (what?)

Regards,
  Peter

[Toscanaj-developers] All set up

[Peter B. <pb...@me...>]

Hello all,

Steve and I finished the import of the ToscanaJ sources from Tockit. We
cleaned up the directory and package structures, the former "ToscanaJ"
module is now split into multiple modules in the new repository and the
packages are more specific, emphasizing the model/view/controller
structure we created during our refactoring in the last week.

An overview of both structures can be found here in the form of two XML
files:
 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/toscanaj/docs/developers/

These files contain the structures and short descriptions -- whenever we
set up a website we can add them there.

CU,
  Peter


PS: the mailing lists won't have reply-to mangling at the time
(administrative problems) -- don't forget to change the address when you
want to reply to the list