[fpc-devel] Lazarus: A new widgest set

[Michael Schnell]

> It depends what effort you plan to invest into testing and debugging. ;-)
> Missing pieces:
> - Documentation.
> - SSL on win32.
> - Consistent error handling and error recovery.
> - Pascalscript import units for complete MSEgui.
> - MSEifi webbrowser plugin.
> - Some convenience tools in MSEide for MSEifi project handling.
>   
As I pointed out, we (on the long run) have to do two projects which 
include remote a GUI.

(1) Server done in Delphi running on a dedicated PC, no chance to 
install any non-standard software on the "Terminal" or use any 
non-standard protocols
(2) Server is an embedded device, software done in Free Pascal, there 
can be our software on the "Terminal",  protocol: any kind of TCP/IP.

I feel that MSEifi might help doing (2), as it needs software (at least 
a dll for the plugin) installed on the Terminal.

So I suppose I don't need SSL, Pascalscript and a browser plugin.

Regarding convenience tools: This project is not going to be started 
soon. It's an add-on for a Linux based embedded device that we are 
planning. First the hardware and the main function is to be crafted, 
this add-on will be the second step. And this step includes porting the 
Free Pascal compiler to the NIOS CPU (unless this is done by somebody 
else before we can start).

Before I knew about MSEifi I intended to attach the remote GUI on a 
"per-control" base via a propriety protocol (e.g. using RemObjects). But 
this would imply handling any program done that way individually, which 
of course is not really desirable. Do you think MSEifi will help ?

An additional consideration is to provide a miniature remote GUI for the 
primary firmware (done in ANSI C) of the device in a way consistent with 
the GUI planned for the future Pascal add-on. Do you think MSEifi will 
help with that ?
> MSEide is GPL, MSEgui and MSEifi use the same modified LGPL license as the FPC 
> RTL. The code is on Sourceforge:
> http://sourceforge.net/svn/?group_id=165409
>   
Sounds good !

During my investigations on open source software licenses I heard about 
some drawbacks when using LGPL code in embedded devices (it might be 
problematic to provide the requested support for the users to upgrade to 
a new version of the LGPL'ed libraries when statically linking, which is 
why sometimes it's recommended not to use the µCLinux version of glibc). 
But I do think this should be solvable, as I don't think it's intended 
by the FSF and the individual copyright holders to prevent the use of 
LGPL'ed code in embedded devices, only because they don't have an MMU 
and thus don't support .so's.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20080229/b575e262/attachment.html>