This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Functional Reactive Programming and have Stephen Blackheath and Anthony Jones on-line!
See this thread for details.
Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Coding your GUI

 
Jeff Allison
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a pretty basic question about coding GUI's; hopefully this is the proper forum in which to ask.

I'm new to Java, although not new to software development. I'm writing a program that will communicate via RS232 to various timing and frequency boxes. The GUI isn't complex, a tabbed window with data getting reported in various fields on each tab. There will be (haven't started this bit yet) input fields for controlling the boxes as well. The question is this: how do you structure the code for your GUI? Do you lump all of the labels, panels, etc, into one big class called "UI?" Or do you break the pieces down into small classes, like one per tabbed panel or something?

The later approach seems more elegant, but at the same time it seems like you'll wind up with a lot of references and classes that don't really buy you anything. Normally you create a class for a well-defined piece of data. Splitting up the UI seems pretty arbitrary.

Thoughts?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Usually what I try and do is keep my UI Panels as modular as possible. So most of my classes will be panel classes. That is to say I will have several classes that extend JPanel. Other than that most things are jumbled together. Otherwise I run into inner-app communication problems between different components.
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With tabbed panels, I use one class per tab, in addition to an overall class for the interface. If tabs are internally complex, I may create additional classes, but these would be subordinate to the panels.

If you think of it from a user interface design perspective, it makes sense: the things that the user will be paying attention to at one time probably belong in the same class; things that aren't even visible at the same time, such as different tabs in a tabbed pane, probably belong in different classes.

I actually find that breaking down the classes this way is even more intuitive for a UI than for data.
 
Jeff Allison
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to Gregg & Warren for the responses. I've been prototyping for a week or so now so my UI code is a complete mess. Now that I've got some idea of what works and what doesn't it's time to step back and organize it properly. I think it makes sense to break things down along panel and/or tabbed pane lines. Not only will that make the code more manageable, it'll give me some flexibility in terms of setting up the UI a little differently for different boxes.

Thanks again.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic