search

gtk-rs / gtk3-rs

Rust bindings for GTK 3
https://gtk-rs.org
MIT License
507 stars 90 forks source link

Split gtk3 crates out of gtk-rs #519

Closed bilelmoussaoui closed 3 years ago

bilelmoussaoui commented 3 years ago

This is a proposal to split the following crates out of the main mono repo and move them to a gtk3-rs repository, similar to the gtk4-rs one.

The reasoning behind is that they end up very confusing to the end-user, especially for crates that links to the glib/gio docs and now the user is on a completely different docs source and might get confused of why they can't find something anymore.

There are various things to think of before doing such change:

The result post proposal:

GuillaumeGomez commented 3 years ago

That seems weird: why would we move the sys repositories outside? Also, if people look for the repository, they can simply look in the crate information.

For the macro crate though, I don't have opinion.

For the examples, they were in their own repository before and it ended up being quite tricky to handle (in the CI mostly). Not sure this is a good idea to move them out.

bilelmoussaoui commented 3 years ago

That seems weird: why would we move the sys repositories outside? Also, if people look for the repository, they can simply look in the crate information.

Not move them outside, just move gtk3 specific crates from the main mono repo, the same way the gtk4-rs mono repo is handled

For the examples, they were in their own repository before and it ended up being quite tricky to handle (in the CI mostly). Not sure this is a good idea to move them out.

That's true, no opinions on that

ids1024 commented 3 years ago

I suppose the other alternative would be to move gtk4 intro this repo as well. Definitely doesn't make sense for gtk3 to be in this repo but not gtk4 (now that gtk4 is released).

gobject-rs/whatever-new-name-rs?

"gobject-rs" seems like a strange name for a repo containing gio, let alone things like pango and cairo (gtk-rs makes a bit more sense, because it's gtk and its dependencies). Not really sure what would be better.

bilelmoussaoui commented 3 years ago

I suppose the other alternative would be to move gtk4 intro this repo as well. Definitely doesn't make sense for gtk3 to be in this repo but not gtk4 (now that gtk4 is released).

No that's just a very bad idea for the docs :) now whenever you look for a Gtk::Button, you would get two of them.

ids1024 commented 3 years ago

Looking at https://docs.rs/futures-core/0.3.14/futures_core/, it doesn't seem to have the docs for futures or other crates in the same repo, and running cargo doc in gtk-rs/glib doesn't generate docs (or show search results) for anything in gtk.

So I don't know how http://gtk-rs.org/docs/gtk/ is currently being generated, but it looks like having them in the same repo and cargo workspace wouldn't necessarily affect the generated docs.

bilelmoussaoui commented 3 years ago

Looking at https://docs.rs/futures-core/0.3.14/futures_core/, it doesn't seem to have the docs for futures or other crates in the same repo, and running cargo doc in gtk-rs/glib doesn't generate docs (or show search results) for anything in gtk.

So I don't know how http://gtk-rs.org/docs/gtk/ is currently being generated, but it looks like having them in the same repo and cargo workspace wouldn't necessarily affect the generated docs.

Except we can't use docs.rs because of the whole lgpl docs situations which requires re-writing files which isn't possible anymore. So the docs will be built as part of the CI and published separately for git/stable releases

sdroege commented 3 years ago

I think that's a good idea if you can come up with a good name for the repo that contains the non-gtk pieces.

pbor commented 3 years ago

As far as I understand the name would just be the repo and would have no effect on the crates on crates.io which is what users would see

sdroege commented 3 years ago

In the C library the glib repo contains glib, gio, gobject etc... so maybe glib-rs is ok?

It doesn't contain cairo and pango though :) But I think this would be OK, yes.

pygobject is a precedent about using gobject for the entire gir based bindings

That's not really true. Previously (before gobject-introspection), there was also pygtk and many others. And now it's all just pygobject because for getting bindings for other libraries you only need to install (from that library) the .typelib file. Except for cases like GStreamer (there's still a gst-python!) that brings pygobject overrides.

GuillaumeGomez commented 3 years ago

glib-rs is too focused on glib in my opinion. What do you think about gtk-rs-foundation? :3

pbor commented 3 years ago

foundation seems ambiguous with organizational stuff (think Rust foundation etc), so if we go with a suffix, I think -core may be better... however :shrug: your call :-)

GuillaumeGomez commented 3 years ago

I prefer gtk-rs-core (I precise: I'm very bad with picking names).

sdroege commented 3 years ago

Sounds good to me

sdroege commented 3 years ago

This is done and finished now or not?

sdroege commented 3 years ago

No, all the issues still have to be moved. Would've been more clever to rename the original one to core, remove gtk/etc and then create a new one for gtk3-rs. Most issues and PRs are for non-GTK things.

bilelmoussaoui commented 3 years ago

Still needs https://github.com/gtk-rs/gtk-rs-core/pull/1 & moving the corresponding issues to the new gtk-rs-core repository

sdroege commented 3 years ago

@bilelmoussaoui This is done now or not?

bilelmoussaoui commented 3 years ago

@sdroege let's say it's done, there are still missing labels for all gtk-rs-core issues but that can be done separately