Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21825 > unrolled thread

Editable issues

Back to article view | Back to comp.lang.java.programmer

Contents

  Editable issues K <kalezwe@gmail.com> - 2013-01-28 21:19 -0800
    Re: Editable issues Mikhail Vladimirov <vladimirow@mail.ru> - 2013-01-28 22:21 -0800
      Re: Editable issues Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-28 23:17 -0800
        Re: Editable issues Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-29 06:27 -0400
          Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-01-29 22:02 -0500
            Re: Editable issues Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-30 07:38 -0400
              Re: Editable issues Lew <lewbloch@gmail.com> - 2013-01-30 08:32 -0800
                Re: Editable issues Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-30 19:34 -0400
                  Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-01-30 20:04 -0500
                    Re: Editable issues Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-31 06:21 -0400
                      Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-01-31 11:10 -0500
                Re: Editable issues Roedy Green <see_website@mindprod.com.invalid> - 2013-01-31 04:15 -0800
                  Re: Editable issues Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-31 07:26 -0800
                    Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-01-31 11:04 -0500
                      Re: Editable issues Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-31 16:54 -0800
                        Re: Editable issues Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-01 04:59 -0400
                        Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-02-01 20:08 -0500
                          Re: Editable issues Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-01 21:54 -0400
                            Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-02-02 12:21 -0500
                              Re: Editable issues Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-02 15:37 -0400
                          Re: Editable issues Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-01 18:12 -0800
                            Re: Editable issues Roedy Green <see_website@mindprod.com.invalid> - 2013-02-01 20:33 -0800
                              Re: Editable issues Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-01 23:39 -0800
                            Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-02-02 12:16 -0500
                              Re: Editable issues Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-02 09:59 -0800
                                Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-02-02 21:05 -0500
                                  Re: Editable issues Gene Wirchenko <genew@telus.net> - 2013-02-04 14:18 -0800
                                    Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:23 -0500
                          Re: Editable issues Gene Wirchenko <genew@telus.net> - 2013-02-04 14:11 -0800
                            Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:17 -0500
                    Re: Editable issues Roedy Green <see_website@mindprod.com.invalid> - 2013-02-01 05:05 -0800
              Re: Editable issues Arne Vajhøj <arne@vajhoej.dk> - 2013-01-30 20:03 -0500
    Re: Editable issues Roedy Green <see_website@mindprod.com.invalid> - 2013-01-29 02:38 -0800

Page 1 of 2  [1] 2  Next page →

#21825 — Editable issues

I made a java program and can't figure out why my uneditable text can still be edited.  I have 2 classes in this program here's the secondary class:
import java.awt.FlowLayout;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import javax.swing.JTextField;
import javax.swing.JPasswordField;
import javax.swing.JOptionPane;
import javax.swing.JFrame;
import javax.swing.JButton;
import javax.swing.Icon;
import javax.swing.ImageIcon;
import javax.swing.JLabel;

public class GUI_two extends JFrame{

	private JTextField item2;
	private JTextField item3;
	private JTextField item4;	
	private JPasswordField itempass;
	ImageIcon image = new ImageIcon("star.png");
	public GUI_two(){
	super("Kale");
	setLayout(new FlowLayout());
	item2 = new JTextField(10);
	add(item2);
	item3 = new JTextField("Enter text here");
	item3.setEditable(false);
	add(item3);
	item4 = new JTextField("Can't edit", 20);
	item3.setEditable(false);
	add(item4);
	itempass = new JPasswordField ("Password");
	add(itempass);
	reg = new JButton("Button");
	add(reg);
	Icon b = new ImageIcon(getClass().getResource("Button 2.png"));
	Icon a = new ImageIcon(getClass().getResource("Button.png"));
	custom = new JButton("Custom", a);
	custom.setRolloverIcon(b);	
	add(custom);
	
	thehandler handler = new thehandler();
	item2.addActionListener(handler);
	item3.addActionListener(handler);
	item4.addActionListener(handler);
	itempass.addActionListener(handler);
	reg.addActionListener(handler);
	custom.addActionListener(handler);
	
	}
	
	private JButton reg;
	private JButton custom;
	
	private class thehandler implements ActionListener{
		public void actionPerformed(ActionEvent event){
			String string = "";
			if(event.getSource()==item2){
				string=String.format("field 2: %s", event.getActionCommand());}
			else if (event.getSource()==item3)
			string=String.format("field 3: %s", event.getActionCommand());
			else if (event.getSource()==item4)
			string=String.format("field 4: %s", event.getActionCommand());
			else if (event.getSource()==itempass)
			string=String.format("itempass is : %s", event.getActionCommand());
			
			
			//JOptionPane.showMessageDialog(null, String.format("%s, event.getActionCommand()"));			
			JOptionPane.showMessageDialog(null, string);
		}
			}
	

}

