Announcement

Collapse
No announcement yet.

XWayland 21.1 Release Candidate Offers Split From The X.Org Server

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by curfew View Post
    Flatpatk cannot do anything more than what is possible via regular "global filesystem" in a traditional distro installation. Flatpak can only introduce additional restrictions which make unifying the look-and-feel of different toolkits even more complex. This is what I was referring to in my earlier post.
    You need to read over the flatpak link again. There is something mega horrible but also required, Flatpak is not using the host themes. Instead you install themes from flatpak repository that are close to the host theme.

    Yes it would be good to add per application theming with flatpak but that does not change that flatpak intentionally don't use the host theming that could be modified in ways that could break applications.

    The current GTK, Qt.... themes have to match the libraries we don't have proper generic theming.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ssokolow View Post
    It did invent and drive the introduction of the XDG Portals system (Can't remember if that was back when it was called xdg-app or if it came about after the name change), which allows anything using QFileDialog without the non-default DontUseNativeDialog flag or GtkNativeFileChooser to seamlessly pick up your desktop's preferred Open/Save dialogs. (Though, when running outside Flatpak or snappy, GTK requires you to manually set the GTK_USE_PORTALS environment variable.)
    XDG Portals starts when flatpak was called xdg-app. That kind of why its XDG portals not flatpak portals. If you check the history in the flatpak repository you will see xdg portals files is first commit dated before flatpak as the name for the project exists as well.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by curfew View Post
    What you said here is impossible. The apps are programmed using Qt or GTK or something else and the packacing format cannot change that.

    Flatpatk cannot do anything more than what is possible via regular "global filesystem" in a traditional distro installation. Flatpak can only introduce additional restrictions which make unifying the look-and-feel of different toolkits even more complex. This is what I was referring to in my earlier post.

    The optimal scenario for Flatpak would be that it doesn't break anything; it also cannot fix anything. (Aside maybe per-app themeability but the docs you linked mention that this is not possible.)
    It did invent and drive the introduction of the XDG Portals system (Can't remember if that was back when it was called xdg-app or if it came about after the name change), which allows anything using QFileDialog without the non-default DontUseNativeDialog flag or GtkNativeFileChooser to seamlessly pick up your desktop's preferred Open/Save dialogs. (Though, when running outside Flatpak or snappy, GTK requires you to manually set the GTK_USE_PORTALS environment variable.)

    Leave a comment:


  • curfew
    replied
    Originally posted by mppix View Post
    Flatpak has desktop integration and decides what application toolkit (Electron, GTK, Qt) to use
    https://docs.flatpak.org/en/latest/d...tegration.html
    What you said here is impossible. The apps are programmed using Qt or GTK or something else and the packacing format cannot change that.

    Flatpatk cannot do anything more than what is possible via regular "global filesystem" in a traditional distro installation. Flatpak can only introduce additional restrictions which make unifying the look-and-feel of different toolkits even more complex. This is what I was referring to in my earlier post.

    The optimal scenario for Flatpak would be that it doesn't break anything; it also cannot fix anything. (Aside maybe per-app themeability but the docs you linked mention that this is not possible.)

    Leave a comment:


  • mppix
    replied
    Originally posted by curfew View Post
    This doesn't happen on classic Linux desktops because the libraries are shared. Not sure about those pesky flatpaks and snapchats and whatevers, though.
    Flatpak has desktop integration and decides what application toolkit (Electron, GTK, Qt) to use
    https://docs.flatpak.org/en/latest/d...tegration.html
    In fact, theming of flatpak apps (except proprietary) tends to be pretty good/unified.
    However, apps can still use different libraries.

    No clue about snap (.. and don't care enough to check ).


    Edit: out of curiosity, I installed picard from debian repos and flatpack:
    --> flatpack follows system-wide dark theme; the native installed client does not (even with preference set to use system-wide theme)!
    I would upload a screenshot but seem to be "not authorized to upload attachments".

    Anyhow, this is quite interesting; anyone concerned with theming might want to try installing as many apps from flatpak as possible
    Last edited by mppix; 22 February 2021, 04:47 PM.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oiaohm View Post

    The reality is that is not true. All 4(wxGTK,wxQT,wxMotif,wxX11) are packaged for arch and gentoo based Linux distributions. If you have only tested with wxGTK on Linux you really should be using the wxWidget option to force particular back-end so a possible future change on your target distribution cannot get you. There are a handful of applications that are arch packaged that do in fact need wxQT or wxMotif and will not function correctly with wxGTK.

    wxWidgets multi backend options brings it own forms of theming headaches and its own particular nasty trap. Yes you would have missed including code so the program errors out if the right wxWidget backend is not present.
    Huh. Learn something new every day. I guess it's a good thing Audacity is the only wxWidgets app I have installed and I almost never use it.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by curfew View Post
    Your ignorance is showing as well. GTK isn't native-to-Linux. It's merely native to Gnome and to some extent XFCE.
    No, but, especially given RedHat's efforts, it's the closest thing Linux has to "the platform's native toolkit" and, in the GTK+ 2.x days, QGtkStyle did a pretty damn good job at making everything look right with a single GTK+ 2.x theme.

    (I say this as someone who wandered through all major desktops back on MandrakeLinux 10.0 (as well as building my own desktops using various WMs like Openbox, Blackbox, FVWM, Fluxbox, and E16, then settled on KDE 3, migrated from KDE 3.5.x to LXDE when KDE 4.0 was adopted too readily, finally came back late in the KDE 4.x cycle when "Now it's responsive and stable" stopped being an aspirational lie, and am still on a mix of KDE and LXDE components which I'll switch to a mix of KDE and LXQt components when I upgrade soon... I never felt Konqueror 4.x or Dolphin were suitable replacements for Konqueror 3.5.x (too many papercut bugs) so I switched to PCManFM. Likewise with KDE "lightweight" text editors being needlessly cluttered with UI elements when Leafpad was all I wanted... I'm probably going to have to fork MComix when I upgrade to get it pared back down to the Comix UI.)

    Originally posted by curfew View Post
    Qt can also natively adapt to OS X and Windows so there is no need for an ugly API that proxies to another toolkit.
    Agreed. That's why I migrated from wxPython to PyGTK when I switched from Windows XP to Linux in the early 2000s, then from PyGTK to PyQt5 when GTK 3.x ruined the "write to the one API every Linux user is likely to have already installed for something and get an app that looks sufficiently native on my KDE desktop" value proposition.

    (These days, I mainly use PyGObject for my QuickTile window-tiling helper, which doesn't draw any on-screen widgets but needs easy access to libwnck.)
    Last edited by ssokolow; 21 February 2021, 02:25 AM.

    Leave a comment:


  • curfew
    replied
    Originally posted by ssokolow View Post
    Your ignorance is showing. wxWidgets is a thin wrapper around the platform-native toolkit with a few extra synthetic widgets to fill in the gaps on whatever platform you're on. [---] On Linux, the backend in use is called wxGTK.
    Your ignorance is showing as well. GTK isn't native-to-Linux. It's merely native to Gnome and to some extent XFCE.

    Qt can also natively adapt to OS X and Windows so there is no need for an ugly API that proxies to another toolkit.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ssokolow View Post
    Huh. Last I heard, wxQt was still the one that nobody packaged because it was about as usable as the Qt backend for XULRunner, and wxX11 and wxMotif were the bogeymen used to scare wxWidgets-using developers into staying on Linux and BSD where they could trust wxGTK would satisfy the dependency instead.
    The reality is that is not true. All 4(wxGTK,wxQT,wxMotif,wxX11) are packaged for arch and gentoo based Linux distributions. If you have only tested with wxGTK on Linux you really should be using the wxWidget option to force particular back-end so a possible future change on your target distribution cannot get you. There are a handful of applications that are arch packaged that do in fact need wxQT or wxMotif and will not function correctly with wxGTK.

    wxWidgets multi backend options brings it own forms of theming headaches and its own particular nasty trap. Yes you would have missed including code so the program errors out if the right wxWidget backend is not present.

    Originally posted by ssokolow View Post
    (Now, if you'd said Ttk, on the other hand, I'd agree. It's annoying how nothing Qt or GTK-based quite matches git-gui, and the Clearlooks theme for Ttk that you can swipe from PySolFC doesn't manage to theme every single widget in it.)
    What you said with tik here applies to wxMofit and wxQt backends as well where at times they drop back to the generic widget rendering that is not themed. From what you have said you were not aware that the multi back ends of wxWidgets was a problem you could run into in the real world so not knowing about wxMotif and wxQt limitations is kind of to be expected.

    Old Qt/GTK theme on a newer version can also result in particular widgets not being properly themed as well. Remember we have systemd-homed now where users are going to be moving their home directory between systems more often and these incompatibility are going to come bigger problems.

    Complex theming alterations that depend on particular library versions to work right really need be on the system not in the user home directory. But user still needs to be able to personal theme from their home directory in a more generic way that not going to ruin there day when old meets new or new meets old.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oiaohm View Post
    That is not in fact 100 percent true all the time. https://aur.archlinux.org/packages/wxqt-dev/

    Wxwindows on different Linux distributions may not always be wxGTK.
    https://docs.wxwidgets.org/3.0/page_port.html

    Would pay to read wxX11 particularly fun there are 4 possible different backend outcomes when you use wxwindows and installing applications on different Linux installs that could be there. 3 possible backend outcomes are themeable with different theme formats. Yes wxX11 is not theme-able by a system theme.
    Huh. Last I heard, wxQt was still the one that nobody packaged because it was about as usable as the Qt backend for XULRunner, and wxX11 and wxMotif were the bogeymen used to scare wxWidgets-using developers into staying on Linux and BSD where they could trust wxGTK would satisfy the dependency instead.

    Either way, there's still no such thing as a "wxWidgets theme" in the sense you used it. In real-world scenarios, it'll either pick up your GTK theme, pick up your Qt theme, or run on a backend which can't be themed and shouldn't be something you bother officially supporting unless you've got a paid support contract.

    (Now, if you'd said Ttk, on the other hand, I'd agree. It's annoying how nothing Qt or GTK-based quite matches git-gui, and the Clearlooks theme for Ttk that you can swipe from PySolFC doesn't manage to theme every single widget in it.)
    Last edited by ssokolow; 20 February 2021, 09:16 PM.

    Leave a comment:

Working...
X