IDEA-UIDesigner is on a wrong way!!!

hi,
i post this message because i noticed the wrong way idea goes with his UIDesigner. if JetBrains develop any longer in this way, i don't know how it ends with idea! i love this ide, but the way JetBrains goes with its UIDesigner is defently the wrong way:

- you must work with idea if you use the UIDesigner. sure they develop on a ant-task but what's up with people how can't use ant or wouldn't use ant?

- if you use the UISourceGenerator-plugin( http://www.intellij.net/forums/thread.jsp?forum=32&thread=36401&tstart=0&trange=50 ) you can work with other ide's(eclispe...) hypothetical. but you must include the forms_rt.jar file because the UIDesigner use his OWN (idea-)LayoutManager. that's so worse!!! IMHO you should be independent from a ide, a project should only needs the jdk and not ide-specific classes!!! that's the great problem with C++ Builder from borland, if you create a project in C++ Builder you can't work on it in another C++ ide, because it needs a lot of Borland-specific classes. please don't use idea-specific classes. if i create a project, i only wnat to link my jdk to the project, not some idea-jars...

31 comments
Comment actions Permalink

It might be better to think of the forms-rt.jar, xml schema, and ant task as a gui framework, seperate from the ide. It's simply yet another gui framework, which you can use or not use as you see fit. It's just like any other third party framework/tool/library you choose to incorporate into your project to save time.

Consider the gui-builder as just a easy way to use this gui framework from within IDEA. Just like IDEA's built-in support for ant or junit. IDEA just has some tools to make it easier to use this framework.

Technically speaking, a project using this framework is not necessarily tied to IDEA, as the xml could be written by hand. Other tools could (and probably will, if the framework is successful) be written which will offer alternative gui builders which output this xml format.

So don't think of forms-rt.jar as idea-specific. Those classes are just framework specific.

Why didn't IDEA make a gui builder which just produces pure swing code? Don't know, but my guess is they felt that gui developers would fall into three camps:
1) Purists, who want really tweaked, polished swing code who would never use a gui builder of any kind, except maybe as a scratch pad.
2) RAD developers, who want to develop reasonably polished, boiler-plate guis as fast and as cheaply as possible.
3) Inexperienced developers, who want to develop the same gui as group 1, but don't know swing well enough to do it, so they try to use a gui builder to build the first few revisions, then try to "take ownership" of the code and hand tweak it from there.

A framework-based approach meets the needs of groups 1 and 2 fairly well, since it potentially will create nicer looking guis in less time and with less necessity for hand-tweaking than a non-framework based gui builder.

It could be argued that group 3 is sort of a lost cause. It's an approach which often fails. Several existing gui builders try and create pure swing to cater to this third group, and just about all of them:
a) generate half-baked or unpolished looking guis, which developers complain about
b) use code patterns instead of frameworks, which still end up (loosely) tying the code to that gui builder, which developers complain about
c) require more time to develop the gui and hand-tweak the gui than a framework-based approach would, which developers complain about

Frameworks have a cost and a benefit. You get a bunch of built-in stuff that saves you time, but you are inevitably locked into using the framework, and you have to accept the limitations of the framework. Gui builders like borland's or netbean's basically impose a "virtual" framework (mostly through code patterns). These virtual frameworks have the same costs as all frameworks, but their only benefits are that they let you use the gui builders.

At least with Intellij's approach, they say explicitly, "Yes, you are using a framework. You must follow these rules to fit into that framework. If you use it, you get these benefits." Because the contract is more explicit, presumably the framework can be more robust and offer more benefits.

0
Comment actions Permalink

The reason I wrote the plugin is because I think that the UIDesigner is a really nice GUI builder that is part of the best development environment I have ever seen. There is only one thing that it lacks, and that is the ability to produce Swing code that can be changed and recompiled by someone else using whatever editor they choose. Right now the plugin relies on code in form_rt.jar, but the folks at JetBrains have said that they are going to open source that code. When they do, I intend to modify the plugin to have the option of generating "all" the source so no external jars are needed, assuming that the JetBrains open source license would allow me to. This way everyone should be happy, those that want to use the framework can, and those that want source can have that too. I can even accomodate those folks that can't make up their minds and want to switch back and forth between using the framework and having source code. 8^)