here's the main class:
import javax.swing.JOptionPane;
import javax.swing.JFrame;

public class Kale_GUI {

	
	public static void main(String[] args) {
		String fn = JOptionPane.showInputDialog("Enter first number");
		String sn = JOptionPane.showInputDialog("Enter second number");
		int num1 = Integer.parseInt(fn)	;	
		int num2 = Integer.parseInt(sn)	;
		int sum = num1 + num2;
		JOptionPane.showMessageDialog(null, "The answer is "+sum, "The title", JOptionPane.PLAIN_MESSAGE);

		 GUI_two kale = new GUI_two();
		  
		 kale.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		 kale.setSize(500,500);
		 kale.setVisible(true);
	}

}

 

[toc] | [next] | [standalone]

#21826

> 	item3 = new JTextField("Enter text here");
> 	item3.setEditable(false);
> 	add(item3);
> 	item4 = new JTextField("Can't edit", 20);
> 	item3.setEditable(false);
> 	add(item4);
Probably because you did setEditable (false) on item3 twice, and didn't do it on item4?

[toc] | [prev] | [next] | [standalone]

#21827

On Mon, 28 Jan 2013 22:21:25 -0800 (PST), Mikhail Vladimirov wrote:

>> 	item3 = new JTextField("Enter text here");
>> 	item3.setEditable(false);
>> 	add(item3);
>> 	item4 = new JTextField("Can't edit", 20);
>> 	item3.setEditable(false);
>> 	add(item4);
> Probably because you did setEditable (false) on item3 twice, and didn't do it on item4?

Copy/paste rears its ugly head again. A helper method would have prevented
the mistake:

  JTextField addUneditable(String text)
  {
    return addUneditable(text, 0);
  }

  JTextField addUneditable(String text, int columns)
  {
    JTextField item = new JTextField(text, columns);

    item.setEditable(false);
    add(item);

    return item;
  }

  public GUI_two()
  {
    ...
    item3 = addUneditable("Enter text here");
    item4 = addUneditable("Can't edit", 20);
    ...
  }

[toc] | [prev] | [next] | [standalone]

#21832

On 01/29/2013 03:17 AM, Peter Duniho wrote:
> On Mon, 28 Jan 2013 22:21:25 -0800 (PST), Mikhail Vladimirov wrote:
>
>>> 	item3 = new JTextField("Enter text here");
>>> 	item3.setEditable(false);
>>> 	add(item3);
>>> 	item4 = new JTextField("Can't edit", 20);
>>> 	item3.setEditable(false);
>>> 	add(item4);
>> Probably because you did setEditable (false) on item3 twice, and didn't do it on item4?
>
> Copy/paste rears its ugly head again. A helper method would have prevented
> the mistake:
[ SNIP ]

Helper method probably best. I'd also name variables better, and 
declare/define and do everything with them in one spot demarcated by WS, 
if possible, e.g.:

private JTextField nameTextFld;
nameTextFld = new JTextField("Enter name");
nameTextFld.setEditable(false);
add(nameTextFld);
MyActionListener aLsnr = new MyActionListener();
nameTextFld.addActionListener(aLsnr);

We've had this discussion before, blocks also ensure that erroneous copy 
& paste (for situations like this) also fails.

I barely ever use Swing, so I won't comment on the ActionListener 
implementation. I do know it's fairly wrong-looking and just plain ugly. 
I'm myself not going to have a spaghetti event handler that looks to see 
who fired it out of many possibilities.

Main problem here is that in 2013 we still have people hand-cranking 
Swing code. It's ugly, tedious, unedifying, error-prone code. It's worse 
than JSF boilerplate and that's saying quite a lot.

.NET tooling has Java beat in this regard.

AHS

[toc] | [prev] | [next] | [standalone]

#21849

On 1/29/2013 5:27 AM, Arved Sandstrom wrote:
> Main problem here is that in 2013 we still have people hand-cranking
> Swing code. It's ugly, tedious, unedifying, error-prone code. It's worse
> than JSF boilerplate and that's saying quite a lot.
>
> .NET tooling has Java beat in this regard.

I strongly suspect that it is not:

lack of GUI builder tools => desire to hand write Swing code

but instead:

desire to hand write Swing code => lack of GUI builder tools

Arne

[toc] | [prev] | [next] | [standalone]

#21866

On 01/29/2013 11:02 PM, Arne Vajhøj wrote:
> On 1/29/2013 5:27 AM, Arved Sandstrom wrote:
>> Main problem here is that in 2013 we still have people hand-cranking
>> Swing code. It's ugly, tedious, unedifying, error-prone code. It's worse
>> than JSF boilerplate and that's saying quite a lot.
>>
>> .NET tooling has Java beat in this regard.
>
> I strongly suspect that it is not:
>
> lack of GUI builder tools => desire to hand write Swing code
>
> but instead:
>
> desire to hand write Swing code => lack of GUI builder tools
>
> Arne
>
If I parse your English correctly, Arne, you're suggesting that folks 
*prefer* to code Swing directly rather than make use of GUI builder 
interfaces?

Man, I'm not sure I buy that. I've suffered through writing Swing code 
from scratch a few times, I don't see how it's any more useful to do 
that than hand-coding JSF Facelets .xhtml and backing bean boilerplate. 
Which is to say, not useful at all. You gain nothing over using GUI 
builder tools, and you lose time better spent on real logic.

AHS

[toc] | [prev] | [next] | [standalone]

#21872

Arved Sandstrom wrote:
> Arne Vajh�j wrote:
> > I strongly suspect that it is not:
> > lack of GUI builder tools => desire to hand write Swing code
> > but instead:
> > desire to hand write Swing code => lack of GUI builder tools
> 
> If I parse your English correctly, Arne, you're suggesting that folks 
> *prefer* to code Swing directly rather than make use of GUI builder 
> interfaces?

No, he's suggesting that in this particular case the person might be deliberately 
doing it by hand. I guess programmers do that when they want to learn what they're 
actually doing.

> Man, I'm not sure I buy that. I've suffered through writing Swing code 
> from scratch a few times, I don't see how it's any more useful to do 
> that than hand-coding JSF Facelets .xhtml and backing bean boilerplate. 
> Which is to say, not useful at all. You gain nothing over using GUI 
> builder tools, and you lose time better spent on real logic.

Yes, even you have written Swing by hand. What's so odd that others might also?

Didn't the experience teach you about Swing? That wasn't useful?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21891

On 01/30/2013 12:32 PM, Lew wrote:
> Arved Sandstrom wrote:
>> Arne Vajh�j wrote:
>>> I strongly suspect that it is not:
>>> lack of GUI builder tools => desire to hand write Swing code
>>> but instead:
>>> desire to hand write Swing code => lack of GUI builder tools
>>
>> If I parse your English correctly, Arne, you're suggesting that folks
>> *prefer* to code Swing directly rather than make use of GUI builder
>> interfaces?
>
> No, he's suggesting that in this particular case the person might be deliberately
> doing it by hand. I guess programmers do that when they want to learn what they're
> actually doing.
>
>> Man, I'm not sure I buy that. I've suffered through writing Swing code
>> from scratch a few times, I don't see how it's any more useful to do
>> that than hand-coding JSF Facelets .xhtml and backing bean boilerplate.
>> Which is to say, not useful at all. You gain nothing over using GUI
>> builder tools, and you lose time better spent on real logic.
>
> Yes, even you have written Swing by hand. What's so odd that others might also?
>
> Didn't the experience teach you about Swing? That wasn't useful?
>
During the learning phase, sure. Makes sense.

But in routine work, once I've gotten the technology, no, I don't want 
to write all the tedious boilerplate. Swing, JSF, JPA etc - I generate 
as much as I can if I can, or I wish I could if it's not possible. All I 
really want to spend my time on is modifying the generated code.

AHS

[toc] | [prev] | [next] | [standalone]

#21893

