freenode/#clim - IRC Chatlog
Search
4:21:03
bugrum
clim-standard seems to be broken on CCL on Mac OS X (I haven't tried ccl on Linux so I don't know if this works there). When I try to load :clim-examples I receive the following error: "Unbound variable: XLIB::+RR-CONFIG-STATUS+". It seems that clim-examples expects an X server running
4:23:24
bugrum
but before submitting my pull request, I thought I should try loading McCLIM proper with it
4:25:11
nyef``
Stale CLX. I had that exact error message, and was told to (QL:UPDATE-ALL-DISTS) to clear it.
4:27:53
nyef``
Yup. Missing EVAL-WHEN on a DEFCONSTANT. SBCL evaluates DEFCONSTANTs at compile-time, CCL doesn't.
4:29:23
nyef``
Vulnerable window in terms of CLX versions is a month and a half to two months. (20170830 is not affected, 20171019 is, 20171023 has it fixed.)
4:34:16
bugrum
well the good news beagle is loading... Now comes the fun part: Objective-C error :-\
4:35:52
bugrum
nyef``: Originally, I was thinking of implementing a backend in Qt (since I'm familiar with Qt), but that's adding Qt dependency
4:36:52
bugrum
then I thought maybe an SDL2 backend since SDL2 is C-based, is a minimal C wrapper, and won't provide too much overhead. Plus it's only a single so, dll, or framework on each platform
4:37:29
bugrum
but looking into the CLX backend, there are comments that only clim-backend needs to be implemented
4:38:45
bugrum
of course, you are correct that there is stuff a more complete UI toolkit will provide for free
4:41:32
bugrum
for the SDL2 idea, I did find a UI toolkit built entirely on SDL2 but I don't know heavyweight it is (it's a port of nanogui): https://github.com/dalerank/nanogui-sdl
4:43:38
bugrum
of course, this was all before I decided to take a step back and see how quickly one of the other backends that is CLX can be revived :-P
5:46:34
red-dot
Interesting, that SDL idea really. Seems simple enough (as mentioned, a single shared lib), multi-platform, device support, and there are already CL bindings for the API.
6:12:50
bugrum
I just don't know if clim-backend is the only package that needs reimplementing (still am going through the comments)
6:13:32
bugrum
however as nyef`` rightfully pointed SDL2 is a proper UI toolkit, so just it by itself may require a bit more work
6:39:46
jackdaniel
what you need to do with SDL is to glue input with event abstractions and plug rendering to sdl (clx-fb is example of working with framebuffer)
6:40:48
jackdaniel
SDL is my favourite choice for custom backend, because while it is not UI toolkit itself, it is a perfect vehicle for McCLIM (which *is* toolkit) if we want something portable across windows, linux, osx and android
6:41:50
jackdaniel
whenever we want it or not, if we want to "talk" with foreign windowing servers, we have to be able to talk with foreign code - windows is c++, android is java/c++, osx is obj-c, unix is c
6:42:23
jackdaniel
we may pile abstraction on top of these languages, but that won't change the fact, that there is foreign bit. only exempt is mezzano, which is lisp os
6:44:17
beach
As long as there is a choice with a minimal amount of foreign code, I am fine with it. I would hate to HAVE TO depend on foreign code too much.
6:45:18
jackdaniel
yes, I'm talking explicitly about backend stuff (referring to the discussion earlier)
6:54:31
bugrum
The more I think about it, the more I think it's doable. However, and this shows my limited understanding of McCLIm
6:55:12
bugrum
meaning the host OS's (or the backend in question) is ultimately responsible for providing basic widgets
6:56:18
jackdaniel
McCLIM backends may be three-fold: 1. you provide methods for everything (in this scenario backend is responsible for providing i.e basic widgets etc)
6:56:50
jackdaniel
2. you provide methods for rendering and gathering input (in this scenario backend is responsible for IO, but McCLIM draws widgets and handles logic – that's how CLX backend works)
6:57:12
jackdaniel
3. you provide only methods for rendering (in this case you have "draw-only" backend, like rendering to pdf, png etc)
6:58:04
bugrum
jackdaniel: based on this categorization, I'm guessing an SDL2 backend would fall into category 2
6:58:05
jackdaniel
that said, we don't have backend working like in point 1., I'm only saying that CLIM specification is defined that way, so you *can* write it that way
6:58:55
jackdaniel
and Qt could fall in 1. or 2. - depends how much you want to augument with "native QT" things
6:59:56
bugrum
I only suggested Qt because I am familiar with the library quite well and enjoyed using it when I had to. QML for example provides some nice fluid animation features that would be cool if brought into McCLIM
7:00:42
jackdaniel
if you like Qt/QML, you may be also interested in EQL5 project (ECL embedded in Qt)
7:04:04
bugrum
jackdaniel: I will check out EQL5. Might be useful for other projects I'm working on.
7:05:22
bugrum
the only thing I guess I'm wondering is a new backend just a matter of implementing the clim-backend package as commented in CLX?
7:09:17
bugrum
I noticed some functions were refactored out from the climi package over to clim-standard
7:09:56
bugrum
Once I fixed those, and then also fixed an issue with define-objc-method not being found (this is on CCL)
7:11:44
bugrum
btw, by fixing those issues, I really mean adding a new import-from clause in the defpackage
7:18:54
bugrum
jackdaniel: okay, I'm going to deal with these issues tomorrow. going to get some shuteye. Thanks for your help
7:30:30
red-dot
Just checking in again. If bugrum wants to try a SDL2 backend, I'd be willing to sponsor some of the work, provided it was done with CLIM-TOS. I realise McCLIM is farther ahead, but I am forbidden to touch anything with an encumbered license, even if that means going the longer and more expensive route.
7:32:47
jackdaniel
red-dot: I've fixed CLX to work with CCL better (what improves CLIM-TOS experience a lot), you may want to try newest quicklisp dist, or directly from sharplispers repository
7:42:18
jackdaniel
as of sdl2 backend, if it is done in separate repository, it may be shared between both implementations (some extra glue-code may be necessary)
7:43:02
loke
jackdaniel: I recall looking at the old GTK backend, but it was impossible for me to get it to work