GUI designer, one more time?
Can somebody explain what is the main reason of having this GUI designer so complicated and not intuitive even for experienced developers?
A number of things trouble me the most:
1. No compile time check of binding between GUI element fields and mapped fields in the corresponding bound class
2. Need IDE every time when some changes are required to the either GUI element or bound class
3. Cannon reuse GUI element in the multiple classes, because nobody knows what is cooking inside
4. Very difficult implementation means a lot of bugs even for good team of Intellij
I asked already and want to ask again, why not to keep it simple? As far as I see, everything can be achieved by having simple but good Panel, JPanel, SWTPanel etc. builder and may be some kind of Menu, Jmenu, SWTMenu etc. builder and that is it. Every field should be accessible by standard getter method and events can be added latter if time left e.g. getFieldName().addEventLisyner(some ListenerClass))
If the goal is to keep the definition in the XML file it is still better to use the JSP approach, first generate java code then use standard compile to build the classes, it will make things more clear and possible for debugging.
Having all this in mind, the Idea team can concentrate on building GUI component instead of reinventing the wheel and patching byte code, BTW what they are going to do when SUN changes the compiler implementation or obfuscation is required?
On the other hand I might miss something, and what is done is really genius, which cannot be understood by ordinary person, or may be limited like myself.
Please sign in to leave a comment.
My customers do not want to get locked into a propriatary technology, that is why they chose Java in the first palce. What is so hard to understand about that concept?
All I am saying is that for the GUI builder to be useful to me, and to an number of other users of Idea according to other responses in this thread, there must be a way to generate standard Java Swing code from the XML definition that can be delivered to a customer so they can hire another Java developer if they ever want to change the UI later.
+What do your customers want to change? The apperance, arrangement of components or the actual handler's code? +
Anything and everything, as soon as their requirements change, business expands, the company logo is altered ... whatever. That's why they insist on code that's easy to maintain by themselves, if the need arises.
+In the first (more likely) case they will need resouce editor, which either will be supplied by IntelliJ +
You seemed to have missed what the gentleman said:
Producing a Swing based application with the current UI means that my customer would be required to buy Idea in order to modify the UI after the code has been delivered and i am gone. That just will not work.
.. and the same goes for me; my customers will run a mile if I tried to present them with an application that required them to deviate from their standard toolset in order to change it.
If they get an XML file and choose to fiddle with it by hand, that should be their choice.
+In the first (more likely) case they will need resouce editor, which either will be supplied by IntelliJ (I
hope so)+
'You hope so?' - Unfortunately, I can't really afford to tie myself to something so proprietary, based on 'hope'.
or will be created by some active community member
Perhaps.
If your customer wants to hassle with Java code, why does not he write the whole app by himself?
He doesn't want to write the whole thing from scratch, but he may want to change it at a later date, and so the code must be as 'un-proprietary' as possible. Of cousrse, this does beg the question, what is 'proprietary'? If I built the app using JBuilder, it would be much easier for them to use JBuilder to make any changes to it; but they certainly wouldn't have to.
This also leads onto another point. I come across many developers who use the GUI Builder to give them the first cut of the code, then they abandon it and do all the GUI fine-tuning by hand.
Why couldn't JetBrains write the "compiler to source code" and have that as an option available from build menu? You guys already do a lot of source code generation. Writing one ourselves is just a workaround/hack that could easily copme back to haunt us. if the UI builder changes, we will have to spend time figuring out what the changes were (after we finally discover that there has been a change) and then figure out what changes we need to make to our "home grown compiler" so that things work again. That just isn't acceptable.
This will also, IMO, hurt Idea's chances for being selected by companies as the IDE to standardize on since they would be required to do extra work just to be able to get standard Java code from a product that is supposed to make the job of producing standard Java code easier and faster for them.
+This will also, IMO, hurt Idea's chances for being selected by companies as the IDE to standardize on since they would be required to do extra work just to be able to get standard Java code from a product that is supposed to make the job of producing standard Java code easier and faster for them. +
I don't they would even get to this point to be honest; the bytecode slicing alone will keep the GUI designer out of most major software shops IMO; this is before we even get to the Ant task, and the requirement to write your own add-ons if you use something else to build your apps(which I don't think is quite as serious)
I also don't think JetBrains are going to change their minds about it; but as long as it is just a plug-in, and not a massive added resource embedded into IDEA, then there is still the option of using something else.
The myth is that open source is always better than other alternatives. Open source does have 2 big advantages which are:
1) I can see what is going on inside, fixing or tailoring it if I really want to
2) I can compile a binary for whatever platform I am using, assuming I have a compiler for that platform and the source is portable. This is obviously not an advantage when you talk about open source Java code.
The real advantage, however, comes when code is open source and open standard compliant. Open standards are why our industry exists. Open standards are the reason the Internet could be created, the reason it could be made commercially available, the reason it has grown as quickly as it has and the reason that it works so well. Swing code is open standard compliant in that it confirms to the Java Language Specification which is widely known and understood. There are lots of developers out there who can produce and modify code that conforms to that specification. What standard does the XML file/screen renderer approach conform to and how many developers are there that can produce or modify it's "source"?
I think that JetBrains Idea of storing a UI definition in an XML file instead of storing it in Java source is a really good way to get around the problem of having to parse a source file to determine a UI's "definition". I even like the concept of not supporting changes to the generated Java source by overwriting it every time the source is generated which was suggested elsewhere in this thread (that would pretty much guarentee that the presentation layer was kept seperated from the other layers). I would like to see the automatic generation of source from XML brfore building/compiling the project be some thing that is configurable, and I would like the ability to regenerate the source without having to compiling any source as an option off of the build menu.
I think an approach like this could satisfy both sides. Those of you who like the ease of use of the current system and the fact that you don't have to look at the UI source would still have the same ease of use (the only requirement would be to use the UI builder to generate the XML file) and and you still wouldn't have to look at the UI source with this approach. You would not be able to change UI resourses by just editing a file, but a mechanism could be added by JetBrains (or a third party) to support overriding the "compiled in" defaults. I know that is a "propriatary" approach, but the only people that have wanted this capability have been the ones who don't want the UI builder to produce source in the first place and like the "propriatary" approach of the current approach.
Unless you changed the FileType extension for IDEA forms to something else than .form
IDE-Settings -> FileTypes.
+_Many developers all over the world use this model successfully every day, so I don't understand what you mean when you say it's a bit of a myth._
The myth is that the vasy majority of developers actually change the open source. The vast majority of the stuff is so useful out of the box, it doesn't need to be altered anyway. Yes, huge numbers of developers make use of open source, but contrary to what you've said, they don't change it unless they really have to.
+
That's a myth I've never heard ... the nearest I have heard is that when
a squillion developers can look at the code, at least one of them will be sufficiently motivated to fix the deficiency that stops you using it. ("To a million eyes, all bugs are shallow")
On Mon, 23 Jun 2003 14:05:28 +0000, Tim Bissell wrote:
Well, from my perspective, when I started using the Anthill automated
build system, I found a bug, at least, I thought it was bug, I had the
source, so I took a peek, and low and behold, it was a bug, turned out to
be a 1 line patch, which I did, and submitted it to the project, its not
included, and other people are happy.
When I started getting back in usenet, and started using Pan, the GUI GTK
based usenet client, I found a problem when sending email ( most people
just followup I guess ) which caused the app to fail the send. I
downloaded the source code. Now - pan is all c based, which I realllllly
suck at, but I know a little, using ddd I found the relative code area
that was failing, turns out it was sending slightly the wrong strings for
SMTP, a few hacks here and there and it was now working, I submitted a
patch, i'm now in the readme.
Ages ago, I found a rare obscure problem with X-Chat, I stumbled through (
yet more c code I didn't really understand ) but managed to fix the
problem.
The same for many other OSS projects - JEdit, Licq, small fixes, but they
helped alot of people. This is the benefit of OSS I find. Small bugs
that iritate people that core developers often overlook can be fixed by
people who really need them.
Not everyone can do that thou, but the potential is there.
--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate
Not everyone can do that thou, but the potential is there.
Yes, the potential is there ... but very few have the time or the inclination to fiddle with open source code.
>Yes, the potential is there ... but very few have the time or the inclination to fiddle with open source code.
Especially, because there is a lot of horrible open source code (but
I'm sure, there is also enough bad closed source code -- you just do
not see it).
Tom