SrainApp / srain

Modern IRC client written in GTK
https://srain.silverrainz.me/
Other
302 stars 34 forks source link

[gtk4] libadwaita implementation #220

Open okias opened 4 years ago

okias commented 4 years ago

Thank you for great IRC client (and replacement of aged and not maintained Polari).

Would you consider use libhandy and allow adaptation for smaller screens (phones, tablets or just using it on desktop with small width)?

Attaching materials which you may be interested in, it would be really great if we had such a nice IRC client on mobiles!

[1] https://tuxphones.com/tutorial-developing-responsive-linux-smartphone-apps-libhandy-gtk-part-1/ [2] https://tuxphones.com/linux-smartphone-app-design-gtk-gnome-tutorial/

EbonJaeger commented 4 years ago

Why do people insist in trying to force desktop applications on mobile devices? Please don't force libhandy on Desktop users. It's stupid.

okias commented 4 years ago

Today is difference between mobile and desktop application UI. libhandy is small library used by GNOME to adapt apps to mobile screens and work is ongoing to integrate most of it into GTK+4.

I don't see any harm.

Desktop application (due to fact it runs on laptop) also needs to be optimized to be power-efficient == reusable on mobile. libhandy is small library and integration of it doesn't visibly impact readability or code performance

I see it as win-win situation, but maybe I'm missing something. Can you give me your insight why you think it'll harm desktop users?

EbonJaeger commented 4 years ago

There are a number of reported issues with GNOME of desktop applications switching to mobile view when they shouldn't. Because of the significant differences between a traditional desktop application and mobile devices, there are exactly 0 areas where it makes sense to have the same program code for both implementations. Doing that just ensures a crappy experience for all users.

okias commented 4 years ago

I understood you had issues with software using libhandy, I myself haven't experienced yet any bad behaviour. Can you point out to bug reports you mentioning?

SilverRainZ commented 4 years ago

I have been following libhandy. I like its responsive UI which not only suit for mobile but also for window manager user (If your app only owns a small pane on screen). So, I will get libhandy integrated in the future, but note that it is not a high priority task.

EbonJaeger commented 4 years ago

I still think you're trying to solve a problem that doesn't exist, using a library that specifically targets phones and is not in any stable state, but I doubt I'll change your mind. Shame.

TraceyC77 commented 4 years ago

Speaking as a professional software tester, here's my 2 cents about adding libhandy to srain. Anytime you add additional code (especially external code) it adds complexity which adds to the risk of regressions, bugs, and other unintended consequences. It also brings in more complexity with code maintenance over time. Therefore there has to be enough benefit to outweigh that risk. My questions would be:

okias commented 4 years ago

IMG_20200331_231259

right now it could use some polishing :) (Librem 5 devkit)

SilverRainZ commented 4 years ago

Wow! Srain can run on librem5 without any patch?

ZachBacon commented 4 years ago

Well yeah, for all tense and purposes it's basically a desktop linux environment with a smooshed up screen, But if you're going to implement libhandy integration, because of various bugs etc, may I suggest adding a build option in srain so that distributions that are avoiding the use of libhandy can compile without it?

okias commented 4 years ago

@SilverRainZ yes, the phone environment is based on just sligtly patched GTK 3 (and also it can work with regular GTK). It kinda remaind legendary Nokia N900, but Nokia patched GTK+2 a lot these days. L5 has actually just optional patches to improve mobile experience.

@ZachBacon libhandy implement adaptive widgets, which behave same way on desktop as classic GTK but also adapt layout when required. I don't think libhandy is even optional for GNOME Control Center since 3.36. When you use app as you do now, you shouldn't see difference, only when you resize under specific size, UI is changed. Also GTK 4 integrate most functionality of libhandy, so with that attitude you couldn't migrate to GTK 4 at some point.

Srain has normal regular UI which is not rocket science, so if you have something against libhandy, write concrete example what implementation part will cause which issue for you.

EbonJaeger commented 4 years ago

I don't think libhandy is even optional for GNOME Control Center since 3.36.

It is still optional. I misunderstood their meson file, it is statically bundled.

When you use app as you do now, you shouldn't see difference, only when you resize under specific size, UI is changed.

And what about on my 1360x768 monitor? Or what about people that only want the application on half of their screen? Having a mobile layout when on desktop is a bug and should be considered as such.

