Board index » kylix » Re: Cross-platform library

Re: Cross-platform library


2005-08-30 07:13:57 AM
kylix0
Hi Thomas,
Quote
The biggest problem with Object Pascal (OP) as I see it for us
developers is that when we pick a development tool, we also tie
ourselves to a library.
Exactly, yes.
Quote
If I want to use Lazarus, I have to use
the LCL. Delphi the VCL, Kylix QT. How do I move my code from
one platform to another? I can't. If there was a library designed
to work with all of them, (or a lot of them), I could quickly and
easily move from development tool, to OS, and back again with
little or no program changes.
Wouldn't porting part of JVCL3 to Lazarus, as it exists for Delphi, .Net
(JEDI.NET just starting!) and Kylix offers a good start ?
For business apps, we would need at least on Lazarus:
- JvDbGrid
- DbEdits: JvDBComboBox, JvDBSearchComboBox, JvDBDateEdit...
- Edits: JvComboLookup, JvSpinEdit...
We would also need cross-platform data access : Zeos, AnyDAC? when/if it
comes to Lazarus.
We could use JVCL3 to develop on all four platforms and provided we use
only JVCL3 controls be able to build on Delphi and Lazarus.
Regards,
Oliver
We would only miss something like RemObjects, Kbm or Realthinclient running
on Lazarus.
 
 

Re:Re: Cross-platform library

"Jonathan Benedicto" < XXXX@XXXXX.COM >wrote in message
Quote
"Thomas Miller" < XXXX@XXXXX.COM >wrote in message
news:431364fc$ XXXX@XXXXX.COM ...
>The biggest problem with Object Pascal (OP) as I see it for us
>developers is that when we pick a development tool, we also tie
>ourselves to a library. If I want to use Lazarus, I have to use
>the LCL. Delphi the VCL, Kylix QT. How do I move my code from
>one platform to another? I can't. If there was a library designed
>to work with all of them, (or a lot of them), I could quickly and
or a VM that wasn't pokey?
 

Re:Re: Cross-platform library

Oliver Feins wrote:
Quote
We would only miss something like RemObjects, Kbm or Realthinclient
running on Lazarus.
I'll see what can I do with kbmMW ;-) As soon I find some spare time...
--
Best regards,
Fikret Hasovic fikret.fbtalk.net
USAID TAMP Senior Programmer
* Firebird Foundation member.
- Join today at www.firebirdsql.org/ff/foundation
* JEDI VCS contributor
jedivcs.sourceforge.net/
* Firebird and Fyracle news
www.fyracle.org
Posted with XanaNews 1.17.5.9
 

{smallsort}

Re:Re: Cross-platform library

Oliver Feins wrote:
Quote
Wouldn't porting part of JVCL3 to Lazarus, as it exists for Delphi,
.Net (JEDI.NET just starting!) and Kylix offers a good start ?
Yes.
Quote

For business apps, we would need at least on Lazarus:
- JvDbGrid
- DbEdits: JvDBComboBox, JvDBSearchComboBox, JvDBDateEdit...
- Edits: JvComboLookup, JvSpinEdit...
That would be good start.
Quote

We would also need cross-platform data access : Zeos, AnyDAC? when/if
it comes to Lazarus.
Zeos already work with lazarus. And UIB, too.
Quote

We could use JVCL3 to develop on all four platforms and provided we
use only JVCL3 controls be able to build on Delphi and Lazarus.
Exactly.
Quote

Regards,

Oliver
--
Best regards,
Fikret Hasovic fikret.fbtalk.net
USAID TAMP Senior Programmer
* Firebird Foundation member.
- Join today at www.firebirdsql.org/ff/foundation
* JEDI VCS contributor
jedivcs.sourceforge.net/
* Firebird and Fyracle news
www.fyracle.org
Posted with XanaNews 1.17.5.9
 

Re:Re: Cross-platform library

Fikret Hasovic wrote:
Quote
>Wouldn't porting part of JVCL3 to Lazarus, as it exists for Delphi,
>.Net (JEDI.NET just starting!) and Kylix offers a good start ?

Yes.
Try it. All JVCL components depend on the JvExVCL units and JvJCLUtils,
JvJVCLUtils. Those are the JVCL core for most components and if you can
port them you will have less work porting most components. These units are
already ported to VCL.NET. The Kylix port of JvExVCL isn't working
anymore. That's the reason why VisualCLX is no more officially supported
by the JVCL.
Quote
>We could use JVCL3 to develop on all four platforms and provided we
>use only JVCL3 controls be able to build on Delphi and Lazarus.

Exactly.
JVCL does not reinvent the VCL controls but heavily use their features. So
most JVCL components which inherit from VCL components are not portable
without a full blown VCL. The TCustomControls and TGraphicControls are
easier to port.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

Re:Re: Cross-platform library

Oliver Feins wrote:
Quote
For business apps, we would need at least on Lazarus:
- JvDbGrid
- DbEdits: JvDBComboBox, JvDBSearchComboBox, JvDBDateEdit...
- Edits: JvComboLookup, JvSpinEdit...

One of the problem is this code is all inherited from Delphi classes.
What if you want to change or fix the ancestor class? You can't. It
is copyrighted and you can't use it.
On the other hand if we start with the LCL or and TNT, we have code that
we can do anything we want. Now once you have a good base, then you go
to JVCL and other projects, and adopt the work there to work on top of
your completely open base.
Quote
We would also need cross-platform data access : Zeos, AnyDAC? when/if it
comes to Lazarus.

We could use JVCL3 to develop on all four platforms and provided we use
only JVCL3 controls be able to build on Delphi and Lazarus.

Regards,

Oliver

We would only miss something like RemObjects, Kbm or Realthinclient running
on Lazarus.
Once the base is there, it would be simple for these products to be ported.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:Re: Cross-platform library

Fikret Hasovic wrote:
Quote
Oliver Feins wrote:

>We would also need cross-platform data access : Zeos, AnyDAC? when/if
>it comes to Lazarus.


Zeos already work with lazarus. And UIB, too.


>We could use JVCL3 to develop on all four platforms and provided we
>use only JVCL3 controls be able to build on Delphi and Lazarus.


Exactly.
I more or less wrote dbExpressPlus with the help of one other
individual. He and I plus a couple of driver vendors are interested in
creating a dbExpress II that is really powerful. So database access
will be there. My problem is that yes I started the project, but my
forte is DB. I need about 3 guys that are really good at the general
low level stuff. I understand one area holding things up is the LCL
TThread object needs a lot of work to be up to Delphi / Kylix standards.
Lots of libraries use this class, so there is a catch 22.
Quote


>Regards,
>
>Oliver




--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:Re: Cross-platform library

Andreas Hausladen wrote:
Quote


JVCL does not reinvent the VCL controls but heavily use their features. So
most JVCL components which inherit from VCL components are not portable
without a full blown VCL. The TCustomControls and TGraphicControls are
easier to port.


Which is why the UOPL is needed. Once the base is all in open source,
then we can do what ever we want.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:Re: Cross-platform library

On 2005-08-29, Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
The biggest problem with Object Pascal (OP) as I see it for us
developers is that when we pick a development tool, we also tie
ourselves to a library. If I want to use Lazarus, I have to use
the LCL. Delphi the VCL, Kylix QT. How do I move my code from
one platform to another?
Use CLX with Delphi/Kylix or LCL on both.
Quote
Once C++ programmers started to standardize on MS library, they
could move there code all over the place. Unfortunately, we
(OP Programmers) can't do that.
What nonsense is this? What MS library works on Unix ?
 

Re:Re: Cross-platform library

On 2005-08-29, Jonathan Benedicto < XXXX@XXXXX.COM >wrote:
Quote
"Thomas Miller" < XXXX@XXXXX.COM >wrote in message
Yes.


>So again, why aren't you interested in helping these guys?

Well, like I said, I prefer a VCL/CLX style api, so if I wrote a wrapper,
I'd write it in C++, then write a Pascal wrapper for my C++ wrapper.
So, I
would not use a Pascal wrapper for gtk, as my wrapper would handle that.
Both Pascal and C++ handle GTK (which has a C level api) by direct headers, not
wrappers. Double wrapping is unnecessary.
The LCL is the wrapper. (to use GTK and win32). However such wrappers over
multiple toolkits are easy in theory, and a lot of work in practice.
 

