search

0x6d61676e7573 / gtk-weechat

GTK3 client for weechat, ported from qweechat.
GNU General Public License v3.0
21 stars 2 forks source link

Add support for adaptive UI layouts #6

Open craftyguy opened 3 years ago

craftyguy commented 3 years ago

The app's layout doesn't really adapt to smaller displays (e.g. mobile screens in portrait mode). It would be great to port it to use libhandy, which would make it look good on a variety of display sizes.

I'm not sure if you have any experience using libhandy or not. I don't, but can take a look at trying to port this app to use it if you aren't interested.

0x6d61676e7573 commented 3 years ago

Hi! I did not know about libhandy until now. It seems like a worthwhile project. It seems that it would mainly involve switching to another set of container widgets. Sadly I do not own neither a purism phone nor pine64 and they seem constantly out of stock, so I don't know how to test software against a mobile device.

craftyguy commented 3 years ago

You don't need a mobile device to test changes to the UI, you can simply resize the window and it should be usable when it is rendered at smaller dimensions.

I took a cursory look at the UI code in this project, and was able to get a quick POC working with libhandy's leaflet widget, though it's far from perfect. What I've been playing around with is here: https://github.com/craftyguy/gtk-weechat/tree/libhandy If you shrink the window's width, eventually you'll see the buffer list on the left go away. It can be shown again by tapping the newly appeared 'buffers' button at the top, and tapping that button again or selecting a new buffer in the list to switch to will hide the buffer list. The nick list should probably be implemented in a similar way, but it was not going to be easy due to how BufferWidget is in a Gtk Stack.

I think that instead of using a Gtk Stack widget with all the buffers, there should be 1 box for the current buffer (and 1 for the current buffer's nick list), and the contents of the box are replaced when the user switches to view another buffer. I don't see an easy way to port the stack layout used today, and I think the stack layout causes further performance issues on underpowered devices too (but I haven't profiled it to be sure)

I'm interested in your thoughts though, since I've only spent a couple of hours looking at the UI portion of the codebase, and you're much (much) more familiar with it than I am. I'm also an extreme newbie to libhandy, so my branch may not be doing things the best way... I used some example projects I found to get an idea for how folks use the leaflet widget.

craftyguy commented 3 years ago

Ah here's an example of how you could test an adaptive UI on a desktop system, without a mobile/small display: https://www.youtube.com/watch?v=kTwzNiAJ6Os

0x6d61676e7573 commented 3 years ago

Awesome! I like where you are going with that code. I'll have to look more carefully into it to figure out how to rewrite the code but I guess without the stack there are two options 1) some other container where widgets are removed and inserted when buffers are switched 2) just have 1 widget of each kind and switch the data buffers that connects to the widgets instead of switching between widgets, e.g. only one TextView widget that connects to the different TextBuffer's that hold the buffer data, instead of having one TextView widget for each buffer as it is done currently.

It seems to me you are alluding to scenario 2) but correct me if I'm wrong. I imagine that would be the more resource efficient implementation.

craftyguy commented 3 years ago

Yeah I was thinking about scenario 2, specifically because I suspect it would be more efficient (which would be most noticeable on underpowered devices..).

I'm playing around now with libhandy/gtk3 on another simpler project to get a better idea of what widgets might be helpful here, since I'm quite the gtk/UI novice at the moment.