Also GTK 4 integrate most functionality of libhandy, so with that attitude you couldn't migrate to GTK 4 at some point.

I'd be more apt to trust a native GTK implementation (even if it's still a stupid concept) than whatever it is the Purism guys are doing. Lemme say it again: no stable releases yet and targetting mobile devices.

If you want a mobile app, then write a mobile app and don't gimp desktop user's experiences. Is that too much to ask?

okias commented 4 years ago

And what about on my 1360x768 monitor? Or what about people that only want the application on half of their screen? Having a mobile layout when on desktop is a bug and should be considered as such.

Nothing will change. Only if you scale application under already fixed dimensions (which you can't reach anyway right now).

I'd be more apt to trust a native GTK implementation (even if it's still a stupid concept) than whatever it is the Purism guys are doing. Lemme say it again: no stable releases yet and targetting mobile devices.

If you want a mobile app, then write a mobile app and don't gimp desktop user's experiences. Is that too much to ask?

I don't see reason why write new convergent application [1] (not saying mobile, because when display, keyboard and mouse is connected, you get desktop from phone), when you can painlessly use existing ones?

I don't see who would win, when application is not adapted. No gain or loss for desktop users (if you don't resize under something you aren't allowed to do right now). I'm really trying to understand your stand, but I really miss what is gained by just missing mobile phones market..

I recommend to checking this video (it's half year old, but still valid): https://puri.sm/posts/the-new-libhandy-0-0-10/ also you can try mobile layout when using GNOME Control Center.

[1] https://docs.ubuntu.com/phone/en/apps/design/get-started/convergence

EbonJaeger commented 4 years ago

Nothing will change.

Uh huh. Other "responsive" websites and apps doing the wrong thing at this resolution cause me to be skeptical there.

Only if you scale application under already fixed dimensions (which you can't reach anyway right now).

Wat?

I don't see reason why write new convergent application [1] (not saying mobile, because when display, keyboard and mouse is connected, you get desktop from phone), when you can painlessly use existing ones?

Wat? I have no idea what you're trying to say here.

but I really miss what is gained by just missing mobile phones market..

You're missing my points here entirely, then. I'm saying that if you want your app to be present on mobile devices, then write a mobile app, and not try to force a desktop app onto a completely different platform.

also you can try mobile layout when using GNOME Control Center.

But I'm on desktop. I don't want a mobile layout, ever. It's really that simple!

travankor commented 4 years ago

Optional features are easy to do with the meson build system.

okias commented 4 years ago

Check out this beautiful example of libhandy usage: https://twitter.com/i/status/1277589500462379010

143mailliw commented 3 years ago

Nothing will change.

Uh huh. Other "responsive" websites and apps doing the wrong thing at this resolution cause me to be skeptical there.

Only if you scale application under already fixed dimensions (which you can't reach anyway right now).

Wat?

I don't see reason why write new convergent application [1] (not saying mobile, because when display, keyboard and mouse is connected, you get desktop from phone), when you can painlessly use existing ones?

Wat? I have no idea what you're trying to say here.

but I really miss what is gained by just missing mobile phones market..

You're missing my points here entirely, then. I'm saying that if you want your app to be present on mobile devices, then write a mobile app, and not try to force a desktop app onto a completely different platform.

also you can try mobile layout when using GNOME Control Center.

But I'm on desktop. I don't want a mobile layout, ever. It's really that simple!

They're saying you will never see the mobile layout, unless the window is sized to a resolution that the program will not allow at the current moment, so unless you daily drive your computer at the fantastic resolution of 620x360 you will never, ever see the mobile layout. You will have to intentionally scale the window to a small size (significantly smaller then your 1366x768 screen) to ever see this (or just run it on a phone)

The author of this issue is stating that they do not wish to write an entirely separate program for mobile users when they can adapt this app using libhandy - which on desktop, will continue to use the current spacing, 2 pane view and interface exactly how it is - you will likely never see a change using this framework.

SilverRainZ commented 3 years ago

FYI: https://adrienplazas.com/blog/2021/03/31/introducing-libadwaita.html

okias commented 3 years ago

Since I noticed you already porting to GTK 4, incorporating libadwaita (which already matured) should be pretty straightforward - https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/index.html