[Sugestion] remove libsoup #193
Comments
Well, the "no one" are you! For me, it works with the libs shipped with Gentoo Linux, and the libs installed from git. Well at least after the fix of the order of install, which we did about 6 months ago. I got no complains from other gintro users. To test it myself, I would have to do a Arch Linux install myself -- unfortunately I have currently only one working box, an Intel NUC, which SDD is not that large. For you, it was suggested that you may try to change the order of install as well to find out if that helps, I think you never replied to that suggestion. For our first issue, it helped to move libsoup upwards, so it was my hope it may help again. For libsoup itself, I do not even know currently what it is, but someone requested it. So you may look at the closed issues and contact him and ask if he still needs it. For the rewrite: Yes seems to be necessary with the behaviour of gobject-introspection which we learned the hard way. A rewrite should be possible, but is some work. I would guess that it may take 100 hours, for a really smart one maybe less. I think I will not do it, as long as I am not concerned myself. As you know I spent 1600 hours on gintro -- hope was to get at least a few dozen users. But one, or as you said two or three, users is really a bit less. And I have really no hope for gintro: The total number of GTK users is tiny. The Gnome forum lists "Views" for posts, views is generally a few dozen only, and users of forum generally only complain about existing Gnome products, there is nearly no one which is developing new software in GTK. My hope was really that GTK4 would have improved the situation, that was the reason why I started the GTK book. But it had not. In the last months I have done some Google and github search for people working on new GTK projects, but I found really nothing. It is really a bit sad. For me personally, I would be willing to donate 1000 Euro, maybe a bit more, for some high quality rewrite of Nim GTK bindings by some experts, maybe based on the Rust bindings. When we could find a few dozen others donating a similar sum, or a sponsor like Gnome or Mozilla foundation, a complete rewrite would be still possible. But of course, as we have 20 GUI toolkits for Nim, Araq does not like GTK but recommends fidget, there is not much hope for GTK. Have you observed Nim in the last months? I did not really, after all the anger with Mr. Rumpf and his fanboys. Have you an idea what the reason for that hard fork skullnim is? I think Disruptec finally left Nim? And the others like mratsim, have you seen him in the last 12 months? In Christmas holidays I looked at the history of Nim PRs, saw so many names from my early Nim days who disappeared... But well, I think I will finish the book, it is already 60% done. I have the hope that it will make starting with Nim for beginners easier, maybe then Nim will become again more popular. And for the gintro rewrite -- actually I can not promise that I will not do it, as I did so many stupid things in all the years. But again, that may break stuff, which no one noticed due to no users, and then in a few years people may complain that they have a project from 2017 that do not work in 2025 any more. Have you thought how we can use the gisup files when we would do a rewrite? I think in one of the last issues I discussed that, can not remember details. A separate gisup for each lib? Or a macro, which delivers the needed info during the compile process using gobject-introspection queries? Have you ever tried processing the GIR XML files directly without gobject-introspection? Some people suggested that, but I have no experience with parsing XML. Would be some gobject-introspection rewrite I assume? Have to do some work now, bye. |
|
This is not only OP's problem. I run into the same problem with the libsoup2/libsoup3 conflict and thus can't install gintro via nimble (I'm on Manjaro, an Arch derivate). |
Are you an experienced programmer, or in best case a Nim or GTK expert? That would really help. I think the first step in investigating this issue would be to find the actual library that is causing the error. It is not libsoup itself, it should be one of the modules processed before. So for people with at least some basic Nim experience, the task would be to move processing of libsoup upwards -- in other words, remove processing of all other libs, then we strongly assume processing libsoup works, then add other modules until libsoup breaks. That way we found one module that have to be processed after libsoup some months ago, but for Arch Linux there seems to be one more now. We had a discussion on the Gnome forum that time. Note that we have a different, harder issue also: That one was related to name conflicts in the mconnect macro, we had introduced a really ugly fix to make it working again, biggest problem was using tuples as optional argument for connect() macro. Our guess was that when we rewrite mconnect() to use plain AST manipulation instead of current text manipulation, we could avoid the name conflicts. Unfortunately I am not that good with Nim macros, have not much experience. Just used text manipulation 5 years ago because that was a way to get it working that time -- no one was willing to help. Are you able to rewrite mconnect() using pure AST manipulation? Have not to be now, so you can learn some more about Nims metaprogramming and maybe do it in Easter holiday this year? For the reason why we have libsoup at all in gintro, I have still no idea. I started with the most basic libs five years ago only. But then people requested more modules -- libnice and gstreamer was really hard to support. Well I should not have accepted all the requests, but now we have all the mess. I can still not remember what libsoup really is, one guess is that webkitgtk needs it. And webkitgtk was requested by Mr Dingle or Mr Bacon, from the famous Dingle/Bacon paper which was discussed for Nims GC. |
|
Gee, you can't just a programmer if they are experienced. Imposter syndrome is real. Jokes aside, I have some experience in programming, also with Nim and I've even did some experiments with macros. Still I would not call myself an expert. I'm not very familiar with GTK, though I've dabbled in it. Sure, I'm interested in all of it but sadly my time is quite limited. But yeah, I've read what you've written and will see if I can find the time to help. |
Honestly then I can not really recommend you using gintro at all. Learning GTK is such a lot work, I have not managed it in all the years, I started in 2007 with the book of A. Krause. So if you not really need GTK, just use one of the other 20 Nim GUI toolkits, at least for toy-apps most of them should work, and at least for fidget you may get some support from the Nim community. |
|
Well, thanks for the heads-up! "Not very familiar" might have been an understatement on my part. I have a good idea of what I'm getting into. I've worked with GTK and Glade before, also in other languages. What I meant is that I do not have deep knowledge of the internals of GTK (which would be required to be called an expert, IMHO) but I'm somewhat familiar with its API. As for the other GUI libraries: actually I do want to use GTK since I'm on Linux and it fits quite nicely. Additionally, there might be some form of nostalgia involved. |
|
Yes, I think then it is OK to still use GTK, I do it myself. But we are a tiny majority, I do know no one who started learning GTK in the last 10 years and then created a new, none toy app. Well the guy from carrot industries is close, with his Horizon EDA app, written in gtkmm. But I think he started more than 10 years ago, he is really smart, but I do not understand, when he likes C++, why he has not choosen Qt. And people still knowing GTK: Mr. Bassi, and maybe Mr Droege and Mr Clasen from Redhat. Really not many any more, and I was told that Mr Bassi is not longer employed by the Gnome foundation. So there is not much hope for GTK. And caution, Glade does not really work for GTK4. |
Yea, now there are 2 project in development for wysiwyg editors. The first is by author of original Glade is Cambalache - https://gitlab.gnome.org/jpu/cambalache |
|
Yes I know that Mr. Bassi is still active in the Gnome forum. He is Mr GTK, I think he has answered 90 % of the questions in the last five years. But it is strange that he was fired, while the Gnome foundation seems to have still other paid people. That GtkSourceView is still under development is interesting news for me, as I used it many years ago for my NEd editor. |
|
I mean SourceView for GTK 4, its SourceView 5, the last thing he working on is vim mode. |
Have you an idea what this sentence may mean? I have no idea. |
|
will separating |
Please note, the actual discussion is here: #190 And I recently had a discussion with Mr. Droege at gnome forum: https://discourse.gnome.org/t/will-dlclose-reset-internal-state-of-libgirepository/8963 To your question, the process of generating gtk3 and gtk4 modules had been separated from the beginning, that is indeed necessary for the same reason. You can see the separation when you look into the nimble file and into the generator script gen.nim. We use two separate processes for generating the gtk3 and the gtk4 modules set. From the latest gnome forum discussion it should be clear that this problem is really hard. It is in principle not restricted to libsoup, but currently it is visible only with libsoup and for Arch Linux users. From the gnome discussion my feeling is, that it is mostly an issue of gobject-introspection and the Arch distribution shipping a consistent library sets. Unfortunately I would have to buy a new box and install Arch Linux to investigate it. The other problem is our motivation: We have currently nearly no serious gintro users, after all these years and all that work, and no hope that we ever get more users. So currently I spent most of my spare time in finishing the Nim book, the book had at least a few readers, and I still have some minimal hope that it may get more readers. |
|
I just took a brake from book writing, and so did some investigations of this issue again, and I had an idea, which turns out not working. But for my Gentoo box, with additional ONLY libsoup installed from git sources to /opt, all works fine. I can even modify the order of installs, and for example put libsoup to the bottom. All works fine. For details see https://discourse.gnome.org/t/libnice-should-have-libsoup-as-depency/9320/6 So I will hope that for ArchLinux it will work now, or soon also. Unfortunately nimble allows no parameters, so there is no good solution for people with problem to pass a parameter to skip libsoup or libnice, maybe even webkit. Maybe we can use environment variables instead of parameters? I just tried to fix the latest issue with #200 which resulted from a rename of uref to unref of latest gobject. For me it works again, I hope my fix will not break it for people with older gobject. I will push that change tomorrow. |
|
Well, after the discussion with Mr. Jens Georg at Gnome forum, we get the impression that latest libnice is the real, and hopefully only problem. So I would assume that when we remove libnice from the GTK4 process, in which libsoup3 is processed, the problems should disappear. The disadvantage is, that then users could not use libnice together with GTK4, as the connect strings for libnice in gisup4.nim will be missing. We may later somehow fix that, but for now we have to verify that removing libnice will really fix the issue. I will push a patched gen.nim file to github in the next days. |
|
We have just applied the uref/unref fix which was necessary for latest gobject, and we removed libnice from the GTK4 process. Seems to work now. The only disadvantage is, that users can not use libnice with GTK4 currently. But we have not that many libnice users at all. And when libnice may much much later decide to use libsoup3, we get new trouble. Another possible solution is to use g_typelib_free() when processing libsoup and libnice, but that has other issues, and may not work for Windows and Mac, see https://discourse.gnome.org/t/libnice-should-have-libsoup-as-depency/9320/13. Please test with nimble uninstall gintro |
As far as I understand, no one can use gintro 9.7 now because of a problem with libsoup((process:10495): libsoup-ERROR **: 00:05:16.306: libsoup3 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.), a simple solution is to clone the repository and delete libsoup lines from gen.nim. So to solve the problem, a significant gintro reworking is required, which is not expected, I suggest simply deleting libsoup. I dont think anyone need it, since nim has plenty of network libraries.
The text was updated successfully, but these errors were encountered: