I know how hard was to find any working code samples for Gtk3. Gtk4? Maybe, one day... When there will be enough documentation. I'm not against this idea, but I'm just a tiny bit scared. I am, though trying to imitate the look of Gtk4 apps.
I know how hard was to find any working code samples for Gtk3. Gtk4? Maybe, one day... When there will be enough documentation. I'm not against this idea, but I'm just a tiny bit scared. I am, though trying to imitate the look of Gtk4 apps.
I tried multiple things already but am a total noob with Python. I tried using gi.require_version('Gtk', '4.0') but it wouldn't run on my machine. I also tried creating a GTK4+LibAdwaita application from GNOME Builder, but couldn't figure out how to include the LBRY SDK, since it's a binary.
It's harder than I thought it would be, since the LBRY isn't like an SDK but more of a "server for your application" and "client to the LBRY network" and not an actual SDK that you call from your program.
I tried multiple things already but am a total noob with Python. I tried using `gi.require_version('Gtk', '4.0')` but it wouldn't run on my machine. I also tried creating a GTK4+LibAdwaita application from GNOME Builder, but couldn't figure out how to include the LBRY SDK, since it's a binary.
It's harder than I thought it would be, since the LBRY isn't like an SDK but more of a "server for your application" and "client to the LBRY network" and not an actual SDK that you call from your program.
You can call it regularly. We were doing it before. But we found that using the server interface was much, much faster than calling it directly. So we are calling it directly.
Maybe, one day, GTK4 will be standard enough so it would be supported on a lot of systems, then we will move over to it.
See, the problem is, we are not compiling it, the software assumes that the user has everything installed. Gtk3 is old enough to have this confidence. Gtk4 not yet. But Gtk3 can look very close to Gtk4. So this why I think, meanwhile we are going to stick to Gtk3.
You can call it regularly. We were doing it before. But we found that using the server interface was much, much faster than calling it directly. So we are calling it directly.
Maybe, one day, GTK4 will be standard enough so it would be supported on a lot of systems, then we will move over to it.
See, the problem is, we are not compiling it, the software assumes that the user has everything installed. Gtk3 is old enough to have this confidence. Gtk4 not yet. But Gtk3 can look very close to Gtk4. So this why I think, meanwhile we are going to stick to Gtk3.
I see FastLBRY is built using GTK3, why not use GTK4 and Libadwaita instead? Python/PyGObject seems to support that technologies.
I know how hard was to find any working code samples for Gtk3. Gtk4? Maybe, one day... When there will be enough documentation. I'm not against this idea, but I'm just a tiny bit scared. I am, though trying to imitate the look of Gtk4 apps.
I tried multiple things already but am a total noob with Python. I tried using
gi.require_version('Gtk', '4.0')but it wouldn't run on my machine. I also tried creating a GTK4+LibAdwaita application from GNOME Builder, but couldn't figure out how to include the LBRY SDK, since it's a binary.It's harder than I thought it would be, since the LBRY isn't like an SDK but more of a "server for your application" and "client to the LBRY network" and not an actual SDK that you call from your program.
You can call it regularly. We were doing it before. But we found that using the server interface was much, much faster than calling it directly. So we are calling it directly.
Maybe, one day, GTK4 will be standard enough so it would be supported on a lot of systems, then we will move over to it.
See, the problem is, we are not compiling it, the software assumes that the user has everything installed. Gtk3 is old enough to have this confidence. Gtk4 not yet. But Gtk3 can look very close to Gtk4. So this why I think, meanwhile we are going to stick to Gtk3.