On 1/30/2013 6:34 PM, Arved Sandstrom wrote:
> On 01/30/2013 12:32 PM, Lew wrote:
>> Arved Sandstrom wrote:
>>> Arne Vajh�j wrote:
>>>> I strongly suspect that it is not:
>>>> lack of GUI builder tools => desire to hand write Swing code
>>>> but instead:
>>>> desire to hand write Swing code => lack of GUI builder tools
>>>
>>> If I parse your English correctly, Arne, you're suggesting that folks
>>> *prefer* to code Swing directly rather than make use of GUI builder
>>> interfaces?
>>
>> No, he's suggesting that in this particular case the person might be
>> deliberately
>> doing it by hand. I guess programmers do that when they want to learn
>> what they're
>> actually doing.
>>
>>> Man, I'm not sure I buy that. I've suffered through writing Swing code
>>> from scratch a few times, I don't see how it's any more useful to do
>>> that than hand-coding JSF Facelets .xhtml and backing bean boilerplate.
>>> Which is to say, not useful at all. You gain nothing over using GUI
>>> builder tools, and you lose time better spent on real logic.
>>
>> Yes, even you have written Swing by hand. What's so odd that others
>> might also?
>>
>> Didn't the experience teach you about Swing? That wasn't useful?
>>
> During the learning phase, sure. Makes sense.
>
> But in routine work, once I've gotten the technology, no, I don't want
> to write all the tedious boilerplate. Swing, JSF, JPA etc - I generate
> as much as I can if I can, or I wish I could if it's not possible. All I
> really want to spend my time on is modifying the generated code.

That requires the generated code to be as good as handwritten code
to work.

That is rarely the case.

Arne

[toc] | [prev] | [next] | [standalone]

#21915

On 01/30/2013 09:04 PM, Arne Vajhøj wrote:
> On 1/30/2013 6:34 PM, Arved Sandstrom wrote:
>> On 01/30/2013 12:32 PM, Lew wrote:
>>> Arved Sandstrom wrote:
>>>> Arne Vajh�j wrote:
>>>>> I strongly suspect that it is not:
>>>>> lack of GUI builder tools => desire to hand write Swing code
>>>>> but instead:
>>>>> desire to hand write Swing code => lack of GUI builder tools
>>>>
>>>> If I parse your English correctly, Arne, you're suggesting that folks
>>>> *prefer* to code Swing directly rather than make use of GUI builder
>>>> interfaces?
>>>
>>> No, he's suggesting that in this particular case the person might be
>>> deliberately
>>> doing it by hand. I guess programmers do that when they want to learn
>>> what they're
>>> actually doing.
>>>
>>>> Man, I'm not sure I buy that. I've suffered through writing Swing code
>>>> from scratch a few times, I don't see how it's any more useful to do
>>>> that than hand-coding JSF Facelets .xhtml and backing bean boilerplate.
>>>> Which is to say, not useful at all. You gain nothing over using GUI
>>>> builder tools, and you lose time better spent on real logic.
>>>
>>> Yes, even you have written Swing by hand. What's so odd that others
>>> might also?
>>>
>>> Didn't the experience teach you about Swing? That wasn't useful?
>>>
>> During the learning phase, sure. Makes sense.
>>
>> But in routine work, once I've gotten the technology, no, I don't want
>> to write all the tedious boilerplate. Swing, JSF, JPA etc - I generate
>> as much as I can if I can, or I wish I could if it's not possible. All I
>> really want to spend my time on is modifying the generated code.
>
> That requires the generated code to be as good as handwritten code
> to work.
>
> That is rarely the case.
>
> Arne
>
>
I disagree that the generated code needs to be as good as handwritten 
code. Handwritten code at what stage - initial layout? Final layout? 
Styled and beautiful? All the actions added? Actions all do something real?

You see my argument? At what point do you consider the handwritten code 
to be done?

What I see as a complete waste of time is handwriting the code for 
layout, for geometry. The generated code only has to give you an 
initial, compilable decent representation of layout, that is all. It 
doesn't have to be as good as several of the later hand-tuned stages.

AHS

[toc] | [prev] | [next] | [standalone]

#21928

