Please, please, please don’t use a GUI toolkit like this, that draws its own widgets rather than using platform standard ones, when developing a plugin for a digital audio workstation (e.g. VST or Audio Unit), as this author is apparently doing. Unless someone puts in all the extra effort to implement platform-specific accessibility APIs for said toolkit. Inaccessible DAW plugins are a problem for blind musicians and audio engineers because of GUI toolkits like this one. Maybe screen readers will eventually use some kind of machine learning to provide access to otherwise inaccessible GUIs, but that’s probably still a long way off. So for now, we need application developers to do their part.
I don’t actually know what the best cross-platform solution is. Is wxWidgets fully functional in a context where it doesn’t own the event loop? I suspect not on Windows in particular. Yes, yes, I know it’s ugly 90s C++, but really, what’s more important, code aesthetics or usability?
> Please, please, please don’t use a GUI toolkit like this, that draws its own widgets rather than using platform standard ones, when developing a plugin for a digital audio workstation (e.g. VST or Audio Unit), as this author is apparently doing.
Um, I have normal but aging sight, and I still can't get a DAW that actually scales its widget to something other than 200% (or 150% if I'm reaaaaally lucky).
I have no GUI that renders at useful speeds using OpenGL or Vulkan.
The Photon author didn't just create this to be contrary. Modern OS GUIs don't work very well for things like DAWs because DAWs often operate much more like a game wherein the screen is animated and has 60fps of stuff going on.
Rather than complaining, write us all an open source GUI that doesn't suck and people will happily use that and then people will write the accessibility hooks for it.
It isn’t really a problem of being cross platform: I don’t think platform UIs have enough richness to handle such applications without a lot of non standard components. You can only do so much with sliders.
Likewise, accessibility capabilities rely on very standard generic UI capabilities. Once you go beyond that with professional tooling, accessibility will have to be custom as well.
Hi I'm Joel, the the author of Photon. Just wondering, do you know any significant (or perhaps even insignificant) VST or AU plugin that uses standard platform widgets? I wonder how that would look like.
I'm pretty sure that there is enough incompatible design between the platforms to make a cross-platform UI using native widgets infeasible. Between Windows, macOS, and X Windows, I'll guess that one of them picks a different meaning of (x,y)--is it the center of the pixel or the upper left? I'm guessing that Cocoa/UIKit's constraints are incompatible with Android's gravity, and what do you do on Windows, which has nothing at all (at least for Win32). Do you re-implement Apple's constraints for Android? Vice-versa? What do you do if you have limited space and you can't fit Windows' large edit boxes but macOS's svelte edit boxes fit snugly? Windows' control expand into their frame, but macOS's controls frequently have padding, which means that for Windows you need to add padding between the controls, but on macOS you put the controls next to each other and the internal padding does it all for you. And for some platforms, it's not even clear what the native widgets are: is Win32, WinForms, WPF, or UWP the native widget set for Windows? Is Gtk or Qt/KDE the native widget set for Linux?
> but really, what’s more important, code aesthetics or usability?
Well, if you want software developers to write using it, code aesthetics is pretty important. Code aesthetics is usability to software developers. End-user usability does tend to trump code aesthetics if you want to get money out of the software you write, but even then, code aesthetics is still a consideration.
> what’s more important, code aesthetics or usability?
My guess is that the answer to this is similar to "what is more important, developer friendliness or minding resource use for users with less capable computers?" that gave rise to Electron.
And i'll also bet that there are way more users that have low end computers than users who rely on OS-supplied usability features.
He needs to take the controls people know and understand and replace them with cryptic methods that require new learning, and are hidden from view by default. Otherwise no one will take it seriously as a modern UI.
From the author "Photon has its own HTML5 inspired canvas drawing engine using Cairo underneath".
That means it should render nicely at any resolution, the author says, "resolution independent and allows for HDPI displays".
But using Cairo means it should not have a good performance at high resolutions. I have yet to find a fork of Cairo GPU accelerated that supports all the API.
So it may fit the bill if you are coding a simple interface, but it will be too slow to render at 60FPS and at high resolution.
What comes closest for me is Dear ImGui, but I never saw an interface with those nicely rendered buttons in real-time done with Dear ImGui.
Hi I'm Joel, the the author of Photon. The "canvas" part is encapsulated and can re-target another vector engine. I'm considering Skia, but it was too unstable when I first tried. Maybe I'll try again.
Funny how there are a few domains where the same problem is solved over and over again. Probably an indication that a good solution is truly missing.
A long time ago I wrote a tiny audio synth. And yep, I wrote my own minimal GUI which had stuff like sliders, and most importantly knobs which general GUIs typically don't provide.
Now I'm working on a non-audio webapp, and I have a problem where a knob would be the ideal solution. Searched far and wide for a Vue knob, and what I found was not usable. It worked if you "rotated" it circularly, but it didn't work if you pulled it up/down like a slider. You might say "use a slider then if you want to pull it up/down". True, but a slider takes a lot of UI space which sometimes is very precious. More importantly, the slider resolution is limited to it's height, while a knob could for example use the whole screen height for a full turn.
> minimal GUI which had stuff like sliders, and most importantly knobs which general GUIs typically don't provide.
They don't provide knobs because they're a bad idea for input. Holding mousedown while drawing an invisible arc with the cursor is an awkward way to change a value. Sliders are generally better but still not great on interfaces with cursors (they're better on touchscreens). Skeuomorphism can be a useful visual design cue but it needs to be secondary to the input capabilities of the device.
Up and down arrow buttons(or plus/minus, or whatever makes sense for the value) are very compact and operable with a variety of input methods. Buttons need a way display the value but there are many options including putting them in the center of a ring of numbers like a knob would use.
> You might say "use a slider then if you want to pull it up/down". True, but a slider takes a lot of UI space which sometimes is very precious. More importantly, the slider resolution is limited to it's height, while a knob could for example use the whole screen height for a full turn.
Perhaps the solution is to make the slider pop up if you press a button?
In the early days of the iOS App Store I worked on a music iPad app. Through many hours of user testing and researching prior art, the best solution we came up with was detecting the trajectory of the user input and supporting both vertical dragging and dial-like rotation. It took a shitload of trial and error fine tuning, but it eventually turned out pretty well.
I think many music apps these days give you the option buried somewhere in settings.
Is it better to write one own's GUI in this case? I believe most toolkits have a way to add new controls, so it should be less work to add a knob to GtK, Qt or any other toolkit.
My current fantasy is that Apple would open-source SwiftUI and the industry converges around that for native UIs, adding support for custom third-party skins/themes later.
If they can already do it for such distinct devices as Mac, iPhone, iPad, TV and Watch, there's no reason it can' be adapted for Windows, Linux and Android as well.
This is something that should have happened 5 years ago, before Electron etc. had a chance to fill in a obviously much-needed need.
Really, why do we need anything more than "Button" to describe a button, or "List" to describe a list, on any GUI? HTML solved this a trillion years ago, it's a wonder it took so long to be wholeheartedly adopted for native UIs. I know Microsoft tried with WPF/XAML but it didn't seem to catch on.
It certainly did catch on Windows, served as influence to JavaFX and QML design, and the WPF grid layout landed on the Web as the initial CSS Grid proposal.
Looks promising. Some things I'd like to see explained:
- How does rendering work? Is it using retained mode or not?
- Does the system prevent unnecessary work, such as repainting of certain elements (even when scrolling, since scrolling can be implemented using a less expensive bitblt)?
- How easy (natural) is it to change the UI hierarchy once it is running?
- Is memory management natural? Is there a form of garbage collection or reference counting for UI elements? How easy is it to accidentally refer to deleted UI elements?
I'll do that in a follow up post. To be honest, I wasn’t ready to release this yet, not in this form, so the info is very preliminary, as noted in the introduction: "Let me tell you a bit about Photon… From my previous post about Ascend, some folks noticed its existence and actually found the github repository. The repository is rather underwhelming, I thought to myself, devoid of any documentation of any sort, other than a very terse description: “Photon Micro GUI library”. I figured perhaps it’s good to post preliminary information about it, maybe starting with some history and basic architecture and design principles and code snippets. Just enough to give it a bit of justice that it deserves."
And then one of my Boost (https://www.boost.org/) peers twitted about it, and ended up being posted here.
IDK about y'all but the main page (https://www.cycfi.com/) this post is on has a bunch of interesting audio hardware/software posts. Pretty neat company!
No mention of accessibility makes it not enough for more generic applications. That's my main pain point. I would love to have a modern alternative to wxWidgets - something in higher level language than C++. Something that would use GTK+ on GNOME, Qt on KDE, Cocoa on macOS, Cocoa Touch on iOS, Android APIs on Android. Android is the trickiest probably, because I would like it to run without NDK, so compiled down to Android JVM or DEX bytecode. Then it could fit every environment just right. Could means, that it's a first step, because those environments have different HIGs etc.
What's interesting is that Lasarus is closest to it, but I would prefer higher level language. Is there a Tcl interpreter written in Java? Then Tcl/Tk could be also an option.
Sorry for a bit off-topic rambling, but I would love to see something like it.
Out of curiosity, why isn't Free Pascal high level enough?
Also FWIW my LIL scripting language, is sort of Tcl-like and has a Free Pascal implementation (and also a C one) with a (optional) Lazarus drag-drop component: http://runtimeterror.com/tech/lil/
I also have a Lazarus component for FPLIL for exposing a Tk-ish (well, not exactly, but on a similar spirit) API: https://i.imgur.com/G8hto0N.gif
Though that last one isn't available anywhere... perhaps i should upload it at the LIL site above. It is just that it hadn't had much testing (i mainly wrote it for my 3D world editor so that scripts can expose simple UIs on the sidebar or in dialog boxes but haven't used it much elsewhere).
EDIT: i decided to take a few minutes and upload the LILGUI stuff to the site above.
Photon was the best I've ever seen. Not the most brilliant desktop environment UI (clearly modern Win7/Unity/Mac-like panels + Mac/Ubuntu-like keyboard features are better, let alone tiling WMs but these are only good with big displays) but the most cozy controls look&feel styling and a great C++Builder-like visual RAD IDE.
Awesome, that looks like an attempt to replace QML by native C++. Would be great if there was a SwiftUI inspired C++ UI framework (well, of course C++ might not lend itself so well for the job, but I'm just very curious what it would look like if someone makes a real attempt).
Can confirm. Came in expecting the other Photon MicroGUI ("now there's a name I've not heard in a long time"), was surprised/disappointed. Man QNX+Photon made for a nice GUI operating environment. Rivaled only by BeOS on my "GUI environments/systems I wish had made a bigger splash" scale.
Same. I don't understand why the authors of the linked project couldn't have done five minutes of research for the name. Or perhaps they did, and figured since QNX has moved on it would somehow make sense to take over the name? As shown here, that only leads to confusion.
This was what I thought as well. It's really too close. But awesome project nonetheless. I've given FLTK a try and while it's usable it seems a bit old in it's architecture.
[+] [-] mwcampbell|6 years ago|reply
I don’t actually know what the best cross-platform solution is. Is wxWidgets fully functional in a context where it doesn’t own the event loop? I suspect not on Windows in particular. Yes, yes, I know it’s ugly 90s C++, but really, what’s more important, code aesthetics or usability?
[+] [-] bsder|6 years ago|reply
Um, I have normal but aging sight, and I still can't get a DAW that actually scales its widget to something other than 200% (or 150% if I'm reaaaaally lucky).
I have no GUI that renders at useful speeds using OpenGL or Vulkan.
The Photon author didn't just create this to be contrary. Modern OS GUIs don't work very well for things like DAWs because DAWs often operate much more like a game wherein the screen is animated and has 60fps of stuff going on.
Rather than complaining, write us all an open source GUI that doesn't suck and people will happily use that and then people will write the accessibility hooks for it.
[+] [-] seanmcdirmid|6 years ago|reply
Likewise, accessibility capabilities rely on very standard generic UI capabilities. Once you go beyond that with professional tooling, accessibility will have to be custom as well.
[+] [-] djowel64|6 years ago|reply
[+] [-] prewett|6 years ago|reply
> but really, what’s more important, code aesthetics or usability?
Well, if you want software developers to write using it, code aesthetics is pretty important. Code aesthetics is usability to software developers. End-user usability does tend to trump code aesthetics if you want to get money out of the software you write, but even then, code aesthetics is still a consideration.
[+] [-] Crinus|6 years ago|reply
My guess is that the answer to this is similar to "what is more important, developer friendliness or minding resource use for users with less capable computers?" that gave rise to Electron.
And i'll also bet that there are way more users that have low end computers than users who rely on OS-supplied usability features.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] reaperducer|6 years ago|reply
He needs to take the controls people know and understand and replace them with cryptic methods that require new learning, and are hidden from view by default. Otherwise no one will take it seriously as a modern UI.
[+] [-] mankeysee|6 years ago|reply
[+] [-] tyingq|6 years ago|reply
http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2F...
[+] [-] rbanffy|6 years ago|reply
[+] [-] FraKtus|6 years ago|reply
That means it should render nicely at any resolution, the author says, "resolution independent and allows for HDPI displays".
But using Cairo means it should not have a good performance at high resolutions. I have yet to find a fork of Cairo GPU accelerated that supports all the API. So it may fit the bill if you are coding a simple interface, but it will be too slow to render at 60FPS and at high resolution.
What comes closest for me is Dear ImGui, but I never saw an interface with those nicely rendered buttons in real-time done with Dear ImGui.
[+] [-] gigatexal|6 years ago|reply
This GUI looks great, too. It’d be interesting to have python bindings to it.
[+] [-] djowel64|6 years ago|reply
[+] [-] srikz|6 years ago|reply
I'm trying to follow all thr efforts in native desktop GUI tools and am currently using Dear ImGui for something which will only be used internally.
[+] [-] pier25|6 years ago|reply
[+] [-] fasterdom|6 years ago|reply
A long time ago I wrote a tiny audio synth. And yep, I wrote my own minimal GUI which had stuff like sliders, and most importantly knobs which general GUIs typically don't provide.
Now I'm working on a non-audio webapp, and I have a problem where a knob would be the ideal solution. Searched far and wide for a Vue knob, and what I found was not usable. It worked if you "rotated" it circularly, but it didn't work if you pulled it up/down like a slider. You might say "use a slider then if you want to pull it up/down". True, but a slider takes a lot of UI space which sometimes is very precious. More importantly, the slider resolution is limited to it's height, while a knob could for example use the whole screen height for a full turn.
[+] [-] extra88|6 years ago|reply
They don't provide knobs because they're a bad idea for input. Holding mousedown while drawing an invisible arc with the cursor is an awkward way to change a value. Sliders are generally better but still not great on interfaces with cursors (they're better on touchscreens). Skeuomorphism can be a useful visual design cue but it needs to be secondary to the input capabilities of the device.
Up and down arrow buttons(or plus/minus, or whatever makes sense for the value) are very compact and operable with a variety of input methods. Buttons need a way display the value but there are many options including putting them in the center of a ring of numbers like a knob would use.
[+] [-] amelius|6 years ago|reply
Perhaps the solution is to make the slider pop up if you press a button?
[+] [-] kitotik|6 years ago|reply
I think many music apps these days give you the option buried somewhere in settings.
[+] [-] jcelerier|6 years ago|reply
I don't think so. It's a pretty standard exercise to try to create an ui framework so of course we're bound to see tons of them.
[+] [-] yoz-y|6 years ago|reply
[+] [-] Razengan|6 years ago|reply
If they can already do it for such distinct devices as Mac, iPhone, iPad, TV and Watch, there's no reason it can' be adapted for Windows, Linux and Android as well.
This is something that should have happened 5 years ago, before Electron etc. had a chance to fill in a obviously much-needed need.
Really, why do we need anything more than "Button" to describe a button, or "List" to describe a list, on any GUI? HTML solved this a trillion years ago, it's a wonder it took so long to be wholeheartedly adopted for native UIs. I know Microsoft tried with WPF/XAML but it didn't seem to catch on.
[+] [-] pjmlp|6 years ago|reply
[+] [-] amelius|6 years ago|reply
- How does rendering work? Is it using retained mode or not?
- Does the system prevent unnecessary work, such as repainting of certain elements (even when scrolling, since scrolling can be implemented using a less expensive bitblt)?
- How easy (natural) is it to change the UI hierarchy once it is running?
- Is memory management natural? Is there a form of garbage collection or reference counting for UI elements? How easy is it to accidentally refer to deleted UI elements?
- Does it make use of a GPU if available?
[+] [-] djowel64|6 years ago|reply
And then one of my Boost (https://www.boost.org/) peers twitted about it, and ended up being posted here.
It seems I have a lot of work to do...
[+] [-] kazinator|6 years ago|reply
[+] [-] tomcam|6 years ago|reply
[+] [-] zengid|6 years ago|reply
[+] [-] srikz|6 years ago|reply
[1]: https://github.com/wjakob/nanogui
[+] [-] ktpsns|6 years ago|reply
[+] [-] hawski|6 years ago|reply
What's interesting is that Lasarus is closest to it, but I would prefer higher level language. Is there a Tcl interpreter written in Java? Then Tcl/Tk could be also an option.
Sorry for a bit off-topic rambling, but I would love to see something like it.
[+] [-] badsectoracula|6 years ago|reply
Also FWIW my LIL scripting language, is sort of Tcl-like and has a Free Pascal implementation (and also a C one) with a (optional) Lazarus drag-drop component: http://runtimeterror.com/tech/lil/
I also have a Lazarus component for FPLIL for exposing a Tk-ish (well, not exactly, but on a similar spirit) API: https://i.imgur.com/G8hto0N.gif
Though that last one isn't available anywhere... perhaps i should upload it at the LIL site above. It is just that it hadn't had much testing (i mainly wrote it for my 3D world editor so that scripts can expose simple UIs on the sidebar or in dialog boxes but haven't used it much elsewhere).
EDIT: i decided to take a few minutes and upload the LILGUI stuff to the site above.
[+] [-] diet_mtn_dew|6 years ago|reply
https://wiki.tcl-lang.org/page/Java+and+Tcl
[+] [-] monetus|6 years ago|reply
[+] [-] qwerty456127|6 years ago|reply
[+] [-] stabbles|6 years ago|reply
[+] [-] torgoguys|6 years ago|reply
[+] [-] asark|6 years ago|reply
[+] [-] scottlocklin|6 years ago|reply
[+] [-] morganvachon|6 years ago|reply
[+] [-] ObscureScience|6 years ago|reply
[+] [-] djowel64|6 years ago|reply
[+] [-] skocznymroczny|6 years ago|reply
[+] [-] rbanffy|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]