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 mppix View Post
    I understand what you are saying in the second paragraph. However, I do not hold my breath. I'm not even sure what a "proper shared theme" can accomplish since e.g. Gnome and KDE apps have vastly different UI guidelines.
    Yes fixing up theming in a large way could be done without aligned UI guidelines. Fixing up accessibility to give a more uniform interface would require making a unified UI guidelines. Yes fight from hell.

    Leave a comment:


  • mppix
    replied
    Originally posted by oiaohm View Post
    I would not say flatpak fixes theming problems. More provided a decent mask over the defect. XDG portals stuff does help some of the common dialogs on the same themes by using the same dialogs.

    Proper fix to theme problem required work like XDG portals and somehow creating a proper shared theme define at least for some bits. Like really why do we need 200+ different ways of defining how a windows boarder looks(I am not kidding with that 200+) that is what X11 WM give us.
    My claim is that flatpak fixes _some_ things that you confirm in your first paragraph.

    I understand what you are saying in the second paragraph. However, I do not hold my breath. I'm not even sure what a "proper shared theme" can accomplish since e.g. Gnome and KDE apps have vastly different UI guidelines.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mppix View Post
    This is getting tiresome. Let's agree to disagree: in your opinion, "Flatpak can only break things, it cannot fix things." In my opinion (and on my system), flatpak fixes some theming things. Cheers.
    I would not say flatpak fixes theming problems. More provided a decent mask over the defect. XDG portals stuff does help some of the common dialogs on the same themes by using the same dialogs.

    Proper fix to theme problem required work like XDG portals and somehow creating a proper shared theme define at least for some bits. Like really why do we need 200+ different ways of defining how a windows boarder looks(I am not kidding with that 200+) that is what X11 WM give us.

    Leave a comment:


  • mppix
    replied
    Originally posted by curfew View Post
    Obviously we cannot read each others minds. Only the text that we (you) write. So take more care in writing out your exact thoughts and don't use vague language.

    I think the "differences" mentioned in the article referred to problems arising from the app using library version A and themes being designed for version B. This usually happens when a feature is added in a later version, the theme is then designed for this version and feature, but the app is bundling an older version and the feature doesn't exist. Someone actually already pointed out this problem in this thread earlier.

    Another example might be dynamically generated theming, which is AFAIK what KDE does in order to adapt GTK apps. Change some color setting in KDE and it will regenerate the GTK stylesheets etc. This might not be possible on Flatpak. I already pointed out myself that Flatpak can only break things, it cannot fix things.
    This is getting tiresome. Let's agree to disagree: in your opinion, "Flatpak can only break things, it cannot fix things." In my opinion (and on my system), flatpak fixes some theming things. Cheers.

    Leave a comment:


  • dragon321
    replied
    Originally posted by Shiba View Post
    Because not all developers come from the same place. I actually prefer CSD, but I don't have the power to control other people's mind (yet).

    I don't care if it's optional or not, this looks like sh*t and unless you intentionally plan to develop a desktop that looks like sh*t it is a big blocker ↓
    I'm not saying that everybody should implement CSD. It should stay optional for every toolkit. What I was saying is that there is another way to solve this problem than simply implementing SSD everywhere. libdecoration sounds like good solution and with additional plugins it should match rest of ecosystem pretty well. There is already work in progress to implement it for SDL2.

    Also unless you plan to use only applications that uses only one toolkit you're gonna hit integration issues sooner or later. There are more issues than simply not matching titlebar.
    Last edited by dragon321; 26 February 2021, 08:41 AM.

    Leave a comment:


  • curfew
    replied
    Originally posted by mppix View Post
    Not really. I did say that flatpak handles theming somewhat different with link and showing that apps may look different on flatpak vs native.
    Sometimes I think that conversations here could gain a lot if we read posts from others with reasonable care.
    Obviously we cannot read each others minds. Only the text that we (you) write. So take more care in writing out your exact thoughts and don't use vague language.

    I think the "differences" mentioned in the article referred to problems arising from the app using library version A and themes being designed for version B. This usually happens when a feature is added in a later version, the theme is then designed for this version and feature, but the app is bundling an older version and the feature doesn't exist. Someone actually already pointed out this problem in this thread earlier.

    Another example might be dynamically generated theming, which is AFAIK what KDE does in order to adapt GTK apps. Change some color setting in KDE and it will regenerate the GTK stylesheets etc. This might not be possible on Flatpak. I already pointed out myself that Flatpak can only break things, it cannot fix things.
    Last edited by curfew; 26 February 2021, 01:34 AM.

    Leave a comment:


  • mppix
    replied
    Originally posted by oiaohm View Post

    Flatpak has more than 1 copy of a lot of themes and in different versions of the same theme for different libraries so depending on what flatpak runtime application users depends on what themes the applications sees. I have had a few cases where 1 application was using the same host and another was dropping back to Adwaita both were using different KDE runtimes with flatpak and only one version of the KDE installed runtimes had the matching theme to my host installed. Even so this does not result in unable to be used application.

    What flatpak does avoids the worst. The worst being you cannot use X application because the theme you have choosen has caused key buttons/interface bits to pull the disappearing act. This is disappearing act is a high risk with setting a theme in home directory then using homed to move that home directory between systems. Current Qt/Gtk theme systems are not library neutral. There is a need going forwards for a library neutral theme system..
    +1
    Not breaking apps and have them reasonably conform is likely the best that can be achieved until some uniform UI tech comes along. I am not too optimistic about the latter.

    Leave a comment:


  • mppix
    replied
    Originally posted by curfew View Post
    No, I was responding to your claim that Flatpak versions of GTK and Qt themes somehow aren't same as non-Flatpak versions of GTK and Qt themes.
    Not really. I did say that flatpak handles theming somewhat different with link and showing that apps may look different on flatpak vs native.
    Sometimes I think that conversations here could gain a lot if we read posts from others with reasonable care.

    Leave a comment:


  • curfew
    replied
    Originally posted by mppix View Post
    .. so what?
    Are you suggesting that Qt, GTK, ... apps cannot be styled to be compatible with other styles or different versions of themselves?
    No, I was responding to your claim that Flatpak versions of GTK and Qt themes somehow aren't same as non-Flatpak versions of GTK and Qt themes.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oiaohm View Post
    There is a need going forwards for a library neutral theme system..
    Agreed. It probably wouldn't fix every reason I'm trying to find alternatives to GTK 3.x apps (There are limits to how much of the GNOME HIG can be undone by a theme), but it'd certainly help to restore what Lubuntu achieved in the GTK 2.x era by writing a theme I found acceptably non-GNOME-ish for GTK+ 2.x and then using QGtkStyle to share it with Qt.

    Leave a comment:

Working...
X