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
Please sign in to leave a comment.
Can you add your own components to it?
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...
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?
>
>
... and will it just be a plug-in?
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...
>
>
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...
>
>
>
>
is
>
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
On Mon, 16 Jun 2003 21:46:37 +0400, Anton Katilin wrote:
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
>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
>
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
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
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
>
"Thomas Singer" <thomas.singer@NOregnisSPAM.de> a ?crit dans le message de
news:irjtev03vve4f8jtcuoh7filmj66osbfpm@4ax.com...
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
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...
>
>
>
>
well
bad
>
"Jacques Morel" <jacmorel@yahoo.com> a ?crit dans le message de
news:bcmm3m$a24$1@is.intellij.net...
Oleg,
Well, Tom also created/rewrote an extended HIGLayout...
Makes me think that HIGLayout is a better approach, don't you think ?
with
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.
the
course
What do you mean exactly by "extract panel" ? creating a new form ?
Or just put all selected components into a nested panel ?
definition.
It's like if it came from Oleg's own mouth ;)
(Sounds very TRIZ oriented)
is
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.
Refactorable is what could make IntelliJ IDEA the most innovative Gui layout
tool
Guillaume Laforge