Window positioning? You cannot position the window, you cannot send a hint, nothing? So my pop-up with GTK4 will randomly be placed somewhere, anywhere, without any control. OK, GTK4 went further and also removed popups without the parent, so you hack that with an invisible anchor window and then write platform-specific code for sane platforms that CAN, of course, move the window. And let's not talk about window icons that you have to put somewhere on the file system?
Have you considered if someone wants to make a compositor where each window is projected onto a facet of a hyper cube and must place windows in 4 dimensions? These are important use cases we should support, we should make cross platform software as difficult possible to develop for Linux by removing features that have been standard on desktop operating systems for decades.
It's not technically behind on window positioning. Rather, it was a deliberate choice not to support it. You can very reasonably object to that, but it is sorta a necessary measure to prevent clickjacking.
And common sense mitigations: if a new program I've never seen before drops an actionable control under my cursor, maybe just default to not immediately accepting the next input to it so I have a chance to see it.
I mean, you can create alternate APIs that would work for the pop-up use case: you could have a command to create a new window positioned relative to the current window’s coordinate space.
That limited capability still has a risk of denial attacks (just throwing up pop-ups that extend beyond the current window’s boundaries), but those can be mitigated in a number of ways (limit the new window’s boundaries to the current window’s, or just limit how many windows can be opened, etc.).
I like how even the nus product (jpegli) is a significant improvement. I am in the process of converting my comic book collection. I save a lot of space and still use JPEG, which is universally supported.
To me, this argument always sounds like someone is being forced or threatened into creating a desktop app. It was never supposed to be easy; the goal is to create an app that users would want and will actually use.
I am working on the UI library and bindings for Go. Still not finished, but currently, the same app can be compiled for Win32, Cocoa, GTK2, GTK3, GTK4, Qt5, Qt6, and Motif. There is a web browser control, a GL canvas, and a regular canvas. I still work on the native table control, though.
IUP has custom-drawn controls for tables and cells (additional controls), and it uses another CD (canvas draw) library for that, not internal IUP Draw functions. I also started rewriting that to use the core IUP drawing functions instead. I also added a few more drawing functions, for rounded rectangles, bezier curves, and gradients. But ALL drivers, including Motif, have native table controls, so I really want to add one.
Edit: Also, the GLcanvas control now has an EGL driver, with native Wayland support for GTK3, GTK4, and Qt6 (needs private headers). I modernized a bit of everything, added support for APPID, DARKMODE, etc. Linux uses xdg-open rather than hardcoding browsers. Win32 driver is not using the Internet Explorer web control but the WebView2 with custom loader, on GTK, you do not have to worry about the WebKitGTK, it will find the correct library with dlopen, etc, etc. But, there is still a lot to do.
Sure, but Apple doesn't fully support HEIC either.
They support only a very specific subset of it, in a particular combination.
Some Apple apps can open third-party HEIC-in-HEIF files, and even display the image correctly, but if you try anything more "complex", it'll start failing. Simply forwarding the image to someone else will result in thumbnails looking weirdly corrupted, brightness shifting, etc...
I've even seen outright crashes, hangs, visible memory corruption, etc...
I bet there's at least one exploitable security vulnerability in this code!
I often use <img> with "width" on GitHub, so that I do not have the scrollbars on the main page, and one can click on the image to see the original size. It is ugly, but what is the alternative in Markdown? Several images instead of one?
I know a few apps that did the same (mpv for example). If you still have it in home root it uses that, when you move it to .config it uses that instead. Auto migrating could and would create issues.
People are talking about AI everywhere, but where can we find documentation, examples, and proof of how it works? It all ends with chat. Which chat is better and cheaper? This local story is just using some publicly available model, but downloaded? When is this going to stop?
reply