feat: in-app browser

[GeopJr]

This is the third GTK browser I've had to write, let's hope it's the last one.

Anyway, in-app browser when enabled. UI switch is missing but Tuba has a dconf entry.

Package maintainers that want this enabled, will have to have webkitgtk available at compile time, just like with clapper, gstreamer, libspelling etc. This is optional, Tuba will work just fine without it.

The progress bar turned out better than expected :)

[GeopJr]

@bragefuglseth quick question, should the headerbar icon that closes the in-app browser be a 'back' button?

I'm afraid people will think it goes to the previous browser page and accidentally close it.

The design is inspired by the android webview, which uses an X icon but I'm unsure if that will also be confused for the window close button (however window controls are disabled)

At the same time, I feel that the back button aligns more with our hig as it follows the NavigationViews (even though this is not one, but looks like one).

[LukaszH77]

I'm afraid people will think it goes to the previous browser page and accidentally close it.

Well... I know what this button does, and yet I've accidentally closed the built-in browser a few dozen times and had to go back to the page I was on. The power of habit is strong.

[LukaszH77]

BTW: I think back and forward buttons could be very useful in the in-app browser. On Android they are hidden in the ⋮ menu to keep the UI clean and simple. Can we have something like that in Tuba?

Nvm, I'm dumb.

[GeopJr]

Maybe a dialog would be better UX-wise? 🤔 But then you compromise on brwoser space...

[bragefuglseth]

I think a dialog with a large enough maximum size (potentially no maximum size at all) would work well here, in addition to solving the arrow button problem for free.

[GeopJr]

Thanks!

I don't think there's a way to make it use as much space as possible, though we can listen to the window size, maybe?

The bottom sheet looks nice but I'm still a bit unsure about the floating one

[bragefuglseth]

I don't think there's a way to make it use as much space as possible, though we can listen to the window size, maybe?

Eh, a large natural size should do the trick. FWIW I think the screenshots look good; the dialog does a better job at reflecting the ephemeral nature of the view than the navigation page did.

[LukaszH77]

I like it. At first, I was worried that it wasn't enough space, but after testing it for a while, I think it's ok.

BTW: Shouldn't this dialogue be closable by pressing Esc?

[GeopJr]

Eh, a large natural size should do the trick

Only thing that worries me about that is that AdwDialogs can become regular modals under some circumstances or when the platform adds supports for it (https://gitlab.gnome.org/GNOME/libadwaita/-/issues/801) and the 1200 default size I've set might be too large then. I'll see if there's a way to check if it's a modal and use the main window's size as the default then.

BTW: Shouldn't this dialogue be closable by pressing Esc?

I disabled it because it will probably not work from browser world (if you are focused in a webpage, that gets control of most keyboard stuff), but I'll test it out and see.