0
Comment actions Permalink

Just my two cents, for what they are worth:
I'm an experienced GUI/Swing programmer, and when JetBrains announced that they are finally creating a GUI designer, I thought: Hm, maybe that's the first one I will actually use, if it's gonna be as great as the rest of Idea.
Well, I played half an hour or so with it, then scrapped it. Even JetBrains did not manage to create a GUI designer, that is worth using.
Might be great for Swing newbies to get started quickly, but in the long run it will do them even more harm than other designers because they never even see and get to understand the code and the principles behind it.
I think it's really weird that those folks that create the best code-centric IDE ever go and create a tool that never let's you get your hands dirty with actual code.

0
Comment actions Permalink

Well, I played half an hour or so with it, then scrapped it. Even JetBrains did not manage to create a GUI designer, that is worth using.


Same for me. I used GUI builders in the past, but later felt very
comfortable with writing GUI code myself. I also expected Jetbrains to
create a GUI builder that would be outstanding compared to the
competitor's. Unfortunately, it's the same inflexible stuff like the
others, just a little bit different (but not in the right direction).

But finally, it's there and it would be completely useless to dump it.
Reviewers will not be able to complain any longer about the missing GUI
builder (maybe this was the main target in creating it). A few people
will use it and (I bet) - if not 100% disciplined - will create
crappy-looking GUIs. But it's their (the user's) choice...

Tom

0
Comment actions Permalink

Hey, it's early days yet. Give it time!

Personally I think it's headed in the right direction and have great hope
for it.

Vil.


Thomas Singer wrote:
>> Well, I played half an hour or so with it, then scrapped it. Even
>> JetBrains did not manage to create a GUI designer, that is worth using.


Same for me. I used GUI builders in the past, but later felt very
comfortable with writing GUI code myself. I also expected Jetbrains to
create a GUI builder that would be outstanding compared to the
competitor's. Unfortunately, it's the same inflexible stuff like the
others, just a little bit different (but not in the right direction).


--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This 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.

0
Comment actions Permalink

> Hey, it's early days yet. Give it time!

Do you really expect significant chances 'til the release of IDEA 4?

> Personally I think it's headed in the right direction and have great
> hope for it.

Different people have different opinions...

Tom

0
Comment actions Permalink

Do you really expect significant chances 'til the release of IDEA 4?


What significant changes are you talking about? If you are talking about
source code then as we already said many times we are discussing this
approach internally and most probably IDEA will generate source code. If
there are some other problems please submit bugs/request. I've found
only two requests from you concerning UI Designer. One of them is fixed
and the second one is planned for Aurora. Please don't be mute if you
don't like some concrete things.

With best wishes,
Vladimir Kondratyev
_____________________
JetBrains

P.S. source code generation is the only one aspect of UI Designer but
there are many others also.

0
Comment actions Permalink

> I've found only two requests from you concerning UI Designer.
> One of them is fixed and the second one is planned for Aurora.

Haven't you read the bunch of messages I sent approx. two months ago?
Ah, now I remember, Jetbrains at all were very calm regarding these
messages.

P.S. source code generation is the only one aspect of UI Designer but
there are many others also.


I agree on this point. The most serious issues I'm concerned about:
- our components need to have non-parameter constructors,
- I don't see a way to use GUI component factories,
- IIRC "hidden" setup within the constructor (might cause problems in
sub-classes),
- missing separation of concerns (layout vs. looking).

Enough for the moment?

Tom

0
Comment actions Permalink

Stephen Kelvin wrote:

Just my two cents, for what they are worth:
I'm an experienced GUI/Swing programmer, and when JetBrains announced that they are finally creating a GUI designer, I thought: Hm, maybe that's the first one I will actually use, if it's gonna be as great as the rest of Idea.
Well, I played half an hour or so with it, then scrapped it. Even JetBrains did not manage to create a GUI designer, that is worth using.


Stephan,

unfortunately I didn't manage to find any bug/feature request from you
concerning UI Designer. It will be great if you share with as your
problems and inconveniences with the UI Designer.
Please do not start the battle about source code generation. It's a
minor aspect and everything is possible to change. I do not know why
many Swing gurus talks that all designers are for newbies. We WANT to
create designer useful for professionals. I cannot believe that Swing
guru (for example you) will create ordinar dialog with dosens of fields
and buttons in GridBagLayout faster then in UI Designer. UI constructing
is often a silly routine and just the time wasting. The main intention
of the UI Designer is to simplify such boring tasks as writing a mass
from GridBagConstrains.

