[Open-graphics] Google summer of code

[PcgScrapAddy]

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 <ViktorPracht at gmx.de> 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.
> 
> 
>