Project X is a Delphi for Mac - What is it ? How work ? VCL ?

Hi

i have read any info about Next Delphi for MAC and Linux       ( *Project X*  )

how work ? 

* IDE is Delphi under windows or native Mac IDE  / Linux ?

* Can i porting Delphi2009-VCL application under MAC / Linux  ( without modify.. )  ?
0
Mauro
6/4/2009 1:32:05 PM
embarcadero.delphi.non-tech 5933 articles. 1 followers. Follow

97 Replies
752 Views

Similar Articles

[PageSpeed] 45

Mauro Botta a écrit :

> i have read any info about Next Delphi for MAC and Linux       ( *Project X*  )
> 
> how work ? 

Nobody knows. We can only guess, but it wil not be the "next" Delphi. It 
is an R&D project as far as we can tell.

> * IDE is Delphi under windows or native Mac IDE  / Linux ?

We can hope that it will be an IDE that will run under Windows, OS X or 
Linux but, whether it will look and feel nbative to each platform, is 
anybody's guess.

> * Can i porting Delphi2009-VCL application under MAC / Linux  ( without modify.. )  ?

I would doubt that this is possible, and if it were, I would not want to 
see Mac development limited to the existing VCL component set. Cocoa UI 
components have a very different look and feel to Windows.

I wold hope that what we are anticipating would be an IDE that allows 
you to use the Delphi language to design Mac applications, not some 
cross-platform monstrosity like you get with Java; which, although it 
might run on most platforms, doesn't look right on any of them.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/4/2009 1:41:13 PM
> I wold hope that what we are anticipating would be an IDE that allows 
> you to use the Delphi language to design Mac applications, not some 
> cross-platform monstrosity like you get with Java; which, although it 
> might run on most platforms, doesn't look right on any of them.

iPhone Support ?
0
Mauro
6/4/2009 1:43:41 PM
Mauro Botta wrote:

> > I wold hope that what we are anticipating would be an IDE that allows 
> > you to use the Delphi language to design Mac applications, not some 
> > cross-platform monstrosity like you get with Java; which, although it 
> > might run on most platforms, doesn't look right on any of them.
> 
> iPhone Support ?

No one knows at this point it is just a fun project to see how far they 
can go. It is has not been scheduled or promised that it will be delivered.
Yes it might be a future version but it can as easely stay a glow in the
eyes of the R&D people.


-- 
"Happiness is good health and a bad memory."
 -- Ingrid Bergman (1917-1982)
0
jo
6/4/2009 1:49:30 PM
Joanna Carter,

It is really not about how the look and feel of components is. It is about the underlying framework that should handle all this. For example, if I do MyButton := TButton.Create() this should create a standard Button under windows with CreateWindowsEx() and under iPhone it should do 

UIButton *Button = [UIButton buttonWithType:]

So basically to me as a developer who has been developing under Windows for 12 years and has 9 months of experience developing for the iPhone, the framework should take care of everything unless you are using the underlying system's API in your program.

So if you are doing this in Windows:

ShowWindow(Form2.Handle, SW_HIDE);

Instead of

Form2.Hide();

Then don't expect Delphi Touch to change your ShowWindow() to an appropriate Mac X equivalent.
0
Vandad
6/4/2009 4:22:04 PM
> {quote:title=jo ko wrote:}{quote}
> No one knows at this point it is just a fun project to see how far they 
> can go.

A fun project? Wow, so much for professionalism.
0
Vandad
6/4/2009 4:23:44 PM
Vandad NP a écrit :

> It is really not about how the look and feel of components is. It is
> about the underlying framework that should handle all this. For
> example, if I do MyButton := TButton.Create() this should create a
> standard Button under windows with CreateWindowsEx() and under iPhone
> it should do
> 
> UIButton *Button = [UIButton buttonWithType:]
> 
> So basically to me as a developer who has been developing under
> Windows for 12 years and has 9 months of experience developing for
> the iPhone, the framework should take care of everything unless you
> are using the underlying system's API in your program.

So, how would I design a form for a Mac app that uses the NSBrowser, 
NSPredicateEditor or an NSRuleEditor control, when all I've got is 
Windows control metaphors?

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/4/2009 4:50:07 PM
jo ko wrote:

> Mauro Botta wrote:
> 
> > > I wold hope that what we are anticipating would be an IDE that
> > > allows you to use the Delphi language to design Mac applications,
> > > not some cross-platform monstrosity like you get with Java;
> > > which, although it might run on most platforms, doesn't look
> > > right on any of them.
> > 
> > iPhone Support ?
> 
> No one knows at this point it is just a fun project to see how far
> they can go. 

As I understood it, it is not a fun project. If they already put
serious R&D in it (and apparently they did), it cost money, and they
don't tend to waste money, AFAICT.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Honolulu, it's got everything.  Sand for the children, sun for 
 the wife, and sharks for the wife's mother." -- Ken Dodd.
0
Rudy
6/4/2009 5:02:32 PM
Vandad NP wrote:

> > {quote:title=jo ko wrote:}{quote}
> > No one knows at this point it is just a fun project to see how far
> > they can go.
> 
> A fun project? Wow, so much for professionalism.

Well, AFAICT, it is not a "fun project".

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"My advice to you is get married: if you find a good wife you'll 
 be happy; if not, you'll become a philosopher."
 -- Socrates (470-399 B.C.)
0
Rudy
6/4/2009 5:03:01 PM
Rudy Velthuis (TeamB) wrote:

> > A fun project? Wow, so much for professionalism.
> 
> Well, AFAICT, it is not a "fun project".

Maybe a fun project, but not just for fun :)

-- 
Cesar Romero
http://www.cesarromero.com.br
http://www.liws.com.br
0
Cesar
6/4/2009 5:04:28 PM
Cesar Romero wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > > A fun project? Wow, so much for professionalism.
> > 
> > Well, AFAICT, it is not a "fun project".
> 
> Maybe a fun project, but not just for fun :)

Exactly.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Because I do it with one small ship, I am called a terrorist. 
 You do it with a whole fleet and are called an emperor."
 -- A pirate, from St. Augustine's "City of God"
0
Rudy
6/4/2009 5:05:35 PM
> {quote:title=Vandad NP wrote:}{quote}
> > {quote:title=jo ko wrote:}{quote}
> > No one knows at this point it is just a fun project to see how far they 
> > can go.
> 
> A fun project? Wow, so much for professionalism.

Hmmm... You make it sound like fun and professionalism can't go together. I assure you they can; I have fun with my job every day, and it's a very professional office and project.
0
Ken
6/4/2009 5:54:22 PM
"Joanna Carter" <joanna@no.spam.for.me> wrote in message 
news:124479@forums.codegear.com...
>
> So, how would I design a form for a Mac app that uses the NSBrowser,
> NSPredicateEditor or an NSRuleEditor control, when all I've got is
> Windows control metaphors?
>

Hire you ?
Rita
0
Rita
6/4/2009 5:56:58 PM
Rita Tipton a écrit :

> Hire you ?

When do I start? :-)

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/4/2009 5:59:01 PM
Rudy Velthuis (TeamB) wrote:

> As I understood it, it is not a fun project. If they already put
> serious R&D in it (and apparently they did), it cost money, and they
> don't tend to waste money, AFAICT.

Nick made it perfectly clear that although they do want to produce "Delphi X"
and market it they can't reassure us that this product will ever get out the 
door. As for wasting of money any R&D has multiple uses beyond the primary 
reaserch goal so it might actualy hit the market in a form completly different 
or multiple forms for that matter. 

As long as they do not commit to a roadmap for this product it has no differense
for us from a just for fun project. 

Don't get me wrong I am excited from what I have heard until know even if this never
gets out the door it shows that they have vision again and the will to follow it.
I am very optimistic for the future of the company regardles of the future products
and their form or shape. 

Regards

-- 
"The covers of this book are too far apart."
 -- Ambrose Bierce (1842-1914)
0
jo
6/4/2009 5:59:07 PM
Joanna Carter wrote:

> > Hire you ?
> 
> When do I start? :-)

Yesterday!

-- 
Cesar Romero
http://www.cesarromero.com.br
http://www.liws.com.br
0
Cesar
6/4/2009 6:03:10 PM
jo ko wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > As I understood it, it is not a fun project. If they already put
> > serious R&D in it (and apparently they did), it cost money, and they
> > don't tend to waste money, AFAICT.
> 
> Nick made it perfectly clear that although they do want to produce
> "Delphi X" and market it they can't reassure us that this product
> will ever get out the door.

That is something different. That doesn't mean it is a "fun project",
as you called it. It means it is seriously researched. Unfortunately,
research is not always successful. If it turns out to be too
hard/complicated or too expensive, I guess they'll have to dump it.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Love: The warm feeling you get towards someone who meets your
 neurotic needs."
0
Rudy
6/4/2009 6:05:04 PM
Vandad NP schrieb:
>> {quote:title=jo ko wrote:}{quote}
>> No one knows at this point it is just a fun project to see how far they 
>> can go.
> 
> A fun project? Wow, so much for professionalism.

No. A sort of ressearch project. If it succeds then it might turn into a
real product otherwise it will simply get dumped.

Greetings

Markus
0
Markus
6/4/2009 6:50:32 PM
Cesar Romero schrieb:
> Joanna Carter wrote:
> 
>>> Hire you ?
>> When do I start? :-)
> 
> Yesterday!
> 

Oh, you forgot to tell her that she should have finished the project by
the day before yesterday already! ;-)

Greetings

Markus
0
Markus
6/4/2009 6:52:55 PM
Markus Humm wrote:

> > Yesterday!
> > 
> 
> Oh, you forgot to tell her that she should have finished the project
> by the day before yesterday already! ;-)

Thank you for make this all clear :-)

-- 
Cesar Romero
http://www.cesarromero.com.br
http://www.liws.com.br
0
Cesar
6/4/2009 6:55:44 PM
"Joanna Carter" <joanna@no.spam.for.me> wrote in message 
news:124479@forums.codegear.com...
> So, how would I design a form for a Mac app that uses the NSBrowser,
> NSPredicateEditor or an NSRuleEditor control, when all I've got is
> Windows control metaphors?

You make a corresponding Windows version of the controls, or you just make a 
few mac-specific controls, or you just leave it out and let the 3rd party 
tools developers fill in the holes.  I dont see what the big deal is here.
0
Joe
6/4/2009 6:58:25 PM
Joe Demartino a écrit :

> You make a corresponding Windows version of the controls, or you just make a 
> few mac-specific controls, or you just leave it out and let the 3rd party 
> tools developers fill in the holes.  I dont see what the big deal is here.

Ah, so I spend a fair deal of money on a cross-platform product, and 
then I have to spend even more time/money trying to fill in the gaps 
that missing controls make. And just how long do you think it's going to 
take to create a Windows equivalent to the sophistication of something 
like NSBrowser?

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/4/2009 7:22:32 PM
Joanna Carter wrote:
> So, how would I design a form for a Mac app that uses the NSBrowser, 
> NSPredicateEditor or an NSRuleEditor control, when all I've got is 
> Windows control metaphors?

Presumably the same way that they handled Task Dialogs on Vista.  The 
controls are available on their native platform, and it's up to you 
whether you want to use them and tie yourself to that platform or not.

Craig Peterson
Scooter Software
0
Craig
6/4/2009 7:52:35 PM
>> So, how would I design a form for a Mac app that uses the NSBrowser,
>> NSPredicateEditor or an NSRuleEditor control, when all I've got is
>> Windows control metaphors?
>
> Presumably the same way that they handled Task Dialogs on Vista.  The
> controls are available on their native platform, and it's up to you
> whether you want to use them and tie yourself to that platform or not.

Like they *should* have done with Unicode...HAHAHA!!!!
0
Eddie
6/4/2009 7:56:39 PM
I've been to the Delphi day today and I asked DavidI about this very topic.

He said that full pascal components should be able to compile.
VCL wise, it'll have to interface with the native MacOs X side.
There's nothing really showable as of yet, indeed at Delphi Live they had a mac mini but that's all they showed.
IDE should be WINDOWS ONLY(that's been pretty clear to my understanding in the keynote) and different targets are... well... on target :-) using Build Configurations.

Andrew
0
Andrea
6/4/2009 8:23:40 PM
Andrea Raimondi a écrit :

> He said that full pascal components should be able to compile.
> VCL wise, it'll have to interface with the native MacOs X side.
> There's nothing really showable as of yet, indeed at Delphi Live they had a mac mini but that's all they showed.
> IDE should be WINDOWS ONLY(that's been pretty clear to my understanding in the keynote) and different targets are... well... on target :-) using Build Configurations.

Hmmm, that's not good. If the idea is to attract Mac development, then 
I, for one, would not be happy having to run an IDE via a Windows VM 
just to end up with an OS X target.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/4/2009 8:42:48 PM
"Joanna Carter" <joanna@no.spam.for.me> wrote in message 
news:124551@forums.codegear.com...
>> You make a corresponding Windows version of the controls, or you just 
>> make a
>> few mac-specific controls, or you just leave it out and let the 3rd party
>> tools developers fill in the holes.  I dont see what the big deal is 
>> here.
>
> Ah, so I spend a fair deal of money on a cross-platform product, and
> then I have to spend even more time/money trying to fill in the gaps
> that missing controls make.

I'm curious what you think "or just make a few mac-specific controls" means. 
Because when I wrote it, I clearly intended to convey the idea that there 
may be VCL controls that have mac-only implementations, and thus cannot be 
used in Windows builds.  And yet somehow you interpreted that to mean "all 
mac controls must have corresponding Windows versions".

>And just how long do you think it's going to
> take to create a Windows equivalent to the sophistication of something
> like NSBrowser?

Now, certainly you wouldnt want to use the Mac-only controls on Windows... 
after all, that wouldnt be a 'pure' Windows interface element.  Right?

So again, I dont see what the big deal is if there's some controls only 
usable in mac builds.   Use them if you need them for a mac project, or dont 
use them if they arent convenient for cross-platform apps.  Or if its a 
religion for you, maintain 2 complete separate GUI's for your app... one for 
the divine OS, and the other for mere mortals.
0
Joe
6/4/2009 8:49:17 PM
> {quote:title=Joanna Carter wrote:}{quote}
> Hmmm, that's not good. If the idea is to attract Mac development, then 
> I, for one, would not be happy having to run an IDE via a Windows VM 
> just to end up with an OS X target.
> 

My understanding is that you write your application in Windows and then can compile to multiple targets, like it happened with Turbo Pascal with Dos, Dos protected mode, etc.

> Joanna

Andrew
0
Andrea
6/4/2009 8:52:51 PM
Joanna Carter escribió:
> Andrea Raimondi a écrit :
> 
>> He said that full pascal components should be able to compile.
>> VCL wise, it'll have to interface with the native MacOs X side.
>> There's nothing really showable as of yet, indeed at Delphi Live they had a mac mini but that's all they showed.
>> IDE should be WINDOWS ONLY(that's been pretty clear to my understanding in the keynote) and different targets are... well... on target :-) using Build Configurations.
> 
> Hmmm, that's not good. If the idea is to attract Mac development, then 
> I, for one, would not be happy having to run an IDE via a Windows VM 
> just to end up with an OS X target.
> 
> Joanna
> 

I agree with Joanna, also imagine using the Delphi form designer in 
windows and try to figure out how it will look in MacOSX. It will be an 
infinite Compile-go-to-Mac-test cycle.

A better approach could be to just create a compiler who can run in each 
environment, then create XCode, KDE, GTK,...bindings. Also an important 
aspect is to encourage developers to start using some MVC or similar 
method if they want multiplatform applications.

Leonardo.
0
Utf
6/4/2009 8:55:31 PM
> If the idea is to attract Mac development[...]

What in the world gave you that idea?  They already tried the "attract 
native developers" deal with Kylix and that went over like a lead 
balloon, and not just because of CLX.  Now that the IDE is intricately 
tied to .NET it makes even less sense to port it.

They're trying to help Delphi developers with existing applications get 
their products onto Mac/Linux.  If someone is already a native Mac 
developer well-versed in Objective C, why would they use Delphi instead, 
whether it's native or not?

Craig Peterson
Scooter Software
0
Craig
6/4/2009 9:26:57 PM
Andrea Raimondi wrote:
>at Delphi Live they had a mac mini but that's all they showed.

There's a video by Jim McKeeth from a "what's cooking the labs" session 
that has a demo of Project X, starts around 6:20

http://www.youtube.com/watch?v=9JcwJVvMa9M
0
harrie
6/5/2009 4:58:14 AM
Joe Demartino wrote:

<snipped>

+1.

....also, to put it in other words:

	- try to minimize the code which is platform specific but accept the 
existence of such a code, including the code/widgets in the Presentation 
Layer. (Btw, how can one port to Mac/Linux TRichEdit?)

	- provide tooling (refactoring, making cross-platform versions of 
*certain* Windows API calls (they need statistical data for this) etc.) 
in order to allow easier code (re)shaping/migration for the existing 
code bases.

	- provide infrastructure (eg. components - perhaps a cross-platform 
library like Qt, builders, designers) for easy-and-quick building new 
interfaces on the desired platform. Here (AFAIS) are two distinct 
directions:
		1.) provide the same look-and-feel on each platform
		2.) provide the platform's specific look-and-feel

		- personally I would opt here for something closer to 2.) given the 
fact that 1.) can be simulated using VM features, _BUT_ this DOESN'T 
mean that we must rewrite/redesign our GUIs.

-- 

m. Th.
0
m
6/5/2009 7:08:30 AM
Leonardo M. Ramé wrote:

> I agree with Joanna, also imagine using the Delphi form designer in 
> windows and try to figure out how it will look in MacOSX. It will be an 
> infinite Compile-go-to-Mac-test cycle.
> 

They invested a lot in Galileo which became a very mature IDE. Isn't 
perfect, but how long it would take to have a similar cross-platform 
IDE? Yeah, I understand you (I'm also developer), but I try also to 
understand them. Having everything 'new' in Project X will give us many 
headaches WRT product's stability. At least for me, having a stable IDE 
is a big relief. Anyway we will fight with the new compiler (rewritten 
from scratch), new/changed VCL (or whatever)/RTL etc.

> A better approach could be to just create a compiler who can run in each 
> environment, then create XCode, KDE, GTK,...bindings. Also an important 
> aspect is to encourage developers to start using some MVC or similar 
> method if they want multiplatform applications.
> 
> Leonardo.

+1! Also, IIRC, at Delphi Live! the 'Hello Mac world!' program was 
compiled on Mac so the compiler is cross-platform. Anyway, being a C/C++ 
command-line thing, it shouldn't be so difficult to achieve. But if 
someone knows better, please drop a line.

-- 

m. Th.
0
m
6/5/2009 7:17:08 AM
Joe Demartino a écrit :

> I'm curious what you think "or just make a few mac-specific controls"
> means. Because when I wrote it, I clearly intended to convey the idea
> that there may be VCL controls that have mac-only implementations,
> and thus cannot be used in Windows builds.  And yet somehow you
> interpreted that to mean "all mac controls must have corresponding
> Windows versions".

The point I am trying to make is that it is very difficult to make a
single "form designer" that can satify the needs of the users of all
platform without looking distinctly "wrong" on one or all platforms.

One can hope that such an IDE would "encourage" the use of the MVC or
MVP design pattern in enforcing a separation of UI handling code from
the actual UI. Then the question of universality of widget libraries
becomes a moot point, as it would be necessary to design the UI
specifically for each platform.

However, this would involve a major re-write of the existing VCL as well
as of the IDE to ensure that code cannot be written in form units; and
this is not going to please all the drop/click coders, with all their
code in the forms, who simply want to recompile their badly designed
apps to every platform in the universe.

> Now, certainly you wouldnt want to use the Mac-only controls on
> Windows... after all, that wouldnt be a 'pure' Windows interface
> element.  Right?

Correct. The problem here is that each platform already has its own
visual metaphors - something that is notoriously difficult to achieve in
a single UI designer.

> ... Or if its a religion for you, maintain 2 complete separate GUI's
> for your app... one for the divine OS, and the other for mere
> mortals.

As I just said, it's not just a case of one UI being superior to another 
(despite my own affectations :-) ), it's more a matter of following the 
expected UI metaphors for the respective platforms. Otherwise, you will 
be getting the same level of universal dissatisfaction that you get from 
users of Java apps.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 7:33:57 AM
Vandad NP wrote:

> > {quote:title=jo ko wrote:}{quote}
> > No one knows at this point it is just a fun project to see how far they 
> > can go.
> 
> A fun project? Wow, so much for professionalism.

Professionalism of what? 
With out fun projects professionalism is just a dirty word.

regards
jo
-- 
"[War] might be avoidable were more emphasis placed on the
 training to social interest, less on the attainment of
 egotistical grandeur." -- Lydia Sicher
0
jo
6/5/2009 7:37:38 AM
Eddie Shipman wrote:

> Like they should have done with Unicode...HAHAHA!!!!

Oh for crying out loud. ANSI is dead get use it already.


-- 
"I am ready to meet my Maker. Whether my Maker is prepared for 
 the great ordeal of meeting me is another matter." 
 -- Winston Churchill.
0
jo
6/5/2009 7:42:04 AM
m. Th. a écrit :

> 	- try to minimize the code which is platform specific but accept the 
> existence of such a code, including the code/widgets in the Presentation 
> Layer. (Btw, how can one port to Mac/Linux TRichEdit?)

