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.
Ralph Saunders wrote:
Wow, I'll go and say that to our Win32 developers. They will be really
excited. :)
/kesh
Thomas Singer wrote:
>>Wouldn't it be better to have the source code generated but that we could
>>not modify (even externally speaking) ?
>>The source file would be overwritten each time the project builds.
>>And if you really wish to do some tweaks, you'd have to tweak a subclass of
>>this generated class.
>>Wouldn't it be better for everybody ?
+10 Good idea, Thomas
/kesh
I agree, except that I think that the user should not be prevented from editing the UI code. If they do, then they are responsible for the resulting modified code and should not expect the UI editor to recognize and preserve it (the UI editor should also not automatically overwrite it with re-generated code.
Can you modify winapp GUI without resource editor? And even if you have resource editor, some RCDATA sections may be illegible for you. So what? You take this as given, right? How Java app is different?
Well, one of the things that folk like about Java, is that it's relatively open and very flexible. Again, I probably won't use a tool that reduces that flexibility.
But even this isn't the main problem with this tool; does the winapp resource editor hack into the executable to add new features?
Do you have to hack bytecodes to change the Java look and feel?
You do not manually create EJB objects for your remote definitions, do you?
No, but I can take my remote definition anywhere, and another app server, can recreate the objects I need.
You're not going to get that with this GUI builder ...
"Rayz" <jiveadmin@jetbrains.com> wrote in message
news:4405498.1055440961218.JavaMail.itn@is.intellij.net...
resource editor hack into the executable to add new features?
No. Resource editor only change resources. In the old days its functionality
was so limited, that one could not, for example, make a string resource
longer that it was, because resources were packed so tight that it would
require to repackage (not recompile!) the EXE file. I am not sure about
current state of resource editing, but at least you can change resources in
size considerably.
But code itlself is never changed. If you changed resource ID or name, you
are screwed ;)
"Thomas Singer" <thomas.singer@NOregnisSPAM.de> wrote in message
news:5jchevknfdfd8sc2ik1alq126qun01205l@4ax.com...
of
>
>
As I can see, we have two major questions here:
1. Bytecode patching
2. Resource-oriented UI handling vs. plain Java Swing code
About the first one: I think it can be avoided if proper base classes are
used in the UI library, and other base classes (for each form) are generated
by UI builder. I am personally against bytecode patching.
The second one splits into two:
2.1 Design-time UI handling
2.2 Run-time UI handling.
I guess, that most people here agree, that (2.1) should be
resource-oriented. IntelliJ guys created XML description specifically for
this, it works, and I totally for this.
The difference of opinions is on (2.2). So i see two solutions:
2.2.1 Keep resource in runtime, handle it with separate library. If UI would
be needed to be changed later, either IDEA UI builder, or external (possibly
third-party) resource editor can be used. Or, one can patch XML manually (I
hope, it will not be "compiled" for runtime).
2.2.2 On the design time create intermediate Java code behind the scenes,
which corresponds to XML resource. Custom class inherits from this base
class and contains the fields, corresponding to UI components. All component
layout is defined in the base class, event handlers are defined in the
custom class. Both classes are compiled together to get the runtime, no
resources are used.
I would like to be able to select between (2.2.1) and (2.2.2). What's more,
I would think that to avoid bytecode patching, the base class for a form
should always be generated. But in (2.2.1) we would have only one base class
for all IDEA forms in the resource support library, in the case of (2.2.2)
we would have one base class per each form.
As for being able to look at the base class Java code during design time: I
personally do not need it, but the possibility of this might be handy.
Michael Jouravlev.
Should controller be separated from the view. Some people think yes and other no. In classic Smalltalk environment, M is separated from V and from C. In Swing, V and C are combined to from a delegate. To separate out event binding from the view would require yet another file. Notice I used the phrase "event binding" insteand of event handling. Event handling consists of event binding and behavior. For example, when a button is push, the binding portion would call a method on a receiver. The method on the receiver does not need to know (mostly likely should not know) that it was called because someone had pressed a button. However, the binding portion certainly knows when a particular button is pressed a specific method is called. All in all, I believe the event binding part should reside with the view since it must have knowledge of the view anyway. However, the actual behavior of the method should be in java source, controlled and edited by a developer.
"Thomas Singer" <thomas.singer@NOregnisSPAM.de> a ?crit dans le message de
news: 5jchevknfdfd8sc2ik1alq126qun01205l@4ax.com...
of
>
Yes, I feel it'd be more natural that way.
It frightens me a lil'bit to know that there is some magic hapening behind
the scences.
So a "read-only" view of the source code generated would suit me !
Guillaume
There is one other approach to the resource issue that I havew seen and it worked quite well. It is to have the resources initially defined in the code, but provide a mechanism to override the "default compiled in" values. I first saw this when building GUI's in X11 using Motif. The initial widget resources were defined in the code, but an end user could override them in a plain text file named .Xdefaults. I am not suggesting that a plain text file is better than XML, but at the time XML didn't exist.
On Thu, 12 Jun 2003 19:06:49 +0200, Thomas Singer wrote:
I like this IDEA. Even if it the byte code engineering was kept in
place, a user could decide to "break ui maintainable" and continue with
the source version.
And maybe have some "import ui maintainable" that could do a one off parse
of the source building the XML file, and importing the form. ( mmm, maybe
not the this later ... )
--
...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
On Thu, 12 Jun 2003 16:32:09 +0400, Mike Aizatsky wrote:
All that means is that someone might write a competing standalone GUI
builder :) Give you guys some competition :)
Mark
--
...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
As the form's compiler code will become open-source one will be able to
write a compiler to the source code. The compiler itself is very simple btw.
--
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Thomas Singer" <thomas.singer@NOregnisSPAM.de> wrote in message
news:cbieev4k8j04vh1kdv33cicam9p85rfnu1@4ax.com...
like to do some changes in generated code.
>
>
>
+As the form's compiler code will become open-source one will be able to write a compiler to the source code. The compiler itself is very simple btw.
+
So as well as your own compiler and Ant task, in the future we may need to rely on the appearance of other tools to switch? What if they don't?
I could be wrong, but I think that many of the more conservative companies will choose not to use it simply to prevent them from being so tightly tied in with the IDEA builder; and the bytecode manipulation certainly won't help.
This is a shame because with Sun finally making a big push for the desktop, I'd like to see this thing really fly; I'm just not sure it will.
I'm assuming that now you've started down this road, you're pretty much staying with it; in which case, all this talk is probably a waste of time ...
Ralph Saunders wrote:
> namely that it requires some speical tool to change the UI.
You can always edit the XML by hand, instead of using the UI builder &
JetBrains have said that the form compilation task will be open-sourced. So
what exactly is the problem?
> simply not look at the code. My opposition is to the approach of not
> producing source code from the XML definition file.
JetBrains have said publicly that they will publish the XML file format used
by the GUI builder. If you really need to see source code, it will be
perfectly possible for you and the others who feel the same to create a
stylesheet to generate the code from the XML file. It may even be possible
to modify the Ant task to generate source code instead of bytecode (or to
provide the option).
Personally I much prefer not having to bother with generated code for the
GUI, so I think JetBrains' current approach to the GUI builder is spot on.
Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
DisclaimerThis e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.
Rayz wrote:
> need to rely on the appearance of other tools to switch? What if
> they don't?
Then you can do it yourself. That's the point of open sourcing the form
compiler.
Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
DisclaimerThis e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.
Gosh Thomas, for someone who said he'd never use the GUI builder you've
certainly been pretty vocal about it! :)
I disagree with having the three views. I just want one: the graphical view.
I don't care how the layout is stored, so I don't want to have to worry
about the XML. And I don't want generated source code cluttering up my
project tree & build process.
I'm sure it will be possible to modify the open-source form compiler to add
an option for generating source code. In fact, if the people on this list
are as willing to write code as they are to be vocal about needing it, I
think that will be one of the first modifications to be submitted.
As JetBrains are opening up (have already opened up?) an API for allowing
custom editor classes, it should be possible to implement the other views as
plugins for those that do want them.
For myself, the current approach is what I want so I hope it stays that way.
Vil.
Thomas Singer wrote:
>>Wouldn't it be better to have the source code generated but that we could
>>not modify (even externally speaking) ?
>>The source file would be overwritten each time the project builds.
>>And if you really wish to do some tweaks, you'd have to tweak a subclass of
>>this generated class.
>>Wouldn't it be better for everybody ?
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
DisclaimerThis e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.
Then you can do it yourself. That's the point of open sourcing the form compiler
Wow. This is getting more complicated by the minute.
So, to build this GUI, take:
One bytecode slicer
One Ant task
One build tool
And in the future.
Write my own module to convert it at a later date.
Something's gone seriously amiss here.
The "you have the source code - write it yourself" thing is a bit of a myth I'm afraid. I've done it myself for a few bits, but it isn't fun, and it adds another level of complication to the project. No thanks.
>Gosh Thomas, for someone who said he'd never use the GUI builder you've
Can't remember I said "never".
>certainly been pretty vocal about it! :)
Maybe I have much experience in GUI design and don't want the GUI
designer to go in the (IMHO) wrong direction?
>I disagree with having the three views. I just want one: the graphical view.
>I don't care how the layout is stored, so I don't want to have to worry
>about the XML. And I don't want generated source code cluttering up my
>project tree & build process.
Well, why you develop with source code at all? Why not click and drag
the whole application together? Because structured text (source code)
is (at least for the moment) the best and most flexible solution. Have
you ever needed to rename something (e.g. from "Ok" to "OK") using a
GUI builder? How long did it take for -- lets say -- 50 dialogs?
>I'm sure it will be possible to modify the open-source form compiler to add
>an option for generating source code. In fact, if the people on this list
Who says, that this source code it the same as the modified class
file? Maybe it's slighly different and you waste a couple of hours to
find a bug?
Tom
>As the form's compiler code will become open-source one will be able to
>write a compiler to the source code. The compiler itself is very simple btw.
Sure, this is an option. But I still do not understand why you modify
the class file when there is another (IMHO better) solution:
from->source->class. Example:
A form called "Dialog.form" will be "translated" to (non-editable,
intermediate) "Form_Dialog.java", that is subclassed by the editable
"Dialog.java".
Advantages:
- even Form_Dialog.java can be debugged,
- developing the transformation would be much easier, because the
result (here Form_Dialog.java) is a text file in a format, that every
Java developer can understand at one glance
Disadvantage:
- it can take some milliseconds longer
Tom
Rayz wrote:
>
There's only really one new tool: the form compiler. The bytecode slicer is
part of that tool, the ant task is a wrapper around it and the build tool is
Ant which most Java developers these days seem to be using already. The
module you mention would be an addition to the form compiler and a
relatively simple one too, from what JetBrains have been saying.
Also remember that you will still be able to use IDEA without using the GUI
builder. So if the way the GUI builder works is so inimical to you or your
organisation, you can either continue creating GUIs the way you currently do
or you can use some other GUI builder which more closely matches your needs.
What do you mean by a "bit of a myth"? If you are using an open source
product which doesn't meet your needs in some way, you are able to modify it
to meet your needs. Ideally these changes go back to the community so
others can benefit from them as well. 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.
I also don't accept that doing this adds a layer of complexity to a project.
The motivation for doing this is, in my experience, to reduce complexity.
It does require a bit of time out from a project, but that comes down to a
simple cost-benefit decision: whether the gains will outweigh the time lost
in implementing it.
If you really need to see some source code generated by the GUI builder, you
have the option to add that functionality yourself. Or, better yet, to work
with other members of the community to add that functionality. How can that
be a bad thing?
Peace,
Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
DisclaimerThis e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.
Have you ever needed to rename something (e.g. from "Ok" to "OK") using aGUI builder? How long did it take for -- lets say -- 50 dialogs?
Well the build tools will be open source ... so you can always write an application that will go through all your dialogs and rename the buttons for you ... :(
On Fri, 13 Jun 2003 12:27:39 +0200, Thomas Singer wrote:
I hope you're not going to suggest a search and replace on all occurances
of "ok" to "OK", with a small slip you could replace alot more than you
really wanted.
--
...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
It could be cool at least if we were able to subclass components.
Such as standard OK, Cancel buttons.
We'd lay out those specialized components, and there would be a single place
to change the label and other default properties. Inheritence is a really
key feature that should be implemented in a way or another by this component
layout manager.
And by the way, on a side note, the label OK should not be written 50 times,
but a single one, thanks to a resource bundle, or a similar means. It's
critical to have a UI designer that is i18n aware.
I'm looking forward to see what JetBrains will bring us regarding i18n
(especially since so far IDEA is not "translatable" in other locales...)
Guillaume Laforge
>
>
>
>
I definetely agree.
And I think this disadvantage is not that big.
It's just at build time that the developpers see the difference. Not the
final customer.
Guillaume
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.
I've had to tailor two open source projects, and it wasn't pleasant. The documentation was non-existent and the code was ... well, it could've been better.
Oh yes, open source has been a life-saver, but not everyone has the time or inclination to fix it. If they did, then Sun, IBM and Microsoft would have gone bust long ago.
I reckon most people use open-source software because it's free; not because they can change it.
I also don't accept that doing this adds a layer of complexity to a project.
Well, I'm afraid it does. I have to write another app to support the project I'm on, then that's another layer, and it's more time for testing and debugging.
+The motivation for doing this is, in my experience, to reduce complexity. It does require a bit of time out from a project, but that comes down to a simple cost-benefit decision: whether the gains will outweigh the time lost
in implementing it.+
And if I was looking to make sure that my app was future-proofed, I'd want a tool that would let me convert, with as little work as possible; if required.
Thomas Singer wrote:
>>Gosh Thomas, for someone who said he'd never use the GUI builder you've
You're right. I've just checked back & while you have said in the past that
you don't need one and would prefer other features instead, you did say
you'd give it a try. My mistake - sorry.
>>certainly been pretty vocal about it! :)
Fair enough. I applaud the fact that you've been making constructive
suggestions too. So many of the posts about the GUI builder have simply
been "I don't like X about it" (where X is usually "byte-code manipulation")
rather than suggestions for how it could be improved.
As far as I'm concerned, that problem highlights some deficiencies in the
current crop of GUI builders rather than indicating the superiority of
structured text for manipulating GUIs.
The main reason for the problem IMHO is that existing GUI builders make it
easier to re-create bits of common functionality than to re-use them. If,
for example, you could create a common dialog shell in a GUI builder and
then reuse that across all your dialogs, there would be far fewer places
that need to be changed from Ok to OK.
There's a related issue brought up by your example: GUI builders need to
recognise that text is part of the user interface and should provide
appropriate tools for handling it. I'd like to see the ability to do search
and replace across UI definitions as part of the tool, for example.
I believe it's a matter of format maturity. Structured text has been used
for decades in the computing industry and there are well known ways of
working with it; we are still inventing the metaphors for working with other
types of information. As we develop our understanding, working with these
other formats will become as easy as working with text and will - in many
cases - surpass it. But we need to make sure that we do develop that
understanding...
Just my opinions of course.
Vil.
--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
DisclaimerThis e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.
The problem is that instead of delivering Java code to a customer i am going to be delivering this propriatary method of generating the UI. My customers don't want to have to learn some propriatry way of building a UI, no matter how good it may be, they want standard Java code that they can change or enhance using what ever tool they want to. 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.
"Ralph Saunders" <jiveadmin@jetbrains.com> wrote in message
news:24703114.1055529204416.JavaMail.itn@is.intellij.net...
going to be delivering this propriatary method of generating the UI. My
customers don't want to have to learn some propriatry way of building a UI,
no matter how good it may be, they want standard Java code that they can
change or enhance using what ever tool they want to. 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.
What do your customers want to change? The apperance, arrangement of
components or the actual handler's code? In the first (more likely) case
they will need resouce editor, which either will be supplied by IntelliJ (I
hope so), or will be created by some active community member. If your
customer wants to hassle with Java code, why does not he write the whole app
by himself?
"dimiter" <dimiter@blue-edge.bg> wrote in message news:bc9e59$ma6$1@is.intellij.net...
>
I already have some work in progress. See my comments
http://www.intellij.net/tracker/idea/viewSCR?publicId=6533
http://www.intellij.net/forums/thread.jsp?forum=22&thread=25031
I don't really like the taken approach so I probably won't use it at all.
(I'm not engaging in the discussion any more because it's going in circles.)
It would be really nice if the GUI layout editor had an open API and/or
was open source so we can use it with another GUI framework.
This whole GUI issue is so controversial that I guess it would be the most
appropriate thing from the very beginning. This way JetBrains could provide
their pluggable(!) "pilot/default implementation" and let anyone to develop
something that suits their needs best. (We can even have a contest later on! :)
--Oleg
>
>