Showing messages 1 through 10 of 10.

• did everybody notice the word "should" in the question?
  2007-06-21 13:59:27 ga427 [Reply | View]
  
  1. I think issues with Matisse are not the point of the poll - notice the word "should".

  Issues with Matisse are, IMHO bugs (which I trust have been logged....)

  2. So, assuming, no bugs, completeness issues, performance issues (all of which are, in fact, IMHO bugs) why wouldn't you completely "live" in Matisse for layout?

  Personally, I can't see why you wouldn't - layout is inherently graphical, and thus the tool to create it should be graphical.

  I also think that Matisse has a design flaw in that it doesn't put its layout code in its own class, and, by default only produce the .class file for the layout class (i.e. no .java file) - simplify the code that developers need to access by eliminating (moving) bits that you can't edit anyway. Of course, the layout java code should be available for examination for the curious as an option, but don't leave it around unless requested.

  In other words, IMHO, developers should treat layout code just like bytecode, binary - a lower level, uninteresting technical detail, generally, but one that had better Just Work, and be complete, performant etc. And if you can make the generated code perform better by doing something that makes it look funky, go for it - its not supposed to be human readable, any more than highly optimized binary/bytecode is.

  3. Its great that people were able to manually workaround the lack of Matisse (after all, while Matisse is excellent, it was unbelievably late arriving, so these skills were critical for a number of years). But now that Matisse is here, we need to move on - get the Matisse bugs/flaws fixed, such as exist, and stop doing layouts by hand, IMHO. Surely there are more difficult, higher level problems to solve.

  We don't write bytecode by hand, after all, except in extreme, highly justified circumstances, today. Why would layout code be any different?

  4. I think the same thing about html, too - I want Matisse for web (and Ruby, GWT, Java FX etc.) - lets make Matisse support pluggable target languages, and support graphically rich web page style backgrounds - how about a Java rich client that looks and feels like a web client? These are, however, other topics.

  While on the topic of Matisse extensions, we need the ability to right click on all components and access the controller logic for that component. And the controller logic should be nicely bundled up in a class for easy editing - some circumstances will naturally suggest Matisse based access to the controller (particularly initially), while others will naturally suggest a traditional editor.

• BOTH
  2007-06-21 05:52:27 xphree [Reply | View]
  
  Visual Tool are great but... something are better to do by hand, by hand i have more control than with the tool!

• A lil of both....
  2007-06-20 13:37:07 lukman_jaji [Reply | View]
  
  M surprised some pple are thinking of AJAX to replace GUI building....doesnt make a bit of sense. A little of both will do. I use a visual tool called GUI genie. Its nice, light and easy to use. I build my GUI's generate my codes and then to my notepad to do the finishing...
  
  Jaji

• gui libs
  2007-06-20 09:49:42 dma02 [Reply | View]
  
  coding the gui by hand doesn't mean your stuck with tons of lines of code. There are many nice libraries out there that make gui building easier. You'll end up with less code to write since most of it will already be written for you.
  
  For example if I wanted to do many forms and tables, I'd use dataform (it's a java.net project) and it builds the form for me and does all the SQL stuff in the background.. so poof I have a DB and forms almost instantly. If Wanted some other type of gui,... I'd most likely use some other lib.

• Cognitive mismatch between Matisse and GroupLayout
  2007-06-19 08:53:45 cayhorstmann [Reply | View]
  
  I enjoy using Matisse, but what I don't enjoy is seeing how an intuitive operation is translated into a complex mess of GroupLayout commands. Does Matisse manipulate an internal model that generates the GL instructions, or does it actually parse them every time? If the former, could we have a Java class that is a facade to the GL with operations that are meaningful to the programmer and that allows for true two-way operation (i.e. visual design and code manipulation, without protected blocks)?

• JFormDesigner Got It Right
  2007-06-19 07:43:58 evickroy [Reply | View]
  
  Take a look at JFormDesigner. Turn off code generation and just use the runtime library to instantiate your GUI at runtime. Extremely fast prototyping/maintenance with the visual editor. Zero boilerplate layout code littering your application. It uses XML Encoding for storing the definitions, so no proprietary storage. This should make it easily ported accross any IDE.

• prototyping
  2007-06-18 22:24:35 jwenting [Reply | View]
  
  GUI builders are nice for rapid prototyping. The final product however usually (unless it's highly simplistic) requires a lot of handcrafting to get it to work as required (or more often to work at all).

  Yet another reasons why GUI builders that don't store their creations as standard Java code (instead using some custom format only they can understand and the user can't modify) are fundamentally flawed by design.

• prototyping
  2007-06-19 00:19:48 fabriziogiudici [Reply | View]
  
  There are other similar discussions ongoing, nevertheless I still can't understand why "to make GUI works they need a lot of handcrafting". During some private mail exchanges I found out that most of things can be easily done without touching any part of the code automatically generated by the IDE (I'm not saying I've made the mind of the counterpart ;-) Need still counter-examples...
• prototyping
  2007-06-22 00:12:41 jwenting [Reply | View]
  
  Just an example: never seen a GUI designer that could create screens that worked well containing components that are created at runtime.
  Or one that will let you use complex components requiring initialisation code.
  Try having components change content depending on the state of other components (especially getting that content from external sources to fill the other component).
  Or try having an ActionListener defined that doesn't exactly fit the template the creator of the GUI designer had in mind.
• prototyping
  2007-06-19 06:57:15 scotty69 [Reply | View]
  
  Well, no tool is perfect. Example: Fire up NetBeans 5.5 and design a little form with a JList. Connect the JList's model within the designer to a method of another bean. The code for this connection is contained in the generated code, and there's even a footprint in the .form-descriptor. Now refactor the bean providing the ListModel (using NetBeans) and rename this method. Every reference gets properly renamed, except the generated code (and also not the .form). You have to edit the generated code because of a tool bug. That's not a great perspective for a production-quality software with years of lifetime and maintaince...