freenode/#clim - IRC Chatlog
Search
11:05:46
loke
Just one more thing on that point: The reason I noticed it was that I had put a breakpoint in the text selection code to look at some variables on the stack, and I realised I had stopped inside the main event loop rather than the application thread.
11:06:22
loke
But I noted that that function did mess around with the actual text in the stream pane, which suggests there is a concurrency issue there.
13:09:02
beach
After I installed Ubuntu 18.04 on my new computer, and I was disappointed with the "desktop", loke recommended Cinnamon, which I have been using ever since. But now I am wondering what the components of such a "desktop" are, and how one would go about writing those components in Common Lisp, perhaps using McCLIM. Any ideas?
13:09:34
beach
Such a "desktop" would be useful on GNU/Linux, of course, but also an essential part of an ultimate CLOSOS system.
13:13:52
jackdaniel
I would start with a content manager (be it files, bookmarks or whatever) and specialize gradually on email, documents, pictures (and that specialized viewers would be "desktop applications")
13:15:26
beach
I am thinking of the desktop as the thing that manages the tool bar, the window decorations, etc.
13:17:01
jackdaniel
for instance stumpwm is a winow manager which provides some toolbars, interaction etc
13:17:29
jackdaniel
on the other hand cinammon is a desktop environment: it window manager *and* applications giving you reasonable workspace
13:19:45
jackdaniel
window manager of course (with toolbars etc, note that the very first thing you have asked: /where/ will be that content manager)
13:20:55
jackdaniel
regarding else: setting manager to configure said wm, terminal emulator, mail reader, file manager, web browser
13:22:05
jackdaniel
that depends. it is not said that applications composing desktop environment are part of said de codebase, it is more about integrations
13:23:25
jackdaniel
think of it as dependencies: foobar-desktop-environment depends on: bar wm (and its inherent tooling), firefox, thunderbird and libreoffice
13:23:58
jackdaniel
as of the "content manager" it was a suggestion where I would start creating the application tooling for a desktop environment, not some specific application I've encountered
13:25:20
beach
OK, I am clearly not asking the right questions. Let me ponder what you said and see whether I can come up with a better set of questions.
13:25:21
jackdaniel
themes, window manager, tooling for said window manager, probably set of default applications
13:26:27
jackdaniel
i.e most KDE components are based on Qt (so tooling is consistent), that doesn't mean you can't run GTK applications. KDE is split into numerous reusable component libraries which may interact with each other etc
13:26:48
random-nick
cinnamon and gnome actually share a lot, since linux mint originally used a modified gnome before making cinnamon
13:27:52
jackdaniel
auxliary tools. for instance: you may use perf (linux application) or clim-flamegraph for profiling (more or less)
13:28:13
jackdaniel
both are tools, and (say) sbcl includes by default clim-flamegraph and ecl includes perf integration
13:29:08
jackdaniel
so while both serve similar purpose, ecl gives you different "tooling" than sbcl with this regard. and regarding consistency: imagine all sbcl "things", like default CL:ED implementation are in CLIM
13:30:19
jackdaniel
what can I say? maybe I use to loose wording, but there is no clear borderline between wm and de
13:30:40
jackdaniel
I'm trying to be descriptive with that. Maybe wikipedia will give you better answer?
13:37:24
beach
Let me ask something simpler (I hope). If I write a GUI application such as an email reader, what part of such an application would be different for different desktop environments?
13:42:55
jackdaniel
or if wm provides account/password managament, your application could optionally use that
13:45:18
jackdaniel
when you receive an email you may expect, that a small popup box appears on a screen, or in taskbar you see small envelope which notifies you (visually) that you have mail
13:46:58
beach
So, basically, every single GUI application on a typical GNU/Linux system has variations based on whether they run on KDE, Gnome, Cinnamon, you name it?
13:49:20
jackdaniel
not necessarily, but such integrations make a bunch of apps a desktop environment. there may be protocols like dbus ir free desktop specification which abstract it a little
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)