if what we are talking about is checking the text or metadata as org capture or emacs understands it against what we are capturing in a maximized application, by means of a popup and a human [myself], then:
i'd say an emacs frame popping up over the application [whether the application is emacs or firefox or whatever] as just another frame for my normal emacs [which has some degree of optimization for ergo and accessibiity], but frame shrunk to fit the text, would actually be preferable to a separate popup application/notifier tool [which would require unfamiliar configuration and might not even be ergo or accessible or portable/lts], provided that it goes away after a configured delay, and does not require the keyboard or the mouse to make it go away. so an emacs frame is not a bad idea, just has to be done right. i think. > For other applications, since you have a requirement of maximized application > window and purely mouse action, I am unsure if you managed to configure fluxbox to add a custom menu entry accessible in such layout. fluxbox is the only wm or de that seems to do everything i need. in this case, it is quite straightforward for me [or else i have put out of my mind any annoyance at previous years' efforts in making it work]. what it does is have a bar that drops down when mouse pointer hits top edge of window. this only works if the application is maximized or normalized rather than fullscreen in fluxbox's terminology. and that is the case for everything i'd need to capture. the only fullscreen apps i have are video players, and idk what the point of fullscreen is but with video players they seem to get fit to screen right then as opposed to having the video extend off teh edge of the screen or be tiny or whatever. i do not need to capture from vlc or mpv. [although a super-fancy doug englebart demo type of pov might have me grabbing a few minutes of video and capturing it and then speech to text from the video and metadata would be captured but i am not holding my breath or expecting that.] then rclick on that fluxbox bar drops down a fluxbox menu of highly useful things, which i can add a line to in .fluxbox/.menu to add one. usually shell commands. and also various fluxbox items like maximize and close. and menus i never use courtesy of fluxbox and debian]. it is copacetic. except for one rather annoying bug, which is that the bar stays there if i select anything from that manu, so i have to move pointer to the top again and then back to make it go away again. i gave up trying to fix that bug, wish it could be fixed. but adding a menu item is for me trivial. so that part is not part of the problem. i just open .menu and cargo cult a line that says capture. On 10/28/22, Max Nikulin <maniku...@gmail.com> wrote: > On 29/10/2022 09:59, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>> %(org-get-x-clipboard 'PRIMARY) >>> " >>> :immediate-finish t) >>> >>> However to be at the safe side I would check if (org-get-x-clipboard >>> 'PRIMARY) value is not nil at first. >> >> My approach to this is simply showing a popup with captured heading >> after capture. If anything is wrong, I can quickly notice. >> >> Not sure if it is suitable for Samuel though. > > I started with a small wrapper that checks if Emacs server is running > and creates a new frame if it does not exist yet. So I avoided a pitfall > with empty string instead of selection. I intentionally do not use > :immediate-finish to inspect capture and to add some comment. > > Samuel wish to have minimal distraction: no sound, no popup window, > Emacs window is not raised in front of current application, visual > notification should disappear after some pause. > > That is why I believe that additional checks are required in such silent > workflow to avoid missed data in notes. > > > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
