Re: We need Grasshopper for Delphi!!

Jonathan Neve [Microtec] wrote:

> Hi Paul,
>
> Paul Nichols [TeamB] wrote:
>> "Jonathan Neve [Microtec]" <jonathan@xxxxxxxxxxx> wrote in message
>> news:430b0dc9$1@xxxxxxxxxxxxxxxxxxxxxxxxx
>>>If you're interested, you can see the project page I made here:
>>>http://jdelphi.dev.java.net
>>>


> Well, ok, JB is, perhaps, a little more RAD than Eclipse, but it
> certainly isn't even remotely comparable to Delphi. Personaly, I find
> the GUI builder heaver, clumsy, and tedious to use. It's not just one
> thing, it's lots of minor things that make it counter-intuitive, slow
> and difficult to use. All this hinders RAD.
>
I guess that depends upon your experience with both environments :)

I will agree that Java Swing development takes more time to become
proficient with. You can use your Delphi OOP experience (especially if you
write your own Components), but there is definitely a difference, and
coming from C++ Builder or Delphi, or any Windows RAD tool, you have to
think, XPLatform.



>> I find that the largest hurdle with Swing is
>> understanding Layout Managers and the listener/action events in Swing.
>
> I emphatically agree. Layout managers are a complex feature that is
> decent when you're designing your window by code, but, IMO, hard to
> reconcile with the concept of RAD and of a GUI builder.

This is actually one feature where JB excels over other tools I have used.
JB actually makes this easier to do with Swing development. Using GridBag
layout, JBuilder has little known but documented ways to design these
nested panels with a right click feature that can perform the XY offsets
for you.

I find many do not know about this feature, however,


> As for the
> listerner/action "events", they are even worse. I think that structure
> is far too heavy. It's good how you can have multiple event handlers for
> the same event, but it needs to be presented in a better way (using
> introspection for example) so that a new class doesn't need to be
> implemented for EVERY event handler...
>
I understand why they are this way (full control over the environment, plus
threading issues), but I would agree, they are complex. The new Swing in
1.5 helps with this complexity.


> I agree, SWT would be a better basis. I would envisage making wrapper
> classes (using the same names as the VCL -- why not? :) ) around SWT so
> that coding it can be simpler and also, so that the internal library
> could painlessly be switched from SWT to something else if a better
> option came along in the future.
>
That's the way I think I would approach it.

I actually started a project to convert Delphi code to Java Swing. I have to
say, too much trouble :)

Converting non GUI code is not that problematic.

>
> Yes, well in any case both J2ME and J2EE are pretty different. J2ME
> means very simple user interfaces. So simple that they probably hardly
> need RAD GUI designing.

Well midlets are actually pretty neat..Yes lighteight and simple, but new
features have been added that are now appearing in the smallest of devices
with CDLC.


> J2EE on the other hand is mostly server stuff
> that hardly needs a GUI at all. Furthermore, both these platforms seem
> to have more tools designed to support them, due to the simple fact that
> Java desktop applications aren't all that popular (for obvious
> reasons...).

I think all desktop applications are becoming less impoertant (except for of
course Office suites and certain tools). Most everything has been NET
enabled. The reasons are simple--- one installation source, and updates do
not need to be rooled out;-- they are instantly available via a url entered
into a browser. No downloads, no bandwidth considerations, and few support
issues are a few of the benefits.

With new extensions like Laszlo (IBM), XUL, and Ajax, they are getting more
able to mimic GUI desktop apps.



>
> So I think J2SE is the only platform that really needs a Java Delphi
> IDE, or at least, the one that needs it the most. If it were possible to
> make rich client applications in Java as easily as they can be made in
> Delphi, and with results as good (mostly as far as the GUI is
> concerned), I'm sure a lot more people would make them. But since
> there's currently no tool to enable this, Java development seems to be
> mainly focused on the web and web-services, or else mobile development,
> and such like.
>
I would think including a JSP type environment and Servlets would be
necessary as well. Delphi that cannot do Web would hinder acceptance,IMHO.


> Exactly. And no, Kylix doesn't seem to be the answer, especially
> considering that Borland doesn't seem too interested in it these days...
>
Unfortunately.. I really think that Borland could have owned the C++ world,
if they had come out with a RAD tool for both Desktop, CLI, Web, and
embedded that was truly xplatform. They started with CBuilderX, but did not
follow through. C/C++ is still widely popular (only behind Java) in most
corporations today.


>> The company I work for
>> (50,000 employees) ,
> !!!
> Didn't even know such a beast existed! Personally, I do prefer working
> in our 7-employee company though. :)

Well, now you can understand why we do little to no Fat Clients. With
50,000 computers to update, can you imagine the logistics nightmare, not to
mention support issues?


>
> Such a concept is very foreign to me. :)

If you were in my shoes :), it wouldn't be.

If you think of the nightmares rich clients would cause in large
enterprises, with such a large user base, it is easy to see why server
based applications are a much better paradigm. That is why most Enterprises
have gone to Intranet/Extranet and Internet based applications.

What we have basically done is moved back to the AS400/Mainframe days. The
5250 and 3270 emulators are now a browser, instead of green screen
terminals :).

Support cost and bandwidth issues will cripple Enterprise IT departments in
the time spend just on updates and support alone with client rollouts. If
you updated only 5 apps per year, that is 50,000 x 5 or 250,000 machines to
update per year. Of course, we have much more than just 5 apps used as
well.

I have worked in three fortune 500-1000 companies with more than 23,000
employees. When rich client/server was the hot issue of the day, updates
literally took weeks to months to straighten out. Server-centric models
work much better here, where the only installs and updates are on the
corporate servers.

Of course when we did rich client GUI programming, we used a Push technology
or EDI. But still, there will always arise install/update issues combined
with user ignorance. :)

This is another reason why I think that a Delphi to Java
extensions/compilers should include basic HTTP type programming models.

Have a great day!!

.

Relevant Pages

  • Re: We need Grasshopper for Delphi!!
    ... > Delphi whatsoever, whereas I am mostly a Delphi developer, ... > with only limited Java experience... ... > it's nothing comparable to Delphi as far as RAD is concerned. ... I do extremely little desktop thick client GUI programming ...
    (borland.public.delphi.non-technical)
  • Re: We need Grasshopper for Delphi!!
    ... COM. Delphi GUI client can also access J2ME on embedded devices. ... Java is able to access Delphi component or even ...
    (borland.public.delphi.non-technical)
  • Re: Death of Kylix and migrating towards Java
    ... > Its been our intentions for about the past 2 years to convert out Delphi ... > and I am rather fearful of the switch. ... Java is where I am personally leaning myself. ... The Java GUI applications can still be a little slow. ...
    (borland.public.delphi.non-technical)
  • Re: Heavy weight companies and Linux.
    ... > and none of them could develop screens in Swing within 5 times of the time ... > would take me to develop a similar screen in Delphi. ... NO GUI development in Java will usually take longer. ...
    (borland.public.delphi.non-technical)
  • Re: We need Grasshopper for Delphi!!
    ... people who joined were mostly Java developpers with no experience of ... Delphi whatsoever, whereas I am mostly a Delphi developer, ... with only limited Java experience... ... reconcile with the concept of RAD and of a GUI builder. ...
    (borland.public.delphi.non-technical)