Re: Fw: [OpenMap Users] OMDrawingTool and other questions

On the issue of:

>> 3. JFrame vs JDialog for floating windows

I have some code in my map handler which turns on the OpenMap support for
using JInternalFrames for dialogs. It seems to work OK and gets rid of the
pop-under problem.

My client didn't like the coffee cup logo on the title bar so I fixed that
too.
The comments below explain what I did. If you need the code in NIApp
that handles the events then let me know.

        // Tell OpenMap to use the desktop pane as the parent for the
        // JInternalFrames that is creates. NIApp places a
ContainerListener
        // on the desktop pane so that it gets notified of changes in
contents.
        // When a JInternalFrame is added (as opposed to one of our
        // NIChildFrames) the componentAdded event handler clobbers the
        // title bar icon and changes it from the default coffee cup
        // to one of our chosing.
        Environment.useInternalFrames(niApp.getDesktopPane());

regards,

Adrian

_____________________________________________

Adrian Lumsden
Product Specialist
Scientific Software and Systems Limited

Tel: +64 4 917-6680 (direct)
        +64 4 917-6670 (reception)
Fax: +64 4 917-6671
E-mail: Adrian.Lumsden@sss.co.nz

Visit us on the Web at: http://www.sss.co.nz
_____________________________________________

This e-mail passed SSS's content security scan.
It is covered by the confidentiality clauses at
http://www.sss.co.nz/content_and_confidentiality

Don Dietrick <dietrick@bbn.com>
Sent by: owner-openmap-users@bbn.com
11/09/03 08:47

 
        To: Piotr Kamiński <Piotr.Kaminski@ctm.gdynia.pl>
        cc: openmap-users@bbn.com
        Subject: Re: Fw: [OpenMap Users] OMDrawingTool and other questions

Hi Piotr,

Thanks for pinging again on these questions:

On Monday, September 8, 2003, at 10:04 AM, Piotr Kamiński wrote:

> Don,
> Any thoughts about questions below? I'm especially interested in your
> opinion about developing OpenMap own file format for storing drawings.
> I think that serialization is simple but makes to many complication
> when classes changes. If you preffer to use simple serializaition
> instead
> of some other solution (XML maybe?) I think it is indespensable to add
> serial Id to all serialized classes (whole omGraphics package).
> Best regards,
> Piotr Kaminski
>
> ----- Original Message -----
> From: "Piotr Kamiński" <Piotr.Kaminski@ctm.gdynia.pl>
> To: "Don Dietrick" <dietrick@bbn.com>
> Cc: <openmap-users@bbn.com>
> Sent: Thursday, July 17, 2003 11:11 AM
> Subject: [OpenMap Users] OMDrawingTool and other questions
>
>
>> Hello,
>>
>> I'd like to discuss some questions:
>> 1. how to save drawings made with OMDrawingTool to files
>> 2. how to load drawings from files for further edition
>> 3. JFrame vs JDialog for floating windows
>> 4. DrawingTool enchancement
>>
>> 1. 2.
>>
>> I'm using OpneMap in my application. One of user's reqirements
>> is: "Make drawings on map, store drawings in file on disk,
>> read drawing from file for further edition".
>>
>> I can use OMDrawingTool for edition, OK. I can save drawings
>> as 'Shape' file but during that process all additional attributes
>> (color, line thickness, and so on) are lost. If I try to read
>> shape file I have to set up parameters, (colors,..) but it works
>> for whole layer not for particular objects. One DrawingLayer
>> is saved to two files .shp and .sxx making it harder for user to
>> maintain. And I can't make further edition of stored drawings!
>>
>> As a quick (and ugly) solution for persistent storage
>> I choose serialization. We've made simple class which
>> takes OMGraphics list and stores it in file. Of course you can
>> read it too. (please see attached files GraphicEditExport and
>> GraphicEditImport). Unfortunatly durring serialization there was
>> error in class DrawingAttributes. This class uses BasicStroke
>> and BasicStrokeEditor which are not serializabe. I have to
>> changed two class fields to transient (see attached file
> DrawingAttributes).
>>
>> In export method:
>> 1. whole OMGraphicsList is stored to file
>> 2. all Stoke objects are break to field and those field are stored to
>> file
>>
>> In import method:
>> 1. whole OMGraphicsList is read from file
>> 2. all Stoke objects are read from file and set in OMGraphics objects.
>>
>> It works now. I can treat one GraphicEditLayer (similar to
>> DrawingLayer)
>> as one vector picture which I can save, load and edit.
>> One drawback is that serialization depend on internal class structure.
>> If I change one field, binary format also changes and I can't read
>> files saved in old format! Solution: don't use default serialization,
>> instaed write own methods for each object to save and load it, and
> carefully
>> add new field to ensure backward compatibility with files with older
> format.
>> Other solution is to use standard file format (maybe SVG?) or develop
>> own OpenMap graphics file format (XML based maybe?). What do you think
> about
>> it?

