4 ms·

> It may do that but generally it still uses Cairo. Uh, no it doesn't. I literally wrote the GL renderer, I know what I'm talking about. > In any case GTK wor

> It may do that but generally it still uses Cairo. Uh, no it doesn't. I literally wrote the GL renderer, I know what I'm talking about. > In any case GTK working on Windows and Mac is an artefact rather than something really usable. Maybe pre-4, which is why it got redesigned. > I suspect that efforts to support such multiplatform feature makes Linux native GUI development less developed. What? > Generally Linux cannot be considered as a desktop OS as it has no stable and uniform system UI (window manager, graphics, etc.) Huh? You're out of your mind.

c-smile 4y ago
> Huh? You're out of your mind. Do we have such basic thing as `MoveWindow(wnd,x,y,w,h)` on GTK? Seems like still not: - https://stackoverflow.com/questions/58103333/set-frame-position-of-decorated-gtkwindow-on-screen https://stackoverflow.com/questions/58103333/set-frame-posit... - https://stackoverflow.com/questions/65508569/how-to-move-my-gtkwindow-to-a-specific-position-on-screen-in-gtkmm-4 https://stackoverflow.com/questions/65508569/how-to-move-my-...
- audidude 4y ago
  How does that make it "not desktop"? This is literally the dumbest argument ever. It's one extra line of code. If you have the GDK X11 backend, get the XID and call MoveWindow() yourself. If you have a macOS Window, call [NSWindow setFrame]. I don't see why you expect GTK to be your abstraction for insecure UI practices. The compositor should be in control of this policy, not applications. Which is why that API isn't there any more.
  - c-smile 4y ago
    Glad you've mentioned "GDK X11 backend". It means that GTK is not a desktop API. X11 is not a desktop API either as you cannot build with it GUI consistent with other applications on target platform. Linux is not a desktop OS. By any means. Dot. Until we have linux_move_window() function.
    - smoldesu 4y ago
      You're right, Linux isn't a desktop OS. Neither is Darwin or NT. To make an OS you need a system of desktop-providing tools. Windows is an operating system that provides a desktop stack to the NT kernel. MacOS is an operating system built on Darwin and Mach. Following this line of logic, there are dozens of opinionated Linux distributions that qualify for your definition of desktop OS. (RHEL, Fedora, Ubuntu, KDE Neon, et al.) Linux systems are no different than Darwin or NT ones if you compare like systems. If you spend all day comparing kernel features to OS features, I don't think you're going to make any meaningful discoveries.
      - c-smile 4y ago
        Neither of RHEL, Fedora, Ubuntu, KDE Neon have APIs that GUI developers can rely on. To be short: First Linux company that will decide to provide stable API similar to `WndProc(window, params)` (Windows) or `class_addMethod(window,@selector)` (Mac/iOS) will win Linux Desktop war - will make the Linux GUI for years to come. If someone knows such company - please let us know, at least I am willing to participate.
        smoldesu 4y ago
        WNDPROC is part of Win32, not the kernel. You seem to have mixed something up. If we're talking about kernels with windowing capabilities, there are none. If you're asking about OSes with a reliable, documented graphics stack, RHEL is literally what you're looking for. It's the shitty, "Windows-ified" model of desktop development, and almost everyone ignores it for desktop use. You might argue that it doesn't qualify, but you can't argue that nobody has tried it before.
        c-smile 4y ago
        > WNDPROC is part of Win32, Users and UI developers don't care. It is part of OS and it is always there. The only things I know for sure are: 1. Desktop OS is not a distribution but set of popular GUI applications that work on that OS natively including tested specifically on it. 2. Lack of stable window and graphics API leads to fractured GUI developers community. Keeping in mind that number of Linux GUI developers is in magnitude of times less than for Windows/MacOS, makes Linux GUI perspectives very grim. In general "desktop Linux" is not fair to its most loyal users because of these. Users are forced to pay extra price for hardware just to be able to run those Electron applications - no real native options for similar functionality.
- nsajko 4y ago
  This is a part of Wayland fanaticism: https://discourse.gnome.org/t/how-to-center-gtkwindows-in-gtk4/3112/9 https://discourse.gnome.org/t/how-to-center-gtkwindows-in-gt... As I’ve said above, not all windowing systems have a concept of global coordinates or allow direct positioning of the windowing from an application. Wayland, for instance, does not. The purpose of the Wayland project was clearly to impose a set of weird limitations like this one on everyone. The best explanation I can think of is that it's all part of some cult at Red Hat.
  - smoldesu 4y ago
    Are they wrong? SwiftUI doesn't have a concept of window positioning coordinates, but that doesn't mean that MacOS isn't a desktop OS. They just implemented their windowing stack differently, and honestly I think the Quartz method is a lot nicer. There's a lot to complain about with Wayland, but this is one of the few changes that seems rooted in logic rather than laziness.
    - c-smile 4y ago
      SwiftUI is not a desktop UI by its concept. It is very close to Web Fronted UI - document UIs running inside a sandbox.
      - smoldesu 4y ago
        Alright, let's go up a layer of abstraction then. Where does the Quartz system expose windowing coordinates the the developer?
        c-smile 4y ago
        Right here: https://developer.apple.com/documentation/appkit/nswindow/1419697-frame?language=objc https://developer.apple.com/documentation/appkit/nswindow/14...
jbritton 4y ago
How do you render fonts on the GPU? Do you use pathfinder, something else, or roll your own?
- audidude 4y ago
  Currently, they are rendered using Pango (thus Cairo) to memory and then uploaded into a texture atlas. This happens once per-glyph/font/size (plus or minus some variants for x/y alignment). You then use the "color shader" to copy from the texture atlas into the destination FBO to both create the shape and color at the same time. Since you often do this for a whole text editor, you can copy all of the glyphs and color them in a single glDrawArrays()s. When GLyphy lands, it's a bit different. You preprocess the bezier curves into a simplified format (which doesn't have overlaps) and upload those to a texture atlas (but for general data). Then use GLyphy's shader program to render them, similarly to how the color shader was used. For more general paths, which is much slower but also still very neat, you would do something akin to Pathfinder.

c-smile 4y ago

> Huh? You're out of your mind. Do we have such basic thing as `MoveWindow(wnd,x,y,w,h)` on GTK? Seems like still not: - https://stackoverflow.com/questions/58103333/set-frame-position-of-decorated-gtkwindow-on-screen https://stackoverflow.com/questions/58103333/set-frame-posit... - https://stackoverflow.com/questions/65508569/how-to-move-my-gtkwindow-to-a-specific-position-on-screen-in-gtkmm-4 https://stackoverflow.com/questions/65508569/how-to-move-my-...