Sometime I read about that gurus tweak generated code to optimize it. It
sounds very strange. I'm well familiar with Swing and I can tell that
you will win nothing if you spend some hours and reduce a little number
of constructed object in the generated code. Just look into the Swing
code and you will understand that a hundred of objects are created when
you move a mouse over the component or resize the window. That is the
place that should be optimized first!

With best regards,
Vladimir Kondratyev
_____________________
JetBrains

0
Comment actions Permalink

Vladimir,

..I do not know why many Swing gurus talks that all designers are for
newbies. We WANT to create designer useful for professionals. ..
Sometime I read about that gurus tweak generated code to optimize it.
It sounds very strange. I'm well familiar with Swing and I can tell
that you will win nothing if you spend some hours and reduce a little
number of constructed object in the generated code. Just look into the
Swing code and you will understand that a hundred of objects are
created when you move a mouse over the component or resize the window.
That is the place that should be optimized first!




If you were to tell us
"we eat our own dog food, and use our uiDesigner for IDEA"
, I think many "gurus"would lose their edge, and maybe reconsider their
position.


Alain

0
Comment actions Permalink

(Just checked)
Current Aurora sources contain 49 UI Designer form files.

--
regards,
Alexey Kudravtsev.
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Alain Ravet" <alain.ravet.list@wanadoo.be> wrote in message news:bgvskk$g45$1@is.intellij.net...

Vladimir,

>

..I do not know why many Swing gurus talks that all designers are for
newbies. We WANT to create designer useful for professionals. ..
Sometime I read about that gurus tweak generated code to optimize it.
It sounds very strange. I'm well familiar with Swing and I can tell
that you will win nothing if you spend some hours and reduce a little
number of constructed object in the generated code. Just look into the
Swing code and you will understand that a hundred of objects are
created when you move a mouse over the component or resize the window.
That is the place that should be optimized first!

>
>
>

If you were to tell us
"we eat our own dog food, and use our uiDesigner for IDEA"
, I think many "gurus"would lose their edge, and maybe reconsider their
position.

>
>

Alain

>


0
Comment actions Permalink

Hi,

Yes, we indeed widely use UI designer in Aurora :) It it saves a lot of
time. And IMO its absolutely clear that everyone who REALLY ever created and
modified complex (static) UIs with many many controls and nested panels
would never say builder is for newbies and that gurus make everything by
hand and making it by hand is faster, results are more maintainable etc.

--
Best regards,
Anton Katilin
-


JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Alain Ravet" <alain.ravet.list@wanadoo.be> wrote in message
news:bgvskk$g45$1@is.intellij.net...

Vladimir,

>

..I do not know why many Swing gurus talks that all designers are for
newbies. We WANT to create designer useful for professionals. ..
Sometime I read about that gurus tweak generated code to optimize it.
It sounds very strange. I'm well familiar with Swing and I can tell
that you will win nothing if you spend some hours and reduce a little
number of constructed object in the generated code. Just look into the
Swing code and you will understand that a hundred of objects are
created when you move a mouse over the component or resize the window.
That is the place that should be optimized first!

>
>
>

If you were to tell us
"we eat our own dog food, and use our uiDesigner for IDEA"
, I think many "gurus"would lose their edge, and maybe reconsider their
position.

>
>

Alain

>


0
Comment actions Permalink

Alexey Kudravtsev wrote:

>(Just checked)
>Current Aurora sources contain 49 UI Designer form files.

>
Aha :)
Now we can talk.

What are the current limitations of the uiDesigner, that prevented you
to use it more/in some - difficult - cases?

Alain

0
Comment actions Permalink

Hi Vladimir,

Although you wrote to Stephan, I also may answer about my concerns.

