-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gintro install may fail for Arch Linux #209
Comments
Well, actually there is some progress. We manage to get an Arch Linux box for testing, and found out that recent Arch Linux ships a libnice which uses already libsoup3. Most other distributions including our Gentoo have a libnice using libsoup2.4 still, and this generates all the libsoup2/libsoup3 trouble. As Mr. Jens Georg told us in https://discourse.gnome.org/t/libnice-should-have-libsoup-as-depency/9320 libnice does a hidden indirect import of libsoup by gupnp. So the suggested solution is to process gupnp, finding out which libsoup version it is using by a call of g_irepository_is_registered(gi, "Soup", "2.4"), and then proceeding in a safe way adapted to the local box. This should work for most library combinations. One problem, which we can not really avoid currently, is, that a box with a libnice using still libsoup2.4, but with installed webkitgtk2 v4.1, and no webkitgtk2 v4.0, will get no webkitgtk2 support for GTK3. But it will get webkitgtk2 support for GTK4 if that lib is installed, and when the user manages to additional install webkitgtk2 v4.0, then that version will be available for Nim too. This should be good enough for now -- soon libsoup2.4 should vanish, and all will become much simpler again. Currently this is our strategy, we have to test it still. |
I'm on Fedora Silverblue and getting this same libsoup2/3 error. Fedora usually ships newer packages, too. nimble install gintroDownloading https://github.com/stefansalewski/gintro using git preparing gintro --2023-07-21 18:34:57-- https://raw.githubusercontent.com/StefanSalewski/oldgtk3/master/oldgtk3/gobject.nim Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 2606:50c0:8003::154, 2606:50c0:8000::154, 2606:50c0:8001::154, ... Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|2606:50c0:8003::154|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 108015 (105K) [text/plain] Saving to: ‘gobject.nim’ |
Thanks for reporting. So is there really a libsoup issue again? Actually, I heard from some people, that gintro does not installs with latest Nim compiler at all, there seems to be some tuple unpacking issues. That unpacking have worked for 8 years without problems, so my feeling is that they may broke it by intent. For gintro, I have not really used Nim in the last 12 months. I have still an old install with a working gintro at least. But I don't think that someone still really intends to use gintro any longer. Or have you created a larger software project with it in the last few years? If not, it may be better to use one of the 20 other Nim GUI toolkits. Some years ago they have advertised Fidget a lot. And I think the other GTK4 one is also interesting, I think its author was named Can Lehmann, and the tool owkettle. He put a lot work in his project, but I am not sure if it is already usable for non-toy projects. I think next winter I will fix the few remaining grammar issues of the book, and maybe let it print at Amazon, so I might do no other Nim work in the new few years. |
Wait.
Are you actually using the latest Gintro package? Did you install as advertised with
I have some serious doubts, as since a year or so, and since the latest libsoup fix, we install GTK3 bindings first. (Of course, above uninstall command may be not necessary, but I am using it to be sure that all old stuff is removed.) When you wonder about @#head, that might be an indication that you have not looked at the README at all -- it is, because Gintro reached version 0.9.9 long time ago already, and we hesitated to make a 1.0. |
I installed I was looking at bindings in other modern languages, but nothing beats Nim in my eyes. I'm specifically in the process of learning GTK, so no big projects, and I probably wont try another framework RN. I'll have a look at Owlkettle, though, it looks really cool! It's probably a good idea to have an explicit disclaimer in the README if your own idea of gintro is that it probably shouldn't be used any longer. |
It is a difficult topic. I have to use it myself still, as I have no real replacement, I have this old SDT project: https://github.com/StefanSalewski/SDT. And doubts that another Nim GUI may be able to replace GTK for it in in the next few decades. But well, SDT is a serious project, started in 2012 in Ruby, then I created Gintro and ported to Nim. My feeling is, that most other Nim users are doing only toy projects, so other GUIs may be good enough and may be more fun. GTK is generally used by only very few people still, look at the Gnome forum, or search for new projects at GitHub: There is nothing. GTK4 has not make GTK more popular. And learning GTK is very much work, I started with GTK in 2006 and still know only parts of it, while I may have spent more than 1000 hours for learning, started in 2007 with the book of A. Krause. I think there are two people who really know GTK -- E. Bassi and C. Larsen. Bassi is still on the Gnome forum. As you may know, beside the Nim book, I started writing the GTK4 one, which is still only 25% finished, and I think I will not continue with it, as no one is really interested. Maybe in next winter i will remove Gintro from GitHub, should be OK as I have the feeling that no one is using it still. Personally, I have some hope for a new Rust GUI, they have money, manpower, and motivation. I think they have at least two projects, both in very early state still. But when one of them will make good progress, I may find motivation to port my SDT to Rust? |
Yeah, a lot of people are going to Rust for exciting GUI and other rendering things. It's a shame you can't do bindings for Rust libraries as easily as for C libraries...
I suggest you not to remove it completely, but add some notice of abandonment or something similar, and if you're planning to stop updating it archiving the repo. The codebase of Gintro might still be useful for someone down the line. |
Recently there have been again vague hints that gintro install may fail for Arch Linux, maybe due to the libsoup v2 vs. v3 issues. Unfortunately we have not been able to reproduce this, or have been able to guess a possible reason. Currently, we have not the time available to set up a Arch Linux box to prove this issue. So when you should have problems with Arch:
Do
nimble uninstall gintro
nimble install gintro@#head
And report the result as detailed as possible. Or even better, try to find the reason for the issue yourself. If you should be able to prove that there are at least a dozen people that have a high demand to use gintro, but suffer from this issue, them we may actually install Arch Linux ourselves and investigate the issue in detail. But for one or two people, that may just try out gintro, and would not really use it, we can really not do such an expensive task, sorry.
The text was updated successfully, but these errors were encountered: