Archive for the ‘Programming’ Category

Netbeaning it again

Friday, September 19th, 2008

I ran across this comment today:

[…] on more complex forms, [the Matisse GUI editor] becomes unbelievably frustrating and time-consuming. It tries to be too intelligent about what it thinks you want to do and often just moves things around wildly when trying to do simple adjustments or additions of components.

and another comment further down:

I’ve spent hours trying to get the layouts I want with it and it seems to be more trouble than it’s worth sometimes. Sometimes it insists on stretching and stretching my forms.

By this time, I’m banging on the desk shouting “Yes! That’s exactly what I’m seeing!”. Further down still:

About the Matisse problems; they rely on the layout. try changing the layout to NullLayout

Oooh, of course. That makes perfect sense.

One downside is that you need to do this before you start. I tried changing it on a complex window layout I’d manage to coax together, and it promptly collapsed all the controls into a heap. But I tried playing around with it in a test window and sure enough, I was able to drag around and place controls wherever I wanted without the annoying repositioning and resizing of other controls.

Apparently, I also lose some other features in this mode. Exactly what, I’m not sure, as I’ve only had a few minutes to play around with it. Maybe some of the fancy alignment tools have gone. I can probably live without that.

Look ‘n’ feel

I finally got my app running far enough to show me my window layout in all its glory. I was startled to see that the Windows XP appearance of the controls that I see in the GUI editor have been replaced with java-rendered equivalents. This is exactly what didn’t happen with the test application I made to make sure that this sort of thing wouldn’t happen. I’ve been hunting around in case there’s an option hidden somewhere that causes it to render controls in the native-OS form. No luck yet. I’m not sure what the difference is between my test app and the main app. Maybe it’s because I started the test app as a Java Desktop Application, whereas the main app started life as a JOGL app, and got additional windows added in.

I daren’t go any further with this until I see how it looks on a Mac. If I need to rebuild the app as a desktop app with JOGL window added in, I want to make sure that looks right on a Mac before I get too far down the path.

Netbeans 6

Saturday, August 9th, 2008

So I’m converting a C# app to Java and I’ve decided to use Netbeans as my editor. It’s been a while since I played with Netbeans, and last time I played with it, I didn’t really do anything major with it. Now I’ve got version 6.1 installed and this time I’m giving it a bit of a workout.

On the whole, I’m liking it. I started by creating a test application with a swing based window and OpenGL rendering, which forms the basis of what I’m aiming to do with it. Getting the OpenGL bindings – jogl – installed and linking was half google and half trial-and-error. It also took a little research to get the Java API docs downloaded and recognized by the IDE, but they’re there now.

Programming in Java is not something I’m terribly used to. I worked on J2ME programming for cell phones a few years ago, which seems worlds away from write J2SE apps for a desktop computer. The cell phones we were targetting at the time had so little space for the jar files that we had to think twice before creating a new class because of the additional jar space it would require. Oh, and I have floating-point arithmetic now, which is nice.

I’m starting with an almost line for line conversion of the C# app, which means cutting and pasting the code into Netbeans, then massaging it until all the red underlines disappear. A lot of this is pretty mindless (good for me!), e.g. a C# property Value { get; set } turns into a Java getValue() and setValue(). Netbeans feels sluggish compared to MS Developer Studio, but Netbeans also points out compile errors as you’re writing, rather than discover them at compile time. The Netbeans auto-completion functionality seems a bit too intrusive. Often I’m coming to a jarring halt in mid flow because it’s auto-completed something I wasn’t expecting and it takes a second or two to make sure I’m not ending with doubled code. It’s probably configurable, and seems intrusive because I’m not used to it.

One of the major changes to the app is the windows interface. The original is all built in C#/.NET Framework 2.0, and I’m re-implementing this using the swing toolset. This is where we come to Netbeans’ GUI designer.

Oh my life.

Initially, I thought it was pretty cool. Placement of controls within the window seemed pretty easy and the guides snapping controls into positions with reasonable borders and spacing seems superior to the GUI designer in Developer Studio. Great, I thought, this is going to take no time at all. Famous last works.

As the window contents became more complicated, strange things began to happen. I’d have five buttons in a row and go to add a sixth. When I try to position the sixth, a couple of the other five pop down the window by some random quantity, stretching the container. I try to push them back into position, but one won’t go. Every time I try to reposition it, it pops down by a bit more, again stretching the window.

When I was first using Microsoft’s gui designer, I found it to be an exercise in frustration, mainly because I didn’t fully understand the docking and anchoring mechansisms, and control orders, and being stuck with the old 1.1 .NET Framework and DevStudio 2003. The 2005 editor is much improved, and understanding how the window system works helps a great deal. I’m hoping there’s a similar trick to the Netbeans system, that some day it will suddenly make sense!

Maybe I need to rely more on frames – keep a minimum of controls within a frame, and use many frames to build the whole window.

Maybe I need to play around with the layout manager a bit more. I think that’s what it’s called. Seems to responsible for how controls are laid out within a container. There’s a particular mode that sounds like it allows completely free-form placement of control, which is what I’m expecting, but apparently requires an additional component to be added and distributed with the app.