Weekly progress news (10-16 of May, 2003)

>We have completed an Ant task which replaces the 'javac' >task and should be
>used to build applications containing GUI forms.

EEEP!! I thought we had driven a stake through the heart of this particular design choice. If I can't use the GUI builder without making IDEA part of my build, then I can't use the GUI builder.

Valentin Kipiatkov wrote:

3. We have completely rewritten the implementation of the editor management.
Now it supports arbitrary custom editors (JComponent) inside the tabbed pane
where all editors are located. This allowed us to put our GUI designer into
the editor pane.
The API of this subsystem should be reviewed and after that we'll make the
first public draft of "custom editor" API.

That's exciting. While you are at it, I want to encourage you guys to
open up all the one-line text areas so that applicable editing features
are available there there as well. For example, keyboard editing
features like Toggle case, Delete to end of word, Ctrl+W, and even that
plugins like the CamelHumps are not restricted to only being available
in the editor.

Thanks,
Jon

EEEP!! I thought we had driven a stake through the heart of this

particular design choice. If I can't use the GUI builder without making
IDEA part of my build, then I can't use the GUI builder.

Why IDEA? It's just a small jar with custom Ant task implementation. We are
even going to make it open-source.

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


"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:19808906.1053109135878.JavaMail.jrun@is.intellij.net...

>We have completed an Ant task which replaces the 'javac' >task and should

be

>used to build applications containing GUI forms.

>

EEEP!! I thought we had driven a stake through the heart of this

particular design choice. If I can't use the GUI builder without making
IDEA part of my build, then I can't use the GUI builder.

Thanks so much for detailing your effort this week. It's really nice to see where the development is happening and it gives us a nice "preview" of the parts of the code we can test.

Taking the time to send out a message like this is really appreciated!

Thanks!
-Chris

+--
Chris Chernesky
Technical Lead
5/3 Bank+