Re:Re: Cross-platform library

On 2005-08-29, Oliver Feins <oliverfeins@rmeloo>wrote:
Quote
Hi Thomas,

>The biggest problem with Object Pascal (OP) as I see it for us
>developers is that when we pick a development tool, we also tie
>ourselves to a library.

Exactly, yes.

>If I want to use Lazarus, I have to use
>the LCL. Delphi the VCL, Kylix QT. How do I move my code from
>one platform to another? I can't. If there was a library designed
>to work with all of them, (or a lot of them), I could quickly and
>easily move from development tool, to OS, and back again with
>little or no program changes.

Wouldn't porting part of JVCL3 to Lazarus, as it exists for Delphi, .Net
(JEDI.NET just starting!) and Kylix offers a good start ?

For business apps, we would need at least on Lazarus:
- JvDbGrid
- DbEdits: JvDBComboBox, JvDBSearchComboBox, JvDBDateEdit...
- Edits: JvComboLookup, JvSpinEdit...

We would also need cross-platform data access : Zeos, AnyDAC? when/if it
comes to Lazarus.

We could use JVCL3 to develop on all four platforms and provided we use
only JVCL3 controls be able to build on Delphi and Lazarus.

Regards,

Oliver

We would only miss something like RemObjects, Kbm or Realthinclient running
on Lazarus.
Some info about packages:
- afaik Zeos compiled with FPC after variant stuff was fixed.
- KBMMW has been tried, is stalled on customvariants support. Sb from CrossFPC
would attempt to add support, but haven't heard anything in a while)
- ICS works on win32. (runtime). A quick test with designtime was also
succesful. (ping demo)
- Indy has been tried, but failed till now (binaries compile with some work,
but don't work). Last attempt over an year ago, will try again
soon.
- Assuming you meant the pascal scripting language with remobjects Carlo Cox'
PasScript (Remobjects Pascal predecessor) has worked on FPC since 2000,
recently untested.
- JCL works largely on Windows. (Linux status unknown, some internal RTTI
stuff and code depending on set sizes need workarounds)
- Jedi DirectX, Math and SDL can be made to work. (apilib is already distributed)
- Decal works
I think most of these packages could be added to the lazarus distro within a
year if a seasoned delphier would take up the maintaining. Except maybe kbmmw,
since I don't know how much work the custom variant stuff is.
 

Re:Re: Cross-platform library

Quote

Wouldn't porting part of JVCL3 to Lazarus, as it exists for Delphi, .Net
(JEDI.NET just starting!) and Kylix offers a good start ?

For business apps, we would need at least on Lazarus:
- JvDbGrid
- DbEdits: JvDBComboBox, JvDBSearchComboBox, JvDBDateEdit...
- Edits: JvComboLookup, JvSpinEdit...

We would also need cross-platform data access : Zeos, AnyDAC? when/if it
comes to Lazarus.

My view of linux is a server-side environment.
What I'd like to have is:
- clientdataset/datasetprovider (compatible with actual delphi
clientdataset, at least with XML format as I understand that the binary
format is "not documented")
- soap/webservices implementation (as a mean to communicate between server
and clients)
 

Re:Re: Cross-platform library

"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
Quote
Both Pascal and C++ handle GTK (which has a C level api) by direct
headers, not
wrappers. Double wrapping is unnecessary.
I would use double wrapping to hide the C level api of GTK. What of these
two do you prefer working with (please excuse the c++) ?
static gboolean delete_event( GtkWidget *widget, GdkEvent *event, gpointer
data )
{
return TRUE;
}
static void destroy( GtkWidget *widget, gpointer data )
{
gtk_main_quit ();
}
int main( int argc, char *argv[] )
{
GtkWidget *window;
GtkWidget *button;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (G_OBJECT (window), "delete_event", G_CALLBACK
(delete_event), NULL);
g_signal_connect (G_OBJECT (window), "destroy", G_CALLBACK (destroy),
NULL);
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
button = gtk_button_new_with_label ("Hello World");
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (button);
gtk_widget_show (window);
gtk_main ();
return 0;
}
Or
class JFMyWindow : public JFWindow
{
private:
JFButton *button;
public:
JFMyWindow()
{
button = new JFButton;
AddControl( button );
button->SetText( "Hello World" );
};
}
int main( int argc, char *argv[] )
{
JFMyWindow *MyWindow;
CreateApplication();
ProcessCommandLine( argc, argv );
MyWindow = new JFMyWindow;
Application()->Run();
return 0;
}
Quote
The LCL is the wrapper. (to use GTK and win32). However such wrappers
over
multiple toolkits are easy in theory, and a lot of work in practice.
I can guess. It was bad enough writing a wrapper over Win32 and XWindow.
But I enjoy this, and don't mind working hard.
Jonathan
 

Re:Re: Cross-platform library

On 2005-08-30, Jonathan Benedicto < XXXX@XXXXX.COM >wrote:
Quote
"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>Both Pascal and C++ handle GTK (which has a C level api) by direct
>headers, not
>wrappers. Double wrapping is unnecessary.

I would use double wrapping to hide the C level api of GTK. What of these
two do you prefer working with (please excuse the c++) ?
I would prefer a straight interface from Pascal to C, instead Pascal ->C++ ->C.
The C++ code is an unnecessary complication, and I'll have my classes wrapper in
(Object Pascal).
So:
C ->(fix hdr for C++, external etc) ->C++ wrapper ->C++ program
and
C ->(pas hdr) ->Object Pascal wrapper ->Pascal app.
Quote
>The LCL is the wrapper. (to use GTK and win32). However such wrappers
>over
>multiple toolkits are easy in theory, and a lot of work in practice.

I can guess. It was bad enough writing a wrapper over Win32 and XWindow.
But I enjoy this, and don't mind working hard.
LCL runs for 7 years with multiple devels. One sees a lot of initiatives that start quickly,
with heated debate, but few are alive after an year.
KOL and LCL are the only long term exceptions that I know of. At least the free ones.
I guess one could add Andreas' CLX patches also. While maintenance, and not
entirely free, it is at least free for Kylix/Delphi owners, long term and
beyond the initial stages.
 

Re:Re: Cross-platform library

"Marco van de Voort" < XXXX@XXXXX.COM >wrote in message
Quote
I would prefer a straight interface from Pascal to C, instead Pascal ->
C++ ->C.

The C++ code is an unnecessary complication, and I'll have my classes
wrapper in
(Object Pascal).
I get what you're saying.
Jonathan
 

Re:Re: Cross-platform library

On 2005-08-30, Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
Oliver Feins wrote:

>For business apps, we would need at least on Lazarus:
>- JvDbGrid
>- DbEdits: JvDBComboBox, JvDBSearchComboBox, JvDBDateEdit...
>- Edits: JvComboLookup, JvSpinEdit...
>

One of the problem is this code is all inherited from Delphi classes.
What if you want to change or fix the ancestor class? You can't. It
is copyrighted and you can't use it.

On the other hand if we start with the LCL or and TNT, we have code that
we can do anything we want. Now once you have a good base, then you go
to JVCL and other projects, and adopt the work there to work on top of
your completely open base.
I think the best way would be to the same way as the other projects were
tackled (ICS, Jedi's JCL, Math, Decal and Apilib, Indy is still being
experimented with):
1 simply take a snapshot start and port what you can. Start with the simplest
components that have the simplest demoes. Don't worry too much about
not modifying code, and don't give up on the first bug. Workaround and
contiune testing.
2 Open a line of communication with the JVCL team. See if they can merge general fixes and
friendlyness back.
3 Document problems you encounter, discuss them with FPC and Lazarus teams,
and post concrete bugs to FPC and Lazarus bug repositories. (with concrete,
I mean one feature/aspect per bug, with a compilable program that shows the
bug, not "this doesn't work" and post a 1 MB source attachement, or some code fragment
without context).
Stuff like (2) is often quite simple, and only meant to make the iteration cycle not
to tedious, manual editing wise. Simple things like balancing comments in program headers,
introducing a central includefiles, and adapting the ugliest IFDEF constructs.
Iterate 1-3 a few times (e.g. with a few months inbetween), and usually it
will go better and better. When everything is reasonably fine, try to do a
port where you do as minimal changes as possible, and put more effort into
formatting, being systematic etc. If it is all working, try to get it merged
back into the parent projects main sourcetree.