Re: [jarp-developer] Comments on version 1.1.5

[Filip L. <fil...@ma...>]

Hi,

> Really, to me it seems that the way to go is PNML.

Yes, I think we should start going in that direction. Of course, full PNML
compatability (whatever that will be) is not something to start out with,
but it should be fairly easy to make a PNML export/import tool that allow
Jarp to be able to read "old" net files and perhaps at the same time allow
other PNML readers to understand Jarp nets too.

As said earlier, I plan to use some time here.


> > I think we talk about slightly different things here. My comments meant:
> > when I press the "new file" tool button, the window that I get (whether
a
> > new window is made or the old one is cleared) will not close without
showing
> > the unsaved-work dialog. Since the net is completely empty there don't
seem
> > to be much need for the dialog in this situation.
>
> Strange... I don't get that in here... When I press 'New', no dialogs pop
> up.

I think you misunderstand. Do this:

1) start Jarp.
2) press the "new file" button (or select File/New)
3) close main window

Now you should get the "unsaved work" warning dialog. In fact, you should
get that warning every time a call to MainWindow.toolDone() has been made,
meaining that you can get even though there is no "real" change to the
drawing.

I think that the ideal for this warning is to only appear when there is real
unsaved work, i.e. if the user will loose some information by closing the
window. Perhaps "changed" could be some sort of attribute on the drawing
that can be reset by the NewTool and LoadTool and set by changes
(add/remove/updates) to the figures in the drawing?

> I received an e-mail from a professor in our lab complaining that JARP
> allowed places and transitions with the same name, and that it was wrong.
I
> think that our question about how places should be uniquely identified is
> answered.

Ok :). After some reflection on the matter, I think its ok to go for the
"HotDraw change" approach (the first approach mentioned it my last mail
about it) if all other "derived" nets preserve the unique name
characteristic (which they do now).

As you may have seen, I've added experimental support for ensuring that
figure names are unique when they are added to the JDrawingView. Currently
this only works for when the user inserts a new place or transition (i.e.
the "autoname" feature will not name something with a name that are already
in use).

However, it is still possible to load nets containing places or transitions
with identical names, and its still possible for the user to change a name
into one that already exists. Of these two "holes", the later is clearly the
worst, so I am planning to look into that now.


> I'll start making that. BTW, changes I've made:
> - Printing support is muuuuch better now. Should fix the black page bug
(at
> least it did here) and nets are shrinked to fit the page;

Incidentally, I don't have a printer added to this computer, so I just have
to take your word for it :-). Also, this means that I get a chance to see
when print-code "breaks" thing for computers without printer.

> - Numbered properties are returned in order according to your note;
> - The NullPointerException while loading files is fixed;

Indeed it is.


> > I not sure what you mean. I was assuming that the "ideal" resize mode
was
> > when the list stay at whatever size it has and only the drawing area
grows
> > and shrinks on resize.
>
> That's fine too. I thought of the equal ratio method because when you
> enlarged the window, you could have more place to read the reached states.

I hope we do agree, that with the current approach of setting the divider
location in order to "hide" the list, the list will appear when resizing
unless the split pane is set to only grow the left component. I would say,
that resizing the main window should be coulpled directly to resizing the
drawing area; if the user wants to see more of the list, he can just slide
the split pane divider. Of course, when the user selectes simulation, the
divider location should be set big enough for all the text in the list to
show.

BTW, how about using the compact notation (multiset notation) for states
that also is used in PetriReacheableStatesAnalysis? In time, I guess we need
to refactor such things into various "notation" or "policy" classes so that
its easier to change for us or the user.

> > I guess if we fix the copy/paste TextFigure warping bug, we don't need
the
> > other feature that much :)
>
> Ok. Anyway, the copy/paste bug is a nasty one...

Good luck hunting it down then :-)


> Well, the sorting is done inside JARP, so the actual
> order in the properties file is irrelevant. The only problem is if there
are
> two properties with the same number: the most recent will override the
older
> one.

This is, as you know, a problem with properties themselves. Fixing this
requires us to use something different for options (flat file, XML, etc.).

> Also, if there a number missing (1,2,3,5), all following numbers are
> ignored.

Hmm, if we sort then there is not much point in using numbers. I've taken
the liberty to refactor it slightly.


BTW, should I make a release now the basic features seem to run?

BR,
---
Filip Larsen <fil...@ma...>