GUI designer - what is it purpose

Hi,

I'm not sure about the exact purpose of the GUI designer at all. Is it
for
1) creating the components and
2) laying them out?

What about component factories? What about own component classes?

Maybe it would make much more sense, if the GUI designer would only
handling point 2, the layout. A kind of visual controllable layout
manager.

What do you think?

Tom

15 comments
Comment actions Permalink

Can you add your own components to it?

0
Comment actions Permalink

Yes, you can. It's a little bit hard now because the only way to do this is
to change the file within idea.jar ('uiDesigner.Palette.xml') but we will
provide better approach in near future.

--
--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"

"Rayz" <jiveadmin@jetbrains.com> wrote in message
news:3696946.1055512256419.JavaMail.itn@is.intellij.net...

Can you add your own components to it?



0
Comment actions Permalink

What about component factories?

Tom


On Sat, 14 Jun 2003 11:50:32 -0700, "Valentin Kipiatkov"
<valentin@intellij.com> wrote:

>Yes, you can. It's a little bit hard now because the only way to do this is
>to change the file within idea.jar ('uiDesigner.Palette.xml') but we will
>provide better approach in near future.
>
>--
>--
>Valentin Kipiatkov
>JetBrains, Inc
>http://www.intellij.com
>"Develop with pleasure!"
>
>"Rayz" <jiveadmin@jetbrains.com> wrote in message
>news:3696946.1055512256419.JavaMail.itn@is.intellij.net...
>> Can you add your own components to it?
>
>

0
Comment actions Permalink

... and will it just be a plug-in?

0
Comment actions Permalink

Yes, it will be a plugin

--
Best regards,
Anton Katilin
-


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


"Rayz" <jiveadmin@jetbrains.com> wrote in message
news:12815297.1055573754200.JavaMail.itn@is.intellij.net...

.. and will it just be a plug-in?

>
>


0
Comment actions Permalink

We don't know yet.

By the way, my personal opinion is that (any) UI designer can be most
useful helping to lay components out, and the things like events processing
much easier can be expressed in program code.

--
Best regards,
Anton Katilin
-


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

"Thomas Singer" <thomas.singer@smartcvs.com> wrote in message
news:3eeabac9.2042496@news.intellij.net...

What about component factories?

>

Tom

>
>

On Sat, 14 Jun 2003 11:50:32 -0700, "Valentin Kipiatkov"
<valentin@intellij.com> wrote:

>

>Yes, you can. It's a little bit hard now because the only way to do this

is

>to change the file within idea.jar ('uiDesigner.Palette.xml') but we will
>provide better approach in near future.
>
>--
>--
>Valentin Kipiatkov
>JetBrains, Inc
>http://www.intellij.com
>"Develop with pleasure!"
>
>"Rayz" <jiveadmin@jetbrains.com> wrote in message
>news:3696946.1055512256419.JavaMail.itn@is.intellij.net...
>> Can you add your own components to it?
>
>

>


0
Comment actions Permalink

By the way, my personal opinion is that (any) UI designer can be most
useful helping to lay components out, and the things like events processing
much easier can be expressed in program code.


Anton, this is my opinion as well. IDEA's GUI designer should only be
a visual front-end for laying out components in an container. To be
exact, I do not care, whether it looks exactly like in the real
application, only the relation between the components matter.

Tom

0
Comment actions Permalink

On Mon, 16 Jun 2003 21:46:37 +0400, Anton Katilin wrote:

We don't know yet.

By the way, my personal opinion is that (any) UI designer can be most
useful helping to lay components out, and the things like events
processing much easier can be expressed in program code.


One of the annoying problems I found with Delphi, which I fear will creep
into IDEAs gui builder, and I'm sure is already a problem in others, is
custom components.

Everyone knows that the basic set of components shown on the GUI pallette
will will give you a nice 'basic' UI, enough for most people, but in time,
or due to certain needs, a user may include third party JavaBeans for that
magic extra-pretty-most-wanted drop down calendar control.

In delphi - these additional components were installed delphi wide, which
means opening the project on a new machine, would cause problems, forms
couldn't be opened cause of ClassNotFound problems.

If JetBrains implement something like this, let them be project based..


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


0
Comment actions Permalink

>One of the annoying problems I found with Delphi, which I fear will creep
>into IDEAs gui builder, and I'm sure is already a problem in others, is
>custom components.
>
>Everyone knows that the basic set of components shown on the GUI pallette
>will will give you a nice 'basic' UI, enough for most people, but in time,
>or due to certain needs, a user may include third party JavaBeans for that
>magic extra-pretty-most-wanted drop down calendar control.

Why should custom components need to be in the GUI palette? Why should
there be a GUI palette at all? Why not just have "mocks" for the
components in the GUI designer, labeled with the components variable
name?. See following example:

----


----- ----


label

textField

----- ----


----


table scroller

----


----


----

okButton

cancelButton

----


----

----




The GUI designer should only show the layout. It's not necessary to
see the components as they will occur when running the application.
The layout, the spacing and the resize-behaviour are the most
important things.

Tom

0
Comment actions Permalink

Why should custom components need to be in the GUI palette? Why should
there be a GUI palette at all? Why not just have "mocks" for the
components in the GUI designer, labeled with the components variable
name?. See following example:

>

The GUI designer should only show the layout. It's not necessary to
see the components as they will occur when running the application.
The layout, the spacing and the resize-behaviour are the most
important things.


That's not a bad idea !
And I agree with you that the layouts, spacing and resize behaviour are
critical things.
But... (yes there's a butt... er no a but ;) ) I think it's more
user-friendly to "see" the component that is being layed out.
I don't think the problem is there.
The most important thing is to be able to easily define the layout, spacing
and resize behaviour as you suggested.

I guess you know HIGLayout already ? Did you have a look at the way the
spacing and resizing behaviour is being done ? It's quite straightforward to
adjust those things. Just define the right column constraints, and you're
done. A UI to define those constraints over HIGLayout would be amazing. And
indeed, it could certainly be done quite easily. At least, it'd be easier
than the current way of define all the spacing/margin properties for each
component...

Guillaume Laforge


0
Comment actions Permalink

And moreover, what I like with HIGLayout is that you don't have to put a
JPanel inside a JPanel inside a Scrollpane inside a JPanel, inside... well
you know what I mean ;)
Thus, it certainly uses less memory, and is certainly quicker that the bad
JPanel-inside-JPanel habit.
But I've never made benchmarks ! (that's just a wild guess).

Guillaume Laforge


0
Comment actions Permalink

I already thought about a Layout Manager, where you can layout
components in a kind of "sub-layout", just like with a different
panel, but more light-weight (because handled only in the layout
manager). But I never felt the need to implement it yet :)

Tom


On Tue, 17 Jun 2003 10:13:52 +0200, "Guillaume Laforge"
<glaforge@reflexe.fr> wrote:

>And moreover, what I like with HIGLayout is that you don't have to put a
>JPanel inside a JPanel inside a Scrollpane inside a JPanel, inside... well
>you know what I mean ;)
>Thus, it certainly uses less memory, and is certainly quicker that the bad
>JPanel-inside-JPanel habit.
>But I've never made benchmarks ! (that's just a wild guess).
>
>Guillaume Laforge
>

0
Comment actions Permalink


"Thomas Singer" <thomas.singer@NOregnisSPAM.de> a ?crit dans le message de
news:irjtev03vve4f8jtcuoh7filmj66osbfpm@4ax.com...

I already thought about a Layout Manager, where you can layout
components in a kind of "sub-layout", just like with a different
panel, but more light-weight (because handled only in the layout
manager). But I never felt the need to implement it yet :)


Well, sometimes we have good and brilliant ideas... but... we have neither
time nor we are brave enough to start coding ;)
And my girl friend already makes some remarks when like yesterday I spend an
hour coding my Jabber plugin...

Guillaume


0
Comment actions Permalink

One of the problem with the current crop of table type layout manager is
aligning subtables in tables.
Oleg, in one of his posting, talked about his completely rewritten version
of the TableLayout/HIGLayout that supports inter subpanels alignment. Oleg,
maybe you could share it with us and JetBrains...

I am not a Swing guru by any mean so bear with me but one problem I see with
a table type layout manager is that the layout is global and isn't
localized. Adding columns would change offsets and you have to update all
affected cells manually. This is one reason why we need a gui builder that
understand table layouts. It will automate the side effects of row/column
manipulation.
Refactorings like "Extract panel" are also very table layout manager
dependent since now to maintain the layout the refactoring needs to know the
particular constraints and initial argument of the layout manager. Of course
they could just pick the best solution but...
So better yet let's try to remove the problem: the global layout definition.
In something like the DialogLayout where you define layout based on
component anchors (from the right side of x, below y...), adding a column is
not an issue. If you delete an anchor, the java editor/javac will
immediately tell you that your layout is broken: it won't even compile. In
addition the anchor components can just become parameters to an extracted
panel creator.
However I haven't done swing development for 2 years now and so I just
started evaluating both approaches. Seems to be very similar but I want
something readable and refactoreable.

Jacques

"Thomas Singer" <thomas.singer@NOregnisSPAM.de> wrote in message
news:irjtev03vve4f8jtcuoh7filmj66osbfpm@4ax.com...

I already thought about a Layout Manager, where you can layout
components in a kind of "sub-layout", just like with a different
panel, but more light-weight (because handled only in the layout
manager). But I never felt the need to implement it yet :)

>

Tom

>
>

On Tue, 17 Jun 2003 10:13:52 +0200, "Guillaume Laforge"
<glaforge@reflexe.fr> wrote:

>

>And moreover, what I like with HIGLayout is that you don't have to put a
>JPanel inside a JPanel inside a Scrollpane inside a JPanel, inside...

well

>you know what I mean ;)
>Thus, it certainly uses less memory, and is certainly quicker that the

bad

>JPanel-inside-JPanel habit.
>But I've never made benchmarks ! (that's just a wild guess).
>
>Guillaume Laforge
>

>


0
Comment actions Permalink


"Jacques Morel" <jacmorel@yahoo.com> a ?crit dans le message de
news:bcmm3m$a24$1@is.intellij.net...

One of the problem with the current crop of table type layout manager is
aligning subtables in tables.
Oleg, in one of his posting, talked about his completely rewritten version
of the TableLayout/HIGLayout that supports inter subpanels alignment.

Oleg,

maybe you could share it with us and JetBrains...


Well, Tom also created/rewrote an extended HIGLayout...
Makes me think that HIGLayout is a better approach, don't you think ?

I am not a Swing guru by any mean so bear with me but one problem I see

with

a table type layout manager is that the layout is global and isn't
localized. Adding columns would change offsets and you have to update all
affected cells manually. This is one reason why we need a gui builder that
understand table layouts. It will automate the side effects of row/column
manipulation.


If we think of rows and columns for defining spaceing between components,
instead of defining margin properties for each component, it's easy to
add/remove a column ! We don't bother with properties for each component.

Refactorings like "Extract panel" are also very table layout manager
dependent since now to maintain the layout the refactoring needs to know

the

particular constraints and initial argument of the layout manager. Of

course

they could just pick the best solution but...


What do you mean exactly by "extract panel" ? creating a new form ?
Or just put all selected components into a nested panel ?

So better yet let's try to remove the problem: the global layout

definition.

It's like if it came from Oleg's own mouth ;)
(Sounds very TRIZ oriented)

In something like the DialogLayout where you define layout based on
component anchors (from the right side of x, below y...), adding a column

is

not an issue. If you delete an anchor, the java editor/javac will
immediately tell you that your layout is broken: it won't even compile. In
addition the anchor components can just become parameters to an extracted
panel creator.


I'm not sure that the idea of anchors is ideal.
When you have three buttons :
- A at 10 pixel from the left side
- C at 10 pixel from the right side.
How will you define the placement for button B which should be centered
between A and C ?
Especially in the case you have to resize the window ?
With HIGLayout, you could define two auto-resizing columns which would get
the added space created when resizing the window or dialog box.

However I haven't done swing development for 2 years now and so I just
started evaluating both approaches. Seems to be very similar but I want
something readable and refactoreable.


Refactorable is what could make IntelliJ IDEA the most innovative Gui layout
tool

Guillaume Laforge


0

Please sign in to leave a comment.