Write the GUI in CL with McCLIM

[daninus14]

DISCLAIMER: I am not associated with McCLIM in any way, nor am I writing any GUIs in CL. I just think this would be for the best both of Nyxt, lem, and the CL ecosystem.

Hi, I'm adding this here as well as in Nyxt ##3346

Since lem is developing a GUI, I think it would it make sense to develop it in CL

• This will avoid tons of issues dealing with FFIs
• Performance should be much better if it's native CL than running with FFIs
• This will also contribute tremendously to the CL ecosystem

Describe your proposed change:

• Collaborate with the McCLIM https://mcclim.common-lisp.dev/involve development
• Develop a way to provide themes for the widgets to make it easy to change the look of an application by simply selecting another theme
• I am suggesting this as well to the Nyxt developers

Why do you believe this to be an improvement?

While McCLIM is not perfect and not finished, in the end, it will probably be much easier to continue development in any project based on it than having to deal with FFIs. Even if it's not electron because of the security vulnerabilities and slowness and other issues, and you decide to go with another toolkit, there will be technical costs in dealing with FFIs.

Whatever other issues exist with McCLIM, by Nyxt and lem developers contributing, the improvement will probably be tremendous for the CL community.

Additional context/User story:

I am not associated with McCLIM in any way, nor am I writing any GUIs in CL. I just think this would be for the best both of Nyxt, lem, and the CL ecosystem.

Contact McCLIM #clim @ libera.chat jackdaniel is currently in charge of the project and it is actively maintained.

I am sure there are tons of people that know more about this than I do. I know there will be a lot of people reading this who will think "I've used whatever CL GUI libraries and they #&!%", but that's the point. They may not be great, but they are advanced enough that with a serious contribution from active lispers involved in GUI development, they will no longer be bad. Furthermore, the McCLIM project is not only actively being developed, but it's open to contributions, so this would be a collaboration project rather than Nyxt simply being a client of some third party library. This will give you say and power in how to improve the library so that it suits your needs and is convenient to use.

[daninus14]

Just found this out: https://codeberg.org/McCLIM/McCLIM/issues/1345

Which looks like there is/was already an attempt at doing this. Adding for reference

@Sasanidas

[daninus14]

Just a clarification

The Goal of this proposal is to write the GUI using McCLIM.

The collaboration with McCLIM would probably be in terms of contributing bug fixes, posting issues, and making requests as you develop your application.

That in itself will probably benefit McCLIM greatly, and maybe if there are features missing that you discover you need as you are developing, you can probably also code them and push them as PR. This seems much easier than dealing with the FFIs.

[garlic0x1]

There are already two GUIs for Lem: SDL2 and Electron. If someone wanted to make another it might be used if it is good 🤷‍♂️

[Sasanidas]

Indeed, I'm quite interested in the way that McCLIM works and I would love to have Lem with that front-end technology. The problem as with everything else in life/software is time. I don't think it's a priority for the project, even tho in this case a very motivated individual can make it work quite decently.

We only need this individual 🥳

[daninus14]

Ok, thanks for replying and considering it! 😄

[aykaramba]

How does McClim handle hardware acceleration? Anyway, any chance you want to take on the #1345 above and see how far you get with that? Even if a proof of concept can be seen it would be cool.

[daninus14]

How does McClim handle hardware acceleration?

Not sure, I just pinged the author in IRC

Anyway, any chance you want to take on the #1345 above and see how far you get with that? Even if a proof of concept can be seen it would be cool.

@Sasanidas How much progress did you make in your attempt above?

I personally don't have much time now. I suggested this because I thought the collaboration may be beneficial. That said, I wouldn't say that I cannot contribute in the future, it's just that now is not a good time. However, if it's not really so complicated, maybe that can change things for at least a proof of concept.

Again, I know nothing about the lem code base or the McCLIM code base, so I'm probably the least qualified of everyone here for this, and it would probably take me the most time... So it's probably not something I can tackle in the next couple of months

[dkochmanski]

Since I've been called out on IRC I'll comment on the hardware acceleration bit - on x11 backend rendering is accelerated by the server (no GPU access), on framebuffer backend everything is rendered with cl-vectors (no hardware acceleration). All other backends are experimental so there's no point in advertising them.

