freenode/#clim - IRC Chatlog
Search
13:51:43
beach
What would one lose if one were to start writing a bunch of desktop components that share the same protocols as (say) Gnome (if that is even practical), as compared to if one where to design fresh protocols adapted to Common Lisp?
13:52:44
beach
Example: could I write a replacement for my workspace manager in Common Lisp, and what would it take?
13:55:38
beach
I am talking about the little thing that lets me have 36 workspaces and have windows attached to each one of them, have the spaces displayed with miniature windows etc. Is that really part of the window manager?
13:56:31
beach
I imagined that thing to work by mapping and unmapping windows without involving the window manager.
13:57:02
jackdaniel
it is an application which may be distributed with a window manager (to visualise workspaces)
13:57:48
jackdaniel
so such "gadget" would be part of a desktop environment. you could write something like that for stumpwm I think - it is programmable from the repl
13:58:09
jackdaniel
so it is just a matter of writing a clim gadget which visualises things and does some automation you want to have
13:59:16
beach
Yeah, I was more interested in replacing only the workspace manager without replacing the window manager. Again, my thinking was wrong.
14:01:15
beach
So it can't be done incrementally? I can't ask someone to write a volume control in Common Lisp that replaces the one in my current toolbar?
14:03:06
jackdaniel
it depends, your toolbar may exhibit api for writing plugins. I have no experience with that
14:04:06
jackdaniel
you may certainly write application which gives you a volume control in common lisp, I'm just not sure if you can add it to the toolbar as a "native" plugin
14:06:01
jackdaniel
toolbar - yes, elements put on a toolbar - not necessarily. it all depends on how the software is written
14:07:09
beach
So perhaps an initial project would be to write a toolbar in Common Lisp, and to design a protocol for adding apps to it?
14:08:54
jackdaniel
I've already mentioned where I would start (from the application whic allows navigating content) - navigating to "workspaces" and "applications" could be a natural extension to it
14:12:32
beach
jackdaniel: I don't want you to spend more time on fixing my ignorance than you already have. You have pointed me in the right direction(s).
14:14:21
jackdaniel
by "I didn't understand what it meant" you mean, that you understand now, or that it is still unclear?
14:16:13
jackdaniel
my base assumption is: CL desktop suite runs from the same Lisp image and desktop is meant for organizing user "content" - files, documents, email
14:17:24
jackdaniel
so if I were writing "desktop in cl" I would write a content inspector/interactor with specialized views for different kind of content
14:17:43
jackdaniel
you could start from a workspace viewer of course, and its "specialized" look would be as of the pane
14:19:23
jackdaniel
so that would be something like a file manager, but the managed content wouldn't be necessarily files (you could organize bookmarks, email and such) with an uniform interface
14:23:12
beach
So the only window manager we currently have that is written in Common Lisp is Stumpwm?
14:29:14
beach
I guess the window manager and the workspace manager are fairly tightly integrated, huh?
14:30:18
dlowe
I always thought that the workspace manager was just something the window manager did by itself
14:30:23
random-nick
there's a wayland compositor written in common lisp: https://github.com/malcolmstill/ulubis
14:31:08
random-nick
but wayland compositors are more complicated, since their Xorg equivalent is Xorg itself and a window manager
14:34:23
random-nick
libwayland is actually just a library for local RPCs, and the wayland specification is a RPC protocol for requesting a window, drawing on that window and getting input
14:35:10
random-nick
which means the compositor has to do everything Xorg does (input handling, graphical output...)
14:42:28
beach
random-nick: I am sure this is all very interesting, but I don't see how it fits in with the desktop stuff I started with.
14:43:26
beach
So, what if on #lisp I suggest "reviving Eclipse" as an independent project? It would be a non-tiling window manager written in Common Lisp.
14:44:33
beach
Perhaps hinting that it could become the basis of a desktop environment written in Common Lisp?
14:45:19
beach
I mean, it is unlikely that there would be any taker, but I could always add it to my list of suggested projects. But I will do that only if it is a reasonable thing to do.
14:51:00
beach
jackdaniel: OK, so nothing obviously wrong about it as far as you can see. I'll think about it some more and maybe suggest it.
15:00:19
beach
I see. And a window manager seems to me that it must be very dependent on the display server. Right?
15:03:08
jackdaniel
someone interested in fooling around could make application-frame-pane monsteriosity, subclass grid-pane composite pane, add window decorations and pretend, that full screen "top-level application frame" is a window manager
15:09:33
djeis[m]
Wayland, for example, is actually little more than a communication protocol between a display server and the programs wanting to draw on said display.
15:10:32
djeis[m]
The equivalent of the window manager in a wayland system actually replaces X11 entirely- it talks directly to the graphics card and has full control over actually painting all of the windows on screen.
15:11:14
djeis[m]
It also recieves the input events from the kernel and passes them along to applications using the wayland protocol.
15:12:06
djeis[m]
Since it actually is what paints the windows on the display it's often called a wayland compositor instead of a window manager.
15:16:51
djeis[m]
Also, the window manager actually is what provides multiple desktops/workspaces in an X11 environment, there's just a protocol by which other applications can ask the window manager what windows are on which workspaces and to switch workspaces. It is just mapping/unmapping windows internally tho, the window manager just has to orchestrate it because of the way other protocols for controlling a window manager work.
15:18:09
djeis[m]
Like the list of minimized applications in a taskbar- said taskbar can actually be implemented by a 3rd party program just talking to the window manager, but if the window manager isn't what manages workspaces then that taskbar has no good way to restrict its list of tasks to just those on the current workspace.
20:32:19
scymtym
i will probably have a pull request for the encapsulation and INDENTING-OUTPUT-STREAM fixes (including a new test) in a bit
21:34:42
jackdaniel
I've changed the margin conception a little, but indenting-output won't change much in it (unless there are good reasons for that)
21:35:11
jackdaniel
in essence instead of creating a new class I repurpose margin abstraction (for filling-output too)
1:00:15
eschatologist
Mezzano uses neither X11 nor Wayland. It just talks to a framebuffer and does software compositing.
1:02:21
eschatologist
What Wayland calls a “compositor” is what NeXT/Apple calls a “window server.” It provides drawing surfaces to applications, composites those surfaces on screen (really, manages the GPU doing so), receives input from HI devices, and dispatches that input to the appropriate application(s).