We've built our own frameworks for GUI components - we never use any
layout manager or constraints directly in application code. Instead we
created wrapper components (like QHIGLayoutPanel or
QGridBagLayoutPanel), that have convenience methods like
addComp(JComponent component, int row, int column, int rowSpan, int
colSpan, boolean stretchVertically, boolean stretchHorizontally).
Additionally we use so-called Editors, aggregations of a label and an
input field component (often JTextField, but might be more like chooser
buttons right beside a file-/directory editor). Even for Editors similar
convenience methods exist. We do not have to bother about distances
between components or stuff like this, because it's done centrally.
That's why our GUI looks very homogeneous. Is this possible with IDEA's
GUI designer?

Generally we tend to make as much as possible variables final. That's
why our JTable-subclass only has one constructor: new
QTable(QTableModel). IIRC, I could not use this table in IDEA's GUI
designer. We use our own QTableScrollPane(QTable). Again, not possible
with IDEA's GUI designer.

We create buttons or menu items using a component factory, e.g.
factory.createButton(QAction). Not possible with IDEA's GUI designer.

We have a framework for dialog content: QDialogPane. It is a JPanel with
two sub-components, the button-panel (always at the bottom) and the
content-component (containing the typical GUI components). But we can
put our QDialogPane in modal JDialogs, in pseudo-modal JFrames and in
JInternalFrames. No line of code needs to be changed for the dialog-pane
itself. Is this possible with IDEA's GUI designer?

> is often a silly routine and just the time wasting. The main intention
> of the UI Designer is to simplify such boring tasks as writing a mass
> from GridBagConstrains.

Sorry, but who tweaks Constraints himself is self-responsible for
unreadable code (see above alternatives or www.jgoodies.com).

> Sometime I read about that gurus tweak generated code to optimize it.
> It sounds very strange. I'm well familiar with Swing and I can tell
> that you will win nothing if you spend some hours and reduce a little
> number of constructed object in the generated code. Just look into the
> Swing code and you will understand that a hundred of objects are
> created when you move a mouse over the component or resize the window.
> That is the place that should be optimized first!

I agree on this, but also think, not every Swing guru tweaks the code
to optimize something. I rather think, a lot of Swing gurus use their
own frameworks (similar to the above mentioned ones) to reduce the
effort required to build GUIs. But quite every GUI designer is
incompatible with such frameworks. I believe, this is the reason, why
Swing gurus don't use GUI builders at all. They are too inflexible.

Tom

0
Comment actions Permalink

If you were to tell us
"we eat our own dog food, and use our uiDesigner for IDEA"
, I think many "gurus"would lose their edge, and maybe reconsider their
position.


:) Take a look at the ugly Main Module page in Project Properties
(especially regarding spacings). If this was built with IDEA's GUI
designer, it convinces me NOT to use any GUI designer.

Tom

0
Comment actions Permalink

In my opinion UI designer now is invaluable tool for constructing static forms.
Under term 'static' I mean forms containing constant number of standard Swing controls.
Static forms constitute 100% but one of my GUI work.

So I think the most vital task now is to bring UI designer to the state in can be used in such kind of UI development.
That task will be greatly facilitated by your concrete requests/bug reports in addition to my nine in the Tracker :)

--
regards,
Alexey Kudravtsev.
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"

PS
Currently UI designer is used in almost every new form created in the Aurora.
Conversion of hundreds of old hand-made forms considered to be low-proirity activity compared to the development of the new
features.


"Alain Ravet" <alain.ravet.list@wanadoo.be> wrote in message news:bgvu0c$rla$1@is.intellij.net...

Alexey Kudravtsev wrote:

>

>(Just checked)
>Current Aurora sources contain 49 UI Designer form files.
>
>
Aha :)
Now we can talk.

>

What are the current limitations of the uiDesigner, that prevented you
to use it more/in some - difficult - cases?

>

Alain

>


0
Comment actions Permalink

Tom,

>

:) Take a look at the ugly Main Module page in Project Properties
(especially regarding spacings). If this was built with IDEA's GUI
designer, it convinces me NOT to use any GUI designer.



To be honest, I was just fishing with my question, hoping that whatever
would come out of the water, would bring some more sense in those "I
love it/I hate" it thread loops.

Now that you know that they eat their own dog food, you can post your
IDEA ui critics - see above - as uiDesigner improvement request. Don't
you find it a good news?

Alain



0
Comment actions Permalink

It was written manually :)

