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