Recent changes to feature-requests

Support Bitmap Editing

Werner Randelshofer — Wed, 28 Mar 2007 11:26:46 -0000

Add support for bitmap editing tools to JHotDraw.

Maybe in a similar fashion like in Adobe Fireworks. So that Bitmap tools act on the currently selected BitmapFigure. If there is no BitmapFigure selected, a Bitmap tool creates a BitmapFigure first.

BitmapFigure could be an extension of the ImageFigure interface.

About Resizing GroupFigures

Carlos Diego Quirino Lima — Thu, 18 Jan 2007 23:01:02 -0000

I'd like to know how don't permit a GroupFigure resizes...

Someone know the property?

Thank you.

StorageOutput sub-classes forced to be order sensitive.

Andrew — Fri, 28 May 2004 18:59:34 -0000

The existing StorageOutput class presumes that the
storage format will be sensitive to the order in which
values are written. Consider the calls to the
StorageOutput.writeInt() methods made in the
ImageFigure.write() method:

<pre>
/**
* Writes the ImageFigure to a StorableOutput. Only a
reference to the
* image, that is its pathname is saved.
*/
public void write(StorableOutput dw) {
super.write(dw);
dw.writeInt(fDisplayBox.x);
dw.writeInt(fDisplayBox.y);
dw.writeInt(fDisplayBox.width);
dw.writeInt(fDisplayBox.height);
dw.writeString(fFileName);
}
</pre>
If the storage format is an SQL database which explicitly
requires sorting to avoid random results, this class may
not be re-created properly. An obvious work-around is
to have the output class generate sequential labels, but
it is better if the class writing the values also generated
the label and asked for it specifically. This could be
gracefully implemented by extending the attribute
system with class specific ones. (E.g.: visible figures
might have an attribute named 'bounding box').
Storage and restoral would then be primarily a matter of
pushing out all the attributes and bringing them back in
again with the class determining which attributes it
interprets internally and which it passes back up the
inheiritance hierarchy for storage. This approach to
attribute handling would also fit very naturally into
creation and organization of property sheets, scripted
manipulation of figures, implementation of classes as
Beans, storing the UIF (menus, floating or docked
toolbars and palettes, configurable mues and palettes,
etc.) as a configuration file instead of fixing it in code.

StorageOutput doesn't allow sub-classing.

Andrew — Fri, 28 May 2004 18:57:16 -0000

Any attempt to sub-class the StorageOutput class is
doomed to functional failure as the parent class will:
1. doesn't have a default constructor (preventing the
sub-class from NOT calling it's constructor),
2. doesn't allow any acces to the output stream it
inializes in the constructor, and
3. all of the output methods make assumptions about
the formatting to be done, so a sub-class can't
guarantee that the output file meets it's formatting
requirements.

Result of this problem is that anyone who needs to
handle additional storage formats (i.e.: XML, JDO, etc.)
will have to ignore the existing Visitor pattern
implementation and create a completely new (and
redundant) mechanism for their storage format.
Compare the following three classes which all have the
same objective:
- StandardStorageFormat,
- SVG StorageFormat, and
- JDOStorageFormat.
In the latter two cases, the StorageOutput and
StorageInput classes are completely ignored although
they could have been used to simplify and speed much
of the implementation.

Possible fixes include:
1. Create a default constructor which assigns nulls to
the internal members. (Then all of the methods need to
check for null every time they are called - quick but not
desireable.)

2. Change all/most of the private data members and
methods to protected so that a sub-class has access to
the existing functionality and can over-ride what it
needs to.

3. Provide protected 'raw write' methods for the output
stream.

private to protected

billyYo — Fri, 28 May 2004 11:07:46 -0000

Can you change the
method "DrawApplication.setStatusLine"
from privet to protected?

TextFigure needs an alignment attribute

Andrew — Tue, 18 May 2004 20:02:14 -0000

TextFigure should have an alignment attribute to specify
how to fit it within a bounding box which isn't perfectly
sized for the current font. This is particularly important
when converting the display for use in other systems.

Attribute Handling

Andrew — Tue, 18 May 2004 16:23:22 -0000

I am working on a project where essentially random
attributes are associated with any figure on the
display. The user is expected to be able to view and
change these attributes and we have run into two
problems:

1. There's no mechanism to list the current attributes
set on a figure which makes it impossible to create a
dialog to view all attributes and their values. The
following method was added to AttributeFigure to fix this
problem:

/**
* Returns the keys for all the named attributes
* *JK LOH
*/
public Enumeration getAttributeKeys() {
if (fAttributes == null)
return
fgDefaultAttributes.keys();
else
return fAttributes.keys();
}

2. Several figures are sub-classes of AbstractFigure
directly rather then AttributeFigure and therefore can't
have attributes assigned to them. We've modified all
the visible figures to derive from AttributeFigure to get
around this problem although more elegant solutions
undoubtly exist.

Group circles/spheres

Markus Elfring — Sun, 18 Apr 2004 15:54:37 -0000

Can objects in the graphics be placed on circles or spheres? I propose that elements can be grouped with their relationships by this layout feature into "bubbles". Each object can be connected with straight lines or "rays".
I assume that it can become difficult to draw a lot of bended lines in big diagrams.

DrawApplication -JPanel not JFrame

Wolfram Kaiser — Wed, 28 May 2003 11:19:23 -0000

I (pmorch) suggest (with a working large patch) that
the JFrame in JHotDraw's DrawApplication gets split out
into another class, allowing for applets to run
DrawApplications too.

See http://demo.capmon.dk/~pvm/jhotdraw/main.html for
working examples.

What do you think? Is this for inclusion in standard
JHotDraw or does nobody care?

Background: I have a need to run the samme application
in both an applet and as an application. I noticed
quite a lot of differences between DrawApplication and
DrawApplet. Especially that DrawApplication uses
PullDown menus and as been extended into a
MDI_DrawApplication and a SplitPaneDrawApplication. I
need that in my applet, regardless whether anyone else
does too...

The basic idea is that I've made DrawApplication extend
JPanel and not JFrame. DrawApplication now has a
reference to an ApplicationContext interface
(suggestions for a better name are welcome...) The
ApplicationContext does the things that the JPanel
can't do (e.g. setJMenuBar, setTitle()...). Two new
classes: CH.ifa.draw.application.DrawFrame and
CH.ifa.draw.application.DrawApplet both implement
ApplicationContext and extend JFrame and JApplet
respectively. They are short and simple. The bulk of
the intelligence still resides in DrawApplication.

Voila. DrawApplications can now run fine in both
JFrames and in JApplets.

Backwards compatibility consequences:

1) Several protected methods are now public, since they
need to be accessed from the ApplicationContext and not
directly from inside the class. If derivatives of
DrawApplication override these methods, they will get
compile-time errors. Change "protected" to "public" and
all is fine.

2) Calls in derived classes directly to JFrame methods
will fail. When DrawApplication no longer derives from
JFrame, obviously calls specific to a JFrame will no
longer work. Override DrawFrame for that functionality
instead.

3) Constructor to DrawApplication now takes an
ApplicationContext instance. So instead of:

public static void main(String[] args) {
MayDrawApp window = new MyDrawApp();
window.open();
}

it is now:
public static void main(String[] args) {
DrawFrame frame = new DrawFrame();
MayDrawApp application = new MyDrawApp(frame);
application.open();
}

I have provided a deprecated constructor with no
arguments that calls
this(new DrawFrame)
but that is for short-term deprecation, so this
consequence is still real.

4) Confusion about DrawApplet. There is now both a
applet.DrawApplet and an application.DrawApplet. Oh
well. If it bothers anyone we could call it
DrawApplicationApplet, I guess.

For application.DrawApplets, it is so now so easy:

public class MyApplet extends DrawApplet {
public void init() {
MyDrawApp appl = new MyDrawApp(this);
appl.open();
setContentPane(appl);
}
}

I've taken a look at
"Future plans forJHotDraw"
https://sourceforge.net/forum/forum.php?thread_id=676270&forum_id=39888
and to me it seems that this idea would apply equally
well to version 6. The actual code would have to change
to match the code changes in version6/DrawApplication.java

Sincerely,

Peter

Pluggable FigureAttributes

Wolfram Kaiser — Mon, 27 Jan 2003 23:45:17 -0000

Have the functionality of attribute maintainance in an
own component (not FigureAttribute) which could be used
by all other figures.