Anyway, if it was created with UI designer, it would be absolutely
understandable that the wrong insets are not resulted by the tool but by its
user. I'm pretty sure that you have examined UI designer very well so
shouldn't claim that it does force user or help user to create such improper
layouts.

--
Best regards,
Anton Katilin
-


JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Thomas Singer" <idea@regnis.de> wrote in message
news:bgvuaj$1a4$1@is.intellij.net...

If you were to tell us
"we eat our own dog food, and use our uiDesigner for IDEA"
, I think many "gurus"would lose their edge, and maybe reconsider their
position.

>

:) Take a look at the ugly Main Module page in Project Properties
(especially regarding spacings). If this was built with IDEA's GUI
designer, it convinces me NOT to use any GUI designer.

>

Tom

>


0
Comment actions Permalink

Glad you put in the (static) modifier there :) There's more than one way to
crack this particular nut; my preferred method is to use a dynamic framework
that builds a complex ui made of simple static units. These simple units
are so simple that using a ui designer to implement them would be, well,
like using a sledgehammer to crack a nut.

I do it this way as I'd rather use code to take tedium away than to use a
tool that just reduces the tedium, and it seems I am not alone in this.

I have no problem with the gui designer as it stands, some people need it,
some people want it, some people just don't care. There are valid uses of
it, and that makes it a valid thing to have in the product. I guess I'm
just trying to say that there will always be 2 sides of opinion in this
area, and so there's no point trying to pull everyone together on it unless
we're talking about standardising all the different frameworks all the swing
"gurus" have brewed for themselves, and that seems a tad ambitious. Neither
camp is wrong, lets remember that, we're just talking at completely
different levels at the moment.

Cheers,
N.

Anton Katilin wrote:

Hi,

>

Yes, we indeed widely use UI designer in Aurora :) It it saves a lot
of time. And IMO its absolutely clear that everyone who REALLY ever
created and modified complex (static) UIs with many many controls and
nested panels would never say builder is for newbies and that gurus
make everything by hand and making it by hand is faster, results are
more maintainable etc.

>
>

"Alain Ravet" <alain.ravet.list@wanadoo.be> wrote in message
news:bgvskk$g45$1@is.intellij.net...

>> Vladimir,
>>
>>> ..I do not know why many Swing gurus talks that all designers are
>>> for newbies. We WANT to create designer useful for professionals. ..
>>> Sometime I read about that gurus tweak generated code to optimize
>>> it. It sounds very strange. I'm well familiar with Swing and I can
>>> tell that you will win nothing if you spend some hours and reduce a
>>> little number of constructed object in the generated code. Just
>>> look into the Swing code and you will understand that a hundred of
>>> objects are created when you move a mouse over the component or
>>> resize the window. That is the place that should be optimized first!
>>
>>
>>
>> If you were to tell us
>> "we eat our own dog food, and use our uiDesigner for IDEA"
>> , I think many "gurus"would lose their edge, and maybe reconsider
>> their position.
>>
>>
>> Alain


0
Comment actions Permalink

Why in a lot of projects developers build GUIs rather than *GUI
designers* (the human beings)? For web-design there are web-designers,
for buildings architects. Giving a decent CAD system to a construction
worker (even an experienced and good one) will not result in a
acceptable building.

It will be possible to build a GUI using a GUI builder (tool), but don't
expect miracles.

Tom

0
Comment actions Permalink

Hi Anton,

I'm sure, the GUI designer allows to make it right, but it's just like
MS Word: There are so many options to tweak, that it is very easy to
miss the "right" and tweaking the "wrong" ones.

Try to compare DocBook with Word: in DocBook you just say, this is a
caption, this is a file name. In word you /can/ do this too, but a lot
of users don't even know it. The result is this: (if you have a decent
stylesheet) in the DocBook the output looks professional and
homogeneous, but with Word it looks - hm - not that professional. Now
consider changes: you decide to change some spacings. With DocBook you
just need to tweak one or two lines in the stylesheet. In Word, you need
to tweak every piece. Same with a decent framework vs. any GUI designer.

Tom

0
Comment actions Permalink

Absolutely agree that such things should be specified only once.

