Some questions about DEMETRA

a) given that DEMETRA has an ETA of summer 2006, will
it run on JDK6 per default?

That seems unlikely, since the release of JDK6 will be in the fall of 2006 (http://weblogs.java.net/blog/ray_gans/archive/2006/01/where_we_are_wi.html).
And Mac OSX users will probably have a JDK6 implementation much later than that.

Bas

Hello Yann,

YC> Just some questions I stumbled about, sorry if any of them is a
YC> repost or has been answered before
YC>
YC> a) given that DEMETRA has an ETA of summer 2006, will it run on JDK6
YC> per default?

No, Demetra will use JDK5.

YC> b) will there be more translations than just EN/JAP? I saw a poll on
YC> your website about this?

Can't say anything on this right now. Maybe. Contributions are welcome. :)

YC> c) it would be nice if there was a "coming up soon" feature list, so
YC> plugin authors could plan accordingly

The best thing that we have right now is the Demetra roadmap:
http://www.jetbrains.net/confluence/display/IDEADEV/Demetra+Roadmap

YC> d) linked with c), I have the personal feeling that there's not much
YC> going on in JIRA during the last 2-3 weeks, e.g. out of the 48 open
YC> bugs/feature wishes I posted only half of them have been assigned or
YC> commented on, although some of them are clearly bugs or exceptions

I admit that it sucks, but unfortunately this is quite typical for the development
phase at which we're now. JIRA gets much more attention at the bugfixing
phase of the release cycle than at the active development phase.

Try submitting bugs for UI Designer - I promise to handle them more promptly.
:)

YC> e) please start providing clear and complete JavaDoc for new
YC> features in OpenAPI NOW, I understand your time is valuable and
YC> there's many other things on your schedule, but the earlier this is
YC> available, the earlier we will see new and improved plugins which
YC> largely contribute to IDEA's success and thereby $$$

I'm afraid that it's not possible with the resources that we have now. New
OpenAPI features often go through many rounds of changes before they are
finalized. The time spent writing clear and complete JavaDoc for API elements
that will not stay in the final release is purely wasted time, and we can't
really afford that.

As with previous item, we plan to dedicate much more time to OpenAPI review
and documentation after the Demetra feature freeze.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

Dmitry,

thanks for your detailed answers!

Well, your answer to e) is not the one I was hoping for - do you really implement new features without any JavaDoc?

Yann

Hello Yann,

YC> Well, your answer to e) is not the one I was hoping for - do you
YC> really implement new features without any JavaDoc?

Do you really think that we implement new features with JavaDoc and then
strip it for evil and malicious purposes? :)

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

ofcourse not ;) but I wonder how this does work in your development process

ofcourse not ;) but I wonder how this does work in
your development process

When everyone working on the code has a deep understanding of it, code is documentation -- no need for javadocs. That's probably what happens on JetBrains.

Dmitry Jemerov (JetBrains) wrote:

YC> d) linked with c), I have the personal feeling that there's not much
YC> going on in JIRA during the last 2-3 weeks, e.g. out of the 48 open
YC> bugs/feature wishes I posted only half of them have been assigned or
YC> commented on, although some of them are clearly bugs or exceptions

I admit that it sucks, but unfortunately this is quite typical for the
development phase at which we're now. JIRA gets much more attention at
the bugfixing phase of the release cycle than at the active development
phase.

I hate to sound like a broken record, but there's not much that is worse than
letting people (your customers) invest their time to file bug reports and then
let those reports sit there for weeks, months and years without any sign that an
issue has been recognized. Often even several questions about an issue's status
are simply ignored. The worst form of communication is no communication at all.

No doubt, not everything can be fixed instantly, but a little more (reliable)
communication would be very appreciated and would save a lot of frustration. At
least my personal frustration is reaching a level where I'm not sure any more if
I waste my time here or not.

My 2c.

Sascha

Hi,

No doubt, not everything can be fixed instantly, but
a little more (reliable)
communication would be very appreciated and would
save a lot of frustration. At
least my personal frustration is reaching a level
where I'm not sure any more if
I waste my time here or not.

I'm back for just one message to say "me too"... And go away again.

