freenode/#clim - IRC Chatlog
Search
4:00:17
loke
Bascially, there is noterally no way you can have two ACCEPT forms working at the same time
4:00:56
loke
Unless they are spearate threads, but then you can't exchange objects between them, which kinda defeats the entire purpose.
4:01:57
loke
beach: because when you click on an object that belongs to one frame, it gets processed by the command loop that is running in said frame.
4:02:25
loke
What you'd want is to ACCEPT an object in one frame and be able to click on another object in a different frame
4:03:33
beach
I think there are ways to make that work. I have been thinking about it in the past, simply because some day I would want several applications running in the same OS process and I want them to be able to exchange data.
4:04:26
loke
beach: There may be. As I said, it may be possible to have a protocol that defines how one active ACCEPT hands over focus to another. However, that would require one of the following:
4:08:31
loke
I want to create a much smarter completion mechamism. Today I simply pop up a menu using FRAME-MANAGER-MENU-CHOOSE. This works, but is very limited.
4:09:03
loke
So I started building a new interface based on the same underlying building blocks that F-M-M-C uses.
4:09:49
loke
Turns out, that in order to add keyboard control to this new menu, I need to have my own loop that calls READ-GESTURE.
4:13:11
loke
It's not too bad when all you want to do is select a completion candidate, but since I also want the window to display the documentation for the the selected option, and you might want to keep it open after selection...
4:14:15
loke
This is the kind of stuff that is absolutely trivial in a GUI system such as Java or GTK, but CLIM makes it incredibly cumbersome. One thing McCLIM definitely needs are new facilities to make this kind of event-driven UI design possible without too much work.
4:16:44
beach
I think that would be a good idea for another reason as well, namely that there are people who are used to such traditional GUI design, and they would have a much easier time converting to McCLIM then.
4:20:20
loke
Developing a CLIM application is somewhat dizzying. :-) It's a crazy mix of almost magic future-tech, and at the same time the inability to handle basic things even the simplest GUI frameworks can do.
4:27:33
loke
beach: There are things that are much better in CLIM, and others that are not. It's like everything I guess, a give and take.
4:28:28
beach
But I do think it would be good to use the basis if McCLIM (I guess Silica) to provide features that are more often seen in other GUI toolkits.
4:28:32
loke
A lot of the imperativeness issues could be worked around using threads, but none of McCLIM is thread safe.
4:29:09
loke
beach: But the main issue, I think is that CLIM doesn't have a central single command loop, as far as I know.
4:29:34
loke
The idea in Genera I think is that that single command/event loop was actually provided by the single REPL
4:30:58
loke
I don't know if I understand things fully, but I believe that if someone wanted to build Climaxima on Genera, they would simply have a way to type Maxima expressions in the same REPL as where you type your Lisp.
4:32:49
loke
Which is why you have the concept of application frames, where each frame has their own command loops, but then things like object selection between frames becomes unnatural. You have to build the infrastructure to support that yourself.
4:34:12
loke
I mean it in the liternal sense, as in “the way things are often done today”. There is no value judgement in it at all.
4:34:13
beach
Not quite, no, because I have no experience with "modern" GUI toolkits, and most of the time when people use "modern" software, it is actually worse than what we already know.
4:34:40
beach
I would be much more inclined to find a way to have the threads of different applications communicate.