While demonstrating objects to kids in my computer programming classes for kids this summer, I wrote a Scrabble board game control. It's on Github right now released under the LGPL.

Here is a brief video demonstration:

https://cache.getlazarus.org/videos/scrabble.mp4

The Github page for this free control is here:

https://github.com/sysrpl/Lazarus.Scrabble

Also, I found a bug with the LCL that prevents arrow key processing on Gtk2 (and maybe Gtk3) which I've written up here:

https://bugs.freepascal.org/view.php?id=35942
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190809/5a427bf1/attachment.html>

Nice job ! As a Scrabble fan, I'll port it to pas2js, another playful demo :-)

Michael.

Preferred way is to add a patch for those lines. You call your solution a hack, but is the context of gtk2 this is ok.

About the mess you were talking about in your presentation.... Note that gtk1 was the first widgetset used by Lazarus. At that time there was no idea how to solve things and having one generic seemed OK at that time. What you see now is alread a reduced splitup handler :)

The windows widgetset was modeled after gtk1 and when gtk2 came we had the illusion that we could support gtk1 and gtk2 from one codebase. This became a mess and they were splitted.

At that time it became clear that this wasn't the way the get forward and when I started with the Carbon interface I decided to move event handlers to the specific widgets. This design is later used for other widgetsets. The gtk and windows widgetset would require a complete rewrite. Besides that I wasn't really happy with the new design. It never came that far to.

Marc

Marc,

I can completely understand how it evolved, and early on the features of both the Free Pascal language, and the way the LCL library were to be adapted to multiple platforms became more clear. Thanks for your hard work.

I've thought about the way the LCL is structured to handle many platforms for quite some time now, and if it were remade I'd strongly prefer it if every platform and native control were implemented through a set of well defined platform agnostic interfaces. Then each platform would adhere to that interface in order to implement it in classes such as TGtk2Canvas, TGtk2Window, and TGtk2WindowManager. Of course this would never happen, as it would mean a complete rewrite of everything, but perhaps someday someone might want to remake a new non Delphi compatible library from scratch for FPC and carry forward with this idea.

For example:

ICanvas = interface
  function MoveTo(X, Y: Integer): Boolean;
  function LineTo(X, Y: Integer): Boolean;
  ...
end;
IWindow = interface
  function Show: Boolean;
  function Hide: Boolean;
  function GetBounds(out Rect: TRect): Boolean;
  function SetBounds(const Rect: TRect): Boolean;
  function GetText(out S: string): Boolean;
  function SetText(out S: string): Boolean;
  ...
end;
IWindowManager = interface
  function WindowCreate(const Params: TWindowParams; out W: IWindow):
Boolean;
  function WindowDestroy(W: IWindow): Boolean;
  function BringToFront(Window: IWindow): Boolean;
  function SendToBack(Window: IWindow): Boolean;
  function GetCursorPos(out P: TPoint): Boolean;
  function SetCursorPos(const P: TPoint): Boolean;
  ...
end;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190809/b1c33863/attachment.html>

Thats what the WSWidgetClasses more or less tried to do. But even with this approach you may encounter cases that for a given widgetset one interface has to implemented partly in one class and partly in another.

Another problem with interfaces I fear is is code size. My feeling says that you need all implementation classes in your exe. I've not experimented with it.

Marc

The WS classes are very difficult to work with IMO. I've used them and they are just messy, as in difficult and not exactly straight forward or intuitive. I'd have to look them over again to put my finger on exactly what's hard to use about them, but I distinctly remember having unnecessary trouble with them. With regards to code size I believe the way it works with WS classes and how it could only work with static linking is to make use of defines and conditional uses that is hopefully limited to only one place.

The way I image interfaces working is that they serve as contracts. One master library unit file would define the interfaces which represent the entirety of every function of a window manager. That is managing windows, handling the mouse, keyboard, painting, and some common ideas such as image lists, canvas, fonts, printing, then a platform implementor writes concrete implementations of those. Native control interfaces for widgets such as TEdit, TButton, TTreeView, TPageControl would be independent interfaces defined in a cross platform control interface unit, but registered by name with the window management so that their function could be loaded by matching a window class name in the Params of WindowManager.WindowCreate().

Anyhow, to change anything now would mean a complete rewrite and at this point it would be a huge undertaking to say the least. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190809/9ceeace4/attachment.html>

Anthony Walter wrote

but perhaps someday someone might want to remake a new non Delphi compatible library from scratch for FPC and carry forward with this idea.

Such libraries already exist. eg: fpGUI Toolkit and MSEide+MSEgui. Feel free to experiment with those. :-)

Regards,
Graeme

Anthony Walter wrote

Here is a brief video demonstration:

I know nothing about Scrabble, but as a seasoned visual component developer I can see a lot of effort went into that. Well done!

Regards,
Graeme