[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.newcomer] Re: GUI builder for new projects

In article <b5005dfa4c00baf07421391b3d708eb4$1@xxxxxxxxxxxxxxx>, 
frecklefoot@xxxxxxxxx says...
> <ns_dkerber@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > What would be the appropriate project or package to use for building new
> > data-collection java applications with very simple gui requirements (a
> > couple of buttons, a small menu, and a scrolling textbox to display
> > data).
> 
> If that's all the GUI you have, it might be easy enough to code it by 
> hand.  It might be easier than trying to learn a new tool.  But if 
> "rolling your own" isn't your cup of tea, a visual editor might be the way 
> to go.

That's certainly a possibility, as simple as our application's needs 
are.  Can you point me to a basic reference for getting started hand-
coding a GUI?  I've done a bit (though not a lot) of searching with not 
much luck.

 
> > In article <grvtv5$1em$1@xxxxxxxxxxxxxxxxx>, eclipse-news@xxxxxxxxxxxx 
> > says...
> 
> > It does, but brings up one more question:  Swing or SWT, and why one 
> > over the other?  

...

> So, if you want "native look and feel," you should probably go with SWT.  
> If you want the app to look the same no matter was O/S it runs on, use 
> Swing.  From personal experience, Swing is pretty easy to use.  The 
> Wikipedia article also claims that SWT doesn't have as much functionality 
> as the Swing components, so that could also influence your decision.
> 
> Sorry this wasn't a "these components are better and this is why," but was 
> "it depends", but this is the way as most things in life...

Thanks!  I knew it would be an "it depends" answer, but was looking for 
"what does it depend on".  So, let me expound a bit:

In my application, I'm somewhat resource limited, especially RAM, and 
it's an industrial data collection application.  So most of the time 
nobody ever looks at it unless we need to do some troubleshooting (a 
couple times per year typically, and some haven't been touched in 3 or 4 
years).  Therefore, looking the same across platforms is a non-issue, as 
is "native" look-and-feel, while memory use could be an issue (I really 
need to avoid disk swapping in normal operation).  We can add more RAM 
to new machines if needed, but would prefer not to, and can't 
realistically add ram to machines that are already in the field when 
deploy new software.


Thanks!
-- 
/~\ The ASCII
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!

Remove the ns_ from if replying by e-mail (but keep posts in the 
newsgroups if possible).