UI designer suggestion

I've been a Delphi programmer and is still yearning the UI design evironment of it. Maybe guys of Jetbrains could learn some good idea from it.

In delphi, there is a form file attached to every UI and there is no tedious auto generated UI layout code in source codes, all layout information are stored in form file. At run time, some runtime code parses form file and renders UI. This is somehow like what IDEA is doing. But the convienient part is that all the component is binded automaticly, that is, when u drop a component on UI form, there is a variable declaration generated in code, only the declaration.

10 comments

tc master wrote:

I've been a Delphi programmer and is still yearning the UI design evironment of it. Maybe guys of Jetbrains could learn some good idea from it.

In delphi, there is a form file attached to every UI and there is no tedious auto generated UI layout code in source codes, all layout information are stored in form file. At run time, some runtime code parses form file and renders UI. This is somehow like what IDEA is doing. But the convienient part is that all the component is binded automaticly, that is, when u drop a component on UI form, there is a variable declaration generated in code, only the declaration.



1. Parsing forms files in runtime breaks byte code obfuscation.
2. There is no need to automatically create a field for each component
in the form. For example, usually UI contains a lot of labels. I don't
think that it will be useful to have all these labels as fields in a class.

With best regards,
Vladimir Kondratyev
_____________________
JetBrains

0

On Fri, 14 Nov 2003 14:26:30 +0300, Vladimir Kondratyev (JetBrains) wrote:

1. Parsing forms files in runtime breaks byte code obfuscation. 2. There
is no need to automatically create a field for each component in the form.
For example, usually UI contains a lot of labels. I don't think that it
will be useful to have all these labels as fields in a class.


Only declaring the fields you want to bind is good, but its still
currently a bit of a manual process (not much, but hey ), an intention
action to "bind field to new variable" would be a great aid here.

I can see intentions in the UI designer being a really need feature.

0

Mark Derricutt wrote:

On Fri, 14 Nov 2003 14:26:30 +0300, Vladimir Kondratyev (JetBrains) wrote:

>>1. Parsing forms files in runtime breaks byte code obfuscation. 2. There
>>is no need to automatically create a field for each component in the form.
>>For example, usually UI contains a lot of labels. I don't think that it
>>will be useful to have all these labels as fields in a class.


Only declaring the fields you want to bind is good, but its still
currently a bit of a manual process (not much, but hey ), an intention
action to "bind field to new variable" would be a great aid here.

I can see intentions in the UI designer being a really need feature.


There is already intentions that create field.

Vladimir Kondratyev
___________________
JetBrains

0

On Mon, 17 Nov 2003 15:38:11 +0300, Vladimir Kondratyev (JetBrains) wrote:

There is already intentions that create field.


Aha! So there is, just took me a whjle to find it. Maybe also
red-lining/intention-bulbing the property inspector could be handy.

0

"Mark Derricutt" <mark@talios.com> wrote in message
news:pan.2003.11.17.18.24.07.394473@talios.com...

On Mon, 17 Nov 2003 15:38:11 +0300, Vladimir Kondratyev (JetBrains) wrote:

>

There is already intentions that create field.

>

Aha! So there is, just took me a whjle to find it. Maybe also
red-lining/intention-bulbing the property inspector could be handy.


This is why I do not like intentions in their current form: one do not know
what intention may pop up at a given moment, line and caret position. This
is so undeterministic from my user's point of view. I want to be able to
access (1) full intention list (2) intentions that are applicable right now,
either enabled or disabled (3) to select any intention I want much alike
selecting operation from refactoring menu. In general, intentions should be
just a subset of refactoring operations, which pop up automatically. I would
like to be able to fine-tune which intentions should pop up and which should
not.

On the topic: I like Delphi approach better. Well, first love does not rust
;) Hmm, not quite the first, but the first real ;) And Delphi also has
visual inheritance, this is so cool when you try it, for example, for
wizards or other common forms.



0

On Tue, 18 Nov 2003 17:32:18 -0800, Michael Jouravlev wrote:

This is why I do not like intentions in their current form: one do not
know what intention may pop up at a given moment, line and caret position.
This is so undeterministic from my user's point of view. I want to be able


I'd rather have intentions than NO intentions, which is why I suggested
their implementation back with the very first incarnation of the UI
designer.

The current model -kinda- follows from the code-editor model where the
intention only shows up when dealing with the code in question, which for
code is ok, but with the UI - you're dealing with the whole thing, all the
time ( generally speaking ). It would be good to see all intentions.
Maybe in a table at the bottom of the editor, like the TODO list or error
lists, showing all intentions for a) the file being edited b) the contents
onscreen of the file being edited.

On the topic: I like Delphi approach better. Well, first love does not
rust ;) Hmm, not quite the first, but the first real ;) And Delphi
also has visual inheritance, this is so cool when you try it, for
example, for wizards or other common forms.


I like delphi, and used it for 9+ years, it was nice, but I found it
didn't really lend itself to nice UI abstraction, it was WAY to easy to
just quickly enter your code logic in the forms processing, which can
often make later refactoring a pain in the arse.

The same ability, but creating Action class instances ( either as inner
classes of the forms bound class, or same-level Action classes
appropriately named in the same package.




0

I would like to the see the integration of intentions and code inspection completed. I know intellij's done some work here. So code inspection would give you a complete list of possible intentions (as you would like), while still have the context popup (which is also nice sometimes).

Of course some intentions will never work with code inspections because they aren't really fixing a problem. They are just suggesting some commonly done actions (like inversing a boolean expression).

0

intention where? I just looked in build 977 and couldn't find it!!

0

Ok Now I see it. It is well hidden! I think it should be an option on the pull down on an empty field so that you don't have to type a name then get an error with an intention to fix it. What works well in code is not right for an inherently graphical tool
It should also be in a right click menu on the graphical object.
In case anybody else is looking for it:
Type a name in the binding text box. You then get a red line under this field on the top left with an intention to create.

0

Joey Edelstein wrote:

Ok Now I see it. It is well hidden! I think it should be an option on the pull down on an empty field so that you don't have to type a name then get an error with an intention to fix it. What works well in code is not right for an inherently graphical tool
It should also be in a right click menu on the graphical object.
In case anybody else is looking for it:
Type a name in the binding text box. You then get a red line under this field on the top left with an intention to create.


Intentions will be also available directly in the property inspector
(currently they are working only in the component tree).

Vladimir Kondratyev
___________________
JetBrains

0

Please sign in to leave a comment.