Most Cocoa controls are fully aware of fonts, colours, etc. and 
NSTextField is virtually a full word processor in a control.

> Here (AFAIS) are two distinct directions:
> 		1.) provide the same look-and-feel on each platform

This is my biggest worry - look at Java...

> 		2.) provide the platform's specific look-and-feel

Ideal but would mean :

1. extending some multi-platform form of the VCL to allow a single UI 
designer that can implement the differing metaphors.

> 		- personally I would opt here for something closer to 2.) given the 
> fact that 1.) can be simulated using VM features, _BUT_ this DOESN'T 
> mean that we must rewrite/redesign our GUIs.

Yes, if I want to run a Windows or Linux app on a Mac, all I have to do 
is use Parallels or VMWare; why bother going to all the time and trouble 
of re-writing the app at all?

If all I'm going to get out of this "super" Delphi is an app that looks 
like a Windows one, I can save myself thousands of pounds and a lot of time.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 7:45:42 AM
Hello,

Joanna Carter wrote:

> Hmmm, that's not good. If the idea is to attract Mac development,
> then I, for one, would not be happy having to run an IDE via a
> Windows VM just to end up with an OS X target.

I don't think that a resurrection of the Kylix approach is worth the
R&D resources. (And we'll probably agree that the Galileo IDE isn't
exactly likely to be ported as a /true/ Mac/Linux application.)

FWIW, all Mac users I know of are using Windows anyway (Parallels), so
it comes down to a mere question of preference.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
6/5/2009 7:47:19 AM
m. Th. a écrit :

> +1! Also, IIRC, at Delphi Live! the 'Hello Mac world!' program was 
> compiled on Mac so the compiler is cross-platform. Anyway, being a C/C++ 
> command-line thing, it shouldn't be so difficult to achieve. But if 
> someone knows better, please drop a line.

IIRC, the demo was a command line app with no UI at all. A far cry from 
an aesthetically pleasing UI :-)

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 7:47:36 AM
> 
> Hmmm, that's not good. If the idea is to attract Mac development, then 
> I, for one, would not be happy having to run an IDE via a Windows VM 
> just to end up with an OS X target.


I who haven't invested on a mac find it briliant that I do not have to 
invest on a mac to be able to create apps for the mac. I wouldn't want
to give Apple more than I absolutly have to.

As for being able to atract MAC developers. Well they will have to wait
for us to debug the new compiler / framework first.

regards
jo

-- 
"One doesn't have a sense of humor. It has you." -- Larry Gelbart
0
jo
6/5/2009 7:51:47 AM
Moritz Beutel <Moritz Beutel a écrit :

> FWIW, all Mac users I know of are using Windows anyway (Parallels), so
> it comes down to a mere question of preference.

So, are we saying that Project X is only aimed at people who prefer to 
work in Windows, so that they can build Mac apps that might use 
Cocoa-style controls but which may well not please Mac fanatics, but 
which the developer would never use in anger on a Mac?

Surely Mac apps are best designed by developers who appreciate what is 
so different about the Mac way of doing things, not a Windows developer 
who thinks that Windows metaphors work in an OS X world?

Are we also expecting Mac users to have to use a Windows IDE simply 
because they want their Mac app to also run on Windows?

Or is this just a "one way street" for Windows developers?

Is Project X going to completely ignore the "native" Mac development world?

If I want to write Mac apps that only target OS X, in a Mac IDE, but 
with my "favourite" Delphi language, I am going to be left with the 
choice of abandoning Delphi and using ObjectiveC in XCode, or running a 
Windows VM and a UI designer that doesn't truly understand Cocoa controls.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 8:05:01 AM
Hello,

Joanna Carter wrote:

> So, are we saying that Project X is only aimed at people who prefer
> to work in Windows

yes. Target audience seem to be existing Delphi developers.


> so that they can build Mac apps that might use Cocoa-style controls
> but which may well not please Mac fanatics, but which the developer
> would never use in anger on a Mac?

Not quite sure how you draw that conclusion from my posting.


> If I want to write Mac apps that only target OS X, in a Mac IDE, but 
> with my "favourite" Delphi language, I am going to be left with the 
> choice of abandoning Delphi and using ObjectiveC in XCode, or running
> a Windows VM and a UI designer that doesn't truly understand Cocoa
> controls.

Why does "a UI designer that doesn't truly understand Cocoa controls"
follow from "running [Delphi in] a Windows VM"?

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
6/5/2009 8:15:22 AM
Moritz Beutel <Moritz Beutel a écrit :

>> so that they can build Mac apps that might use Cocoa-style controls
>> but which may well not please Mac fanatics, but which the developer
>> would never use in anger on a Mac?
> 
> Not quite sure how you draw that conclusion from my posting.

I was not drawing any conclusions from your post, I am simply discussing 
ramifications which may occur.

> Why does "a UI designer that doesn't truly understand Cocoa controls"
> follow from "running [Delphi in] a Windows VM"?

Because, if I am using a Windows IDE in a VM to create a Cocoa UI, I'm 
not going to get a Cocoa designer, just what a Windows developer thinks 
a Cocoa designer should be.

XCode and Interface Builder can be downloaded for free, so you can see 
just how fully-featured the Cocoa controls are. Or, at least, you could 
if you were running a Mac :-)

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 8:28:41 AM
m. Th. wrote:
>> A better approach could be to just create a compiler who can run in each 
>> environment, then create XCode, KDE, GTK,...bindings. Also an important 
>> aspect is to encourage developers to start using some MVC or similar 
>> method if they want multiplatform applications.
>>
>> Leonardo.
> 
> +1! Also, IIRC, at Delphi Live! the 'Hello Mac world!' program was 
> compiled on Mac so the compiler is cross-platform. Anyway, being a C/C++ 
> command-line thing, it shouldn't be so difficult to achieve. But if 
> someone knows better, please drop a line.
> 

+1000 ;)

Maybe RemObjects (or someone else) could write an integration to Visual 
Studio and MonoDevelop for this new native Delphi cross-platform compiler.

All we really need is the compiler and the RTL, there are already enough 
GUI designers and libraries out there that could be used to create the 
UI for the respective platforms.

Some bindings for the respective libraries would be cool, but that could 
also be done by the developer community.

I'd really like to have a native counterpart to Oxygene. (I know there 
is fpc, but I don't like the compiler very much).

A cross-platform IDE should have low priority, if they do a Galileo 
integration for Windows that would be a good starting point, you could 
debug, design and write the business logic using Windows and do the UI 
specific stuff on the target platforms (using Glade for Gtk on Linux, 
XCode for Cocoa on the Mac, etc.)

I'm also against tying Delphi X to a particular framework (like it was 
done with Qt in Kylix).

-- 
Regards
Jens
0
Utf
6/5/2009 8:48:01 AM
Hello,

Joanna Carter wrote:

> Because, if I am using a Windows IDE in a VM to create a Cocoa UI,
> I'm not going to get a Cocoa designer, just what a Windows developer
> thinks a Cocoa designer should be.

then what do you, as a privileged Mac user, think of the approach taken
by Qt? Do Qt applications qualify as true Mac applications? And if they
do, why would that be different for Delphi applications?

Anyway, I can imagine ways around the problem you're mentioning
(perhaps a "remote form designer"?). But I don't believe the Galileo
IDE is going anywhere other than Windows, and that's good, IMHO.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
6/5/2009 8:50:21 AM
Joanna Carter wrote:
> m. Th. a écrit :
> 
>> 	- try to minimize the code which is platform specific but accept the 
>> existence of such a code, including the code/widgets in the Presentation 
>> Layer. (Btw, how can one port to Mac/Linux TRichEdit?)
> 
> Most Cocoa controls are fully aware of fonts, colours, etc. and 
> NSTextField is virtually a full word processor in a control.
> 

That's fine and a big step forward. Also we acknowledge that sending 
messages directly to the control's handle isn't 'pure Pascal' and we 
should maintain it by ourselves. But the main problem is wh/if my code 
will have:

CrossPlatformRichEdit1.LoadFromFile(...)

CrossPlatformRichEdit1.SaveToFile(...)

Perhaps shall we accept that the file formats will be different across 
platforms and that's it?

-- 

m. Th.
0
m
6/5/2009 9:03:00 AM
I didn't want to invest in a Mac computer but to be honest with you, buying a Mac Mini was worth every single penny I spent. It is a great machine, really powerful and allows me to expand my development knowledge. I think if Delphi wants to allow users to develop applications for the Mac without the requirement of actually owning a Mac, it has to spend a great deal of time making this work perfectly.
0
Vandad
6/5/2009 9:03:55 AM
Joanna Carter wrote:
> m. Th. a écrit :
> 
>> +1! Also, IIRC, at Delphi Live! the 'Hello Mac world!' program was 
>> compiled on Mac so the compiler is cross-platform. Anyway, being a C/C++ 
>> command-line thing, it shouldn't be so difficult to achieve. But if 
>> someone knows better, please drop a line.
> 
> IIRC, the demo was a command line app with no UI at all. A far cry from 
> an aesthetically pleasing UI :-)
> 
> Joanna
> 

Yes, sure. I just wanted to point out that (most probably) we already 
have what he requested (a compiler which works on different platforms). 
We all know that the main battle is VCL, OS integration and, especially, UI.

-- 

m. Th.
0
m
6/5/2009 9:23:16 AM
m. Th. a écrit :

> That's fine and a big step forward. Also we acknowledge that sending 
> messages directly to the control's handle isn't 'pure Pascal' and we 
> should maintain it by ourselves. But the main problem is wh/if my code 
> will have:
> 
> CrossPlatformRichEdit1.LoadFromFile(...)
> 
> CrossPlatformRichEdit1.SaveToFile(...)
> 
> Perhaps shall we accept that the file formats will be different across 
> platforms and that's it?

I guess that we also have to consider the differences in line endings 
between *nix and Windows, but I would have thought that would be a part 
of the adapter classes that would have to be written to support the 
common abstraction of such controls.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 10:05:10 AM
Joanna Carter wrote:
> m. Th. a écrit :
> 
>> That's fine and a big step forward. Also we acknowledge that sending 
>> messages directly to the control's handle isn't 'pure Pascal' and we 
>> should maintain it by ourselves. But the main problem is wh/if my code 
>> will have:
>>
>> CrossPlatformRichEdit1.LoadFromFile(...)
>>
>> CrossPlatformRichEdit1.SaveToFile(...)
>>
>> Perhaps shall we accept that the file formats will be different across 
>> platforms and that's it?
> 
> I guess that we also have to consider the differences in line endings 
> between *nix and Windows, but I would have thought that would be a part 
> of the adapter classes that would have to be written to support the 
> common abstraction of such controls.
> 
> Joanna
> 

