is there presently any way to make the copy/paste and undo/redo functionality built into XPCE’s editor/text_buffer classes support fragments?
When I copy and paste text with fragments, the fragments are not included. Likewise, when I undo and redo text with fragments, the fragments disappear.
I understand if this is not supported, but I think it would be a nice feature. Would there be interest in a patch that adds it?
I very much think XPCE is a valuable asset for SWI-Prolog, even if it is old and not actively worked upon; just the fact that the language includes a GUI toolkit is a great and unique feature IMO.
I’d love to see your approach, since I fully agree with your final statement, and I have myself a small dream in the box, about making XPCE editor ‘simpler’, for instance adopting the ‘banal’ ^c^v (or ^x^v) instead of the current method for clipboard handling, and macros generated registering the strokes and cursor placement as patterns… in Prolog, of course.
Are you thinking about the Prolog or C level for your patch ?
I’ve only been working with XPCE for the last couple of days, but my impression is that some things in the built-in classes, or at least the editor class, are difficult to override in Prolog, so I was thinking about a patch to the C code.
On the other hand, I haven’t done much experimentation with text_buffer yet, so it is possible that it could be solved in Prolog. I will probably attempt a Prolog solution first and see where that leads.
But I thought I’d ask about it all before starting, in case any work on this has been done before.
By the way, in case you are interested, here is a link to my work on an improved editor class:
Thanks for looking into this. I still have little clue where the GUI or IDE future for SWI-Prolog should be. For the IDE, the Language Server Protocol may eventually provide good Prolog interaction for every IDE supporting it. LSP is, I guess, the only viable alternative to the XPCE based IDE tools. The IDE landscape is so fragmented these days that there is no hope we can provide dedicated (SWI-)Prolog for them and Prolog is too small to make them do it.
For Prolog GUI applications my current focus is currently web based GUIs. Possibly we should look at https://www.electronjs.org/ ?
The alternative would be to upgrade XPCE. Improving the editor is nice. Go ahead and I’ll merge the patches. Work like ieditor should (of course) be moved to the built-in view and related classes. In this case this is most likely also less work. I don’t know what use case requires redrawing the line before, but a small adjustment of the redraw area computation in text_image should fix this as well.
Upgrading XPCE as a whole probably requires replacing the native Windows/X11 low level binding with something portable so we can natively run on MacOS and Linux Wayland. Graphics should move away from pixels and get scaling and rotation. Next there are all the widgets. They are now all done in XPCE itself. That is not sustainable. Moving to an existing widget library however doesn’t match the current widget classes. This will have portability consequences
Small enhancements are always welcome. If anyone has a credible plan for the future, please step forward.
For what it’s worth, the benefit to the widgets being implemented in XPCE is that one doesn’t need to rely on another library that may change or become deprecated in the future. In a way, the same thing can be said for the Windows/X11 bindings.
That was the design philosophy Those were the days (1990s!) with only two (relevant) GUI low level APIs though. Now we have at least four (Windows, MacOS, X11 and Wayland) and it gets a bit harder to sustain. Ok, for Linux/Wayland the X11 route is good and will probably remain so for quite some time. The MacOS X11 route is not so good (the current XQuartz is really slow, at least on the M1). We’d also want the more advanced graphics stuff such as transformations and alpha channel (transparency). But yes, doing the widgets themselves in xpce makes them 100% portable and easy to maintain at the price of being not so good and looking a bit retro
