freenode/#clim - IRC Chatlog
Search
5:13:16
loke
What would be a good way to transfer the selected text to the clipboard? (i.e. what in Windows/GNOME is achieved by pressing Control-C, orin OSX by pressing ⌘-C)
5:15:42
loke
Or something with the mouse? We already steal Shift-Click on the text... So perhaps Shift RIght-Click?
5:16:49
loke
It's something that until now simply hasn't been supported, so except for the interactor command, it's something that doesn't have an analogue in older CLIM applications, I think?
5:18:50
slyrus
I'm a big fan of selecting text and then using the middle button to "paste" said text. Not sure what the magic under the covers is but that sequence just worked for me on thunderbird (to select text from my IRC window) and emacs (to "paste" the text using the middle mouse button).
5:19:50
loke
slyrus: The new stuff is support for the clipboard. C-c (or ⌘-c) copies the content of the selection to the clipboard.
5:22:08
loke
I mean, for anything that supports plain slections (i.e. middle-click) that still works of course.
10:42:14
loke
jackdaniel: Rememebr how the suggestion was to send an event containing the content of the clipboard after it's requested?
10:43:46
loke
The problem is that events are sent to panes, but the requestor may not be a pane. In most cases it's a DREI instance. (there can be many DREI's in a single pane)
10:46:49
loke
Now... The existing implementation does send an event, but it has an event-handler that picks that event up, and rainses a singnal, the condition that is raised contains a slot that holds a reference to the event. Then, inside DREI::READ-GESTURES-AND-ACT, it catches this signal and inserts the text. I tried the same, but it turns out that's not the only place the events are processed.
10:47:34
jackdaniel
that's why I want to get rid of drei, it does not fit well in clim infrastructure with all emacsusms it has
10:47:42
loke
It just so happens that it works in the existing implementation because you're in the middle of clicking the mouse when pasting. When typing, the condition is raised inside a completely different function.
10:48:51
loke
The issue here is that I need to be able to deliver the notification that the clipboard data has been returned to an arbitrary receiver.
10:50:11
loke
The callback mechanism that I proposed earlier will work. Another idea is to add an argument to REQUEST-CLIPBOARD-CONTENT which is an object, and then a generic function is called with that object as argument. So you could, for example, have a method (DELIVER-CLIPBOARD-CONTENT receiver content), where reciver may be the buffer or whatnot
10:50:34
loke
jackdaniel: Yes. The existing implementation hooks into there. Which is why a plain drei pane can't handle copy&paste
10:51:50
jackdaniel
I can' t help you much with drei, I don't know it well and as you see general clim knowlege cant be applied
10:52:21
loke
jackdaniel: Right, let's forget about drei and focus on the issue itself (which is not related to drei actually)
10:54:26
loke
(Just for completeness sake: Pasting into interactors sometimes work. It does use the same text-editor-thingy)
10:54:29
jackdaniel
and it doesn't work, because it is drei? then it really is related to drei /actually/
10:54:54
loke
jackdaniel: No. It doesn't work, because an event is delivered to a pane. And you can have many different receivers of events inside a pane.
10:55:22
jackdaniel
and it is up to a sheet/pane how it deals with the content ,but in principle input-editing-stream should be one of the pane superclasses
10:56:03
loke
I guess there going be some logic in the sheet that would know what to do with the data...
10:56:07
jackdaniel
not some internal object, and if it is not, then it is sheet responsibility to "know" where to pass th econtent (not via event)
10:56:46
jackdaniel
and from this opint on (where sheet handles the event) CLIM considers the event handled
10:58:11
loke
When you shift-drag in a stream pane, I note that all the drawing and processing of the highlighting is done in the CLIM event loop itself. That's... Not ideal, given the fact that CLIM is not thread-safe
11:00:06
jackdaniel
to put it simply: McCLIM is thread-safe internally, it is not thread-safe against asynchronous operations from outside its own loops
11:00:28
loke
Yes. But the drag processing happens in the main event loop, that handler then calls methods on the pane itself to look at the output records with text and stuff... That menas that those records are being read while at the same time the application thread may be running doing its own things.
11:01:18
loke
If you write a program that updates the content of a stream pane, and you shift-drag at the same time, you'll end up having two threads manipualting the output records at the same time, no?
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.