Regarding McCLIM frontend for LEM - if anyone is interested in working on that, then I'll be happy to assist with CLIM-specific questions. That said I don't think that calling for others to write a frontend, without time to do it yourself, has a slim chance of success - unless someone is paid, they must be internally driven to do something.

Note, that it was suggested that I'm McCLIM author and that is not true, I'm currently leading the development, but there are many prominent hackers who created it.

[cnickh]

I have a few specific questions about the internals of Lem. Mainly I'm confused about the proper format for events sent to Lem and what some of the drawing-object's are supposed to represent (like eol-cursor-object or extend-to-eol-object). I haven't been able to get a good understanding looking through source.

Also would appreciate any input on what I've done so far... currently working on a fork of lem here all the work is in frontends/clim. If anyone can spare a few minutes to chat that'd be great.

I've been taking a stab at this, as a personal project... Hoping to get more familiar with CLIM and Lisp.

[Sasanidas]

Thanks a lot for the effort! Ping @cxxxr as he is the expert on the internals of Lem 👍
(I'll keep an eye on the fork)

[cnickh]

@Sasanidas

Not sure the best place to hit @cxxxr... Going to post a series of questions here for visibility, feel no obligation to reply fast or at all... been doing what I can to answer these on my own.

• What lem-if functions have return values that are used other than the obvious get methods?

• Should input events always be sent one at a time or can user input be sent as a string with more than one char?

• I have seen the other lem frontends send to lem both actual pixel coords and character coords. What should be returned from get methods? What should be expected in set/create methods?

• I noticed that the x coord passed to render-line seems to always be zero. Am I missing something? It doesn't seem to be needed as far as I can tell.

• Is there anything I should know about happening to the view returned from make-view other than simply storing a reference?

• Sometimes I see update-display get called multiple times seemingly unnecessarily. Is there something I can do to prevent this? I also notice my code changes can cause a recursive call to redraw-display. What could I be doing to cause this/how can it be prevented?

[aykaramba]

Apologies for the noise, I'm a noob and cannot help. But, I wanted to drop in and let you know how excited I am about the possibility of using an McClim based front end. I have switched to LEMsdl exclusively for my day to day editing and learning and it works great. I would love to experience an McClim based front end regardless of the state it is in.

Thank you for the inspiration.

[cxxxr]

I am very glad that you are interested in lem.
I've tried to answer your questions, but please let me know if there are any deficiencies in my answers.

What lem-if functions have return values that are used other than the obvious get methods?

There are several.
The following functions use return values.

• lem-if:display-width
• lem-if:display-height
• lem-if:display-title
• lem-if:display-fullscreen-p
• lem-if:make-view
• lem-if:view-width
• lem-if:view-height
• lem-if:clipboard-paste
• lem-if:object-width
• lem-if:object-height

Should input events always be sent one at a time or can user input be sent as a string with more than one char?

When the user enters a key, the frontend converts the input to lem:key and sends it to the editor thread using send-event.

I have seen the other lem frontends send to lem both actual pixel coords and character coords. What should be returned from get methods? What should be expected in set/create methods?

If it is necessary to handle characters (e.g. ncurses), 1 is returned,
when it is handled in pixel units (e.g. sdl2), the character width is returned.

I noticed that the x coord passed to render-line seems to always be zero. Am I missing something? It doesn't seem to be needed as far as I can tell.

You are probably right.

Is there anything I should know about happening to the view returned from make-view other than simply storing a reference?

I'm not sure, it depends on the implementation of each front-end.

Sometimes I see update-display get called multiple times seemingly unnecessarily. Is there something I can do to prevent this? I also notice my code changes can cause a recursive call to redraw-display. What could I be doing to cause this/how can it be prevented?

This is because the optimization of the drawing of lem is insufficient.
For example, after the state of the editor has changed due to the execution of a timer, it may be necessary to redraw the screen, so it is always redrawn.

[ioolkos]

@cnickh I compiled your fork with make clim, and after minor adaptations it works for me! Awesome :)

I had to adapt the resources path for the PNGs, and I added (setf MCCLIM-TRUETYPE::*DPI* 160) to clim.lisp file. (issue with my high screen resolution).
Is there still stuff missing in the implementation?

[cnickh]

Hey @ioolkos great to hear you were able to build it.

So, there are still a few things not working quite right yet. I'll list what I've noticed below... but if you or anyone else finds something else broken please let me know and I'll add it to the list. This excludes some code clean up still needed and improvements to performance I have in mind.