Thanks,
Dmitry

To readonly mode not away from forums :)

Hello Sascha,

SW> No doubt, not everything can be fixed instantly, but a little more
SW> (reliable) communication would be very appreciated and would save a
SW> lot of frustration. At least my personal frustration is reaching a
SW> level where I'm not sure any more if I waste my time here or not.

Sorry for tooting my own horn, but I'll say this once again: I promise rapid
replies and reliable communication to anyone who sends any kind of feedback
related to the UI Designer. :)

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

Although I'm not Sascha, I bite:

Sorry for tooting my own horn, but I'll say this once
again: I promise rapid
replies and reliable communication to anyone who
sends any kind of feedback
related to the UI Designer. :)

As long as you can't make the UI Designer smoothly usable for existing component references, component factories or components without default constructor (e.g. our JTable- or JTree-subclasses with model-parameter in the constructor), it is useless and taking a detailed look wasted time for us.

Tom

Hello Thomas,

TS> As long as you can't make the UI Designer smoothly usable for
TS> existing component references, component factories or components
TS> without default constructor (e.g. our JTable- or JTree-subclasses
TS> with model-parameter in the constructor), it is useless and taking a
TS> detailed look wasted time for us.

I understand that. Suggestions on ways to enable these scenarios are very
much welcome.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

Hello Thomas,

>> Sorry for tooting my own horn, but I'll say this once
>> again: I promise rapid
>> replies and reliable communication to anyone who
>> sends any kind of feedback
>> related to the UI Designer. :)
TS> As long as you can't make the UI Designer smoothly usable for
TS> existing component references, component factories or components
TS> without default constructor (e.g. our JTable- or JTree-subclasses
TS> with model-parameter in the constructor), it is useless and taking a
TS> detailed look wasted time for us.

To clarify the problem a bit: our UI designer supports both bytecode instrumentation
and source code generation. Because of this, the common solution to this
problem used in other designers (entering fragments of source code in "Custom
creation code" property) is not acceptable for us - there will be no way
for us to compile the code if bytecode instrumentation is used.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

>>> Sorry for tooting my own horn, but I'll say this once
>>> again: I promise rapid
>>> replies and reliable communication to anyone who
>>> sends any kind of feedback
>>> related to the UI Designer. :)

TS> As long as you can't make the UI Designer smoothly usable for
TS> existing component references, component factories or components
TS> without default constructor (e.g. our JTable- or JTree-subclasses
TS> with model-parameter in the constructor), it is useless and taking a
TS> detailed look wasted time for us.

To clarify the problem a bit: our UI designer supports both bytecode
instrumentation and source code generation. Because of this, the common
solution to this problem used in other designers (entering fragments of
source code in "Custom creation code" property) is not acceptable for us
- there will be no way for us to compile the code if bytecode
instrumentation is used.

Well, than make it work at least for source code - this would be still much much more than nothing -
i.e. the actual state.

Ahmed.

I wish I could promise you immediate feedback on refactorings, java code insight features, psi, vfs, code coverage and something I don't recall right now, but I'm afraid I can't do it.

Why add initialization code at all? Why not just create/modify one method JComponent createPanel() treating the form class as a panel factory/getter?

Tom

Hello Thomas,

TS> Why add initialization code at all? Why not just create/modify one
TS> method JComponent createPanel() treating the form class as a panel
TS> factory/getter?

Could you please expand on this a bit? Do I understand you correctly that
createPanel() should contain user-written code creating all component instances,
and the rest of the property/layout initialization code should be generated
by the UI designer elsewhere?

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

No, I meant, that method createPanel() should create the outer panel and adds all components to it (plain layout method). All components are available as fields and are created in the constructor. The initialization code either is created by the UI designer or hand coded (the user should have the choice).

Tom

I'm working with JDK 1.6 + latest EAPs for some while and have had no problems, yet.
Editor fonts look a lot better on LCD panels !!

Just one tiny issue: idea.exe does not launch with 1.6 -- whatever I try, it will invariably launch JDK 1.5;
so I use idea.bat instead.

Do not icons popping in the tray for heavyweight hints irritate you?:)