5 ms·
TIL: about the rope data structure[1]. Never heard of it in decades in the industry. Disagree with the comment "Cross-platform UI toolkits never look and feel
by fernly 11y ago
TIL: about the rope data structure[1]. Never heard of it in decades in the industry.
Disagree with the comment "Cross-platform UI toolkits never look and feel quite right." Qt, for one, uses the native toolkit on Mac and Windows and I can't see a difference in look'n'feel.
[1] https://en.wikipedia.org/wiki/Rope_%28data_structure%29 https://en.wikipedia.org/wiki/Rope_%28data_structure%29
- jdub 11y agoYou can't see it, but boy can you feel it.
- mwcampbell 11y agoAnd you can literally feel it, or hear it, if you're blind. Non-native GUIs are very often less than fully usable, or even downright inaccessible for less common toolkits, with a screen reader. The one exception I can think of is XUL-based apps (e.g. Firefox and Thunderbird) on Windows.
- lmm 11y agoQt specifically has very good accessibility support, no?
- mwcampbell 11y agoQt's accessibility support is only moderately useful in practice. As one anecdote, TeamTalk (http://bearware.dk/ http://bearware.dk/) has a "classic" MFC-based front-end just for blind Windows users.
- pcwalton 11y ago> TIL: about the rope data structure[1]. Never heard of it in decades in the industry. And if you've used JavaScript, you may have been using them without realizing it—JS engines will choose rope representations for strings if they observe that the usage patterns would benefit from them.
- atombender 11y agoI can recognize a non-native Qt right app away. There's something off about it. The project author is absolutely right, cross-platform UIs are terrible.
- coldtea 11y ago>Qt, for one, uses the native toolkit on Mac and Windows and I can't see a difference in look'n'feel. QT interfaces stick out like a sore thumb on the Mac. Unless you custom-skin them to the point that they still stick out, but they at least don't fall into the Uncanny Valley.
- mherrmann 11y agoIs there something in particular that annoys you about Qt interfaces? I'm just launching a Qt app (https://fman.io https://fman.io) and want to avoid any unnecessary annoyances.
- blub 11y agoIt's expected to have rubber band scrolling on OS X and as far as I've seen it's not easy to do it in widget-based apps.
- mherrmann 11y agoI'll watch out for it. Thanks!
- bjz_ 11y agoWeird widgets that you don't normally see Cocoa OSX apps, like toolbars or non-standard file pickers. The worst offenders are those tabbed form widgets with the pill buttons: http://doc.qt.io/qt-5/qtwidgets-index.html#styles http://doc.qt.io/qt-5/qtwidgets-index.html#styles
- mherrmann 11y agoI'll keep it in mind. Thanks!
- coldtea 11y agoI can't tell from this particular screenshot, but things I've seen in other QT apps: widgets don't conform to all OS X standard behaviors (e.g. accepting keyboard shortcuts, scrolling behavior like "rubber band scrolling" etc), custom (Qt drawn) widgets with differing look from platform ones throwing you off, lack of support for new features as they are introduced, like OS X native full screen, etc. I'd say keyboard shortcuts and native widget behavior is the #1 thing though, followed by looks. >Of course there are alternative file managers for other platforms. But none of them make you really go wow. Btw, there are a couple for Mac too, in case you haven't seen them, e.g.: http://www.binarynights.com/forklift/ http://www.binarynights.com/forklift/ , http://mac.eltima.com/file-manager.html http://mac.eltima.com/file-manager.html and http://www.cocoatech.com/pathfinder/ http://www.cocoatech.com/pathfinder/.
- cmrdporcupine 11y agoThe GNU C++ standard library, and the SGI STL before that (where it came from), used to include a rope implementation. I think last time I looked it wasn't there anymore. But I didn't dig deep. https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a00223.html https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USER...
- iso-8859-1 11y agoSeems like it is still there? https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/ext/rope https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/i...
- pjmlp 11y agoJust try a Qt application on mobile OSes, you will see it right away. It doesn't have support for native widgets, everyone has to emulate them via QML.
- zellyn 11y agoYeah, I first heard about them while reading writeups from http://save-endo.cs.uu.nl/ http://save-endo.cs.uu.nl/ and spent quite a while trying to figure out how so many of the contestants knew about them and how I would have found them by Googling (never was successful). I think it would have been easier to find them now in 2016… I've seen lots of implementations floating around :-)
- cm3 11y agoSpeaking as a user only, and someone who sometimes builds software that needs Qt4 or Qt5, Qt is definitely better than Gtk3. It has an odd 30MB base memory overhead for any Qt window, but it just works, it doesn't require you to fix your theme on each Gtk3 release, and it doesn't have many regressions, like black rectangles visible for each window upon creation, before widgets are visible. It also didn't break its file selector from the previous release (Gtk2). Moreover, and this may be debatable, it didn't force ClientSideDecorations in the form of vertical space waste, at a time when vertical space is getting scarce and it's all just wider and wider, on everything, regardless of GNOME or Wayland use. Gtk3 had one job: make it work with Wayland and HiDPI, but like many open source projects they redid too much and broke more than they fixed. Case in point: just updated to Firefox 46 and it now requires Gtk3, which introduced many UI regressions and oddities. So, Qt is the better choice when compared to Gtk3, though those who don't feel the pain of Gtk3 and use GNOME may disagree. I use Qt apps on X, Wayland and Windows, for what it's worth.
- cm3 11y agowxWidgets recently added a not-yet-stable Qt5 implementation. Thus, it seems to me that Gtk3 is driving everybody but GNOME projects away, while Gtk2 was preferred in the past.