On 1/31/2013 5:21 AM, Arved Sandstrom wrote:
> On 01/30/2013 09:04 PM, Arne Vajhøj wrote:
>> On 1/30/2013 6:34 PM, Arved Sandstrom wrote:
>>> On 01/30/2013 12:32 PM, Lew wrote:
>>>> Arved Sandstrom wrote:
>>>>> Arne Vajh�j wrote:
>>>>>> I strongly suspect that it is not:
>>>>>> lack of GUI builder tools => desire to hand write Swing code
>>>>>> but instead:
>>>>>> desire to hand write Swing code => lack of GUI builder tools
>>>>>
>>>>> If I parse your English correctly, Arne, you're suggesting that folks
>>>>> *prefer* to code Swing directly rather than make use of GUI builder
>>>>> interfaces?
>>>>
>>>> No, he's suggesting that in this particular case the person might be
>>>> deliberately
>>>> doing it by hand. I guess programmers do that when they want to learn
>>>> what they're
>>>> actually doing.
>>>>
>>>>> Man, I'm not sure I buy that. I've suffered through writing Swing code
>>>>> from scratch a few times, I don't see how it's any more useful to do
>>>>> that than hand-coding JSF Facelets .xhtml and backing bean
>>>>> boilerplate.
>>>>> Which is to say, not useful at all. You gain nothing over using GUI
>>>>> builder tools, and you lose time better spent on real logic.
>>>>
>>>> Yes, even you have written Swing by hand. What's so odd that others
>>>> might also?
>>>>
>>>> Didn't the experience teach you about Swing? That wasn't useful?
>>>>
>>> During the learning phase, sure. Makes sense.
>>>
>>> But in routine work, once I've gotten the technology, no, I don't want
>>> to write all the tedious boilerplate. Swing, JSF, JPA etc - I generate
>>> as much as I can if I can, or I wish I could if it's not possible. All I
>>> really want to spend my time on is modifying the generated code.
>>
>> That requires the generated code to be as good as handwritten code
>> to work.
>>
>> That is rarely the case.

> I disagree that the generated code needs to be as good as handwritten
> code. Handwritten code at what stage - initial layout? Final layout?
> Styled and beautiful? All the actions added? Actions all do something real?
>
> You see my argument? At what point do you consider the handwritten code
> to be done?
>
> What I see as a complete waste of time is handwriting the code for
> layout, for geometry. The generated code only has to give you an
> initial, compilable decent representation of layout, that is all. It
> doesn't have to be as good as several of the later hand-tuned stages.

Ah.

Then I think we are pretty close to agreement.

When writing GUI code, then I typical either copy paste from
somewhere else or use a GUI builder to get "something" and
then manual edit it from there.

(not so much GUI builder in Java since switching from JBuilder
to Eclipse)

Arne

[toc] | [prev] | [next] | [standalone]

#21918

On Wed, 30 Jan 2013 08:32:09 -0800 (PST), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>No, he's suggesting that in this particular case the person might be delibe=
>rately=20
>doing it by hand

There is a generic problem with generators.  If for any reason you
have to modify the generated code, it becomes impossible to maintain. 
If you change at a high level your tweakings will be lost.  If you
change at a low level, you must deal with the generated spaghetti.

You need a very good separation of visual and any other logic, so the
generator deals purely with visual code, with no need to jump outside
its box.

Generators sometimes give you stubs to insert your own code, but
figuring out how to use them is often much harder than just writing
the whole thing out long hand.

The other generic problem with generators is they are one more tool
you and anyone modifying your code has to learn.  This drawback
suggests if you only have a little bit of visual code you should spell
it out longhand.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development 
time. 
~ Tom Cargill  Ninety-ninety Law 

[toc] | [prev] | [next] | [standalone]

#21924

On Thu, 31 Jan 2013 04:15:57 -0800, Roedy Green wrote:

> On Wed, 30 Jan 2013 08:32:09 -0800 (PST), Lew <lewbloch@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
> 
>>No, he's suggesting that in this particular case the person might be delibe=
>>rately=20
>>doing it by hand
> 
> There is a generic problem with generators.  If for any reason you
> have to modify the generated code, it becomes impossible to maintain. [...]

This may be true of poorly designed GUI editors. But frankly, it does not
_have_ to be true of all editors. In fact, to Arved's previous point, it's
been my experience that the code generated by Microsoft's tools is very
maintainable.

The .NET WinForms GUI designer doesn't do anything except the initial
initialization. This includes layout, initial property settings (such as
color, text, customizing behaviors such as read-only text, etc.), and
hooking up event handlers ("listeners" in Java-jargon).

Customization of behavior involves overriding event responses, either with
an actual virtual member override or in an event handler implementation,
depending on specific needs and the situation. It's quite easy to do those
things without abandoning the designer-generated code, or even the designer
itself.

Similar things are true for the WPF designers, though it's taken some time
for Microsoft to evolve to a nice, seamless, integrated toolset there. (In
earlier versions of WPF, there was a rudimentary designer in Visual Studio,
while Microsoft expected the heavy lifting to be done in Expression
Blend...my understanding is that in VS2012, they are shifting the Blend
designer functionality back into the IDE).