Hmmm... I don't know. Yes, at first glance. But wh/if one wants to do 
manual text parsing (for i:=0 to length(foo) do)?

Another interesting point is TWebBrowser. What is situation on Mac?

-- 

m. Th.
0
m
6/5/2009 10:25:53 AM
m. Th. a écrit :

> Hmmm... I don't know. Yes, at first glance. But wh/if one wants to do 
> manual text parsing (for i:=0 to length(foo) do)?

I guess Unicode rules apply.

> Another interesting point is TWebBrowser. What is situation on Mac?

That would be the WebView.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 10:32:54 AM
m. Th. a écrit :

> Yes, sure. I just wanted to point out that (most probably) we already 
> have what he requested (a compiler which works on different platforms). 
> We all know that the main battle is VCL, OS integration and, especially, UI.

Of course, if the engineers at CodeGear as as clever with Project X as 
they have been in the early days of Delphi, then we could get an IDE 
written for the Mono .NET framework, with the UI designed separately for 
each platform and using the MVC design pattern and Delphi Prism to 
connect the Mac designers to the Mono/.NET backend.

:-)

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 12:37:35 PM
Joanna Carter wrote:
> m. Th. a écrit :
>
>> Yes, sure. I just wanted to point out that (most probably) we already
>> have what he requested (a compiler which works on different
>> platforms).
>> We all know that the main battle is VCL, OS integration and,
>> especially, UI.
>
> Of course, if the engineers at CodeGear as as clever with Project X as
> they have been in the early days of Delphi, then we could get an IDE
> written for the Mono .NET framework, with the UI designed separately
> for each platform and using the MVC design pattern and Delphi Prism to
> connect the Mac designers to the Mono/.NET backend.
>
> :-)
>
> Joanna

This is sort of the point I've trying to put  my finger on: Who else 
remembers what a revolution Dephi 1.0 was, when viewed from Turbo Pascal for 
Windows? That's the sort of shift we (would) need to make Delphi X a success 
and I don't know what the shift would consist of ... I'm not part of 
CodeGear's research dept. It might not be Mono at all.

Answering a different post (from Joanna) ... I can't envisage a single layer 
UI designer coping with Win32, Win64, .NET and OSX all in one ... but if the 
IDE recognised the need for the decoupling and encouraged coding in that 
style it could be a very important step.

I also can't imagine sitting at my windows machine, with check boxes for 
Win32, .NET, OSX and Gnome and KDE, expecting the compiler to generate 
native apps. for all of those targets from one platform.

I can imagine harmonising my engine code between my code repository and my 
Mac and Windows workstations (or emulators/virtual machines) and producing 
my Mac version on a Mac.

As I (think I) have said elsewhere, getting the UI right and "in keeping" is 
much more important for Mac users than general for Windows users, or Linux 
users.

-- 
Ed.
0
Ed
6/5/2009 1:22:45 PM
>> Like they should have done with Unicode...HAHAHA!!!!
>
> Oh for crying out loud. ANSI is dead get use it already.
>

Oh, it's not dead in hundreds of millions of lines of legacy Delphi code.
0
Eddie
6/5/2009 1:34:47 PM
harrie pearce wrote:
> Andrea Raimondi wrote:
>> at Delphi Live they had a mac mini but that's all they showed.
> 
> There's a video by Jim McKeeth from a "what's cooking the labs" session 
> that has a demo of Project X, starts around 6:20
> 
> http://www.youtube.com/watch?v=9JcwJVvMa9M

That's very sexy.

--
Warm Regards,

Lee
0
Lee
6/5/2009 6:08:42 PM
"Joanna Carter" <joanna@no.spam.for.me> wrote in message 
news:124679@forums.codegear.com...
> The point I am trying to make is that it is very difficult to make a
> single "form designer" that can satify the needs of the users of all
> platform without looking distinctly "wrong" on one or all platforms.

True, but even more difficult is compiling hundreds of thousands of lines of 
delphi code on a mac without a delphi for mac compiler.

Given the choice between having a mac compiler/ide thats not 'perfect', and 
not having one, I'll take the former.  Developers just need to understand 
that 1) cross platform requires a certain amount of 
lowest-common-denomonator decisions, and 2) its a first version which will 
undoubtably see improvements.  Plus, if you really feel this way, there's 
nothing stopping you from creating your windows/GUI in code rather than with 
the form designer.  You may balk at that, but even having that option is a 
world better than what we have now, which is nothing.

> Correct. The problem here is that each platform already has its own
> visual metaphors - something that is notoriously difficult to achieve in
> a single UI designer.

Difficult, yes.  But I dont see the harm in letting Embarcadero try to pull 
it off.  I'm very impressed with Embarcadero's vision here - they should be 
supported, not jumped on for shortcomings of an system thats not even an 
alpha version yet.
0
Joe
6/5/2009 6:59:00 PM
Joe Demartino a écrit :

> True, but even more difficult is compiling hundreds of thousands of lines of 
> delphi code on a mac without a delphi for mac compiler.

Don't forget that a compiler is usually targetted at a particular 
processor rather than the OS. To the best of my knowledge, you can use a 
DLL compiled for Intel on Windows, OS X and Linux. The main difference 
with a Mac app is that the exe is placed inside an .APP bundle, along 
with its associated resources and private directories.

> 1) cross platform requires a certain amount of 
> lowest-common-denomonator decisions

Or more work on separating the UI from the business code :-)

> 2) its a first version which will undoubtably see improvements.

Of course but, if the first version can't produce UIs that look and feel 
right on a Mac, I personally would stick with Delphi Prism which can 
produce separate UIs and Mac app bundles right now.

> Plus, if you really feel this way, there's 
> nothing stopping you from creating your windows/GUI in code rather than with 
> the form designer.  You may balk at that, but even having that option is a 
> world better than what we have now, which is nothing.

OK, I've obviously been spoiled by not having to use Windows for so long 
now, I have problems adjusting when I have to use VS ;-)

> Difficult, yes.  But I dont see the harm in letting Embarcadero try to pull 
> it off.  I'm very impressed with Embarcadero's vision here - they should be 
> supported, not jumped on for shortcomings of an system thats not even an 
> alpha version yet.

Of course, you are absolutely right, but it doesn't hurt to drop subtle 
hints as to what the great unwashed are expecting :-)

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 8:22:13 PM
Joanna Carter schrieb:
> Andrea Raimondi a écrit :
> 
>> He said that full pascal components should be able to compile.
>> VCL wise, it'll have to interface with the native MacOs X side.
>> There's nothing really showable as of yet, indeed at Delphi Live they had a mac mini but that's all they showed.
>> IDE should be WINDOWS ONLY(that's been pretty clear to my understanding in the keynote) and different targets are... well... on target :-) using Build Configurations.
> 
> Hmmm, that's not good. If the idea is to attract Mac development, then 
> I, for one, would not be happy having to run an IDE via a Windows VM 
> just to end up with an OS X target.
> 

And I'd be not too happy if they had to invest large sums of money and
tuime just to have the IDE on Mac OS as well. If the compiled apps run
well enough there it's ok for me. Porting the IDE might be feasible as
2nd step but not on the first run please! Too costly for the benefit.

Greetings

Markus
0
Markus
6/5/2009 8:25:11 PM
Hello,

why on earth do you always assume that you cannot write correct looking
Mac apps in a Windows hosted IDE? What makes you think this? One can
develop a GUI designer capable enough of doing that. Then compile it and
copy the executable over to your Mac. If running in a VM and using
shared folders you might be able to even save this step as the
executable would be created directly on your Mac. Then with some remote
debugger you can connect to it. If it's done clever enough you could
even start it from IDE. So what's your point?

Otherwise I'd have to switch constantly IDEs when developping in a mixed
project group. Is that any better?

Greetings

Markus
0
Markus
6/5/2009 8:31:53 PM
Markus Humm a écrit :

> why on earth do you always assume that you cannot write correct looking
> Mac apps in a Windows hosted IDE?

Because, unless you can find a way of creating genuine Cocoa controls in 
a Windows IDE, not "lookalike" ones, you will still be left with a UI 
that may not lack visual similarity but that lacks  essential 
architecture. I would hope that, if a Delphi IDE for Mac becomes 
available, that it will be capable of binding controls to properties of 
objects, rather than the outdated "data-aware" model that is current.

> Then with some remote debugger you can connect to it.

Now, this would be clever, and much desired. It is the one let down with 
Prism that you can't debug a Mac app, even though it was developed in 
the VS shell.

> If it's done clever enough you could even start it from IDE.

If you mean the app, wouldn't that require loading OS X? If so, Apple 
might not be too keen on allowing OS X to run on non-Apple hardware, 
even if it is just to support testing an app.

> So what's your point?

See the above points.

> Otherwise I'd have to switch constantly IDEs when developping in a mixed
> project group. Is that any better?

Mac developers are used to using two programs at the same time. XCode is 
responsible for managing the project, whilst Interface Builder is 
responsible for designing the UIs. Not much different from developing in 
Prism where you use VS for the project and Interface Builder for the UI.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 9:31:26 PM
Joanna Carter wrote:

> Joe Demartino a écrit :
> 
> > True, but even more difficult is compiling hundreds of thousands of
> > lines of delphi code on a mac without a delphi for mac compiler.
> 
> Don't forget that a compiler is usually targetted at a particular 
> processor rather than the OS. To the best of my knowledge, you can
> use a DLL compiled for Intel on Windows, OS X and Linux.

It would actually surprise me. Linux has a different format, and I
assume that OS X might have another format too.


-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Multitasking /adj./ 3 PCs and a chair with wheels !" -- unknown
0
Rudy
6/5/2009 9:34:43 PM
In article <124932@forums.codegear.com>,
 Rudy Velthuis (TeamB) <newsgroups@rvelthuis.de> wrote:

> > Don't forget that a compiler is usually targetted at a particular 
> > processor rather than the OS. To the best of my knowledge, you can
> > use a DLL compiled for Intel on Windows, OS X and Linux.
> 
> It would actually surprise me. Linux has a different format, and I
> assume that OS X might have another format too.

   ELF and Mach-O. There are other reasons it's not that simple either, 
such as what is mentioned in Eli's blog: 
http://blogs.embarcadero.com/eboling/
-- 
David Dean (Embarcadero)
Lead C++ QA Engineer
0
David
6/5/2009 9:56:18 PM
Rudy Velthuis (TeamB) a écrit :

> It would actually surprise me. Linux has a different format, and I
> assume that OS X might have another format too.

Well, I do know that you install the same Mono assemblies on both 
Windows and OS X. But I am open to correction as I haven't delved too 
deep into this aspect.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/5/2009 10:14:35 PM
Joanna Carter wrote:

> Rudy Velthuis (TeamB) a écrit :
> 
> > It would actually surprise me. Linux has a different format, and I
> > assume that OS X might have another format too.
> 
> Well, I do know that you install the same Mono assemblies on both 
> Windows and OS X. But I am open to correction as I haven't delved too 
> deep into this aspect.

Mono assemblies are probably different. 

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Knowledge speaks, but wisdom listens."
 -- Jimi Hendrix
0
Rudy
6/5/2009 11:40:38 PM
Why not build a proper IDE/Compiler/Language/Framework that targets Mac OS 
only and does away with all the cross-platform considerations?
One would think that with the growing popularity of Macs there is a business 
case for that!
0
Martin
6/6/2009 5:13:28 AM
Joanna Carter wrote:
> m. Th. a écrit :
> 
>> Hmmm... I don't know. Yes, at first glance. But wh/if one wants to do 
>> manual text parsing (for i:=0 to length(foo) do)?
> 
> I guess Unicode rules apply.
> 

Yes, of course, but I meant about different OS/internal conventions eg. 
CRLF vs LFCR. We will have perhaps some consts to abstract these things. 
Eg.:

const
	{$IFDEF WIN}
	NewLine = CRLF;
	{$ENDIF}

	{$IFDEF OSX}
	NewLine = LFCR;
	//etc.

for i:=0 to length(foo) do
	if //check for NewLine...

>> Another interesting point is TWebBrowser. What is situation on Mac?
> 
> That would be the WebView.
> 

Ok, thanks. On Linux?

....And I presume that WebView it has a different API. What engine is 
underneath? WebKit or Gecko? It would be an interesting option to have a 
cross-platform HTML engine. Unfortunately, it seems that these engines 
carry a bunch of files with them...

> Joanna
> 


-- 

m. Th.
0
m
6/6/2009 9:36:14 AM
Jens Mühlenhoff wrote:
> m. Th. wrote:
>>> A better approach could be to just create a compiler who can run in each 
>>> environment, then create XCode, KDE, GTK,...bindings. Also an important 
>>> aspect is to encourage developers to start using some MVC or similar 
>>> method if they want multiplatform applications.
>>>
>>> Leonardo.
>> +1! Also, IIRC, at Delphi Live! the 'Hello Mac world!' program was 
>> compiled on Mac so the compiler is cross-platform. Anyway, being a C/C++ 
>> command-line thing, it shouldn't be so difficult to achieve. But if 
>> someone knows better, please drop a line.
>>
> 

> All we really need is the compiler and the RTL, there are already enough 
> GUI designers and libraries out there that could be used to create the 
> UI for the respective platforms.
> 
> Some bindings for the respective libraries would be cool, but that could 
> also be done by the developer community.
> 
> I'd really like to have a native counterpart to Oxygene. (I know there 
> is fpc, but I don't like the compiler very much).
> 

Hmmm... I certainly understand you, but I think that there's a trap inside.


Anyway, what 'Delphi' means?

A language spec? An IDE? A box? Imho, is 'everything'. More like a 
concept. A turn-key environment which would allow Rapid Application 
Development ( n.n. unfortunately. I would change 'Development' with 
'Delivery') using human-oriented tooling (eg. Form Designers, Integrated 
Debugger with advanced Data Display etc.).

That's why imho they should continue to provide tooling (including a 
Standard Component Library) to do this. I don't say that all this 
tooling should be CodeGear brand (they already do this - see eg. Boost) 
but they should provide this because this becomes 'infrastructure' for 
the others - you can take it for granted and build upon it.