So on the build machine (let's say the nightly build is performed on a non-development box), all we'd need to build a project using the gui framework would be this jar and the custom ant task? That jar will contain everything required to compile your xml format into .class files? And this will be open-source? (wow)

Will he compiled .class files will rely on a library which needs to be redistributed with the application?

So on the build machine (let's say the nightly build is performed on a

non-development box), all we'd need to build a project using the gui
framework would be this jar and the custom ant task? That jar will contain
everything required to compile your xml format into .class files? And this
will be open-source? (wow)

Exactly.

>

Will he compiled .class files will rely on a library which needs to be

redistributed with the application?

Yes, there will be another small jar with a few classes to be distributed
with the application. It will likely be open-source as well.

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

"Russell Egan" <russegan@email.com> wrote in message
news:9662290.1053112988501.JavaMail.jrun@is.intellij.net...

So on the build machine (let's say the nightly build is performed on a

non-development box), all we'd need to build a project using the gui
framework would be this jar and the custom ant task? That jar will contain
everything required to compile your xml format into .class files? And this
will be open-source? (wow)
>

Will he compiled .class files will rely on a library which needs to be

redistributed with the application?

Love the progress news. Very exciting to get that "behind the scenes" look at your development process, and what's coming up. IntelliJ EAP rocks!

Okay, got it, you scared me there. Absolutely reat to hear you'll be open-sourcing the form compiler.

Out of curiousity, though I ask one point of clarification. By "replace javac", do you mean "forms files are compiled with this new Ant task to .class files, while .java files are compiled with javac to .class files" or do you mean "both form files and .java files are compiled to .class files using this new task". That second one seems odd, as it means you're on the hook to support any future changes to the javac task in your form compilation task.

BTW, I absolutely love the progress report idea. Thanks.

On Fri, 16 May 2003 22:52:10 +0400, Valentin Kipiatkov wrote:

Why IDEA? It's just a small jar with custom Ant task implementation. We
are even going to make it open-source.

Whats needed to deploy apps using the Idea GUI designer? Do we need to
ship a small runtime jar?

--
...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 Fri, 16 May 2003 23:34:38 +0400, Valentin Kipiatkov wrote:

Yes, there will be another small jar with a few classes to be distributed
with the application. It will likely be open-source as well.

What license will Jetbrains be choosing for this?

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

>> EEEP!! I thought we had driven a stake through the heart of this particular design choice. If I can't use the GUI builder without making IDEA part of my build, then I can't use the GUI builder. <<

Er .. isn't that the point of these chaps writing an ant task?

The reports are a really good idea by the way. If folk don't see a new EAP for as while, at least they know what's going on ...

+1

Ian Mayo

"Chris Chernesky" <online@reality3.com> wrote in message
news:5622243.1053112306235.JavaMail.jrun@is.intellij.net...

Thanks so much for detailing your effort this week. It's really nice to

see where the development is happening and it gives us a nice "preview" of
the parts of the code we can test.
>

Taking the time to send out a message like this is really appreciated!

>

Thanks!
-Chris

>

+--
Chris Chernesky
Technical Lead
5/3 Bank+

Out of curiousity, though I ask one point of clarification. By "replace

javac", do you mean "forms files are compiled with this new Ant task to
.class files, while .java files are compiled with javac to .class files" or
do you mean "both form files and .java files are compiled to .class files
using this new task". That second one seems odd, as it means you're on the
hook to support any future changes to the javac task in your form
compilation task.

I mean the second. It extends javac task so there should be no problems when
it changes.
The reason why we need to process both java and form files is that we need
to incorporate some code into classes using the forms.

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


"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:27228227.1053117376593.JavaMail.jrun@is.intellij.net...
>

Okay, got it, you scared me there. Absolutely reat to hear you'll be

open-sourcing the form compiler.
>

Out of curiousity, though I ask one point of clarification. By "replace

javac", do you mean "forms files are compiled with this new Ant task to
.class files, while .java files are compiled with javac to .class files" or
do you mean "both form files and .java files are compiled to .class files
using this new task". That second one seems odd, as it means you're on the
hook to support any future changes to the javac task in your form
compilation task.
>

BTW, I absolutely love the progress report idea. Thanks.

Whats needed to deploy apps using the Idea GUI designer? Do we need to
ship a small runtime jar?

Yes, exactly. We will likely open-source it, if you care. See above.

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


"Mark Derricutt" <pinhead@satinism.org> wrote in message
news:pan.2003.05.16.20.43.28.506250@satinism.org...

On Fri, 16 May 2003 22:52:10 +0400, Valentin Kipiatkov wrote:

>

Why IDEA? It's just a small jar with custom Ant task implementation. We
are even going to make it open-source.

>

Whats needed to deploy apps using the Idea GUI designer? Do we need to
ship a small runtime jar?

>

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

>

What license will Jetbrains be choosing for this?

I cannot answer this question in details yet (it's just not decided yet) but
I suppose you'll be allowed both redestribute it with any application and
make any changes into it if you like.

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


"Mark Derricutt" <pinhead@satinism.org> wrote in message
news:pan.2003.05.16.20.44.26.674395@satinism.org...

On Fri, 16 May 2003 23:34:38 +0400, Valentin Kipiatkov wrote:

>

Yes, there will be another small jar with a few classes to be

distributed

with the application. It will likely be open-source as well.

>

What license will Jetbrains be choosing for this?

>

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

>

+1

+1

+1

3. We have completely rewritten the implementation of
the editor management.
Now it supports arbitrary custom editors (JComponent)
inside the tabbed pane
where all editors are located. This allowed us to put
our GUI designer into
the editor pane.
The API of this subsystem should be reviewed and
after that we'll make the
first public draft of "custom editor" API.

Is it also as a step towards "Allow for multiple views of the same file"?
http://www.intellij.net/tracker/idea/viewSCR?publicId=7326

I mean the second. It extends javac task so there
should be no problems when
it changes.
The reason why we need to process both java and form
files is that we need
to incorporate some code into classes using the
forms.

I have two serious concerns with this:

1. We're using javamake (which is also an extension to javac task) to recompile our sources with dependency checking. We'll have got a trouble combining this with "intellij" ant task.

2. Maybe I did not follow the discussion on GUI designer carefully enough, but I do not remember someone saying that java source files will require modification/preprocessing. Given that as a net result we'll have got compiled binary classfiles, without any intermediate source code, I'd say it seriously compromises openness of the framework. What code is to be incorporated into java source files? What's the reason to do this and could it be done in a different way? Why can your task not generate just source code (perhaps to a separate dir), which can be then compiled by a standard javac task or javamake?

+1

+3. We have completely rewritten the implementation of the editor management.
Now it supports arbitrary custom editors (JComponent) inside the tabbed pane
where all editors are located. This allowed us to put our GUI designer into
the editor pane.
The API of this subsystem should be reviewed and after that we'll make the
first public draft of "custom editor" API.+

do you change the open api for including own editor panes (like an editor for java-internationalization)? when do you do this? at the same time when you change the API?

Is it clear which source file have to be compiled with the intellij compiler? Perhaps the use of the intellij ant task can be isolated to only those source files which interact with the gui framework, while the rest of the project can continue to use javamake or whatever?

Is it also as a step towards "Allow for multiple views of the same file"?
http://www.intellij.net/tracker/idea/viewSCR?publicId=7326

We plan this request for Aurora. You may think it's a step in this direction
as well.

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


"Sergei S. Ivanov" <jiveadmin@jetbrains.com> wrote in message
news:13162031.1053329615292.JavaMail.jrun@is.intellij.net...

3. We have completely rewritten the implementation of
the editor management.
Now it supports arbitrary custom editors (JComponent)
inside the tabbed pane
where all editors are located. This allowed us to put
our GUI designer into
the editor pane.
The API of this subsystem should be reviewed and
after that we'll make the
first public draft of "custom editor" API.

>

Is it also as a step towards "Allow for multiple views of the same file"?
http://www.intellij.net/tracker/idea/viewSCR?publicId=7326

1. We're using javamake (which is also an extension to javac task) to

recompile our sources with dependency checking. We'll have got a trouble
combining this with "intellij" ant task.

Given our Ant task is open source you (or someone else) can change our task
to be based on javamake.

>

2. Maybe I did not follow the discussion on GUI designer carefully enough,

but I do not remember someone saying that java source files will require
modification/preprocessing. Given that as a net result we'll have got
compiled binary classfiles, without any intermediate source code, I'd say it
seriously compromises openness of the framework. What code is to be
incorporated into java source files? What's the reason to do this and could
it be done in a different way? Why can your task not generate just source
code (perhaps to a separate dir), which can be then compiled by a standard
javac task or javamake?

It does not modify the source code, it just incorporates some code into the
classs "associated" with the form. It's necessary to instantiate the form,
bind it's controls to the fields of your class etc.
Again given it's open source you may change it in any way which you want.

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

"Sergei S. Ivanov" <jiveadmin@jetbrains.com> wrote in message
news:16480967.1053336727972.JavaMail.jrun@is.intellij.net...

I mean the second. It extends javac task so there
should be no problems when
it changes.
The reason why we need to process both java and form
files is that we need
to incorporate some code into classes using the
forms.

>

I have two serious concerns with this:

>

1. We're using javamake (which is also an extension to javac task) to

recompile our sources with dependency checking. We'll have got a trouble
combining this with "intellij" ant task.
>

2. Maybe I did not follow the discussion on GUI designer carefully enough,

but I do not remember someone saying that java source files will require
modification/preprocessing. Given that as a net result we'll have got
compiled binary classfiles, without any intermediate source code, I'd say it
seriously compromises openness of the framework. What code is to be
incorporated into java source files? What's the reason to do this and could
it be done in a different way? Why can your task not generate just source
code (perhaps to a separate dir), which can be then compiled by a standard
javac task or javamake?

Is it clear which source file have to be compiled with the intellij

compiler? Perhaps the use of the intellij ant task can be isolated to only
those source files which interact with the gui framework, while the rest of
the project can continue to use javamake or whatever?

You should only compile the forms themself and all classes "associated" with
them. (For each form, there is one class associated with it which has fields
binded to form controls. Instantiating of this class automatically
instantiates the form and fill the fields.)

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


"Russell Egan" <russegan@email.com> wrote in message
news:14023934.1053342787757.JavaMail.jrun@is.intellij.net...

Is it clear which source file have to be compiled with the intellij

compiler? Perhaps the use of the intellij ant task can be isolated to only
those source files which interact with the gui framework, while the rest of
the project can continue to use javamake or whatever?

API is meant as Open API. So internal API to custom editors already exists
and we just have to review it and make open.

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

"Michael Seele" <mseele@guh-software.de> wrote in message
news:21818888.1053338372939.JavaMail.jrun@is.intellij.net...

+3. We have completely rewritten the implementation of the editor

management.

Now it supports arbitrary custom editors (JComponent) inside the tabbed

pane

where all editors are located. This allowed us to put our GUI designer

into

the editor pane.
The API of this subsystem should be reviewed and after that we'll make the
first public draft of "custom editor" API.+

>

do you change the open api for including own editor panes (like an editor

for java-internationalization)? when do you do this? at the same time when
you change the API?

+8. We were experimenting on Look&Feel changes. They are in progress yet
(that might cause inconsistencies).+

do you change the whole look&feel or only parts of it?

ok. great!!!