11 ms·
Nana: A modern C++ GUI library
- deleted 8y ago[deleted]
- vfclists 8y agoDoes it support interop with plain C, eg C99? No C++ malarkey for me!!
- vfclists 8y agoWhy do people do stupid shit like this? Voting down comments they don't like? C++ GUI libraries are like the fox and stork to the rest of the world.
- CamperBob2 8y agoThe title itself says it's a C++ library, so if you're not interested in C++, it's easy enough to move on to the next distraction.
- nzjrs 8y agoA modern GUI library without screenshots on the homepage...
- hellofunk 8y agoThere is one screenshot on the front page, and I must admit, it does not look modern.
- vijaybritto 8y agoI think the modernity is in the code and the API rather than the output
- dearrifling 8y agoWell, that example shows some too stringy API for my taste.
- vijaybritto 8y agoOk. I'm not sure what they consider modern in the c++ world
- dearrifling 8y agoAs many words in C++, "modern" is overloaded. In this case I think it means it uses c++11 or later.
- asveikau 8y agoModern probably refers to the use of recent c++ standards. (In typical jargon this is termed "modern c++")
- eps 8y agoMore importantly, it doesn't look _native_ ... to anything really, which is the main (and hard) problem for any portable GUI library. Modernity can be added on top using a thin layer, if and when needed.
- lake99 8y agoIt looks like a native Breeze themed KDE application. If I did not know I was on the Nana website, I would have assumed it's all Breeze.
- alexandernst 8y agoThe screenshots link is somewhere in the middle of the page: https://github.com/cnjinhao/nana/wiki/User-Works-using-Nana https://github.com/cnjinhao/nana/wiki/User-Works-using-Nana
- dreamcompiler 8y agoWhat problem does this solve that Qt doesn't solve? (Yes I can DDG the answer, but the Nana home page should make that unnecessary.)
- jcelerier 8y agoThe "modernness" in Nana comes at a heavy cost : callbacks are based on std::function, which means that adding a callback - e.g. as in their front page : btn.events().click([&fm]{ fm.close(); }); will do a dynamic allocation, and create an indirection, since std::function does type erasure (so you get a vtable, etc...). Qt may look less modern, but the cost of doing a `connect` there is far smaller especially if you connect to a member function.
- dearrifling 8y agostd::function implementations typically have small buffer optimization, a lambda capturing a single reference will most likely fit in there. But yes, it's quite heavyweight in general.
- radarsat1 8y agoFor a high-speed callback that might not matter but is the potential slowdown of a few microseconds for the extra indirection really a problem for reacting to button clicks?
- zarkov99 8y agoHard to see how that is a real problem. For one std::function implementations usually do small obj optimization, so if all you are capturing is a pointer there is typically no allocation. Furthermore, this a setup cost, so typically only paid once, and it is a UI, so there is a human in the loop anyway, which enormously increases the performance tolerances.
- antoinevg 8y agoOh ffs, have you actually calculated this "cost" on a CPU made after 1985?
- eps 8y agoWelcome to the Kingdom of Electron, where RAM is aplenty and CPU cycles are puny noise down the line.
- jscholes 8y agoCorrect me if I'm wrong, but these widgets are custom-drawn, making the "modern" world completely inaccessible to and unusable by the majority of disabled users.
- snarfy 8y agoDon't blame the GUI, blame the screen reader. It's the screen readers that are stuck in the 70's. We have software that can do facial recognition and run on an raspberry pi but for some reason screen readers still need some ascii text buffer to send to the equivalent of a speak&spell.
- jscholes 8y agoThe screen reader I'm using includes modern accurate OCR. I'm very interested in this, though. How do you suggest a screen reader should recognise the often subtle differences between control types and states across every application and framework when custom controls are so common?
- taeric 8y agoTo add to your point, why require such sophistication if it can be avoided? I mean, we could all send bitmaps back and forth to communicate. We could literally just take pictures of hand written notes. Encoded email seems much saner.
- deleted 8y ago[deleted]
- csande17 8y agoAt least on Linux, there are already a few different GUI toolkits that custom-draw their own widgets. Presumably those projects all implement some sort of standard accessibility interface -- maybe this one could do the same?
- c-smile 8y agoThis: "Hello, <bold blue size=16>Nana C++ Library</>" looks a bit strange. Looks like XML but it is definitely not (the </> construct for example). If the purpose is to provide inline styling then I would use something richtext alike: "Hello, [B S16 C#00F]Nana C++ Library[bsc]" But split on HTML (semantic, structure) and CSS (styling) is anyway better for many reasons.
- taeric 8y agoIs it really better to split on semantic/structure and styling? Specifically, do we have evidence that that is the case? I know we certainly seem to like it. Quite often, any supposed advantages of it are never realized. And instead we grow into rather heavy solutions that are so painful to work with we reach for the next framework.
- c-smile 8y ago"Is it really better to split on semantic/structure and styling?" When you need to show the same UI on different devices (desktop, mobile, OSes) and media (screen, high-dpi-screen, printer) you will come up to the need of separate style definition entity almost immediately. Like this: "Hello, <bold blue size=16>Nana C++ Library</>" Should be just this "Hello, <em>Nana C++ Library</em>" and styles for the emphasis that can be different for each platform. Even for the same OS and user session you will need different style systems if you want to support dark and light theming for example. Yet having UI nailed down to pixels grids (<bold size=16>) is a path nowhere.
- taeric 8y agoThis is an appealing argument. But most of us don't actually have that. Worse, many attempts have shown greater success with just minimal styling and/or multiple versions.
- keerthiko 8y agoAnother important consumer-end feature of splitting style/structure is it allows clients to have custom styles, accessibility-oriented styles, by just swapping out the "styling" content of an application/page without needing to swap out or inject into the UI structure/code. The benefits to developers are more "trade-offs", but I think it generally is a better raw framework to work in without significant IDE-assistance to do development.
- floatboth 8y ago- no Wayland support - no GPU accelerated rendering - no accessibility That's not very modern, sorry, that's very 90s. Regardless of how the programming interface looks.
- viraptor 8y agoNot saying these aren't important, but you can implement these features once you've got a nice API working. You can't easily retrofit a nice API into an existing project with lots of features. So maybe they chose the right way.
- smitty1e 8y agohttps://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
- mcbits 8y agoIt claims to be a GUI library in modern C++, not (necessarily) a modern GUI library in C++.
- johnisgood 8y agoIn all fairness, it does not say that the GUI library itself is modern in that sense, but that it uses modern C++.
- shams93 8y agoWell for something like a gui for a Linux lv2 audio plugin this is pretty quick to learn and much smaller than qt
- aphextron 8y agoEvery nontrivial GUI framework eventually converges on a poor reimplentation of HTML/CSS. If you need a complex modern interface, just use Electron or the like.
- jplayer01 8y agoIs HTML/CSS really easier to use than something like Qt/QML?
- rat9988 8y agoI truly believe that writing html is way easier than qt/qml. I can't remember how hard was styling in qt/qml.
- ridiculous_fish 8y agoThis is a great sickness of the web: every website does custom styling on controls, and neglects all but the most primitive UIs. The result is a lowest common denominator: the web only really supports the click and the tap. Consider the humble popup button: a native one can support mouse input, or arrow keys, or keyboard shortcuts, or type selection, or accessible interfaces. Take it a step further and support scripting. But if your popup button is a div with an onClick, it won't support any of these. Even if you go the extra mile and reimplement all of them, the user won't even think to try it, because it's a "styled" snowflake. So the web sinks. HTML is way easier because it does a hell of a lot less.
- ken 8y agoAppKit doesn't look anything like HTML/CSS to me, nor does it appear to be heading in that direction.
- Klonoar 8y agoI've written and shipped UIs with AppKit/UIKit, Qt, a Tkinter (I know...) implementation, and HTML/CSS. HTML/CSS win for a reason. ;P
- ncmncm 8y ago> lab.format(true) gives me a bad feeling. However, in 35 years of programming I have not coded any kind of GUI, so my judgment might be off.
- int_19h 8y agoThis looks like a common C++ pattern of having a pair of overloaded methods as property accessors - foo() to get the value of foo for this object, and foo(x) to set it.
- ncmncm 8y agoYes, that's the bad feeling all right. Classic anti-pattern.
- otabdeveloper2 8y agoDisagreement about how to name methods is not an 'anti-pattern'. It's a literal non-issue that affects nothing at all whatsoever. Junior programmers pick on whitespace formatting and variable names because that's the only kind of criticism their skill level allows.
- ncmncm 8y agoThis is not about naming or formatting. This is about the prevalence of what are commonly called "setters and getters", that are a fairly reliable indicator of poorly thought-out design. You can learn something here, if you pay attention. In a sound design, objects more usually get their attributes at construction time, and keep them until they are destroyed. When something needs to change, from outside the object, it is usually better to make another object. Of course an object can still have mutable state, altered by member functions that do actual, useful work, but they have no use for setters and getters -- they have direct access to the member data that needs to change. The key here is that the public member functions should be doing useful work for you. Just mutating primitive state is noise. If the object doesn't abstract anything, it isn't earning it keep. Another indicator of bad design is public virtual functions.