> A cross-platform IDE should have low priority, if they do a Galileo 
> integration for Windows that would be a good starting point, you could 
> debug, design and write the business logic using Windows and do the UI 
> specific stuff on the target platforms (using Glade for Gtk on Linux, 
> XCode for Cocoa on the Mac, etc.)
> 

Just to make them 'official' by integrating them in 'Delphi' 
environment. By 'environment', I don't mean necessarily Galileo, but 
rather a commitment like 'We support this path, here are the tools, 
build upon.' - but of course the 'path' must be in accord with our needs 
because otherwise... :-)

> I'm also against tying Delphi X to a particular framework (like it was 
> done with Qt in Kylix).
> 

Not quite. If you would write "I'm also against tying Delphi X to a 
particular framework *ONLY*" - then we agree. :-) FTR, I do think that 
this is what you meant, but I wanted to stress it more because I don't 
want to see a plain-vanilla "least common denominator solution".


-- 

m. Th.
0
m
6/6/2009 9:59:35 AM
Ed Weatherup wrote:
> Joanna Carter wrote:
>> m. Th. a écrit :
>>
>>> Yes, sure. I just wanted to point out that (most probably) we already
>>> have what he requested (a compiler which works on different
>>> platforms).
>>> We all know that the main battle is VCL, OS integration and,
>>> especially, UI.
>> Of course, if the engineers at CodeGear as as clever with Project X as
>> they have been in the early days of Delphi, then we could get an IDE
>> written for the Mono .NET framework, with the UI designed separately
>> for each platform and using the MVC design pattern and Delphi Prism to
>> connect the Mac designers to the Mono/.NET backend.
>>
>> :-)
>>
>> Joanna
> 
> This is sort of the point I've trying to put  my finger on: Who else 
> remembers what a revolution Dephi 1.0 was, when viewed from Turbo Pascal for 
> Windows? That's the sort of shift we (would) need to make Delphi X a success 
> and I don't know what the shift would consist of ... I'm not part of 
> CodeGear's research dept. It might not be Mono at all.
> 

Yes, sure. But for this they must communicate much more with us. D1 was 
born from a stringent need and it was a success.

Delphi X will be also a success if it will _really_ cover a stringent 
need. And the 'cross-platform' *alone* isn't a stringent need. The 
cross-platform in the _way_we_want_it_ is a stringent need. (See 
Joanna's opinions about cross-platform in Java-way)

> Answering a different post (from Joanna) ... I can't envisage a single layer 
> UI designer coping with Win32, Win64, .NET and OSX all in one ... but if the 
> IDE recognised the need for the decoupling and encouraged coding in that 
> style it could be a very important step.
> 

Oh yes. But MVC is a problem for our community imho. because is 'harder' 
  compared with the classical way of embedding the BO in eg. .OnClick 
handlers of a form (ok, OnClick of each component).

AFAIS, this should be one of the important things which should go in 
Weaver (but I don't think that there is time anymore). A smooth 
migration to MVC-like style of programming.

> I also can't imagine sitting at my windows machine, with check boxes for 
> Win32, .NET, OSX and Gnome and KDE, expecting the compiler to generate 
> native apps. for all of those targets from one platform.
> 

Why not? The problem isn't the compiler, is mostly the Designer(s) and 
the library(es). Provided that TCheckBox encapsulates correctly the 
corresponding widgets (which is something very easy if we program 
against a cross-platform lib) and your code doesn't have 
platform-specific parts or your platform-specific parts are correctly 
{$IFDEF}ed then why not?

> I can imagine harmonising my engine code between my code repository and my 
> Mac and Windows workstations (or emulators/virtual machines) and producing 
> my Mac version on a Mac.
> 

Also this is possible. Since the have a cross-platform compiler (I mean 
here an executable who _runs_ on multiple platforms not one who generate 
code for multiple platforms) this should be pretty easy to accomplish.

> As I (think I) have said elsewhere, getting the UI right and "in keeping" is 
> much more important for Mac users than general for Windows users, or Linux 
> users.
> 

Yes, it seems so. :-)


-- 

m. Th.
0
m
6/6/2009 10:17:27 AM
Joanna Carter wrote:
> m. Th. a écrit :
> 
>> Yes, sure. I just wanted to point out that (most probably) we already 
>> have what he requested (a compiler which works on different platforms). 
>> We all know that the main battle is VCL, OS integration and, especially, UI.
> 
> Of course, if the engineers at CodeGear as as clever with Project X as 
> they have been in the early days of Delphi, then we could get an IDE 
> written for the Mono .NET framework, with the UI designed separately for 
> each platform and using the MVC design pattern and Delphi Prism to 
> connect the Mac designers to the Mono/.NET backend.
> 
> :-)
> 
> Joanna
> 

Nice idea. But I think that they will focus first on 'bare things' fist: 
compiler, RTL, libs - things like this - and to try to use Galileo as 
much as possible.

-- 

m. Th.
0
m
6/6/2009 10:20:56 AM
Martin Kammann wrote:
> Why not build a proper IDE/Compiler/Language/Framework that targets Mac OS 
> only and does away with all the cross-platform considerations?
> One would think that with the growing popularity of Macs there is a business 
> case for that!

Because the Linux is *WAY WAY WAY* bigger market on the server side:

http://news.netcraft.com/archives/2009/05/27/may_2009_web_server_survey.html

-- 

m. Th.
0
m
6/6/2009 10:30:06 AM
"Martin Kammann" schrieb:
> Why not build a proper IDE/Compiler/Language/Framework that targets Mac OS
> only and does away with all the cross-platform considerations?
> One would think that with the growing popularity of Macs there is a 
> business
> case for that!

I think that Apple has created a real masterpiece with their iPhone and 
iPhone OS. Making an IDE for this platform would probably make even more 
sense than for Mac OSX (which has definitely lost the fight with Windows on 
for Desktop PCs).

Especially Apple's Appstore and the ease of use for from iPhone and iPod 
Touch. If Microsoft would try to pull the same stunt for Windows and 
implement an online store directly into their next Windows version, with 
advertising and product categorization and easy search options - combined 
with reduced product pricing, it would be a win-win situation for everyone. 
Product publishers would have the best platform for advertising their 
products, Microsoft would collect some revenue from all sales and customers 
would have a great and reliable source for purchasing software.

There are now a few companies trying to do something similar (like "Steam" 
from Valve or "Impulse" from Stardock), and I'm sure they are making good 
money only by offering advertising and simplified order processing for 
customers, but something built directly into the OS - like it's the case in 
iPhone - would make a world of a difference. I'm just not sure if there 
isn't some stupid anti-trust law making this impossible for Microsoft.

Cheers,
Danijel
0
Danijel
6/6/2009 10:52:03 AM
m. Th. a écrit :

> Nice idea. But I think that they will focus first on 'bare things' fist: 
> compiler, RTL, libs - things like this - and to try to use Galileo as 
> much as possible.

FMPOV, the compiler really isn't going to be that different, as long as 
all platforms run on Intel CPUs, especially since part of CodeGear's 
roadmap is to split the compiler into separate front/back ends.

As for RTL, you would have to be talking a complete encapsulation of 
each platform's libraries.

I would reiterate that being compelled to use a Windows IDE, simply 
because I want to generate OS X only applications but using the Delphi 
language is not all that attractive to me. To my mind, this would mean 
having to run a Windows VM to do the development work, even though it 
would not be possible to run the app from within the IDE.

