I have been experimenting with the grid control of a Common Lisp
implementation on a Windows platform and ran into some problems. I
experienced this type of problems before with other products. In general
the problem is that the GUI library is a wrapper with some limitations:
- it doesn't completely look like Windows;
- it doesn't offer the full functionality of Windows;
- it is outdated when a new version of Windows ships and
- it is difficult to add the unsupported functionality.
I think the cause of the problem is that such GUI libraries shield you
from the Windows interface. At first this seems an advantage, but when
you run into the limitations of the library it becomes a problem.
This made me wonder whether a different approach is possible. Wouldn't
it be possible to construct the user interface in for example Visual
Basic and let this Visual Basic application call some Lisp
implementation? This gives full access to the Windows funcionality (be
it in an annoying lanuage) for the GUI while the remainder can be done
in Lisp.
Does anybody have ideas or experience with such a solution?
Paul
Paul,
I'm assuming that you're using Allegro CL because you refer to a grid
widget. Unfortuneatly, I don't have any practical experience with ACL
or VB, so I am unable to assist specifically.
I do have experience with Lispworks's CAPI. The library is a little
bit underdocumented, but it's not a big deal to make use of it. I
have found that the constraints have lead me to use a spare, muted
design for my GUIs.
Forgive me for giving unsolicited advice (I am unsure of the interface
problems that you may be facing), but I sincerely think it is better
to make use of existing (and quite complete) features rather than
adding (perhaps) gratuitious complexity in the form of a VB front.
I was also a little annoyed with some obstacles in CAPI a few months
ago, but then I read this page http://www.iarchitect.com/mshame.htm
(sorry, it uses frames so you have to click "Tabbed Dialogs" and
search for multiedit) and I used the suggested conversion from tabbed
dialogs to list-panel-property sheets to significantly reduce GUI
complexity. Perhaps, you should ask around your firm for suggested
GUI alternatives. Once you write the GUI in VB, you lose the ability
(I'm assuming) to dynamically patch and update your GUI code.
Rand
The two I have worked with (ACL and MCL) provide (1) pretty thin
wrappers and of course (2) an FFI. The latter lets you work with the
host OS directly putting up native widgets, which work because of the
former, ie, you really are working with the host OS GUI system.
But you say things do not look like Windows and that new Win versions
break your code, so maybe I am missing something.
Anyway, the FFI is there, so just get a good Win32 book and knock
yourself out.
As for using VB to provide a front end to a Lisp engine... now /that/
sounds like work. But if you are already a VB guru and you do not need a
snazzy dynamic interface, it might work. I have no experience with that,
but I have heard that VB is a huge pain if it turns out you need
behavior other than what VB provides by default.
If you have to do some work, figure out how to use FFI to work directly
with Windows, then the world is your oyster. VB will be death by a
thousand cuts, and your toil will never end.
kenny
clinisys
Paul wrote:
> I have been experimenting with the grid control of a Common Lisp
> implementation on a Windows platform and ran into some problems. I
> experienced this type of problems before with other products. In general
> the problem is that the GUI library is a wrapper with some limitations:
> - it doesn't completely look like Windows;
> - it doesn't offer the full functionality of Windows;
> - it is outdated when a new version of Windows ships and
> - it is difficult to add the unsupported functionality.
>
> I think the cause of the problem is that such GUI libraries shield you
> from the Windows interface. At first this seems an advantage, but when
> you run into the limitations of the library it becomes a problem.
>
> This made me wonder whether a different approach is possible. Wouldn't
> it be possible to construct the user interface in for example Visual
> Basic and let this Visual Basic application call some Lisp
> implementation? This gives full access to the Windows funcionality (be
> it in an annoying lanuage) for the GUI while the remainder can be done
> in Lisp.
>
> Does anybody have ideas or experience with such a solution?
>
> Paul
>
Kenny Tilton wrote:
>As for using VB to provide a front end to a Lisp engine... now /that/
>sounds like work. But if you are already a VB guru and you do not need a
>snazzy dynamic interface, it might work. I have no experience with that,
>but I have heard that VB is a huge pain if it turns out you need
>behavior other than what VB provides by default.
It might not be that bad. I am working on a project where we have decided to go with VB UI components. It's a hard one to fight as the components are numerous and free. We use Corba to connect to the business logic. There is a rather neat little Orb for Vb (VbOrb - you can find it on the web).
You must be disciplined not to let business logic creep into the UI.
Mind you, some of the code you have to write to make VB components work is sickening. But you can then deploy in browsers as ActiveX or whatever its called.
"Paul" <········@hotmail.com> wrote
...
>In general
> the problem is that the GUI library is a wrapper with some limitations:
> - it doesn't completely look like Windows;
> - it doesn't offer the full functionality of Windows;
> - it is outdated when a new version of Windows ships and
> - it is difficult to add the unsupported functionality.
>
> I think the cause of the problem is that such GUI libraries shield you
> from the Windows interface. At first this seems an advantage, but when
> you run into the limitations of the library it becomes a problem.
>
> This made me wonder whether a different approach is possible. Wouldn't
> it be possible to construct the user interface in for example Visual
> Basic and let this Visual Basic application call some Lisp
> implementation? This gives full access to the Windows funcionality (be
> it in an annoying lanuage) for the GUI while the remainder can be done
> in Lisp.
>
> Does anybody have ideas or experience with such a solution?
I generally use the FLI/FFI to directly call the Win32 API.
That way you can build the win32 application you want with the all the
functionalities you want. (controls, OpenGL, etc.)
I think that Common Lisp + Win32 API is far superior to the MFC or other
Win32 frameworks. The before/around/after method combinaisons are really
useful here.
Now I tend to use IE as an interface rather than Win32 when I don't need
OpenGL.
Another possibility would be to make a Web service in Lisp. You would get
the added benefit of being buzzword compliant ;-)
Marc