3 ms·
> So you'll end up with awkwardly large and cumbersome controls for mouse users and to small and finicky controls for touch users to interact with. GTK+3 gives
by 0815test 7y ago
> So you'll end up with awkwardly large and cumbersome controls for mouse users and to small and finicky controls for touch users to interact with.
GTK+3 gives you touch-sized controls anyway, even on mouse/keyboard-only systems, and it works quite well - at most, it adds one or two steps for rare operations (click a hamburger menu, whatever) compared to a solely mouse-focused interface. They were striving to be "touch-ready" from the very beginning, and managed it quite well.
It is really only e.g. dragging/swiping that works very differently between touch and mouse interfaces. And of course mice come with extra buttons and scroll controls that make up for that.
- aequitas 7y ago> It is really only e.g. dragging/swiping that works very differently between touch and mouse interfaces. And of course mice come with extra buttons and scroll controls that make up for that. It's this that I think will be the problem. Normal buttons and textfields will probably be usable on both control systems. But if you want to leverage the advantage of one of the systems you loose out on the other. So you either have to develop your UI twice or leave on of the two with a lesser experience. If Apple should go through with this I hope they will set strict requirements in the store guidelines that ensures lazy app makers provide a proper experience for both kinds of controls.
- derekp7 7y agoA couple good examples: When you touch the screen, and drag, the mouse equiv. action is clicking the button and dragging. But with touch, in many cases you want the screen to scroll, whereas with the mouse you want to select / highlight text. Also, with touch you don't have a "hover" operation, so you have to make "click" (touch) initiate a "hover" type of action in some cases, but in other cases you want touch to actually be the same as a mouse click.
- Crinus 7y ago> GTK+3 gives you touch-sized controls anyway, even on mouse/keyboard-only systems Which is my biggest (in both interpretations) issue with Gtk3: Gtk2 already had oversized controls compared to Windows that wasted a lot of screen space, but Gtk3 took it to another level. > it works quite well All UIs that use Gtk3 i've experienced suck to the point where i try to avoid anything that uses that toolkit. I saw that Geany -the editor i mostly use when on Linux - switched to Gtk3 and i fear for the moment it'll drop on Debian. I have a Debian VM with everything i need preinstalled, just in case, but this is a stopgap solution - i'll need to find some other editor. I'm not a fan of Qt but i think Qt5 applications can be made to not waste as much space as Gtk3. Or i can go back to NEdit. The main things i'll miss is a sidebar to browse the files from and some sort of toolbar to launch stuff from. > They were striving to be "touch-ready" from the very beginning, and managed it quite well. Where "quite well" really means "made it worse for desktop only, keyboard and mouse only users". Gtk3 is a disaster. Gtk2 was the last decent version and that was mainly because everyone had agreed to target it as a de-facto standard for Linux GUI applications, otherwise it had several issues itself. Of course the Gtk3 devs shat the bed (i'm not even sure if the Gtk3 devs are the same people as the Gtk2 devs, i cannot imagine the same people making such awful decisions) by breaking backwards compatibility, breaking theming, forcing smartphone interaction on everything in an attempt to mimic Apple's success with iPhone as if people with iPhones would suddenly switch to Gnome because of its oversized buttons, huge icons and boulevard-wide gaps between everything. If you cannot tell, i don't like Gtk3 or Gnome3 or anything associated with freedesktop.org (mainly because most of it comes either from Gnome people or people who design things like Gnome). I'd be on the KDE bandwagon but their reliance on Qt means they rely on the whims of a corporation whose primary interest is not in maintaining a stable desktop environment API but on providing a toolkit for whoever pays them (which is fine for Qt, but breaking changes sucks for a platform like KDE). And it isn't like they're free from freedesktop.org infestation either. Perhaps adding theme support to Motif will be what saves us all.
- 0815test 7y ago> Gtk2 already had oversized controls compared to Windows GTK+2 can actually be run with a Windows 9x/2000 widget theme ("redmond9x" IIRC). It's a tiny bit more compact, but just doesn't save a real amount of space compared to the default look. Unfortunately GTK+3 has moved to CSS which was probably necessary for things like proper support on high-DPI screens, but has broken the existing theming support altogether. I do agree that the current lack of a "compact" mode for touch-free, mouse/keyboard-only use is a bit of an annoyance. But, like you, I don't necessarily view Qt as being all that better. And the default Adwaita theme in GTK+3 is tolerable enough.
- Crinus 7y agoYou do not need CSS for proper high-DPI support, you just need a scale factor for your windows that your code doesn't ignore. AFAIK this is what Qt5 does. Also AFAIK Gtk+3 cannot do real scaling and instead pretends the display is always a low DPI device and applies integer scaling to everything - their "fractional scaling" is really rendering with integer scaling upwards to a bitmap which is then downscaled (AFAIK^2 this is only done on Wayland because they rely on the compositor for that even though there is nothing that forbids them doing it on X11 too - but i guess they need to push their awful tech somehow). This is where things such as "there are no half-pixels" come from when they talk about fractional scaling. FWIW personally i use the OneStepBack theme for Gtk3 because it makes the controls actually visible (especially your selection in menus, tabs, etc that isn't just a blue line beneath the control) and saves a bit of screen space.