Finally, having to debug an app running on another platform from within 
the development platform doesn't seem to be a simple task, otherwise I 
would have expected Prism to already do it for a Mac app.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/6/2009 11:01:23 AM
m. Th. a écrit :

> Oh yes. But MVC is a problem for our community imho. because is 'harder' 
>   compared with the classical way of embedding the BO in eg. .OnClick 
> handlers of a form (ok, OnClick of each component).

Actually, the MVP frameworks that I have been working on, and which are 
due to be published soon, are actually easier to use, simply because teh 
only code in the form designer classes is that which creates the 
components and lays them out. All custom handling of button/menu events 
is simple matter of adding a simple custom Command class to the Model; 
all standard button/menu items are handled by already written standard 
Commands. Common commands include Save, Close, Cancel, Add, Remove, 
Edit, View.

> AFAIS, this should be one of the important things which should go in 
> Weaver (but I don't think that there is time anymore). A smooth 
> migration to MVC-like style of programming.

Well, it's certainly taken them long enough and they still haven't even 
separated out data awareness from the (horrible) TDataset paradigm :-( 
This is something that has to be addressed before we even get a hint of 
being able to use MVC/MVP; my frameworks are still exclusively .NET but, 
because Cocoa provides property bindings, it is also possible to connect 
a Cocoa control directly to a property of a Prism MVP business object.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/6/2009 11:20:29 AM
m. Th. a écrit :

>> That would be the WebView.
> 
> Ok, thanks. On Linux?

Sorry, I don't use Linux at all, so I don't know.

> ...And I presume that WebView it has a different API. What engine is 
> underneath? WebKit or Gecko? It would be an interesting option to have a 
> cross-platform HTML engine. Unfortunately, it seems that these engines 
> carry a bunch of files with them...

AFAICS, Apple is tied in to WebKit.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/6/2009 11:22:31 AM
> {quote:title=Joanna Carter wrote:}{quote}

> I wold hope that what we are anticipating would be an IDE that allows 
> you to use the Delphi language to design Mac applications, not some 
> cross-platform monstrosity like you get with Java; which, although it 
> might run on most platforms, doesn't look right on any of them.

You can always hope. However I don't see any sense in there, business model wise.
0
Marco
6/6/2009 12:31:31 PM
> sense than for Mac OSX (which has definitely lost the fight with Windows on 
> for Desktop PCs).

?????????????!!!!

> iPhone - would make a world of a difference. I'm just not sure if there
> isn't some stupid anti-trust law making this impossible for Microsoft.

fair and competative trading is good for the whole industry including M$
0
David
6/6/2009 12:32:39 PM
> Answering a different post (from Joanna) ... I can't envisage a single layer 
> UI designer coping with Win32, Win64, .NET and OSX all in one ... but if the 
> IDE recognised the need for the decoupling and encouraged coding in that 
> style it could be a very important step.
 
> I also can't imagine sitting at my windows machine, with check boxes for 
> Win32, .NET, OSX and Gnome and KDE, expecting the compiler to generate 
> native apps. for all of those targets from one platform.

Not in one go. You hope the generic cross-UI framework does the heavy lifting, and 
you do a bit of polishing and OS dependant code here and there.

If I have to create 4 different apps, what am I doing it for? Its the frameworks I 
majorly want to avoid, they are more costly to learn than a language.
 
> As I (think I) have said elsewhere, getting the UI right and "in keeping" is 
> much more important for Mac users than general for Windows users, or Linux 
> users.

True. But it also provides a horrible hump to make development for  Mac 
worthwhile if it is not your primary target. And if it is your primary target, what 
are you doing in this group? :-)
0
Marco
6/6/2009 12:36:23 PM
"David Champion" schrieb:
>> sense than for Mac OSX (which has definitely lost the fight with Windows 
>> on
>> for Desktop PCs).
>
> ?????????????!!!!
>
>> iPhone - would make a world of a difference. I'm just not sure if there
>> isn't some stupid anti-trust law making this impossible for Microsoft.
>
> fair and competative trading is good for the whole industry including M$

I do not see why an online shopping center offering products from all 
vendors would hinder competition. That's nothing different from having a 
single publisher offering products from a variety od authors and collecting 
a share from revenue for promotion, marketing and sales processing. With the 
only difference that M$ share could be kept very low. If you look at product 
prices in the Appstore, you will see that most apps are being offered fo $1 
USD - but are still being actively maintained with frequent free updates, 
which means that there is a big enough market to justify that price.

Cheers,
Danijel
0
Danijel
6/6/2009 1:12:06 PM
Joanna Carter wrote:
> Don't forget that a compiler is usually targetted at a particular 
> processor rather than the OS. To the best of my knowledge, you can use a 
> DLL compiled for Intel on Windows, OS X and Linux. The main difference 
> with a Mac app is that the exe is placed inside an .APP bundle, along 
> with its associated resources and private directories.
> 
I am guessing that this is true in that the IA32/IA64 machine code are 
mostly the same when it comes to implementing the core language 
features. That said, things such as the structure of executables, 
dynamic libraries, calling conventions and exception handling tend to be 
very OS specific. In the case of DLLs, the structure and loading process 
is firmly entrenched in Windows. In fact, according to what I have read 
in several places, the module loader is arguably one of the most complex 
parts of Windows. Here is a good starting point for anyone that *really* 
wants to know the gory details ;)

http://blogs.msdn.com/junfeng/archive/2006/11/20/debugging-loadlibrary-failures.aspx

For those that remember the debut of Kylix, there were also some 
interesting articles that described the differences between Linux and 
Win32 and how they affected Kylix code generation. IIRC there was 
something about register usage and relocatability of dynamic libraries 
on Linux which impacted Kylix.

It is pure speculation on my part, but I bet the current cross-platform 
effort borrows some tricks from Kylix at the code generation level. IMHO 
there was really very little wrong with the compiler itself. I am 
hopeful that they will do a much better job this go around since OS X is 
a very real market today and they seem to have the wind at their back ;)

David
0
david
6/7/2009 12:31:33 AM
Rudy Velthuis (TeamB) wrote:
> Joanna Carter wrote:
> 
>> Rudy Velthuis (TeamB) a écrit :
>>
>>> It would actually surprise me. Linux has a different format, and I
>>> assume that OS X might have another format too.
>> Well, I do know that you install the same Mono assemblies on both 
>> Windows and OS X. But I am open to correction as I haven't delved too 
>> deep into this aspect.
> 
> Mono assemblies are probably different. 
> 

Considering that it uses DLLs just as a mans to store some resources 
(which make up the CIL and metadata) I would say it doesn't matter. It 
would be completely another story if the mono runtime actually had to 
load the DLLs as code modules.

AFAIK the assemblies are the same since the P/Invoke linking is done at 
runtime and the code can check the platform then.

-- 
Ciobanu Alexandru

Lead Technical Writer
Embarcadero Technologies
0
Alexandru
6/7/2009 8:46:45 AM
david taylor wrote:

> For those that remember the debut of Kylix, there were also some 
> interesting articles that described the differences between Linux and 
> Win32 and how they affected Kylix code generation. IIRC there was 
> something about register usage and relocatability of dynamic
> libraries on Linux which impacted Kylix.

IIRC, Linux requires position independent code (PIC) in the libraries.
Windows doesn't need this, because it fixes all addresses during the
loading of the DLL, using data in the header of the DLL.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A single death is a tragedy, a million deaths is a statistic."
 -- Joseph Stalin.
0
Rudy
6/7/2009 8:49:29 AM
Alexandru Ciobanu wrote:

> > Mono assemblies are probably different. 
> 
> Considering that it uses DLLs just as a mans to store some resources 
> (which make up the CIL and metadata) I would say it doesn't matter.
> It would be completely another story if the mono runtime actually had
> to load the DLLs as code modules.
> 
> AFAIK the assemblies are the same since the P/Invoke linking is done
> at runtime and the code can check the platform then.

Indeed. AFAIUI, .NET/Mono assemblies my contain the ending DLL, but
they can only be used by .NET/Mono code. They are not like normal DLLs,
except that they probably contain a small stub for certain platforms,
just like (most?) Windows .exes still contain DOS code to display a
message they can only be run on Windows.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"... one of the main causes of the fall of the Roman Empire was 
 that, lacking zero, they had no way to indicate successful 
 termination of their C programs." -- Robert Firth
0
Rudy
6/7/2009 8:55:49 AM
Joanna Carter schrieb:
> Markus Humm a écrit :
> 
>> why on earth do you always assume that you cannot write correct looking
>> Mac apps in a Windows hosted IDE?
> 
> Because, unless you can find a way of creating genuine Cocoa controls in 
> a Windows IDE, not "lookalike" ones, you will still be left with a UI 
> that may not lack visual similarity but that lacks  essential 
> architecture. I would hope that, if a Delphi IDE for Mac becomes 
> available, that it will be capable of binding controls to properties of 
> objects, rather than the outdated "data-aware" model that is current.
> 
>> Then with some remote debugger you can connect to it.
> 
> Now, this would be clever, and much desired. It is the one let down with 
> Prism that you can't debug a Mac app, even though it was developed in 
> the VS shell.
> 
>> If it's done clever enough you could even start it from IDE.
> 
> If you mean the app, wouldn't that require loading OS X? If so, Apple 
> might not be too keen on allowing OS X to run on non-Apple hardware, 
> even if it is just to support testing an app.
> 

No. I meant: run the IDE inside the VM and outside the VM runs this
remote devbugger. Both can communicate via TCP. The app's source and
executable is placed on a shared folder so it's already accessible for
Mac OS which is the host to the VM. Then in the IDE pressing F9 just
sends a command to the remote debugger to start this app which is
already there. Neat wouldn't it be?

Greetings

Markus
0
Markus
6/7/2009 9:13:23 AM
Markus Humm a écrit :

> No. I meant: run the IDE inside the VM and outside the VM runs this
> remote devbugger. Both can communicate via TCP. The app's source and
> executable is placed on a shared folder so it's already accessible for
> Mac OS which is the host to the VM. Then in the IDE pressing F9 just
> sends a command to the remote debugger to start this app which is
> already there. Neat wouldn't it be?

Sounds OK to me.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
6/7/2009 11:18:52 AM
Rudy Velthuis (TeamB) wrote:
> 
> IIRC, Linux requires position independent code (PIC) in the libraries.
> Windows doesn't need this, because it fixes all addresses during the
> loading of the DLL, using data in the header of the DLL.

Yes, that is what I was trying to recall. It has been a few years...

David
0
david
6/7/2009 7:46:46 PM
m. Th. wrote:
> That's why imho they should continue to provide tooling (including a 
> Standard Component Library) to do this. I don't say that all this 
> tooling should be CodeGear brand (they already do this - see eg. Boost) 
> but they should provide this because this becomes 'infrastructure' for 
> the others - you can take it for granted and build upon it.

