For Go, Rust, Haskell, autoconf, CMake, you would invoke the meson and ninja commands as part of your build process. You can't use them in the same exact way as meson subprojects, but these are just shell commands. It's the standard way to build any project with an external build tool. Am I misunderstanding a requirement? For a static build deployed in a specialized situation, you would likely need a customized gtk build to begin with.
I think it would be worth asking if they could keep that libgtk_static around, for users who know what they are doing. Make it very obvious you are not creating extra burden on them for just your use case. The problem with an option to build and install is that it makes it so they have to support static linking in lots of other use cases, which it doesn't seem they want to do.
I'd be interested to hear if static linking GTK even has that many benefits. From what I have seen, the library may not play so well with LTO.
I don't have any particular opinion on the best way to do this, but from those comments by the tilix developer, it doesn't seem like the approach taken by vte-ng was the right one either.
From the VTE maintainer's perspective, adding any additional external symbols can create trouble, because those symbols have to be maintained for the duration of the major version, and they can prevent further refactorings. It's usually not easy to get public API changes into old libraries like this.
I'm sorry, I misunderstood. I thought you meant the toplevel window controls like close, minimize, maximize. There is currently no way to make all the widgets render using the Win32 API to look like Windows widgets. You probably don't want to do that anyway, it will start to look and act really inconsistent when an application uses custom widgets.
Somebody could definitely fake a theme that makes the widgets look like Windows, and ship that with their windows builds, if that was desired. That to me is a much more viable option. There are multiple themes like this for GTK3. [0] [1] I don't know if any have been ported to GTK4 yet, but they could.
>The amount of condescension and misplaced confidence displayed in that thread is impressive.
I would say that assuming condescension is assuming bad faith. If there is a comment that is truly rude and dismissive, it should be reported as a code of conduct violation. Otherwise, please don't assume the response is trying to put you down because it's disagreeing on technical grounds. Any bug report has to go through technical review, and the developers will almost always have more information about the code than the reporter.
>I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.
To give another opinion, I personally don't feel the same way about this, and I don't think it would be much benefit for there to be a setting.
>If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.
I'm not affiliated, I'm just expressing my personal opinion on this, as you are. Not all user feedback is created equal. Sometimes, the developer must firmly say no because something isn't technically viable. Users don't decide what is technically viable or not, only the developer tasked with writing the code can make that decision. Sometimes, the developer is faced with a choice between competing requirements, and it's not possible to fulfill both technically. Once the decision has been firmly made, there's little purpose to accepting further feedback after that. Committing to a solution means the developer has to accept the effects of it, losing users is always a possible effect, but so is users changing their mind.
Where is meson not a choice, when it's already needed to build gtk? Projects written in other languages would still probably want to have it as a subproject and then invoke meson as part of the build process to build gtk, you wouldn't need to rewrite your whole build process in meson.
If this is wanted in a distro, that distro can install that .a file if they want to support it. I don't see why upstream support is needed there. In my experience this is going to be one additional line needed in the package manifest.
I'm sorry to hear that. I'll reiterate that if someone was rude and hostile to you, that would probably be considered a code of conduct violation, and it would be appreciated if that was reported so it doesn't happen again.
Why can't you static link against that libgtk_static target that already exists? That should be accessible if you have gtk as a meson subproject. It doesn't actually look like anything special needs to be done here.... I'll be commenting on that issue.
>What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available?
They could but then every terminal would have to re-implement the same feature causing needless code duplication. You can see here later a comment from the tilix developer that explains it: https://github.com/gnunn1/tilix/issues/848#issuecomment-2892...
I don't meant to say it doesn't have bugs, of course it does. Every project has bugs. As with all open source, submitting patches to fix those bugs will usually go farther than patiently waiting and hoping that another volunteer will get frustrated enough by the bug to fix it eventually. The obvious segfault bugs that affect everyone badly will tend to get fixed pretty fast, the more obscure ones that arise from weird use of widgets (and need a lot of in-depth debugging) are a harder thing to ask a volunteer to spend their time on.
That seems to be over simplifying, every database is "just running a loop over a list stored in RAM." The challenge is in how you build that list, and then with a GUI the challenge becomes how to display it. Win95 had to run in very memory constrained environments compared to today so I'd imagine there is some special considerations there.
At least from my read of the gitlab issues, I don't think anyone is saying that the current solution doesn't have problems. The idea is to get those problems fixed instead of ditching the current solution entirely, or making it an optional toggle (which would make even more likely that nobody fixes the issues). For me personally, I did use type-ahead but my feeling is that a really good and fast search would make it obsolete.
> Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system at all.
So would a simple search in that folder? I don't see what is special about type-ahead here. I'm not talking about recursive search, that can already be disabled in Nautilus if you don't want it. I think this another reason is why it's bad that people get so outraged about this, a lot of the anger is directed at recursive search when really the solution there is to just fix or disable recursive search. Bringing back type-ahead is not the only way to deal with the problem. Another option would be to speed up recursive search so that it uses your suggestion first to do a fast search and quickly display results from the current folder before recursing, that would be the best of both worlds.
>By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory.
That could also be solved with an intentional search option to search by prefix, maybe with a button and bound to a certain key that makes it obvious and not confusing what's happening. I'm not saying it's bad to search by prefix.
If you're set on linear search then you would see the same performance for a simple search box too, I don't see how type-ahead changes it. For big folders you will still need an index, imagine now you sorted the list by reverse alphabetical, typing an 'a' is still going to be slow when you're at the top.
It may be that this is not implemented yet for some backends (I think it is not implemented in the Windows one) but they probably would accept a patch to implement it there if you know how to do it. Please avoid making these hostile assumptions about open source developers without having the full information. From what I have seen, there is a push recently to make GTK4 a better cross platform toolkit than GTK3 was.
Until global file indexing became a thing built into operating systems, every file manager was slow to open and sort directories with a lot of files. At least that was my experience. An index is still needed to do type-ahead, at minimum you'd need to build a prefix tree. You can't just load the list of files and be done; linear search will cause the same arbitrary slowness. Imagine typing an 'a' when on disk the all the 'a' files happen to be stored at the end of the directory. You would have to rescan the whole list every time you type another letter.
>you can't be helped
This is not the way to have a constructive conversation, please stop. I gave an example of how it's confusing and not predictable for some, let's discuss ways we can make it more predictable.
If you don't preload the folder contents and index it then type-ahead will also be arbitrarily slow there too. I don't know of any Linux filesystem that stores the files sorted and indexed on disk.
>And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them?
The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior should be consistent and predictable with what the user was really trying to do (search). Doing a strange and inconsistent matching behavior that is not available through any other means and is essentially hidden functionality is only going to cause confusion.
>It doesn't need to be a one or the other type deal.
Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to the user why this is or why some files are accessible in one way but not the other. You and I may be familiar with the approach because we're used to it but other users might not. I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager.
>I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search.
Why not? I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.
From what I have seen, I don't believe they ever intended to support those apps that didn't provide decorations. The move towards CSD was intentional for them and started 10 years ago, and supporting those CSD apps is the primary focus. This wasn't a problem for Qt apps either because Qt does provide decorations.
No, I'm just an app developer who used GTK recently and noticed that a lot of what people say about it is based on out-of-date information. My experience really wasn't that bad, progress is being made and issues are being addressed, even though it's not happening as fast as some would like. For whatever reason there is a staggering amount of misinformation in these HN threads.
I think it would be worth asking if they could keep that libgtk_static around, for users who know what they are doing. Make it very obvious you are not creating extra burden on them for just your use case. The problem with an option to build and install is that it makes it so they have to support static linking in lots of other use cases, which it doesn't seem they want to do.
I'd be interested to hear if static linking GTK even has that many benefits. From what I have seen, the library may not play so well with LTO.