For that matter, while I have learned to loathe Apple's development
environment Xcode, this is primarily because I don't like Objective-C. Even
a decade ago, they had a reasonably workable GUI editor. My main complaint
back then was lack of integration into the code editor. More recently,
Xcode and their "Interface Builder" have become more tightly integrated.
Either way, I doubt that there's any significant number of programmers
writing modern code (i.e. Cocoa-based) for Apple's OSs that does everything
by hand, or even close to everything.

I've used and become disgusted with at least one iteration each of Java GUI
designers in Eclipse and Netbeans, so I understand where Arne is coming
from when he suggests you can always write better GUI code by hand in Java.

But that's hardly something that _has_ to be true. It just happens to be
true for the lame GUI designers that Java programmers have been subjected
to.

Pete

[toc] | [prev] | [next] | [standalone]

#21927

On 1/31/2013 10:26 AM, Peter Duniho wrote:
> On Thu, 31 Jan 2013 04:15:57 -0800, Roedy Green wrote:
>
>> On Wed, 30 Jan 2013 08:32:09 -0800 (PST), Lew <lewbloch@gmail.com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> No, he's suggesting that in this particular case the person might be delibe=
>>> rately=20
>>> doing it by hand
>>
>> There is a generic problem with generators.  If for any reason you
>> have to modify the generated code, it becomes impossible to maintain. [...]
>
> This may be true of poorly designed GUI editors. But frankly, it does not
> _have_ to be true of all editors. In fact, to Arved's previous point, it's
> been my experience that the code generated by Microsoft's tools is very
> maintainable.
>
> The .NET WinForms GUI designer doesn't do anything except the initial
> initialization. This includes layout, initial property settings (such as
> color, text, customizing behaviors such as read-only text, etc.), and
> hooking up event handlers ("listeners" in Java-jargon).
>
> Customization of behavior involves overriding event responses, either with
> an actual virtual member override or in an event handler implementation,
> depending on specific needs and the situation. It's quite easy to do those
> things without abandoning the designer-generated code, or even the designer
> itself.
>
> Similar things are true for the WPF designers, though it's taken some time
> for Microsoft to evolve to a nice, seamless, integrated toolset there. (In
> earlier versions of WPF, there was a rudimentary designer in Visual Studio,
> while Microsoft expected the heavy lifting to be done in Expression
> Blend...my understanding is that in VS2012, they are shifting the Blend
> designer functionality back into the IDE).

> I've used and become disgusted with at least one iteration each of Java GUI
> designers in Eclipse and Netbeans, so I understand where Arne is coming
> from when he suggests you can always write better GUI code by hand in Java.
>
> But that's hardly something that _has_ to be true. It just happens to be
> true for the lame GUI designers that Java programmers have been subjected
> to.

I don't like the code generated by VS.

But there is one big advantage there. The partial class concept allows
to nicely separate the generated stuff from the manual written stuff.

Arne

[toc] | [prev] | [next] | [standalone]

#21944

On Thu, 31 Jan 2013 11:04:38 -0500, Arne Vajhøj wrote:

> I don't like the code generated by VS.

I don't have to like it, as long as I don't have to see it or mess with it.

And with the VS Designer, I don't have to. Even when customizing the UI to
suit my needs, nothing about the Designer-generated code has to be touched.

> But there is one big advantage there. The partial class concept allows
> to nicely separate the generated stuff from the manual written stuff.

But even prior to partial classes, the IDE used code regions to collapse
the Designer-generated code. Either way, it doesn't really matter what's in
the generated code, as long as it does what it's supposed to and the
programmer doesn't have to mess with it directly (whether to customize the
GUI behavior, or for some other reason).

And in VS, that's how it is.

It's true that without the partial class feature, a Java-oriented GUI
designer couldn't be quite as seamless as what one finds in the .NET
toolset. But I think someone with sufficient motivation could in fact write
a GUI editor that works practically as well, even without that.

They just don't seem to have yet. And IMHO this is one reason why at least
some people eschew using Java for desktop apps. It's certainly a
significant factor in why I stopped bothering and went back to using .NET
for my day-to-day ad hoc projects.

I can't prove that I'm typical. But it's likely I'm not entirely unique
either. :)

Pete

[toc] | [prev] | [next] | [standalone]

#21950