For the non-visual part, I agree. There should be a standard library to 
deal with string handling, RPC, database access, date and time handling, 
file system handling, etc.

A standard component library for cross-platform is difficult and I'd 
rather see support for the already existing bindings out of the box then 
another new immature library.

OTOH if they manage to write a good class library that is written after 
the MVC model I'm all for it, but I don't think it's realistic to write 
such a library in a short period of time.

In all cases the new library or bindings should not be made VCL 
compatible, the VCL was designed 15 years ago with a very different 
focus (to provide a high level and OO abstraction of the "glorious" 
Windows API).

> 
>> A cross-platform IDE should have low priority, if they do a Galileo 
>> integration for Windows that would be a good starting point, you could 
>> debug, design and write the business logic using Windows and do the UI 
>> specific stuff on the target platforms (using Glade for Gtk on Linux, 
>> XCode for Cocoa on the Mac, etc.)
>>
> 
> Just to make them 'official' by integrating them in 'Delphi' 
> environment. By 'environment', I don't mean necessarily Galileo, but 
> rather a commitment like 'We support this path, here are the tools, 
> build upon.' - but of course the 'path' must be in accord with our needs 
> because otherwise... :-)

I don't have to mention Kylix, C++ Builder X, C# Builder and Delphi.NET 
here, have I?

I'd rather stay as much IDE and framework independent as possible. They 
should just provide the compiler and a minimal framework that is 
well-designed and well-tested.

> 
>> I'm also against tying Delphi X to a particular framework (like it was 
>> done with Qt in Kylix).
>>
> 
> Not quite. If you would write "I'm also against tying Delphi X to a 
> particular framework *ONLY*" - then we agree. :-) 

Agreed.

-- 
Regards
Jens
0
Utf
6/8/2009 12:36:09 PM
m. Th. wrote:
>>> Another interesting point is TWebBrowser. What is situation on Mac?
>> That would be the WebView.
>>
> 
> Ok, thanks. On Linux?
> 

There are web browser components for both Gtk and Qt (e.g. GTKMozEmbed, 
QtWeb, ...).

Both Webkit and Gekko are available of course ;).


-- 
Regards
Jens
0
Utf
6/8/2009 12:50:28 PM
Joanna Carter schrieb:
[snip]
> 
> I would reiterate that being compelled to use a Windows IDE, simply 
> because I want to generate OS X only applications but using the Delphi 
> language is not all that attractive to me. To my mind, this would mean 
> having to run a Windows VM to do the development work, even though it 
> would not be possible to run the app from within the IDE.
> 

Seems you haven't yet read my idea outlined below. If it gets
implemented you can run the app from the IDE. Requiring a native Mac IDE
 would be a waste of time imho as the Windows one is good enough for
most parts. There are many more necessary things first before even
thinking about a Mac IDE makes sense! Better think about these other things.

Greetings

Markus
0
Markus
6/8/2009 6:59:34 PM
Hello,

the problem here is that MS as shop owner would make money or at least
hinder other shop owners of other shops like this as users often use the
preinstalled stuff rather than looking for better alternatives.

Greetings

Markus
0
Markus
6/8/2009 7:03:49 PM
<SNIP>

> As I just said, it's not just a case of one UI being superior to another
> (despite my own affectations :-) ), it's more a matter of following the
> expected UI metaphors for the respective platforms. Otherwise, you will
> be getting the same level of universal dissatisfaction that you get from
> users of Java apps.
>

Yes, see what Google said about Chrome:
Still, Google is being careful not to rush its development of Chrome for
machines running Mac OS X. "It's important to us that the Mac port
feels and performs like a native Mac application, and that it provides the
kind of high-quality experience Mac users expect."
0
Eddie
6/8/2009 8:47:09 PM
Jens Mühlenhoff wrote:
> m. Th. wrote:
>>>> Another interesting point is TWebBrowser. What is situation on Mac?
>>> That would be the WebView.
>>>
>> Ok, thanks. On Linux?
>>
> 
> There are web browser components for both Gtk and Qt (e.g. GTKMozEmbed, 
> QtWeb, ...).
> 
> Both Webkit and Gekko are available of course ;).
> 
> 

In fact, I'm looking at a cross-platform way to represent formatted 
text. As expected, we have solutions here.


....but I'm wonder now if we'll have an editor component for this 'rich' 
format? (read: HTML). On Windows, it will be _very_ interesting if we'll 
have the embedded HTML editor from Galileo. Also, AFAIS now it seems 
that it can be ported on other platforms... but, as always, possible 
dark and deep dependencies of Windoze components will stop my dreams... 
:-) ...another solution would be (*if* it's possible) to have the HTML 
editor from Thunderbird (of any open-source eMail client). I had a look 
many many moons ago and it seems that it's structure is pretty modular 
but isn't, of course, a Delphian way to do things ("no BDE, no .dll, no 
..ocx").

-- 

m. Th.
0
m
6/9/2009 6:29:02 AM
Joanna Carter wrote:

+1 at Markus's comments.

> 
> FMPOV, the compiler really isn't going to be that different, as long as 
> all platforms run on Intel CPUs, especially since part of CodeGear's 
> roadmap is to split the compiler into separate front/back ends.
>

It will be _very_ different, compared with the one which we have now. It 
is/will be rewritten almost from scratch, even if on the surface will 
support the same language spec (in the 1st phase, of course). Hence, 
they will have plenty of work to do here.

> As for RTL, you would have to be talking a complete encapsulation of 
> each platform's libraries.
> 

Yes, sure. The thing which is important in your statement is 'complete'. 
What means 'complete' and how much work is needed to transform 
'complete' in 'concrete'?

-- 

m. Th.
0
m
6/9/2009 6:36:36 AM
Eddie Shipman wrote:

> > > Like they should have done with Unicode...HAHAHA!!!!
> > 
> > Oh for crying out loud. ANSI is dead get use it already.
> > 
> 
> Oh, it's not dead in hundreds of millions of lines of legacy Delphi code.

then use a legacy delphi version for them.

-- 
"Every journalist has a novel in him, which is an excellent
 place for it."
0
jo
6/9/2009 6:47:50 AM
Markus Humm wrote:

> Hello,
> 
> the problem here is that MS as shop owner would make money or at least
> hinder other shop owners of other shops like this as users often use the
> preinstalled stuff rather than looking for better alternatives.

So instead of educating the users you propose what exactly?


-- 
"Peace is constructed, not fought for." -- Brent Davis
0
jo
6/9/2009 7:05:35 AM
Jens Mühlenhoff wrote:
> m. Th. wrote:
>> That's why imho they should continue to provide tooling (including a 
>> Standard Component Library) to do this. I don't say that all this 
>> tooling should be CodeGear brand (they already do this - see eg. Boost) 
>> but they should provide this because this becomes 'infrastructure' for 
>> the others - you can take it for granted and build upon it.
> 
> For the non-visual part, I agree. There should be a standard library to 
> deal with string handling, RPC, database access, date and time handling, 
> file system handling, etc.
> 

+1

> A standard component library for cross-platform is difficult and I'd 
> rather see support for the already existing bindings out of the box then 
> another new immature library.
> 

You mean here the VISUAL part, isn't? If yes, I agree. I don't see any 
benefit from building a yet another Qt/GTK/Whatever competitor. The 
library must be _very_ good in order to make sense. And here 'good' 
means everything 'good design', 'good quality' etc. Not going to happen 
imho.

> OTOH if they manage to write a good class library that is written after 
> the MVC model I'm all for it, but I don't think it's realistic to write 
> such a library in a short period of time.
> 

....OTOH the can be agile. Eg. if they'll include in the IDE a 
refactoring/application which will collect statistical data about what 
are the most used classes nowadays in our existing code bases they can 
be much more flexible: "Oh, TStringList is used heavily, we must provide 
for this the fastest and the most compatible implementation. Also, is 
fairly easy to do it, so we must do it by ourselves, even if in the 
outside libs there is (perhaps) a TStringList equivalent. Oh, the class 
<TFoo> is used very rarely so we can solve the problem through a 
binding." And in time, based on customer pressure they can write more 
classes (replacing existing bindings where applicable) in the places in 
which makes sense.

> In all cases the new library or bindings should not be made VCL 
> compatible, the VCL was designed 15 years ago with a very different 
> focus (to provide a high level and OO abstraction of the "glorious" 
> Windows API).
> 

Woah! Son! :-) This is _very_ delicate imho. Do you ask is I agree? Sure 
I agree. Theoretically. But what we'll do with the existing code bases? 
Mind you, there are plenty of users which doesn't even care to monitor 
these ng and/or blogs and which rely heavily on big component libraries 
whose their vendors is possible to be out of (Delphi) business.

Delphi has some magic words: "Code compatibility", "Smooth as possible 
transition" etc. How we'll cope with these? How they will cope with these?

> - but of course the 'path' must be in accord with our needs 
>> because otherwise... :-)
> 
> I don't have to mention Kylix, C++ Builder X, C# Builder and Delphi.NET 
> here, have I?
>

Yes, these are examples about "We know better what's better for you. We 
don't need to tell us what to do"...


> I'd rather stay as much IDE and framework independent as possible. They 
> should just provide the compiler and a minimal framework that is 
> well-designed and well-tested.
> 

Sure, as principle sounds good.
But what means 'as much as possible'? ...and 'minimal'?

We must not forget what made Delphi successful, because otherwise we'll 
fail. See

http://www.businessweek.com/print/magazine/content/09_21/b4132026786379.htm

Delphi succeeded (imho) because it provided OOTB all the tooling needed 
to write an application _fast_ (remember the RAD wave?). This doesn't 
mean that they bundled an extensive framework but means that the VCL 
architect from those days (ChuckJ) knew very well what it was needed as 
infrastructure to build an application at 199x standards. He kept the 
VCL minimalist, but _sufficient_ because the team had permanent contact 
with the community (Charlie Calvert, Danny Thorpe etc.) and in this way 
they succeeded.

Mind you, many companies today which (still) are Delphi shops have as 
policy to use only the 'official' components provided 'in-the-box'. 
Imho, is one of the pillars which made Delphi distinct and one of the 
main success factors for Java/C# (ie. that they have their 'own' 
framework behind).

-- 

m. Th.
0
m
6/9/2009 7:29:02 AM
> Yes, see what Google said about Chrome:
> Still, Google is being careful not to rush its development of Chrome for
> machines running Mac OS X. "It's important to us that the Mac port
> feels and performs like a native Mac application, and that it provides the
> kind of high-quality experience Mac users expect."
Just like Chrome feels native on Windows...
0
Utf
6/9/2009 5:01:52 PM
jo ko schrieb:
> Markus Humm wrote:
> 
>> Hello,
>>
>> the problem here is that MS as shop owner would make money or at least
>> hinder other shop owners of other shops like this as users often use the
>> preinstalled stuff rather than looking for better alternatives.
> 
> So instead of educating the users you propose what exactly?
> 
> 