I was going to suggest SVG, since I assumes it handles Paints
(Textured, Gradient and Colors) and Strokes, and that's a lot less to
write. The batik package should handle this, but the OMGraphics have
to be smart enough to read and write their lat/lon coordinates instead
of their projected coordinates. A small thing to modify, though.

>> 3.
>> In my application main window is almost all time maximized on screen
>> to
>> display as big map as it can. When I launch my own dialog windows I
>> use
>> JDialog and set parent as main JFrame. It guarantee that dialog
>> window is allways over main frame. When I launch any OpenMap window
>> (especially OMDrawingToolLauncher) and click anywhere on main frame
>> this windows hides under main frame. It is very frustrating to the
>> user especially during edition of graphics. Is there any simple
>> method to lauch all windows as JDialog? Can WindowSupport be used to
>> this? Now it uses JInternalFrame or JFrame. I'd like to see JDialog
>> also possible to use. I wonder if any other OpenMap user find JFrame
>> windows uncomfortable to use?

Good point. I think that all of the OpenMap components that pop up a
frame now use the com.bbn.openmap.gui.WindowSupport object. That could
be modified to use a JDialog window instead just to compare the
behavior between the two.

>> 4. My user wants to use text in drawings. Standard OpenMap has OMText
>> class but not EditableOMText. We made such class with other needed
>> tools (OMTextLoader, and so on). It works almost good, but:
>> - create new text (using OMDrawingToolLauncher)
>> - change some attributes, text and it changes immediately on map
>> - finish editing
>> - choose gestures mouse mode
>> - select drawn text (window should appear on screen)
>> - change colour and it changes immediately
>> - BUT change text and it doesn't change!
>> - MOVE text on map and after that you can change all parameters and
>> changes appears immediately again
>>
>> The same situaltion is with polyline:
>> - draw open polyline
>> - ...
>> - select polyline for edition
>> - try closing polyline (and change is not visible)
>> - try changind line parameters (and change is not visible)
>> - move polyline a little and all works good again
>>
>> What's going on?

I'm not sure. I haven't tested the EditableOMText object yet. I have
seen weird behavior before in the EditableOMPoly, where after changing
the color the grab points stop changing the shape of the poly but allow
it to be moved, and I haven't been able to track that down. Come to
think of it, I haven't seen that behavior lately, so it might have been
fixed due to some recent changes in the poly states in the state
machine.

>> I hope all changes I've made could be included into main OpenMap
>> source
>> tree. You can modify it as you like. Now classes have
>> com.obrctm.openmap package
>> but you can move them to com.bbn.openmap.

Thanks for submitting them, we're still in the process of digesting
them.

>> I'd like to see some other enchancement in drawing tool. In one of
>> our porducts (written in C++ and Motif), we have graphics editor.
>> Users use it to draw additional layers on map (e.g. restricted
>> areas). To make it precisely they need to type (not click on map)
>> latitude and longitude of points. For polygons and polylines we used
>> dialog window with list of point. User could select any point and
>> modify it location, add points and remove points. Additionaly he/she
>> could click on map to quickly draw something, and then correct
>> locations in dialog window.
>>
>> Such dialog windows was used for all graphics objects (lines,
>> circles, rectangles, text, and so on). If such feature would be added
>> to OpenMap it could be used to make not just drawings but real and
>> precise layers. Storing those layer in files is indispensable (see
>> point 1., 2.) and own file format would be nice to have.

Seems like a change to OMGraphics, where they can provide a GUI to
control their location. Interesting feature. I'll add it to the list,
but I can't say when it would be implemented. The
com.bbn.openmap.layer.TestLayer does something similar, I think, but in
a layer's palette.

>> I'd like to see small change in OMDrawingToolLauncher:
>> add:
>> protected JComboBox requestors;
>>
>> public void setRequestor(String aName) {
>> if (requestors == null)
>> return;
>> requestors.setSelectedItem(aName);
>> }
>>
>> and use that field instead of local 'requestor' variable in method
>> resetGUI().

Done, I'll check it in when some other things with the launcher get
settled out, shortly.

Thanks for the questions and feedback,

Don

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Dietrick, BBN Technologies, dietrick@bbn.com
10 Moulton Street, Cambridge, MA 02138
617-873-3031 [fax]-2794
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe 
openmap-users"]
--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]