audidude 4y ago
How does that make it "not desktop"? This is literally the dumbest argument ever. It's one extra line of code. If you have the GDK X11 backend, get the XID and call MoveWindow() yourself. If you have a macOS Window, call [NSWindow setFrame]. I don't see why you expect GTK to be your abstraction for insecure UI practices. The compositor should be in control of this policy, not applications. Which is why that API isn't there any more.
- c-smile 4y ago
  Glad you've mentioned "GDK X11 backend". It means that GTK is not a desktop API. X11 is not a desktop API either as you cannot build with it GUI consistent with other applications on target platform. Linux is not a desktop OS. By any means. Dot. Until we have linux_move_window() function.
  - smoldesu 4y ago
    You're right, Linux isn't a desktop OS. Neither is Darwin or NT. To make an OS you need a system of desktop-providing tools. Windows is an operating system that provides a desktop stack to the NT kernel. MacOS is an operating system built on Darwin and Mach. Following this line of logic, there are dozens of opinionated Linux distributions that qualify for your definition of desktop OS. (RHEL, Fedora, Ubuntu, KDE Neon, et al.) Linux systems are no different than Darwin or NT ones if you compare like systems. If you spend all day comparing kernel features to OS features, I don't think you're going to make any meaningful discoveries.
    - c-smile 4y ago
      Neither of RHEL, Fedora, Ubuntu, KDE Neon have APIs that GUI developers can rely on. To be short: First Linux company that will decide to provide stable API similar to `WndProc(window, params)` (Windows) or `class_addMethod(window,@selector)` (Mac/iOS) will win Linux Desktop war - will make the Linux GUI for years to come. If someone knows such company - please let us know, at least I am willing to participate.
      - smoldesu 4y ago
        WNDPROC is part of Win32, not the kernel. You seem to have mixed something up. If we're talking about kernels with windowing capabilities, there are none. If you're asking about OSes with a reliable, documented graphics stack, RHEL is literally what you're looking for. It's the shitty, "Windows-ified" model of desktop development, and almost everyone ignores it for desktop use. You might argue that it doesn't qualify, but you can't argue that nobody has tried it before.
        c-smile 4y ago
        > WNDPROC is part of Win32, Users and UI developers don't care. It is part of OS and it is always there. The only things I know for sure are: 1. Desktop OS is not a distribution but set of popular GUI applications that work on that OS natively including tested specifically on it. 2. Lack of stable window and graphics API leads to fractured GUI developers community. Keeping in mind that number of Linux GUI developers is in magnitude of times less than for Windows/MacOS, makes Linux GUI perspectives very grim. In general "desktop Linux" is not fair to its most loyal users because of these. Users are forced to pay extra price for hardware just to be able to run those Electron applications - no real native options for similar functionality.
nsajko 4y ago
This is a part of Wayland fanaticism: https://discourse.gnome.org/t/how-to-center-gtkwindows-in-gtk4/3112/9 https://discourse.gnome.org/t/how-to-center-gtkwindows-in-gt... As I’ve said above, not all windowing systems have a concept of global coordinates or allow direct positioning of the windowing from an application. Wayland, for instance, does not. The purpose of the Wayland project was clearly to impose a set of weird limitations like this one on everyone. The best explanation I can think of is that it's all part of some cult at Red Hat.
- smoldesu 4y ago
  Are they wrong? SwiftUI doesn't have a concept of window positioning coordinates, but that doesn't mean that MacOS isn't a desktop OS. They just implemented their windowing stack differently, and honestly I think the Quartz method is a lot nicer. There's a lot to complain about with Wayland, but this is one of the few changes that seems rooted in logic rather than laziness.
  - c-smile 4y ago
    SwiftUI is not a desktop UI by its concept. It is very close to Web Fronted UI - document UIs running inside a sandbox.
    - smoldesu 4y ago
      Alright, let's go up a layer of abstraction then. Where does the Quartz system expose windowing coordinates the the developer?
      - c-smile 4y ago
        Right here: https://developer.apple.com/documentation/appkit/nswindow/1419697-frame?language=objc https://developer.apple.com/documentation/appkit/nswindow/14...

jbritton 4y ago

How do you render fonts on the GPU? Do you use pathfinder, something else, or roll your own?

audidude 4y ago
Currently, they are rendered using Pango (thus Cairo) to memory and then uploaded into a texture atlas. This happens once per-glyph/font/size (plus or minus some variants for x/y alignment). You then use the "color shader" to copy from the texture atlas into the destination FBO to both create the shape and color at the same time. Since you often do this for a whole text editor, you can copy all of the glyphs and color them in a single glDrawArrays()s. When GLyphy lands, it's a bit different. You preprocess the bezier curves into a simplified format (which doesn't have overlaps) and upload those to a texture atlas (but for general data). Then use GLyphy's shader program to render them, similarly to how the color shader was used. For more general paths, which is much slower but also still very neat, you would do something akin to Pathfinder.