On 18 August 2011 22:27, Max Vlasov wrote:
> I glanced at the quick guide. Actually MiGLayout looks promising, but
> personally I'd use it if it's implemented with intuitiveness and visual
> sense in mind.
"visual" doesn't always make things better. In fact, visual often
posses more limitations. T
On 08/17/2011 11:57 PM, Graeme Geldenhuys wrote:
Why define a UI with co-ordinates, then sit with problems like
overlapping components, components that don't scale, locked to a
specific DPI etc.
This is similar to HTML vs PDF.
PDF always looks the same _if_ it can be displayed at all.
HTML (ho
On Thu, Aug 18, 2011 at 9:56 PM, Graeme Geldenhuys
wrote:
>
>
> On Thursday, 18 August 2011, Max Vlasov > wrote:
>
> > Adding new aligners and using it for items of another aligner can build
> very complex layouts not using direct coordinates at all. Seems like the
> port of this component works
On Thursday, 18 August 2011, Max Vlasov > wrote:
> Adding new aligners and using it for items of another aligner can build
very complex layouts not using direct coordinates at all. Seems like the
port of this component works in Lazarus. If the concept is worth considering
I can provide the source
On Thu, Aug 18, 2011 at 1:57 AM, Graeme Geldenhuys
wrote:
> On 15 August 2011 10:48, Michael Schnell wrote:
> >
> > I never tried this, but I feel that IDEs (integrating code editor, GUI
> > designer, make process, and debugger) have been invented for a purpose.
>
> I agree with all except the "gu
Graeme Geldenhuys schrieb:
On 15 August 2011 10:52, Michael Schnell wrote:
What is the main difference between the fpGUI designer and MiGLayout ?
[...]
If you read the MiGLayout white paper, you will learn some more of the
advanced features which are mind blowing! The author thought of
everyt
Graeme Geldenhuys schrieb:
I think Lazarus improved a lot over Delphi here, but Lazarus's
designer is still way to complicated and error prone for complex UI's.
Look at all the settings in the Align/Anchor property editors, yet
often you still have to code some UI rules irrespectively. With good
On 15 August 2011 10:52, Michael Schnell wrote:
>
> What is the main difference between the fpGUI designer and MiGLayout ?
Like day and night. fpGUI's UI Designer is similar to Delphi or
Lazarus's Form designers. Drop components, set some properties etc.
The only difference there is that fpGUI's
On 15 August 2011 10:48, Michael Schnell wrote:
>
> I never tried this, but I feel that IDEs (integrating code editor, GUI
> designer, make process, and debugger) have been invented for a purpose.
I agree with all except the "gui designer" part. Layout Managers are
by far the better choice compare
Am 15.08.2011 10:52, schrieb Michael Schnell:
On 08/15/2011 12:39 AM, Graeme Geldenhuys wrote:
On 14 August 2011 20:21, Sven Barth wrote:
Just curious: Do you still plan to port it to Pascal?
Definitely!
Hmm, in the end giving us the choice between LCL/VCL, Firemonkey, fpGUI
designer, and MiG
On 08/15/2011 12:39 AM, Graeme Geldenhuys wrote:
On 14 August 2011 20:21, Sven Barth wrote:
Just curious: Do you still plan to port it to Pascal?
Definitely!
Hmm, in the end giving us the choice between LCL/VCL, Firemonkey, fpGUI
designer, and MiGLayout (and...).
Maybe too many alternatives
On 08/14/2011 08:09 PM, Graeme Geldenhuys wrote:
And yes, even complex UI's are a breeze to code up with
MiGLayout
I never tried this, but I feel that IDEs (integrating code editor, GUI
designer, make process, and debugger) have been invented for a purpose.
-Michael
___
On 8/14/2011 14:09, Graeme Geldenhuys wrote:
On 12 August 2011 14:12, Michael Schnell wrote:
But you can't use the Lazarus GUI designer. I feel that without same the
development is far more stressful.
GUI designers are not always needed. Take MiGLayout manager for Java.
It is extremely easy
On 8/13/2011 11:14, Jonas Maebe wrote:
From the horse's mouth:
https://forums.embarcadero.com/message.jspa?messageID=379331#379331
"If there are any changes or fixes we would contribute them, happily. I don't
believe that we made any but it's our policy to contribute back fixes/changes to any
On 14 August 2011 20:21, Sven Barth wrote:
>
> Just curious: Do you still plan to port it to Pascal?
Definitely! I just keep getting other work that takes priority - damn
bosses. :) I really should try and make time for it, because I can't
wait to start using it. I've played around quite a bit wi
On 14.08.2011 19:46, Graeme Geldenhuys wrote:
On 12 August 2011 07:33, Felipe Monteiro de Carvalho>> As far as
I'm currently aware of the state of LCL-fpGUI (I never tested it yet) I'll
need to implement TTreeView...
If you ever do, please implement it in the Custom Drawn Package from
Lazarus
On 14.08.2011 20:09, Graeme Geldenhuys wrote:
On 12 August 2011 14:12, Michael Schnell wrote:
But you can't use the Lazarus GUI designer. I feel that without same the
development is far more stressful.
GUI designers are not always needed. Take MiGLayout manager for Java.
It is extremely easy
On 12 August 2011 14:12, Michael Schnell wrote:
>
> But you can't use the Lazarus GUI designer. I feel that without same the
> development is far more stressful.
GUI designers are not always needed. Take MiGLayout manager for Java.
It is extremely easy to create a GUI without the need for a GUI
D
On 12 August 2011 07:33, Felipe Monteiro de Carvalho >> As far as
>> I'm currently aware of the state of LCL-fpGUI (I never tested it yet) I'll
>> need to implement TTreeView...
>
> If you ever do, please implement it in the Custom Drawn Package from
> Lazarus,
Oh, maybe I understood the original
On 14 Aug 2011, at 09:05, Mark Morgan Lloyd wrote:
> Which presumably means they're using the standard command-line parameters, so
> potentially a different PPC could be used to generate code for some other
> target.
They generate a project for Apple's Xcode IDE to compile everything. The
pro
Jonas Maebe wrote:
On 07 Aug 2011, at 20:53, Jonas Maebe wrote:
They only have to share them with their customers who get the binary (and even
then only for nominal shipping and handling fees). Of course, those customers
are then free to pass them along further, if they want to. And in practi
On Sat, 13 Aug 2011, Jonas Maebe wrote:
On 07 Aug 2011, at 20:53, Jonas Maebe wrote:
They only have to share them with their customers who get the binary (and even
then only for nominal shipping and handling fees). Of course, those customers
are then free to pass them along further, if th
On 07 Aug 2011, at 20:53, Jonas Maebe wrote:
> They only have to share them with their customers who get the binary (and
> even then only for nominal shipping and handling fees). Of course, those
> customers are then free to pass them along further, if they want to. And in
> practice, I can't
On 12-8-2011 14:54, Flávio Etrusco wrote:
|
Look at the documentation, that is easier:
http://developer.android.com/sdk/ndk/index.html as a start.
Almost ALL OpenGl calls are available under Android Gingerbread.
In all my postings I am talking about Gingerbread or higher.
But indeed, I am just exp
On Fri, Aug 12, 2011 at 9:18 AM, Michael Schnell wrote:
> On 08/12/2011 01:56 PM, Thaddy wrote:
>>
>> It is not slow at all, it is lightning fast.
>
> So it obviously does use rendering hardware.
>>
>> As far as I suspect the framebuffer manipulation is indeed through the
>> kernel.
>
> I did not
And more important for me: the same code I can use on several OS:
Android, WebOs, Linux, Windows, .. iOs ( I hope that FPC will be able to
crosscompile to iOs soon), server can be embedded or standalone
This might not be possible from non Apple targets, because of Apple's
licence restrictions (t
On 12-8-2011 14:18, Michael Schnell wrote:
If you use openGL v2 there's of course just one abstraction layer extra.
Yep. I did understand wrong that not using GL would imply not using
the rendering hardware and directly writing to the pixel array instead.
Will not only provide screenshot but ac
On 08/12/2011 01:56 PM, Thaddy wrote:
It is not slow at all, it is lightning fast.
So it obviously does use rendering hardware.
As far as I suspect the framebuffer manipulation is indeed through the
kernel.
I did not take a look into the framebuffer driver API, but it's quite
obvious that it
On 08/12/2011 10:52 AM, Dariusz Mazur wrote:
For me browser has more capabilities than native widgets.
But you can't use the Lazarus GUI designer. I feel that without same the
development is far more stressful.
-Michael
___
fpc-devel maillist -
On 12-8-2011 14:06, Michael Schnell wrote:
On 08/11/2011 05:28 PM, Thaddy wrote:
Not really/ somewhat / close enough
Can you provide a photo ?
- Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/li
On 08/11/2011 05:28 PM, Thaddy wrote:
Not really/ somewhat / close enough
Can you provide a photo ?
- Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 12-8-2011 13:44, Michael Schnell wrote:
On 08/11/2011 11:24 PM, Graeme Geldenhuys wrote:
I will offer fpGUI support to anybody that works on LCL-fpGUI though.
So if you do go that route and get stuck with fpGUI concepts, don't
hesitate to send me a mail.
Great.
Sven: For me right now the bi
On 12-8-2011 13:16, Michael Schnell wrote:
On 08/11/2011 04:09 PM, Jeppe Græsdal Johansen wrote:
Android also has some support for a pixbuf object in native mode,
which I guess could be used for the same
Having the processor write into the pixel array would be horribly
slow. I am right now pla
On 08/11/2011 11:24 PM, Graeme Geldenhuys wrote:
I will offer fpGUI support to anybody that works on LCL-fpGUI though.
So if you do go that route and get stuck with fpGUI concepts, don't
hesitate to send me a mail.
Great.
Sven: For me right now the biggest problem with fpGUI/LCL is that
Applic
On 08/11/2011 09:58 PM, Graeme Geldenhuys wrote:
Umm.. I'm getting more and more interested in the Android platform.
Maybe it's time I officially start working on a OpenGL backend for
fpGUI. fpGUI would at least guarantee a small executable - at least
compared to LCL.
Great !!
Of course fpG
Am 12.08.2011 10:52, schrieb Dariusz Mazur:
Even if KSD or now FireMonkey supports ARM Linux this does not mean
anything for Android. While Android does support native Linux
applications it does not have a X server. Currently the only possibility
for this is to run a X server through a VNC viewe
On 08/11/2011 05:20 PM, Thaddy wrote:
Since you have access to a NDI native screenbuffer
Does this mean, you can't use the hardware rendering (if the Chip
provides it) ?
you can use opengl v 2 to render anything directly without qt if you
want, so small is definitely possible.
That answer
On 08/11/2011 04:33 PM, Thaddy wrote:
I have qt code running myself on an very cheap Android 2.3 tab from a
toyshop and it works a charm.
GREAT !
Maybe you might be ablt to check if OpenGL is supported, too.
I also have Mono/.net code running on it.
Great ;)
Currently both under C and C#. T
On 08/11/2011 04:09 PM, Jeppe Græsdal Johansen wrote:
Android also has some support for a pixbuf object in native mode,
which I guess could be used for the same
Having the processor write into the pixel array would be horribly slow.
I am right now planning a hardware design using TI ARM process
On 12-8-2011 11:07, Felipe Monteiro de Carvalho wrote:
Just one hint: Android is a *lot* more then just drawing some
graphics. For example: 1> Virtual keyboard. There are dozens and
dozens, even widespread devices like Galaxy Tab come with non-standard
keyboards, some of them only for China, so
On Thu, Aug 11, 2011 at 9:58 PM, Graeme Geldenhuys
wrote:
> Umm.. I'm getting more and more interested in the Android platform.
> Maybe it's time I officially start working on a OpenGL backend for
> fpGUI. fpGUI would at least guarantee a small executable - at least
> compared to LCL.
>
> I'll be
On 12-8-2011 10:52, Dariusz Mazur wrote:
My previous post crossed yours! Tnx for the good work.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 12-8-2011 7:33, Felipe Monteiro de Carvalho wrote:
This could be fixed by introducing some phone-like layouts in the LCL,
like the linear layouts from Android.
That's what I am currently experimenting with in opengl. I don't mean to
turn it into a full widgetset, though.
Another way is maybe
Even if KSD or now FireMonkey supports ARM Linux this does not mean
anything for Android. While Android does support native Linux
applications it does not have a X server. Currently the only possibility
for this is to run a X server through a VNC viewer and thus you can not
reproduce the usual fe
On 11-8-2011 21:58, Graeme Geldenhuys wrote:
Umm.. I'm getting more and more interested in the Android platform.
Maybe it's time I officially start working on a OpenGL backend for
fpGUI. fpGUI would at least guarantee a small executable - at least
compared to LCL. I'll be Google'ing some more t
On 08/11/2011 04:24 PM, Ludo Brands wrote:
According to http://labs.qt.nokia.com/2011/02/28/necessitas/#comment-19682
the qt port uses the framebuffer driver.
I don't know if this Frambuffer needs to have and/or already has the
necessary support for OpenGL, that I understand to be what KSD (mayb
Am 12.08.2011 07:33, schrieb Felipe Monteiro de Carvalho:
On Thu, Aug 11, 2011 at 10:33 PM, Sven Barth
wrote:
I also already thought about using fpGUI, but as a LCL backend. The reason
is that I have two Windows Mobile LCL applications that are tailored to my
own needs that I'd like to use whe
On Thu, Aug 11, 2011 at 10:33 PM, Sven Barth
wrote:
> I also already thought about using fpGUI, but as a LCL backend. The reason
> is that I have two Windows Mobile LCL applications that are tailored to my
> own needs that I'd like to use when I have a new Android phone.
The LCL-Android already h
On 11 August 2011 22:33, Sven Barth wrote:
> I also already thought about using fpGUI, but as a LCL backend. The reason
> is that I have two Windows Mobile LCL applications that are tailored to my
I have created a few GPS related apps using fpGUI (directly) for my
Garmin PDA. It was just to see i
On 11.08.2011 21:58, Graeme Geldenhuys wrote:
On 11 August 2011 17:20, Thaddy wrote:
Since you have access to a NDI native screenbuffer you can use opengl v 2
to render anything directly without qt if you want, so small is definitely
possible.
Umm.. I'm getting more and more interested in the
On 11 August 2011 17:20, Thaddy wrote:
> Since you have access to a NDI native screenbuffer you can use opengl v 2
> to render anything directly without qt if you want, so small is definitely
> possible.
Umm.. I'm getting more and more interested in the Android platform.
Maybe it's time I officia
On 11.08.2011 17:28, Thaddy wrote:
On 11-8-2011 17:01, Sven Barth wrote:
I know about X servers running there (I have looked that up today
morning, because I liked to know whether I somehow could run Wine on
Android), but all I've found yet was the restriction to access the X
screen through a V
On 11-8-2011 17:28, Thaddy wrote:
On 11-8-2011 17:01, Sven Barth wrote:
I know about X servers running there (I have looked that up today
morning, because I liked to know whether I somehow could run Wine on
Android), but all I've found yet was the restriction to access the X
screen through a
On 11-8-2011 17:01, Sven Barth wrote:
I know about X servers running there (I have looked that up today
morning, because I liked to know whether I somehow could run Wine on
Android), but all I've found yet was the restriction to access the X
screen through a VNC viewer. If you know more, I'd
On 11-8-2011 16:37, Felipe Monteiro de Carvalho wrote:
toyshop and it works a charm.
What is the size of an app using Qt on Android counting the Qt
libraries that it downloads?
Just what you expect from any GNU compiled program and just what you
expect the runtime libraries to be with any qt ba
Sven Barth schrieb:
On 08.08.2011 22:11, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
That being said, there is another bubble going on in Mobile, and we
have to
be very careful that such things don't happen again.
May I ask you to explain what you mean here? (Just cur
Am 11.08.2011 16:33, schrieb Thaddy:
On 11-8-2011 13:56, Sven Barth wrote:
Even if KSD or now FireMonkey supports ARM Linux this does not mean
anything for Android. While Android does support native Linux
applications it does not have a X server. Currently the only
possibility for this is to ru
On Thu, Aug 11, 2011 at 4:33 PM, Thaddy wrote:
> I have qt code running myself on an very cheap Android 2.3 tab from a
> toyshop and it works a charm.
What is the size of an app using Qt on Android counting the Qt
libraries that it downloads?
--
Felipe Monteiro de Carvalho
_
On 11-8-2011 13:56, Sven Barth wrote:
Even if KSD or now FireMonkey supports ARM Linux this does not mean
anything for Android. While Android does support native Linux
applications it does not have a X server. Currently the only
possibility for this is to run a X server through a VNC viewer a
> > While Android does support native Linux applications it
> does not have
> > a X server. Currently the only possibility for this is to run a X
> > server through a VNC viewer and thus you can not reproduce
> the usual
> > feel of an Android application. For that you'd need to write a Java
> > b
On 11-08-2011 13:56, Sven Barth wrote:
Am 09.08.2011 11:54, schrieb Michael Schnell:
On 08/08/2011 10:00 PM, Sven Barth wrote:
It will be interesting to see whether they want to license Cooper,
RemObject's upcoming Pascal compiler for Java, as well; their plans to
support Android as well in the
On 08/11/2011 01:56 PM, Sven Barth wrote:
While Android does support native Linux applications it does not have
a X server. Currently the only possibility for this is to run a X
server through a VNC viewer and thus you can not reproduce the usual
feel of an Android application. For that you'd n
Am 09.08.2011 11:54, schrieb Michael Schnell:
On 08/08/2011 10:00 PM, Sven Barth wrote:
It will be interesting to see whether they want to license Cooper,
RemObject's upcoming Pascal compiler for Java, as well; their plans to
support Android as well in the future could mean this.
Of course Coop
On 08/09/2011 11:28 AM, Graeme Geldenhuys wrote:
I'm pretty sure Kylix and CLX would have worked if Borland just paid a
bit more attention to quality and better marketing.
+1
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lis
On 08/08/2011 10:00 PM, Sven Barth wrote:
It will be interesting to see whether they want to license Cooper,
RemObject's upcoming Pascal compiler for Java, as well; their plans to
support Android as well in the future could mean this.
Of course Cooper would be a way to support Android for framew
On 9 August 2011 09:49, Mark Morgan Lloyd wrote:
>
> I don't think that the VCL was the issue with Kylix. The issues were (a)
> uncertainty over the Linux community's acceptance of a non-free development
>
Add to that list:
- CLX was buggy as hell because they didn't even write the Kylix ID
In our previous episode, Mark Morgan Lloyd said:
[ Charset windows-1252 unsupported, converting... ]
> Hans-Peter Diettrich wrote:
>
> > IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix:
> > the Win32 centric VCL :-(
>
> I don't think that the VCL was the issue with Kylix.
Hans-Peter Diettrich wrote:
IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix:
the Win32 centric VCL :-(
I don't think that the VCL was the issue with Kylix. The issues were (a)
uncertainty over the Linux community's acceptance of a non-free
development environment and
On 8-8-2011 21:57, Sven Barth wrote:
On 07.08.2011 19:52, Marco van de Voort wrote:
That being said, there is another bubble going on in Mobile, and we
have to
be very careful that such things don't happen again.
May I ask you to explain what you mean here? (Just curious)
Regards,
Sven
_
On 08.08.2011 22:45, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
the Win32 centric VCL :-(
It was not only the VCL. They included stuff in the assemblies that made
them basically hard to use from other languages. Things like
initialization and finalization sections jus
In our previous episode, Sven Barth said:
> > the Win32 centric VCL :-(
> >
>
> It was not only the VCL. They included stuff in the assemblies that made
> them basically hard to use from other languages. Things like
> initialization and finalization sections just don't work that well in
> the C
On Mon, Aug 8, 2011 at 11:15 PM, Hans-Peter Diettrich
wrote:
> IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix: the
> Win32 centric VCL :-(
Non-sense, if it was like that Gtk2 would be a huge failure, because
it is totally X11-centric, but nevertheless it has a very big us
On 08.08.2011 23:15, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
On 08.08.2011 12:48, Michael Schnell wrote:
On 08/06/2011 12:16 PM, Jonas Maebe wrote:
So it's just a stopgap solution for them until they have time to build
their own ARM compiler,
They continue to use the product from RemO
On 08.08.2011 22:11, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
That being said, there is another bubble going on in Mobile, and we have to
be very careful that such things don't happen again.
May I ask you to explain what you mean here? (Just curious)
That donations
Sven Barth schrieb:
On 08.08.2011 12:48, Michael Schnell wrote:
On 08/06/2011 12:16 PM, Jonas Maebe wrote:
So it's just a stopgap solution for them until they have time to build
their own ARM compiler,
They continue to use the product from RemObject as their .Net compiler
:). So I suppose they
In our previous episode, Sven Barth said:
> > That being said, there is another bubble going on in Mobile, and we have to
> > be very careful that such things don't happen again.
>
> May I ask you to explain what you mean here? (Just curious)
That donations of large pieces of code are not checked
On 08.08.2011 12:48, Michael Schnell wrote:
On 08/06/2011 12:16 PM, Jonas Maebe wrote:
So it's just a stopgap solution for them until they have time to build
their own ARM compiler,
They continue to use the product from RemObject as their .Net compiler
:). So I suppose they are not in a hurry (
On 07.08.2011 19:52, Marco van de Voort wrote:
That being said, there is another bubble going on in Mobile, and we have to
be very careful that such things don't happen again.
May I ask you to explain what you mean here? (Just curious)
Regards,
Sven
On 8/7/2011 12:50, Jonas Maebe wrote:
On 07 Aug 2011, at 17:57, Graeme Geldenhuys wrote:
Makes you wonder, will they start submitting patches for FPC too?
I hope so. The main problem I see with that is that they would become somewhat
"tainted" by the FPC source code if they do so, which may
AFAIU, the Windows 32 FPC has some disadvantages regarding the Delphi
compiler (compiling speed, executable speed, executable size).
(Obviously providing multiplatform does not come for free.)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepa
On 08/06/2011 12:16 PM, Jonas Maebe wrote:
So it's just a stopgap solution for them until they have time to build their
own ARM compiler,
They continue to use the product from RemObject as their .Net compiler
:). So I suppose they are not in a hurry (in case that FPC works as
expected, which
+1
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Mon, Aug 8, 2011 at 12:49 AM, Florian Klämpfl wrote:
> Am 07.08.2011 18:27, schrieb Jonas Maebe:
> >
> > And I don't
> > understand all this hostility towards Embarcadero.
>
> Indeed. People should be happy that there is a pretty large commercial
> vendor which provides an professional object p
On 07-08-2011 20:42, Graeme Geldenhuys wrote:
own compiler later on. As long as they don't start blatantly copying code from
FPC
into their own compiler
The problem is, how would we know? Nobody can see their compiler code.
Good news is that any modifications or bug fixes they make, they wil
Am 07.08.2011 18:27, schrieb Jonas Maebe:
>
> And I don't
> understand all this hostility towards Embarcadero.
Indeed. People should be happy that there is a pretty large commercial
vendor which provides an professional object pascal development
environment. Even if one doesn't use it, one shoul
In our previous episode, Jonas Maebe said:
> > Anyway, there are more gotchas. They could e.g. have stuff like
> > linkerscripts in a external files, and since they are not GPLed, not deliver
> > them.
>
> a) again, I have a really hard time imagining that the people at
> Embarcadero would go out
On 07 Aug 2011, at 22:00, Marco van de Voort wrote:
> Anyway, there are more gotchas. They could e.g. have stuff like
> linkerscripts in a external files, and since they are not GPLed, not deliver
> them.
a) again, I have a really hard time imagining that the people at Embarcadero
would go out
In our previous episode, Dimitri Smits said:
> > Florian, has anybody from Embarcadero approached you on this? I
> > wonder if they know that any modifications they make to the FPC
> > compiler must be made available as open-source? The compiler is
> > GPL'ed
> > after all.
>
> contrary to popula
- "Graeme Geldenhuys" schreef:
> Florian, has anybody from Embarcadero approached you on this? I
> wonder if they know that any modifications they make to the FPC
> compiler must be made available as open-source? The compiler is
> GPL'ed
> after all.
contrary to popular belief, it is not s
On 07 Aug 2011, at 20:42, Graeme Geldenhuys wrote:
> Good news is that any modifications or bug fixes they make, they will
> have to share.
They only have to share them with their customers who get the binary (and even
then only for nominal shipping and handling fees). Of course, those customer
On 7 August 2011 18:50, Jonas Maebe wrote:
>
>> Makes you wonder, will they start submitting patches for FPC too?
>
> I hope so.
+1
At least for now FPC scored some bragging rights. :)
> The main problem I see with that is that they would become somewhat "tainted"
A very valid point.
> own co
On 7 August 2011 18:08, Bernd Mueller wrote:
>
> they could even save more time, it they would use Lazarus ;-)
I wouldn't mind them building a workable debugger for FPC.
>> Makes you wonder, will they start submitting patches for FPC too?
>
> I had the same thought. What happens, if their custom
On 7-8-2011 18:50, Jonas Maebe wrote:
I hope so. The main problem I see with that is that they would become
somewhat "tainted" by the FPC source code if they do so, which may
make it harder to work on their own compiler later on. As long as they
don't start blatantly copying code from FPC into
they could even save more time, it they would use Lazarus ;-)
That's the one part they - Embarcadero - are still miles ahead in
productivity and reliability. Lazarus is workable - more than that - but
still cannot compete with Delphi in productivity - but that of course is
for Windows only. I
In our previous episode, Jonas Maebe said:
> I hope so. The main problem I see with that is that they would become
> somewhat "tainted" by the FPC source code if they do so, which may make it
> harder to work on their own compiler later on. As long as they don't
> start blatantly copying code fro
In our previous episode, Jonas Maebe said:
> > Jonas Maebe wrote:
> >
> >> ...So it's just a stopgap solution for them until they have time to build
> >> their own ARM compiler...
> >
> > wow! The former state of the art compiler vendor
> > (Borland/Inprise/Borland/Codegear/Emb...) is not able
On 07 Aug 2011, at 17:57, Graeme Geldenhuys wrote:
> Makes you wonder, will they start submitting patches for FPC too?
I hope so. The main problem I see with that is that they would become somewhat
"tainted" by the FPC source code if they do so, which may make it harder to
work on their own co
On 07 Aug 2011, at 18:08, Bernd Mueller wrote:
> What happens, if their customers report bugs concerning the code generation?
> Are they competent enough to fix them? (I don't think so)
I can't imagine why they wouldn't be able to do so. And I don't understand all
this hostility towards Embarc
>
> Makes you wonder, will they start submitting patches for FPC too?
>
that was what I was wondering about as well. Why not participate in fpc/lazarus
development and "add" the missing features (packages etc; some language
features) or "update" the D7-isms to XE standards instead of doing it
Graeme Geldenhuys wrote:
On 7 August 2011 17:29, Jonas Maebe wrote:
Going from a completely i386-specific code generator to an ARM
code generator is a lot of work, especially if you at the same time
also have to create a 64 bit code generator.
Maybe they should just call it quits on there comp
1 - 100 of 108 matches
Mail list logo