Concerning spaces in UI designer. For example, gaps. You can set gaps to the
upper panel, and if not nested panel overrides this, nested panels will have
same gaps. If no panel assigned a gap, the default value will be used. Right
know it is hardcoded, but we'll provide ability to change it (like layout's
static field etc.). So all gaps are potentially specified only once, and in
program code.

The other things that currently need boring tweaking they also can be
discussed and lets try to find the best way how to do it.

--
Best regards,
Anton Katilin
-


JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Thomas Singer" <idea@regnis.de> wrote in message
news:bh00dj$5tv$1@is.intellij.net...

Hi Anton,

>

I'm sure, the GUI designer allows to make it right, but it's just like
MS Word: There are so many options to tweak, that it is very easy to
miss the "right" and tweaking the "wrong" ones.

>

Try to compare DocBook with Word: in DocBook you just say, this is a
caption, this is a file name. In word you /can/ do this too, but a lot
of users don't even know it. The result is this: (if you have a decent
stylesheet) in the DocBook the output looks professional and
homogeneous, but with Word it looks - hm - not that professional. Now
consider changes: you decide to change some spacings. With DocBook you
just need to tweak one or two lines in the stylesheet. In Word, you need
to tweak every piece. Same with a decent framework vs. any GUI designer.

>

Tom

>


0
Comment actions Permalink

Tom,

> Why in a lot of projects developers build GUIs rather than *GUI
designers* (the human beings)?
> For web-design there are web-designers, for buildings architects.


The building association is one that keeps coming back, but I think it's
dead wrong :
the architect = the developer
the builders = the java compiler, Ant, ..

> For web-design there are web-designers,

"Web Designer" is too vague a notion.
Currently, I'm playing the role of a /Web designer/, even though I work
with a /graphist/ that doesn't have a clue about programming. He made
drawings with Illustrator, on a functional skeleton that I build, when
wearing my /Architect/ hat, from my interpretation of the client request
I collected when I was an /Analyst/, and after years of Internet usage,
as a /User/. In a next phase, I'll also be an /Web UI Implementer/. Web
Designer covers all those tasks..
I don't think a GUI Designer work would be very different. The
/graphist/ would make it look good, but the /Implementer/ would make it
work.
I really don't see why the application developer couldn't also be the
gui implementer.

That's where a tool is handy : facilitating the work of the implementer.


Alain

0
Comment actions Permalink

Alexey Kudravtsev wrote:

>PS :
>Currently UI designer is used in almost every new form created in the Aurora.
>Conversion of hundreds of old hand-made forms considered to be low-proirity activity compared to the development of the new
>features.

>

Too bad. I'm sure you would learn a lot about refactoring and
retrofitting UIs.
I understand your priorities, though.

Alain

0
Comment actions Permalink

What significant changes are you talking about? If you are talking
about source code then as we already said many times we are
discussing this approach internally and most probably IDEA will
generate source code.


Why have you not mentioned this before??? I think it is great that you will "probably" generate source code from the GUI form, but the reason I started writing the plugin was because in earlier threads dealing with the issue all I ever heard was "we'll open source the framework so anyone who wants GUI source code can write their own code to generate it". I personally thought this was the wrong answer and I'm thrilled that you have changed your position on this, but if you really are going to add the ability to generated stand alone source code (i.e. Swing code that can be changed and recompiled having only the generated source and a JDK), please let me know so I can stop working on a plugin to do this.

I am also curious as to why JetBrains has had a change of heart about GUI source code generation.

0
Comment actions Permalink

Stephan,

Stephen ;)

unfortunately I didn't manage to find any bug/feature request from you
concerning UI Designer. It will be great if you share with as your
problems and inconveniences with the UI Designer.

I spent quite some of my (employer paid) time by posting comments and bugs
about Aurora, which is ok, because I need not use the EAP if I didn't want to.
I just did not rate the GUI designer important enough to bother with it,
because the approach did not convince me.
However your comments might convince me that the final GUI designer might
turn out great and that it's worth contributing to it. (And getting some
responses on the many topics that I posted would definitly foster my
motivation ;- see end of this text.)

The most discouraging is that if I create a GUI using Idea everybody using
Eclipse, NetBeans, JBuilder and working on the same project will have to
adapt. Sure we are using ant, but I won't be able to sell my boss the idea
to incorporate an Idea-specific task to it and enforcing Idea for everyone
working on the UI.

Please do not start the battle about source code generation. It's a

minor aspect and everything is possible to change.
Won't battle, but I don't think it's a minor aspect.

I do not know why many Swing gurus talks that all designers are for newbies.
We WANT to create designer useful for professionals. I cannot believe that Swing
guru (for example you) will create ordinar dialog with dosens of fields
and buttons in GridBagLayout faster then in UI Designer. UI constructing
is often a silly routine and just the time wasting. The main intention
of the UI Designer is to simplify such boring tasks as writing a mass
from GridBagConstrains.


I wrote my own layout manager long ago. It's inspired by
TableLayout (http://www.clearthought.info/software/TableLayout/)
but completely rewritten and greatly enhanced. Just got permission of
my boss to open source it, but that still may take me a couple of weeks.

Also using a handcoded UI I can encapsulate common behaviour into super
classes or mini-patterns, while in general with a GUI designer I end
up specifying every solution again and again.

IMHO these are inherent problems with GUI designers, i.e. reuse and
organization of components (but I had hoped JetBrains could overcome those problems).
Guess I am not alone with this opinion, e.g. see this issue of the Java
Specialists newsletter:
Heinz M. Kabutz, The problem with RAD GUI Tools
http://www.javaspecialists.co.za/archive/Issue074.html

A big problem for us has always been the platform and JDK version specific
occurence of Swing bugs. (E.g. I remember a nasty bug where on Linux a
disposed dialog won't open again if reshown, or another one where the
default button was lost on revalidation.)

I ended up writing a subclass for each and every Swing component to work around
these bugs.

I18n
====

It's a must-have for us. Our current concept is this: Every component
is created using an action. Most Swing components already support this
(JButton) for some other, our subclasses add this (JLabel, tab panel for
tabbed panes, ...). Swing components will react automatically on
property changes of their action, again this is default Swing behaviour,
but we added some bug fixes and enhancements (like updating the mnemonic
and having an action property for the mnemonic index).
Each of these actions is created using a resource bundle name and key
and updated whenever the locale is changed (so that all components update
on the fly).
There is a tracker entry that I already added some comments to:
http://www.intellij.net/tracker/idea/viewSCR?publicId=14255

Sometime I read about that gurus tweak generated code to optimize it. It
sounds very strange. I'm well familiar with Swing and I can tell that
you will win nothing if you spend some hours and reduce a little number
of constructed object in the generated code. Just look into the Swing
code and you will understand that a hundred of objects are created when
you move a mouse over the component or resize the window. That is the
place that should be optimized first!

I'm totally with you on this one. The longer I program the more simple
my code gets, I've learned to resists the premature optimization temptation.
The only thing that pays off is clean, simple code and using a profiler
to tune your application before release.

-



And if you complain about lack of work, here are some of my comments/issues that desperately need an update.
Would really increase my motivation to file new comments if these get some attention from JetBrains ;)

Commented in great detail about the Module configuration GUI and proposed changes, nobody from JetBrains ever answered
http://www.intellij.net/forums/thread.jsp?forum=22&thread=35216

Posted detailed comments, no answer: Commit Project - Cool features but minor issues
http://www.intellij.net/forums/thread.jsp?forum=22&thread=32755

#13371, Still in state "To be discussed", I think the discussion that's there gave a good refinement to my original propposal, and many people are quite in favour of it: Auto-insert imports without user interaction
http://www.intellij.net/tracker/idea/viewSCR?publicId=13371

#9565, I really don't see why this is in state "Obsolete", have tried twice to get some comment from JetBrains: New Project Wizard should auto-select Target JDK if only one is defined
http://www.intellij.net/tracker/idea/viewSCR?publicId=9565

#9694, Added some detailed comments, but nobody answered: Removing superfluous and possibly erroneous imports after move
http://www.intellij.net/tracker/idea/viewSCR?publicId=9694

#11196, State is still "To be discussed", though noone ever argued against it: Renaming a method should optionally rename overloaded versions of the method
http://www.intellij.net/tracker/idea/viewSCR?publicId=11196

#10549, State is open, but it seems to be fixed: Alt-space should bring up windows menu
http://www.intellij.net/tracker/idea/viewSCR?publicId=10549