On 01/31/2013 08:54 PM, Peter Duniho wrote:
> On Thu, 31 Jan 2013 11:04:38 -0500, Arne Vajhøj wrote:
>
>> I don't like the code generated by VS.
>
> I don't have to like it, as long as I don't have to see it or mess with it.
>
> And with the VS Designer, I don't have to. Even when customizing the UI to
> suit my needs, nothing about the Designer-generated code has to be touched.
>
>> But there is one big advantage there. The partial class concept allows
>> to nicely separate the generated stuff from the manual written stuff.
>
> But even prior to partial classes, the IDE used code regions to collapse
> the Designer-generated code. Either way, it doesn't really matter what's in
> the generated code, as long as it does what it's supposed to and the
> programmer doesn't have to mess with it directly (whether to customize the
> GUI behavior, or for some other reason).
>
> And in VS, that's how it is.
>
> It's true that without the partial class feature, a Java-oriented GUI
> designer couldn't be quite as seamless as what one finds in the .NET
> toolset. But I think someone with sufficient motivation could in fact write
> a GUI editor that works practically as well, even without that.
>
> They just don't seem to have yet. And IMHO this is one reason why at least
> some people eschew using Java for desktop apps. It's certainly a
> significant factor in why I stopped bothering and went back to using .NET
> for my day-to-day ad hoc projects.
>
> I can't prove that I'm typical. But it's likely I'm not entirely unique
> either. :)
>
> Pete

+1. That's how I see it, all of it, except better phrased. I also don't 
much care about the VS-generated code, although I find it tolerable at 
worst, pretty decent usually. Fact is, as Pete points out, it don't 
matter - I can concentrate on interesting stuff and if I change layout 
later VS won't trample it.

I also cannot see why someone couldn't write decent code generators for 
AWT or now Swing, or JSF. As I pointed out previously, people have 
accomplished just this, in Java and for Java/XML source, for process 
designers and SOA type tools, which is considerably more complicated. So 
I don't know why this is so bloody difficult.

Like I mentioned to Arne, I already have my workaround, because I can't 
stand to waste my time writing JSF boilerplate. Thankfully I don't have 
to write Swing - I've managed to stick to .NET for desktop GUIs.

AHS

[toc] | [prev] | [next] | [standalone]

#21992

On 1/31/2013 7:54 PM, Peter Duniho wrote:
> On Thu, 31 Jan 2013 11:04:38 -0500, Arne Vajhøj wrote:
>
>> I don't like the code generated by VS.
>
> I don't have to like it, as long as I don't have to see it or mess with it.
>
> And with the VS Designer, I don't have to. Even when customizing the UI to
> suit my needs, nothing about the Designer-generated code has to be touched.
>
>> But there is one big advantage there. The partial class concept allows
>> to nicely separate the generated stuff from the manual written stuff.
>
> But even prior to partial classes, the IDE used code regions to collapse
> the Designer-generated code.

Yes.

But that does avoid mixing generated and non generated up in source
control.

Or having to view the generated code when using a plain editor/

>                           Either way, it doesn't really matter what's in
> the generated code, as long as it does what it's supposed to and the
> programmer doesn't have to mess with it directly (whether to customize the
> GUI behavior, or for some other reason).

But of one do need to mess with it, then ...

> And in VS, that's how it is.

You have never heard of anyone using VS that wanted to do something
for GUI that required manual editing??

> It's true that without the partial class feature, a Java-oriented GUI
> designer couldn't be quite as seamless as what one finds in the .NET
> toolset. But I think someone with sufficient motivation could in fact write
> a GUI editor that works practically as well, even without that.
>
> They just don't seem to have yet. And IMHO this is one reason why at least
> some people eschew using Java for desktop apps. It's certainly a
> significant factor in why I stopped bothering and went back to using .NET
> for my day-to-day ad hoc projects.
>
> I can't prove that I'm typical. But it's likely I'm not entirely unique
> either. :)

I am sure there are other that do not like the Java GUI builders.

But I am convinced that the main reason for the low usage
of Java for desktop apps is the look and feel not being
sufficient native.

Arne

[toc] | [prev] | [next] | [standalone]

#21995

On 02/01/2013 09:08 PM, Arne Vajhøj wrote:
> On 1/31/2013 7:54 PM, Peter Duniho wrote:
[ SNIP ]
>>
>> They just don't seem to have yet. And IMHO this is one reason why at
>> least
>> some people eschew using Java for desktop apps. It's certainly a
>> significant factor in why I stopped bothering and went back to using .NET
>> for my day-to-day ad hoc projects.
>>
>> I can't prove that I'm typical. But it's likely I'm not entirely unique
>> either. :)
>
> I am sure there are other that do not like the Java GUI builders.
>
> But I am convinced that the main reason for the low usage
> of Java for desktop apps is the look and feel not being
> sufficient native.
>
> Arne

