IDEA 4.0???
"IDEA 4.0 Comming soon" is getting kinda stupid. It's been there for months.
WHEN will 4.0 get released? We bought 3.0 in the belief that 4.0 would come soon with GUI support.
No such luck :(
Please sign in to leave a comment.
In article <26482333.1075327154575.JavaMail.itn@is.intellij.net>,
charles decroes <spam@decroes.com> wrote:
Both. That is, best people who develop GUIs and the best people who
design GUIs.
The Mac also has really nice GUI design tools, but since I haven't used
many non-Mac GUI design tools (except for Visual Cafe way back when
(yeeeech!)), I can't compare the Mac's GUI design tools to any other
ones.
But my point was that people have been making really good Mac GUIs for
many years using GUI design tools rather than by hand-coding them.
On Tue, 27 Jan 2004 15:27:14 -0500, Erb wrote:
Ironically, the UI designer started out built in, then separated out to a
plugin, then later on, returned to the core application, and the backend
split into the redist jars.
"Just cause theres no JSR doesn't means theres no standard, or can't be."
All current Java standards originates from a JSR, Sun or a major standardization organization.
XUL is useless.
Aha, I got you.
Distance to borders: all anchors have a offset displacement which is system wide setting. Distance to border (or anything else) is a 10 seconds change.
The kind of change that your way cannot possibly deal with easily is when the controls are to move around, or when the entire form is to be reorganized. With XY and anchoring, this is brainless but hopless with your way (unless you wanna spend your life beeing non-productive.)
I cannot believe we are even discussing this...
On Thu, 29 Jan 2004 08:23:17 +0000, no_mail wrote:
In what way? At least quantify your argument with reasons...
On Wed, 28 Jan 2004 13:48:42 -0800, Erik Hanson wrote:
I can't see where it bogs down the UI, its completely hidden from view
unless you use it ( evident from the number of posts from people saying
"where the hecks the GUI builder"
Try to start a new thread on Javalobby with this topic ;)
Tom
Well, let a dumb developer use the GUI designer (the tool) and you will
get a horrible GUI.
Tom
"Mark Derricutt" <mark@talios.com> wrote in message
When you talk about vomit, do you mean Delphi or JBuilder? I used Dephi from
1.02 to 5.0 and it was the best language/IDE/UI designer/debugger tool I
ever seen for Windows. The VCL beautifully hides the rusty nuts and bolts of
WinAPI and form design is as easy as dropping a control and writing a
handler for it. No unnecessary interitance of controls unless you do not
want to have more handlers, here you are, the whole WinAPI and messaging
system is for you. The possibility of inheriting forms. The protocol to
create your own components is pretty simple and straightforward. Delphi is a
underappreciated gem. Well, Mark, you know it :)
One of the problem of IDEA and Java in general that all UI is in the code,
there are no resources. This is just plain stupid, because resources do not
have to be bitmapped or fixed-positioned. In fact, Windows dialogs were
always measured in dialog units which is not the same as pixels. On the
downside Windows dialogs do not have these handy layouts as Swing has where
components can move each other. I cannot get why Swing designers did not
combine the best from different systems and invented pure source-code
technology instead.
If IntelliJ guys want to be really different they should create java
resource format (XML whatever, who cares about file size now) and render
forms dynamically in runtime. Their current approach of compiling of XML
layout and source code stubs into a class file is just a half step, but I
think this is the step in the right direction. I never worked with Mac or
XWindow but I guess the principles there are the same as on Windows:
controls with types and IDs and a messaging system. Application may
intercept messages if it wants to. This approach allows to modify resources
and a code separately, basically it is a runtime binding. IDEA UI Designer
currently produces a monolythic code bound at compile time. The classic way
to localize Windows application is to edit resources, change menu items,
change bitmaps, change error messages. All this can be done within EXE file
without recompiling it. Can you do it with IDEA-generated code? I haven't
checked lately but I guess the answer is still No.
When UI Designer supports proper internationalization without recompiling,
it will use some sort of resources being loaded during runtime. So the
support for runtime resource loading will be there anyway. Then why not to
build the whole system using runtime resources from the beginning???
And one last thing: can someone explain to me why there are no resources in
Swing? Maybe I miss something?
Michael J.
Well, Carlos, if you ever have created dialog resources for Windows you
should know that their sizes are in dialog units not in pixes. Dialog unit
size depends on dialog font size as well as on screen resolution (not the
size in pixels, but resolution which is usually 72, 96, 120 dpi or some
other).
This is why properly designed dialogs look good after you change your system
fonts to "Large". Windows does this "10% increase" automatically. Consider
it a built-in layout manager, though not so feature-rich like modern Swing
layout managers, but the USER.EXE is what? 20 years old.
Swing designers could do much better but they decided to stuff everything in
the code instead. Bummer.
Michael J.
"Carlos Costa e Silva" <carlos@keysoft.pt> wrote in message
news:bv8u1i$trq$1@is.intellij.net...
>
>
>
...
>
"Resources, resources", shouted they ;)
1. Error check --> DTD/schema
2. Reference check --> what for? UI calls the code, not the code calls UI.
Well, yes you need to populate lists and enable buttons, but this can be
done using messages. No recipient -- no cry. The same with button press --
no resource --> no message.
3. Why use variable names in XML if one can use control IDs? Code is bound
to UI, so code needs to know IDs. UI is not bound to code, why it would need
to know real variable names?
Maybe my Windows past blurres the new world of Java GUI to me?
Michael J.
"Thomas Singer" <nomail@nodomain.com> wrote in message
news:bv7q40$671$1@is.intellij.net...
>
>
"Rob Bradley" <no_mail@jetbrains.com> wrote in message
news:14034423.1075285056388.JavaMail.itn@is.intellij.net...
>
as an optional plugin too. As it's something I'm probably never going to
need I'd rather it didn't bog down the IDE so to speak.
That was I tried to suggest to jetbrainers. Stuff like J2EE support, UI
Designer, quality Starteam integration should be plugins. Like it -- buy it.
Don't need it -- get the base IDE for, say, $200 instead of $500. Is it
really a bad business model? I guess Eclipse is going it this direction. The
base thing is free, but there are a lot of cool plugins which are not. All
in all, I like Eclipse more and more as an IDE and as a business approach.
The situation is almost like Netscape vs IE. After v 4.0 was released, where
did Netscape go?
>>If the coordinates aren't in pixels, what are they in?
usually dialog units or twips or some other logical metric.... ever changed the font size or border sizes in windows? this work like a sharm, yet everything in windows is designed in XY layout - this is due to using dialog units rather than pixels.
combined with anhoring, logical XY is actually very good, if not the best.
Michael Jouravlev wrote:
mozilla/firebird? imho much much better than IE.
--
Dmitry Skavish
"Dmitry Skavish" <dmitry@jzox.com> wrote in message
news:bvbvsc$3q9$1@is.intellij.net...
All
approach.
where
>
This is for geeks, I was talking mass market. Anyway, I am on Windows and I
use IE + Naviscope, good enough to cut off ads. Development tools are for
geeks by definition but still, I was talking about business model, forget
IE. The point is that Eclipse provides a lot for free. If one needs
additional tools, he can get them either for free or buy them depending on
3rd party vendor. The funniest thing is that this business model is nothing
new, it was used for ages in scientific, egineering and imaging software.
Need a functionality -- go buy a module. Simple. To make everybody happy 3rd
party vendors just have to pay small royalties to Eclipse for their plugins
being used, because if not for Eclipse they would not be used at all. Any
comment on that?
I have a feeling that next Eclipse after 3.0 will murder IDEA. Well,
Jetbrains joined JTC, Sun is gathering allies to start friendsade against
Eclipse. Considering that IDEA does not support SWT and there are no plans
to do that, it is probably more reasonable to join JTC instead of Eclipse.
We will see. I personally like SWT, this model is so much closer to what I
was doing before plus native LnF plus other native goodies like
drag-and-drop.
I think this year will be the point of no return for IDEA and I do not have
too high expectations about that. Aurora is still somewhat shaky, from the
other hand I am totally satisfied with my 3.0 version. Eclipse is getting
better and better, my former company released pretty nice and useful plugin
for it, but not for IDEA. They and others are going to promote Eclipse while
benefiting themselves. Go figure.
Michael.
On Thu, 29 Jan 2004 11:51:50 -0800, Michael Jouravlev wrote:
JBuilder/Netbeans vomit. I love the .dfm form format of Delphi, the only
thing I didn't like about it was having three pages of TLabel, TDBEdit,
TTable controls declared, when I never actually used them ( in cases where
they were databound, without any event handlers directly against the
objects ). Being able to declare only those objects I actually wanted (
such as with the IDEA GUI tool ) would be nice.
Definitely, and it'll be interesting to see how Delphi 8.NET fares, I
looked eagerly at Kylix when it came out, using various betas, but
unfortunately it just never lived up to what I hoped. It was good, but by
the time it came out, other solutions for RAD linux development were
showing their heads ( I also discovered Visual Works Smalltalk for linux,
now if only I could grok Smalltalk more ]]>).
Oh god how I hated twips-per-inch ;p
Being able to switch, mix, and match would be great. Alot of forms you
wouldn't want end users to edit, but mix in dynamic generation, and
scripting languages, and you've got a hell powerfull match there...
Looking at the current third-party source generator, it wouldn't be hard
to write your own dynamic loader. The only problem I see with that, is
linking up events and listeners to controls, if someone edits the name of
the control, or changes its class, you've now got something thats liable
to break without strict control measures.
The UI designer can currently load labels from any defined resource file,
with full i18n.
Mark
"Mark Derricutt" <mark@talios.com> wrote in message
news:pan.2004.01.29.23.55.14.576502@talios.com...
Exactly. That is what I meant by saying that Swing designers could do
better, they could take the best from all the worlds.
>
If we used messages and control IDs, than no one would care for class or
variable name or even for existence of a particular control. Classic
messaging gives much more loose relation of UI to handlers.
What about images? No, it is not like a loading from resource yet. When they
implement dynamic loading of all possible resources they will end up with a
proper resource file ;)
On Thu, 29 Jan 2004 17:08:32 -0800, Michael Jouravlev wrote:
One thing thou, the XML files loaded dynamically, are they going to be
buried in a .jar or left open for the world to see, having joe-blogs user
modify things, then complain the behaviour has all changed is just a
asking for a support persons nitemare...
Michael,
In my imagination you only add components to the layout manager (e.g.
panel.add(button, "okButton");) and the layout manager reads the layout
from a resource file. The resource file defines the rows and columns of
the layout and where to put the components.
Now there need to a tool, that allows you to set the row and column
properties as well the position of the components. But there also should
be a tool, that verifies at compile time, whether the "cancelButton",
that is positioned at cell (8; 9) in the resource file is also added to
the layout manager.
Cheers,
Tom
I'm going to be honest with you I'm just assuming that it bogs down the IDE, as must any other features or plugins you add which is why they should be optional. Extra features like this usually means larger files, longer to load, and (sometimes) more memory used. It's not so much that it's bogging down the IDE as that it's using resources on my machine that I could do without.
Don't get me wrong, I don't mind having it there, and it doesn't effect productivity in any way with it being there... just that if it were an optional download from an official JetBrains plugins site (i.e. a place that stored ONLY plugins written by JetBrains themselves) then it wouldn't have to be packaged with the primary build.
I'm not even going as far as saying I'd like JetBrains to developer different versions and pricing structures to IDEA. That just over-complicates things IMO and I like the flexibility of being ABLE to use things like a GUI designer in case I ever need it without having to fork out for a different license. However I would like to have something like an area accessed through your license key (or the IDEA plugins browser) that licensed users could go to download these features.
I'd say it's just the opposite. I don't think these integrated features consume noticeably more
resources. I'd even say that, if ever, these things become plugins, there's a chance that they
are less performant than they could be when tightly integrated. This would be a bad deal then
for those who actually use these features - even if just occasionally.
Fact is, that it would take (developer-) resources for JB to isolate the "big" features into plugins.
This would only pay off if the whole business was changed. Isolating stuff and making it optional
just for saving a few KB pays off for nobody. Not JB, and even not really for the users because
it's just more hassle to download the things when you need them. My opinion is that if the IDE
doesn't run with those features (e.g. the GUI designer) it doesn't without them either. On the other
hand, if it works well for you, you'll also never notice the difference. So why bother?
Just my 2c.
Sascha
Rob Bradley wrote:
is why they should be optional. Extra features like this usually means larger files, longer to load, and (sometimes) more memory
used. It's not so much that it's bogging down the IDE as that it's using resources on my machine that I could do without.
>
if it were an optional download from an official JetBrains plugins site (i.e. a place that stored ONLY plugins written by JetBrains
themselves) then it wouldn't have to be packaged with the primary build.
>
over-complicates things IMO and I like the flexibility of being ABLE to use things like a GUI designer in case I ever need it
without having to fork out for a different license. However I would like to have something like an area accessed through your
license key (or the IDEA plugins browser) that licensed users could go to download these features.
"I have a feeling that next Eclipse after 3.0 will murder IDEA."
Certainly not. Not because Eclipse is bad, but because there's not professional support available. A lot of companies choose to not use Eclipse because it's open source with the risk that involves.
I know that a former edition of Together/J was created on top of Eclipse but they decided to drop it because the future of Eclipse was very unclear.
Also, IDEA has crucial features that Eclipse lacks and will lack for a long time.
While I hate the IDEA UI Designer, I still think IDEA is by far the best coding tool for Java. Yes, I've tried 'em all.
I have tested it for a day now.
Not very promising... it took forever to create even a simple GUI.
Is this supposed to be "taking the pain out of GUI building" ??????
Here is what they advertise:
"Here's instant relief from the "pain points" of creating Java™ GUIs. Stop wrestling with layouts and writing loads of code for even simple things. Drop your "widgets" into the design space, position them where you want them, "wire" them up to the application's functionality, and you're done. IDEA intelligently handles the runtime layout positioning and generates all the internal UI code. "
First of all, the first thing I was wrestling about were layouts. Loads of code for even simple things... well I even had to code the frame title text !!! Position them where you want them? No xy or null layout support so this doesn't work either. "wire" widgets up? Can't even generate event handlers :(
I certainly hope the released version is better than this 'cus this is the worst UI designer I've seen in a long, long time. How sad.
The IDE in general seems a little slower, but I guess this will be fixed in the release.
Thomas,
we are talking about different things here. You want the components
themselves to be defined in the code, and to keep only their positioning in
the resource file. In this case you need this complex validation to verify
that there are corresponding components for your positioning -- you cannot
position something you do not have. Also, you get obvious dependency here:
first you define the components, then you define positioning for them. Which
means that you cannot define form with a button and not have a corresponding
code for it.
This totally differs from standard resource-based approach: create a dialog,
drop a button, assign an ID. Then go to the code and write a message/event
handler for this button. Or two handlers, or ten of them. Or none. Or do it
vice versa and write handlers first. The point is that UI and the code is
decoupled which, granted, can lead to strange behaviour if you forget to
write a proper message handler. But it gives more freedom. Also code does
not create the components themselves, the UI subsystem does (in Windows case
it is done somewhere in the USER module, whatever).
I have done quite a bit of Windows UI development using standard resorce
compiler + plain message loop approach as well as more development-friendly
Delphi approach. If one cannot make do with dialogs, he can create controls
right in the code as well. So I cannot get why AWT/Swing which was released
15 years after Windows first came out, has less functionality than old rusty
tools.
The bottom line is that someone has to come up with proper resource
management for Java GUI with real dynamic loading. Until then everything we
get will be just a dressed-up code generator.
Michael J.
"Thomas Singer" <nomail@nodomain.com> wrote in message
news:bvd5dn$q94$1@is.intellij.net...
>
>
>
Michael Jouravlev wrote:
I've never done much work with windows gui programs, so can't really
comment on this. Tried a bit of vb gui (1996? about vb 3?) and really
hated it: no autosizing of text fields, no auto spacing of components,
no anchors, ... -> real xy layout :) Lot's of work producing usable
data entry forms.
Well, the discussion on xy layouts started really badly :)
Up to this thread, every reference to XY swing layouts I've
read/heard about has been to absolute positioning layouts -> xy
positions in pixels and no anchoring/relative positioning/etc.
This thread has been enlightening (to me) in that the XYLayout that has
been talked about in here has no relation to an abolute layout and
seems to be somewhat usable :-).
Jus't for curiosity, does the XYLayout in JBuilder/Netbeans/... manage
all/most of what has been talked here: anchors, relative xy dimensions
(twips/dpis/whatever), parametrizable distances to borders and h/v
distance between components?
???
Carlos