Hi, On Mon, Aug 8, 2022, 8:38 AM Benoît Gschwind <gschw...@gnu-log.net> wrote:
> Hello, > > After a quick reading of your DevHelp case, I think the issue belong > devhelp and your app that using it. DevHelp have to provide an API to > be embeded in another application and Wayland protocol should not be > involved. Maybe d-bus can be used as pipe between DevHelp and others > applications. > Problem is - DevHelp is like a plug-in- it can be used with a thousands of applications, not just a specific one. And DevHelp don't have control over them. So you reading comprehension is too fast. :-) Thank you > Best Regards > > Le lundi 08 août 2022 à 14:12 +0200, Sébastien Wilmet a écrit : > > Hi, > > > > I've seen the discussion this month about positioning windows. > > > > The use-case is something concrete: the Devhelp [1] assistant window. > > > > For some background, Devhelp (and libdevhelp) is implemented > > flexibly: > > it can be used as a standalone app, it can be integrated into GTK > > IDEs, > > the standalone app can be called to search or open a symbol. > > > > And there is the Devhelp assistant window: it is typically used by a > > text editor, to ask Devhelp to show a small window with the > > documentation for the symbol under the cursor. > > > > And that is where positioning is necessary: to not occlude the line > > of > > text where the cursor is, and to show the documentation at a sensible > > place (near the cursor position). > > > > With Wayland, this should be implemented with a subsurface. I may be > > wrong, but in this case it's not possible, because it's not the same > > app (the same process). > > > > (For example you open a terminal, then open Vim, then you press a key > > and it opens the Devhelp assistant window). > > > > So, what would be your suggestion in such a use-case? To still retain > > the flexibility of Devhelp. > > > > Thanks, > > Sébastien > > > > [1] https://wiki.gnome.org/Apps/Devhelp (an API browser) > >