I always propose educating the users but:

a) nobody wants to do this (at least none of those vendors responsible)

b) there are way too many users which lack ... (you know what I mean)
   ;-)

Greetings

Markus
0
Markus
6/9/2009 6:00:36 PM
"Maël Hörz" <none@invalid.invalid> wrote in message 
news:125716@forums.codegear.com...
>> Still, Google is being careful not to rush its development of Chrome for
>> machines running Mac OS X. "It's important to us that the Mac port
>> feels and performs like a native Mac application, and that it provides 
>> the
>> kind of high-quality experience Mac users expect."
> Just like Chrome feels native on Windows...

Now, now... we've been over this... when Google or Apple dont follow 
standards or they otherwise commit user-interface atrocities... thats called 
"innovation". :-)
0
Joe
6/9/2009 6:13:22 PM
Reply:

Similar Artilces:

Need help to allow a working Delphi 3 project to build on Delphi XE
How do I adjust this working Delphi 3 program that uses OLEAUTO and OLE2 to work on the newer Delphi XE, Program code is below this, errors are here : Checking project dependencies... Compiling admn_api.dproj (Debug, Win32) dcc command line for "admn_api.dpr" c:\program files (x86)\embarcadero\rad studio\8.0\bin\dcc32.exe -$O- -$W+ --no-config -M -Q -AWinTypes=Windows;WinProcs=Windows;DbiTypes=BDE; DbiProcs=BDE;DbiErrs=BDE -DDEBUG -I"c:\program files (x86)\embarcadero\rad studio\8.0\lib\Win32\release";"C:\Users\Administrator\Documents\RAD Studio...

delphi.Net Delphi 2005 Project Upgrades?
Our company aquired the software property from another last year. Most of the projects were written in Delphi 2007. We purchased Delphi XE which gave us access to previous versions, including D 2007... all is well. However, 3 projects were written Delphi 2005 for .Net. The VM we received from this company included D2005 but it was licensed from the previous developer. I've contacted Embarcadero about obtaining a copy and or a license+registration for Delphi 2005 and was told this product is no longer available. I'm under the impression Delphi for .Net was abandoned. My qu...

Delphi 64bit versus Delphi Mac/Linux
interesting comments... http://www.deltics.co.nz/blog/?p=452 "Ralf Stocker" <nospam@nospam.com> wrote in message news:127800@forums.codegear.com... > interesting comments... > http://www.deltics.co.nz/blog/?p=452 A very small fraction of Delphi users actually need the memory access of 64 bit, and 32 bit apps will work the same on x64 anyway. A small fraction of Delphi users actually need cross-platform support. I'm not sure if having either first will 'save' Delphi from the 'traditional' tools for each platform (VS, Cocoa, Eclipse, et...

Why does this work fine in Delphi 2009, but not in Delphi 2010
I've been racking my head trying to figure this out and can't understand what is wrong, TFileStream.ReadComponentRes fails when I try to read a component containing a record, it works fine in Delphi 2009 and Delphi 2007, but fails with Delphi 2010 Here is the unit source and DFM *+//UnitSource+* unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TThresholdMode = (tm0,tm1,tm2,tm3,tm4,tm5); TThreshold = Record Mode:TThresholdMode; Filter,Start,Stop:Integer; end; ...

Delphi 2010 and Delphi XE5 shuts down when opening projects
Over the last week I have found it increasingly difficult to open projects. Even really simple projects, some more complex. For example if start Delphi 2010 Enterprise Edition. I see the list of recently opened projects. I then click on a simple existing project, I get a hour glass for about a second and then Delphi IDE has gone. In the windows task manager, there are now no applications running. I have not changed the installation, being using Delphi 2010 enterprise on the same computer for a few years. I'm not a full time developer, but do internal development of our compa...

Delphi 2010 and Delphi XE5 shuts down when opening projects
Over the last week I have found it increasingly difficult to open projects. Even really simple projects, some more complex. For example if start Delphi 2010 Enterprise Edition. I see the list of recently opened projects. I then click on a simple existing project, I get a hour glass for about a second and then Delphi IDE has gone. In the windows task manager, there are now no applications running. I have not changed the installation, being using Delphi 2010 enterprise on the same computer for a few years. I'm not a full time developer, but do internal development of our compa...

Code works in Delphi 7 but not in Delphi 2010 [Edit]
hello, i have a procedure that open's a file by passing the file name as the parameter to the executable. something like this {code} C : \ P r o g r a m F i l e s \ Da c k e r \ D r a c k e r . e x e " G : \ D E l p h i 7 \ D e l p h i 7 A p p _ l o g . t " {code} The source code is {code} procedure OpenFileWithExe var hReg: HKEY; Ret: Longint; RegDataType, RegDataSize: DWORD; CmdLine: array [0..560] of Char; Len: Integer; SInfo: TStartupInfo; PInfo: TProcessInformation; begin Ret := windows.RegOpenKeyEx(HKEY_CURRENT_USER, ...

Convert a Delphi 2006 WinForms project to Delphi Prism
How can I go about doing this short of recreating the project and transfering code? Just wondering what to expect if we go to Prism. Thanks. -- Don Gollahon Don Gollahon wrote: > How can I go about doing this short of recreating the project and > transfering code? > > Just wondering what to expect if we go to Prism. > > Thanks. Hi Don, Have you checked out the migration tool Oxidizer ? http://prismwiki.codegear.com/en/Oxidizer Cheers, John -- John Moshakis wrote: >Don Gollahon wrote: > >> How can I go about doing th...

Delphi on Mac OS X
Hello, Are there plans to extend Delphi to run on other OS's like Mac OS X, Ubuntu and Solaris ? Mac OS X is booming business. You can read it everyday in the newspapers and on internet. Because Delphi is not available for the Mac, I have to use NetBeans with MySQL. When I give demonstrations on the Mac and ask then when it was the last time that they want to throw the PC out of the window, people are easy to be persuaded to buy a Mac. It is a pity that I still have to use Windows. I have been developing software for 20 years on MS-DOS/Windows systems and still have r...

delphi 2010 memory not released when closing delphi project
each time im runing delphi 2010 the memory that was used was not release after closing a project and the memory don't stop to grow and the browsing for file becoming slow any idea ? Thanks Pierre Auger wrote: > each time im runing delphi 2010 the memory that was used was not > release after closing a project and the memory don't stop to grow and > the browsing for file becoming slow > > any idea ? You are using some 3rd-party components that do not properly release memory in their design-time packages would be my guess. A design-time package stays l...

Delphi on Mac OS X
Hello, In the closing keynotes of Coderage III, Wayne Williams told that Embarcadero has plans to port Delphi to Mac OS X and Linux. How far are these plans and realisations ? I see on internet that a lot of Delphi developers want to use Delphi on the Mac: http://www.petitiononline.com/bdfmosx/petition.html More and more companies are moving to Mac OS X: e.g. http://www.macnn.com/articles/09/02/23/siemens.nx.6.for.mac/ Hubert On Wed, 25 Feb 2009 00:47:47 -0800, Hubert Anemaat wrote: > In the closing keynotes of Coderage III, Wayne Williams told that > Embarcader...

Is dll developed in Delphi 6 works on Delphi 2?
I have a one dll, whose work is to creates a form with some normal vcl controls, print selected tables and email some reports. It was developed in Delphi 6. Can any other application which was developed in Delphi 2 use that dll.? If not, please let me know in which areas i need change. The dll work is only to print and email. With regards, Srikanth Varma Srikanth varma wrote: > I have a one dll, whose work is to creates a form with some normal > vcl controls, print selected tables and email some reports. It was > developed in Delphi 6. Can any other application which was d...

Delphi and Delphi for .Net
It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. I would like to know is it true all .Net application is slower than Win32 native applicaiton or it is Delphi for .Net only. Your information is great appreciated, Inung On 2011-06-21 18:20:17 +0100, Inung Huang said: > It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. > I would like to know is it true all .Net application is slower than > Win32 native applicaiton or it is Delphi for .Net only. If you are only running the code in the application once then, yes, yo...

Project Manager Delphi 2007 vs Delphi 5
I am in the midst of moving from Delphi 5 to Delphi 2007. I have a .BAT file that I use to do some post processing on the executable after it is built. In Delphi 5, I just added the .BAT file to the project manager. Then when I wanted to execute the .BAT file I just right clicked its entry in the project manager and selected Execute. There doesn't seem to be anyway to add the .BAT file to the project manager in Delphi 2007. How can I set up something similar to what I had in Delphi 5? I thought about using a Post Build event but I don't necessarily want to execute the .BAT fi...

Web resources about - Project X is a Delphi for Mac - What is it ? How work ? VCL ? - embarcadero.delphi.non-tech

The Project Shrink - Welcome To Shrinkonia.
... about the importance of the environment we work in and the stories we tell, we should have a Set Designer and a Storyteller on our projects. ...

Better Projects
I think this book by Tobias is beautifully written. There is real craftmanship in the prose here. The book is made up of independent self contained ...

Project Gutenberg - Wikipedia, the free encyclopedia
Most of the items in its collection are the full texts of public domain books . The project tries to make these as free as possible, in long-lasting, ...

Wrike Rises Above Other Project Management Software After Testing
Over the last year I had occasion to look at and purchase Task and Project Management software. I had several folks on different teams sign up ...

Get trained for a career in project management for $39
... change can be daunting—and expensive, when you’re starting your training from scratch. So if you’ve been thinking about a new career in project ...

Future Islands side project The Snails release Christmas song, playing shows
Future Islands singer Samuel T. Herring and guitarist/bassist William Cashion have another band called The Snails (not to be confused with the ...

Actress Lake Bell, first female voice of the iPhone, is taking over Hollywood one project at a time
... the time to direct, but the problem that I have just personally is that there are only so many years in my life to dedicate to certain projects. ...

Apple & SunPower Collaborating On 170 MW Solar Power Project In Mongolia
Three solar power projects with a combined capacity of 170 MW are being constructed by Zhonghuan Energy in the northern Chinese territory of ...

Retired Prof Hates Israel So Much She Won’t Help 13 Year Old With School Project
Retired Prof Hates Israel So Much She Won’t Help 13 Year Old With School Project

Sander/Moses Inks Deal With NBCU Int’l TV, Sells Projects To Amazon & ABC
Producers Ian Sander and Moses ( Ghost Whisperer, Reckless, Profiler ) have signed a first-look deal with NBC Universal International TV Production. ...

Resources last updated: 12/3/2015 1:13:05 AM