• Like you mentioned the file path not working 100% of the time.

• Lem has the ability to display image files, I have not yet added this feature.

• The folder icons aren't displayed with a transparent background.

• I have yet to test forwarding mouse input to lem.

• I've noticed the sdl2 version highlights the line where the cursor is. I have not done this with clim, I am not sure if this should be handled entirely by the frontend or if lem will update the background for that line. that's a question for @cxxxr.

[ioolkos]

Thanks for your list with open points. I haven't noticed any other broken things so far but I guess it takes some more regular use to discover them. Looking forward to testing the mouse events.

[rpx99]

Can you make a short video and put it on YouTube or the discord channel how it looks like with mcclim?

[ioolkos]

@rpx99 it pretty much looks the same. @cnickh that's expected, right? it should not really look different with McCLIM?

[rpx99]

I am trying to understand pros / cons of McClim vs sdl2. Is it more portable / performant than sdl2? Can somebody explain or summarize this, please?

@daninus14 Did you mean McClim here ?

Even if it's not electron because of the security vulnerabilities and slowness and other issues, and you decide to go with another toolkit, there will be technical costs in dealing with FFIs.

[daninus14]

Hi, McCLIM is Common Lisp so there's no Foreign Function Interface

[rpx99]

Yes, thanks - but I wonder why we did not use it in the first place...the sdl2 approach doesn't seem to be natural because it depends on OS specifics (in which users ran into some problems with on arch, OpenBSD,...).

So the McClim frontend seems to be straight forward?

What security issues did you mean btw...

[rpx99]

I mean all you need for this is sbcl or another implementation? Or does it use sdl2 behind the scenes, too?

https://codeberg.org/McCLIM/McCLIM/src/branch/backend-sdl2/Backends/SDL2/README.org

[daninus14]

I don't know. That's probably a question for the contributors of lem like @Sasanidas or @cxxxr or @garlic0x1

[rpx99]

@cnickh Tried the latest version with latest fixes. Works - I like it!

[ioolkos]

For me, just shows the editor window for a second, then crashes/disappears.

@cnickh maybe you can enable issues on your fork, to provide feedback. Or do you prefer us to wait a bit more before we "test"? would understand :)

[aykaramba]

How is this compiled? Make clim tells me "qlot cannot be found" and I don't see any issues in the make file.

Suggestions?

[rpx99]

Maybe try pulling latest git again. Before this I was having this, too. Am 30. Juli 2024, 16:29, um 16:29, ioolkos ***@***.***> schrieb:

…

For me, just shows the editor window for a second, then crashes/disappears. @cnickh maybe you can enable issues on your fork, to provide feedback. Or do you prefer us to wait a bit more before we "test"? would understand :) -- Reply to this email directly or view it on GitHub: #1311 (reply in thread) You are receiving this because you were mentioned. Message ID: ***@***.***>

[rpx99]

Think you need to export the QLOT variable pointing to where it is located. It is shown at the end of the install process if I remember correctly https://github.com/fukamachi/qlot?tab=readme-ov-file#installation Another possibility (without make) is just to start sbcl, do a (ql:quickload :lem-clim) and after it loaded everything start lem with (lem:lem) Am 30. Juli 2024, 18:57, um 18:57, aykaramba ***@***.***> schrieb:

…

How is this compiled? Make clim tells me "qlot cannot be found" and I don't see any issues in the make file. Suggestions? -- Reply to this email directly or view it on GitHub: #1311 (reply in thread) You are receiving this because you were mentioned. Message ID: ***@***.***>

[aykaramba]

Aha! That was it. I had qlot installed but did not realize what it was. Once installed, the binary is usually in ~/.qlot/bin/qlot so added that path and I was able to:

• sbcl
• (load "build-clim.lisp")

Okay, that is fun! Thank you.

[cnickh]

Hey, thought I'd update.

I have opened issues on the repo, so you don't have to clutter up this main repo. I have implemented what I listed above and fixed some issues that was causing crashes, but performance is still terrible compared to sdl2.

[daninus14]

Interesting, that's probably a good opportunity to ask the fold coding McCLIM for guidance or let them know so that they can improve their project (assuming it's not related to the way lem interacts with sdl2 and McCLIM)