I think you're right about that latter. Desktop apps that I've written 
for various platforms in the past few years, professionally that is, 
have not been Java because they look like Java, not native. And I'll use 
Mono before I use Java, on other OS's.

The pain of using Swing is there, it helps convince me not to use Java 
for desktop apps, but L&F is a bigger factor, sure.

So for me the current painpoint with Java and GUIs is JSF, because I do 
that quite a lot. Like I said, I finally bit the bullet and automated 
the process for myself, so I can easily generated matching XHTML 
Facelets pages and managed beans, for example.

AHS

[toc] | [prev] | [next] | [standalone]

#22012

On 2/1/2013 8:54 PM, Arved Sandstrom wrote:
> On 02/01/2013 09:08 PM, Arne Vajhøj wrote:
>> On 1/31/2013 7:54 PM, Peter Duniho wrote:
> [ SNIP ]
>>>
>>> They just don't seem to have yet. And IMHO this is one reason why at
>>> least
>>> some people eschew using Java for desktop apps. It's certainly a
>>> significant factor in why I stopped bothering and went back to using
>>> .NET
>>> for my day-to-day ad hoc projects.
>>>
>>> I can't prove that I'm typical. But it's likely I'm not entirely unique
>>> either. :)
>>
>> I am sure there are other that do not like the Java GUI builders.
>>
>> But I am convinced that the main reason for the low usage
>> of Java for desktop apps is the look and feel not being
>> sufficient native.
>
> I think you're right about that latter. Desktop apps that I've written
> for various platforms in the past few years, professionally that is,
> have not been Java because they look like Java, not native. And I'll use
> Mono before I use Java, on other OS's.
>
> The pain of using Swing is there, it helps convince me not to use Java
> for desktop apps, but L&F is a bigger factor, sure.
>
> So for me the current painpoint with Java and GUIs is JSF, because I do
> that quite a lot. Like I said, I finally bit the bullet and automated
> the process for myself, so I can easily generated matching XHTML
> Facelets pages and managed beans, for example.

But is it really a GUI builder or a wizard you want?

GUI builder = tool you use initially and for maintenance of the GUI

wizard = tool that generates a lot of boilerplate stuff that is then
refined and maintained by hand

Arne

[toc] | [prev] | [next] | [standalone]

#22019

On 02/02/2013 01:21 PM, Arne Vajhøj wrote:
> On 2/1/2013 8:54 PM, Arved Sandstrom wrote:
>> On 02/01/2013 09:08 PM, Arne Vajhøj wrote:
>>> On 1/31/2013 7:54 PM, Peter Duniho wrote:
>> [ SNIP ]
>>>>
>>>> They just don't seem to have yet. And IMHO this is one reason why at
>>>> least
>>>> some people eschew using Java for desktop apps. It's certainly a
>>>> significant factor in why I stopped bothering and went back to using
>>>> .NET
>>>> for my day-to-day ad hoc projects.
>>>>
>>>> I can't prove that I'm typical. But it's likely I'm not entirely unique
>>>> either. :)
>>>
>>> I am sure there are other that do not like the Java GUI builders.
>>>
>>> But I am convinced that the main reason for the low usage
>>> of Java for desktop apps is the look and feel not being
>>> sufficient native.
>>
>> I think you're right about that latter. Desktop apps that I've written
>> for various platforms in the past few years, professionally that is,
>> have not been Java because they look like Java, not native. And I'll use
>> Mono before I use Java, on other OS's.
>>
>> The pain of using Swing is there, it helps convince me not to use Java
>> for desktop apps, but L&F is a bigger factor, sure.
>>
>> So for me the current painpoint with Java and GUIs is JSF, because I do
>> that quite a lot. Like I said, I finally bit the bullet and automated
>> the process for myself, so I can easily generated matching XHTML
>> Facelets pages and managed beans, for example.
>
> But is it really a GUI builder or a wizard you want?
>
> GUI builder = tool you use initially and for maintenance of the GUI
>
> wizard = tool that generates a lot of boilerplate stuff that is then
> refined and maintained by hand
>
> Arne
>
>
Much closer to a wizard then to a builder. That's why using a simple 
Scala DSL for JSF works for me, it's not so much that I want to do 
layout that I want to avoid boilerplate. I generate coarse layout with 
divs and panelGrids and panelGroups and dataTables; I do the fine layout 
with CSS anyhow at a later stage.

AHS

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web