Stick with Netbeans, it is a nice IDE that costs nothing! JBuilder is commercial the last time I checked. Not to mention that if the extensions you write are a hit then you can sell them. Netbeans should provide everything needed to make a damn good designer. Have you looked into the framework (platform) page? Using the platform you build from the ground up instead of starting with everything (the IDE) and removing the bloat.

http://www.netbeans.org/features/platform/index.html

I'm not an Java expert but used Netbeans for a few years so I will dive in to help out as soon as I am setup. (new machine, etc.) After that I should be able to provide some ideas on how to abstract the UI from the underlying code.

Cheers,

Kevin


Timothy Normand Miller wrote:
On 3/3/08, Viktor Pracht <[EMAIL PROTECTED]> wrote:
Timothy Normand Miller wrote:

 > We're not doing physical floor-planning here.  We're doing high-level
 > Verilog modules.  P&R isn't involved.  Or do you mean P&R in terms of
 > how the Verilog modules are placed and routed visually in the IDE?


I mean the latter. The algorithms will have very much in common with other
 P&R tasks, except that we *want* to stay in a local optimum. One one hand,
 you don't want to align everything manually. On the other hand, you don't
 want your entire schematic to be completely scrambled just because you
 added a single wire. Mirroring the thoughts of the developer is more
 important than having the tightest layout.

For a first run, let's make the placement manual.  The routing will
always have to be manual anyhow.  The main instance where automatic
would be useful is when we're importing existing code.  Then, we want
something half-way sensible on the screen, even though the user will
still have to move things around a bit.

 > Check out NetBeans.  Create a simple Swing app.  Notice how there are
 > bits of auto-generated code that are hidden by default by the editor
 > but can be expanded to show comments loudly warning about not editing
 > this section of code.


NetBeans sucks. Check out JBuilder.

I'll have a look some time.  I use NetBeans not because it's it's the
best but because I have invested some time into figuring out how to
use it.  If I switch, I'll have to learn another tool.  I'm trying to
minimize cognitive load here, which is why I decided to use Java (for
the UI elements) and an IDE in the first place.

 Nothing is hidden and there are no scary warnings anywhere. When you edit
 the size of a widget, the visual editor updates to reflect the change.

I was suggesting that the hiding thing was a benefit.  You can always unhide it.

We don't need to get into a debate on the better IDE.  Let's just use
an IDE.  I'm not very proficient with Java, but Java's GUI system
(Swing, etc.) is very well integrated, and I don't want to screw
around with something else.  Since I'm not proficient with Java, I
want an IDE that will let me browse and search the class hierarchy,
show me what methods are available and their parameters, etc.

 > We can do the same thing.  Some of our stuff is
 > metadata, and when the metadata is missing (for instance from an
 > import of existing code), then we just default to something sensible.
 > Lots of our stuff is auto-generated code that describes the
 > interconnects between modules.  The most important part of this, to
 > me, is the interconnecting glue modules that tie other blocks
 > together, because this is the place where I make the most mistakes.


All semantically relevant data will be stored as Verilog code. This is an
 important difference between our case and a GUI editor: the 2D layout of
 the schematic is thrown away for synthesis, while the layout of a GUI is
 one of the most important parts.

 This difference is also the reason why I prefer the single-file approach.
 There will be no Verilog code which the user can't edit. Only the comments
 with the 2D information will need special handling. I hope to reduce that
 special handling to "keep the comment together with the clause it was
 generated for", but otherwise allow any syntactically valid modifications
 of the Verilog code, including adding human-readable comments.

Yeah.  Now, this has to be on a per-instance basis.  It's not where
the module is defined but where it's instantiated that we need to have
these things.  We need something like this:

some_module /* position: X,Y */ instance_name(
    .some_port(local_wire) /* position: left,offset */,
    ...
);

Oh, and positions should be proportional.  That is, if you resize an
instance, the port spacing should grow or shrink accordingly.

 If there is a P&R algorithm which can locally optimize a layout, the
 comments only need to encode *which* local optimum to generate. My first
 approach would be to specify a "floor plan", and leave the routing and the
 alignment of blocks to the optimizer. Could this work in real time?

Possibly.  I'm starting to think about use cases for this and how some
automatic stuff would be helpful.  I want to drop in a module and wire
it up, and I don't want to muck about with fiddly details.  For common
templates (like pipeline stages), the ports would default to something
that would generally not require them to be moved.

Plus, it might be cool to have some kind of lego-snap like thing,
where if you bring two modules together in some way, wires
automatically get inserted.  So you bring them together, then apart
and position how you like, and you're done.  If you want to remove all
the wires, rubber-band select all of them and press Delete.



_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to