#14436, State is fixed, but it's still open in 887: Some checkboxes get focus, some doesn't
http://www.intellij.net/tracker/idea/viewSCR?publicId=14436

#14098, Still in state "To be discussed": refactor to replace deprecated things with a valid alternative
http://www.intellij.net/tracker/idea/viewSCR?publicId=14098

0
Comment actions Permalink


"Thomas Singer" <idea@regnis.de> wrote in message
news:bh00dj$5tv$1@is.intellij.net...

Try to compare DocBook with Word: in DocBook you just say, this is a
caption, this is a file name. In word you /can/ do this too, but a lot
of users don't even know it.


AmiPro 3.0 required creation of style for each non-standard formatting. I
hated this feature. Humans are not that dumb to use their judgement when to
use styles, and when tweaks. And this judgement is what differs
word-processing professional from amateur :)


0
Comment actions Permalink

effort required to build GUIs. But quite every GUI designer is
incompatible with such frameworks. I believe, this is the reason, why
Swing gurus don't use GUI builders at all. They are too inflexible.


You say the GUI builders are inflexible because they don't support your
framework. So I say your framework is inflexible because it cannot be
used with the GUI builders. Just put it the other way round and your
framework is crap and the GUI builder is great. You can see it this way
as well as that way. :)

0
Comment actions Permalink

Hi Alain,

I don't mean to cause offence but having a graphic artist working alongside
a developer does not equate to an having Usability/HCI expert working on the
team. There are cases where a developer can output something acceptable,
maybe when he is building a tool for developers, but in the majority of the
cases you will not have created the optimal user experience.

Please do not simplify HCI down to a programmer who can draw a nice little
icon, some of us have spent considerable time and money researching this
rather large field of science(s). Granted we do not always get the time to
do it the way we would like.

Regards,

William Louth
JDBInsight Product Architect
www.jinspired.com


"Alain Ravet" <alain.ravet.list@wanadoo.be> wrote in message
news:bh01vs$rla$3@is.intellij.net...

Tom,

>

> Why in a lot of projects developers build GUIs rather than *GUI
designers* (the human beings)?
> For web-design there are web-designers, for buildings architects.

>
>

The building association is one that keeps coming back, but I think it's
dead wrong :
the architect = the developer
the builders = the java compiler, Ant, ..

>

> For web-design there are web-designers,

>

"Web Designer" is too vague a notion.
Currently, I'm playing the role of a /Web designer/, even though I work
with a /graphist/ that doesn't have a clue about programming. He made
drawings with Illustrator, on a functional skeleton that I build, when
wearing my /Architect/ hat, from my interpretation of the client request
I collected when I was an /Analyst/, and after years of Internet usage,
as a /User/. In a next phase, I'll also be an /Web UI Implementer/. Web
Designer covers all those tasks..
I don't think a GUI Designer work would be very different. The
/graphist/ would make it look good, but the /Implementer/ would make it
work.
I really don't see why the application developer couldn't also be the
gui implementer.

>

That's where a tool is handy : facilitating the work of the implementer.

>
>

Alain

>


0
Comment actions Permalink

William

> I don't mean to cause offence but ..
None taken.


>Please do not simplify HCI down to a programmer who can draw a nice
little
>icon, some of us have spent considerable time and money researching this
>rather large field of science(s). Granted we do not always get the
time to
>do it the way we would like.

Please do not take every programmer for a complete idiot - *1 - who
can't go much further than drawing a "Save-As" confirmation dialog.
Before being a developer, we/I'm an "old" user, with 10 fingers, 2 eyes
and 1 brain, like most of my users, but much more experience (usage) and
education (books) about the subject than the typical users.
Though, I would hire a UI specialist for a project like Encarta, or a
newspapers website, but not for a simple, generic and small/medium
budgeted application.
I'm convinced common sense, experience and some education (like the book
"GUI bloopers") can go a long way; not the whole way, but a long way.

As there is a place for G.P. in the medical world, there is a place for
multi-hatters experienced developers, that know their limits, and are
smart enough to ask for help when they reach them. This is the kind of
people than I'm sure will benefit from a "simple" tool.

We must fight the "No pain, no gain" cliché, wherever it makes sense.

Alain

*1 : I know, you didn't say nor implied that.

0

Please sign in to leave a comment.