Crysstalis
Then those parts will be easier to port as well, so there is not much benefit to having this backwards compatibility when more benefits can be gained by porting. This is why most GNOME applications have ported.
>Even if that is the case, it still has all the other backwards compatibility issues i mentioned.
Those issues would be even worse by trying to hack various things into GTK1.
>The effort i mentioned here was on designing backwards compatible APIs and libraries
My point was that some things are impossible to design in a backwards compatible way. For example, anything that leads to certain assumptions getting hard coded in the app. You cannot API design your way out of those type of problems. The app has to be rewritten or ported.
>it is not like i expect any Gtk developer to suddenly come across my posts and somehow get enlightened or something
Keep in mind that GTK developers have very likely already weighed the benefits of what you are suggesting and have decided that it is not worth it, for various reasons.
My point is those users will be unhappy anyway, they choose to break their own system. There is little reason to try to accommodate them further. The alternative is always going to be don't use that WM or don't have scaling support. It is not superior as you are always faced with this choice. That is the choice you get when you want to use legacy apps and WMs which is the only real reason to still be using X11.
In my personal opinion, all those panel and decoration protocols are broken and are needlessly recreating many of the same problems as were present in X11.
That Joel article is more of a rant than a coherent statement, it is not reasonable to ask developers to stop working on new APIs and libraries.
>None of these are the case with Gtk though.
But this is incorrect, development can continue independently on old versions of GTK.
Pretty much every custom widget with custom drawing does this, so that excludes most non-trivial applications from using this method.
>Much preferable to having to port to some different toolkit.
Again, for applications with no custom widgets or without any use of the complex features, the porting effort to newer versions of GTK is also just a few lines of code, if even that. The simple things like buttons and inputs have barely changed.
>The point is at least making an effort.
Well, GNOME will probably not make this effort, as they dropped GTK1 around twenty years ago. It is not used anywhere in their stack. It was much easier and more beneficial for them to port or rewrite every application, multiple times actually. So I cannot really buy this complaint that porting is so difficult yet adding this compatibility to GTK1 is supposedly easy. If the method in Lazarus works so well then maybe an interested party should look at implementing it into GTK1 proper, because no one else seems to have any interest in maintaining GTK1.
>you have to take that into account from the point where you design the new features, not try to backport them after the fact.
Again there is nothing to take into account here. The issue is that the app developers also have hard coded these bad assumptions into their apps. If the app has to be changed to change the assumption then you might as well just port the app, because the only way to deal with it is to do that or backport it after the fact.
The issue with this thinking is that those cons eventually cascade back to the developer, if you know for a fact users will use an option that is going to break the intended use case. Window Maker is going to be broken or have a sub par experience with the situation you describe, because that only works with applications that support this method. Old legacy applications with no scaling support will still need support from the window manager. So that is a perfect illustration of why that solution is inferior and can never work correctly if you want to take this angle of "I can make whatever choice I want, including the broken ones".
>Your responses indicate that your beliefs are wrong then
I do not think so, your additional writings have drifted further from that subject. I should remind you, this thread is a discussion of GNOME, not Window Maker.
Part of the reason that the themes changed and the CSS implementation got changes was because of these issues, i.e. pretty much all GTK1 and GTK2 applications and themes had no concept of device-independence, most drawing was done hard coding a DPI against raw device pixels. The few applications that implement it themselves would not benefit from any backwards compatibility layer.
You can also apply the same logic to many of the other changes in GTK. Your suggestions just cannot be done by swapping out the library, they are either impossible or are even more impractical than the current situation. If it were as easy as you seem to think it is then the GTK developers would have done it by now.
Then your actual criticism is that those previous versions have stopped development, not that backwards compatibility was broken. The whole thing about "backwards compatibility" is a distraction. And again, it is not a waste of time keeping up if they actually want the new features. If they do not want them then they are free to spend their time maintaining the old versions.
Well my point was that it will always be an inferior experience on X11 even though it technically is possible in some circumstance. WM hints only work correctly if the window manager is compositing which many window managers are not, or do not want to add, and some X11 users still seem to insist on not using them... Any attempts to add this to X11 are fighting an uphill battle.
>I suggest try to actual read what people are writing
I did and I believe those replies are following those patterns. Those comments seem unrelated to the other things about backwards compatibility. It is an entirely separate concern.
This is already how it is. If you want those features, then port to newer versions. If you do not want them, then do not port.
>could have been implemented and designed in such a way as to avoid breaking existing applications but also making porting the applications easy.
This is simply not possible. Many older APIs are just not designed to support this.
>then there is absolutely nothing that is affected in that application by improvement to scaling support, CSS support, rendering models or anything else.
Indeed, such a program would probably be trivial to port.
>With what i describe if Gtk4 was backwards compatible with Gtk1, a binary of that application compiled against Gtk1 would run under Gtk4 and get the new file picker dialog instead of the weird one used in Gtk1, would get antialiased font rendering, would get the themes used by Gtk4, etc.
If you want binary compatibility, that is a different story. It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4. But only the most trivial ones like a form with a couple of buttons. Anything with custom widgets (which is all non-trivial applications) would probably break or would lose most/all of the benefits, the GTK1 API simply was not designed in that way.
This is incorrect, things like the DPI scaling, or the CSS changes, or the new rendering model in GTK4 could not be added in a backwards compatible way. They require porting to gain any of the benefits. It is simply not possible to design an API in such a way that you can perfectly anticipate all future changes. The "force of nature" here is not the GTK developers, it is the surrounding environment changing in ways that require the API to change to keep up, and it is in fact unavoidable for any developers trying to support that environment. The rest of the comment stems from this incorrect assumption so I have not much else to say.
If the suggestion is that GTK should somehow get the same budget that Microsoft has to put towards backwards compatibility, you know very well this is not possible. It would probably not even be wanted, GTK is a lot less popular than Windows.
Because it needs special support in the window manager. At that point it is the same as what Wayland is doing except it still has all the other flaws of X11 and it will break when someone wants to disable compositing or use another old window manager. As for the other parts, those would technically work, and it already does work like that for the most part. Most programs that can do DPI scaling do already have a way to scale themselves. But that is not a good experience for users, the point of it working seamlessly is to have support for it built into the window manager.
>Then i suggest making better effort towards understanding what others write or at least ask clarifications
There are no clarifications to ask, you are repeating the same comments that get posted all the time. Keep in mind these are the type of comments that you can see repeated very often:
"I have no problem, it works on my hardware"
"It is not a problem because I personally prefer it this way"
"Just try to fix the problem yourself by tweaking these developer settings (config files, environment variables, etc) and hoping it works"
If your comment follows this pattern then I would say just avoid making that comment, it is not moving the discussion forward. I think you can agree, when building these systems the goal is to get something that is usable out of the box for everyone. So these comments do not "move the needle" towards that, these are just reinforcing the current status quo.
In practice D-Bus is functionally similar to many other IDL schemes and can be trivially tunneled over SSH. But yes, it has mostly become used for local applications to communicate with system daemons, and the networked case is not particularly relevant.
The modern replacement for networked objects is to write a web server and communicate using XMLHttpRequest/fetch/websockets, which is outside the scope of a desktop environment.
>Ideally I would use an embedded Wayland compositor widget instead of a webview and broadway, but unfortunately there is only an old non working prototype called Wakefield and finishing it is a project on its own. In any case replacing the webview with a wayland compositor widget would be trivial.
Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland.
>For example i prefer to have tearing on my desktop... In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory
>Well, yes, it is your problem
This is also doing the same thing that the parent post is asking you not to do. It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.
This is how it already is for MATE as long as they intend to keep it that way. It uses GTK3, which is currently in maintenance mode, and will only receive bug-fixes and nothing else.
See my other comment about impedance mismatch for an explanation of the challenges with using command lines to remotely administer GUI desktops. It can be something that complements GUI administration, but can never possibly supplant it, because if you do that then you're intentionally trying to route around the problem space.