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.
> DAWs often operate much more like a game wherein the screen is animated and has 60fps of stuff going on.
This is puzzling to me. Do sighted DAW users really rely on such a high-bandwidth, continuous flow of visual information? What kind of information? Mainly volume meters, or other things as well?
FWIW, I'm just starting to dabble with a DAW myself. But I know that blind people have successfully done all stages of music and other audio production using a DAW. From what I understand, they do it by concentrating solely on the audio itself during real-time playback and recording. But the UI does need to be accessible for non-real-time work, e.g. plugin configuration, switching tracks, switching instruments, or making precise edits.
At least VST allows you to switch to and from using basic controls and the full plugin UI. Actually, if your plugin does not provide a UI, the DAW host will provide a generic one for you, with basic controls like sliders, drop-down menus, etc. that map to the parameters that your plugin use. You should probably just use those if you are blind, again assuming that the host provides all the accessibility features you need (I am not sure if all VST hosts do, you should check).
First of all, I doubt that writing yet another toolkit of my own would be the solution. How could I know that anyone would adopt it? And as for spending time contributing to an existing toolkit, which toolkit? I read about several per year here on HN. That's why I've been pleading with developers to use platform widgets, or cross-platform toolkits that wrap those widgets (like wxWidgets), wherever I can. But the replies on this thread have convinced me that sometimes, the platform widgets really do leave a lot to be desired. So, I don't know what to do instead.
You don't. But if it's better, people will actually use it. This is currently a glaring hole in the software development landscape screaming for a better solution.
I'm currently in a similar boat as the Photon author and I have a much more prosaic application. But I have a lot of interaction with OpenGL and the GUI system, and none of the GUI toolkits like that.
Photon is simply doing the same thing that GTK did originally--GTK was written specifically for the GIMP and only later did it become general purpose.
> And as for spending time contributing to an existing toolkit, which toolkit?
That's your choice to make. And your efforts help make those decisions. The toolkit that attracts motivated people and improves starts gaining momentum and attracts more people. Even a single motivated individual can tip the balance when things are unsettled.
Unfortunately, this is not a well-trod and settled area. Part of being on the bleeding edge is that you get cut.
FWIW, Photon scales well. One issue is that DAWs may or may not allow scalable UIs. VST2 for example, is not designed to be scalable, but VST3 is. I'm very open to addressing accessibility if anyone wants to do some work on 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.
I'm not convinced that standard controls are insufficient for a DAW plugin UI. Can you please explain why? Is it all about looks, or are there actually usability problems for sighted users?
Let me flip that question around: given what the plugin UI does, how would the interface actually look using LCD UI components and would the experience even be meaningful for unsighted users?
Real time scrubbing and mixing with...a screen reader...how does that even work? I’m sure it could work, but you would still wind up with something as custom as seen here, perhaps even more so. Accessibility isn’t a free lunch except in very generic limited use contexts.
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.
The closest ones I can think of are not VST or AU, but the Audacity LADSPA plugins. They are not platform native either, but rather GTK+. They are fairly simple with just buttons/sliders. It's the best example I can think of.
Same here. And for that matter, all DAWs I know also do not use standard platform widgets. Logic Pro, Reaper, Ableton, Pro Tools, Cubase etc. all use their own custom UI elements.
You're right about the DAWs, though last time I checked, REAPER on Windows uses some standard Win32 controls in its dialogs, which helps. Also, REAPER has rich enough plugin support that a couple of plugins have been written to hack screen reader support into REAPER. In particular, check out the open-source OSARA [1] project. This work-around isn't feasible for making plugins accessible, since those plugins are generally not as hackable as REAPER itself. I don't know about other DAWs.
You spend a minuscule amount of time with Dialogs. You spend Most of the time in the project window itself, the mixer, transport, and all the plugins. None of those use standard controls. If they did, they would've pleased all blind users (assuming they do implement the accessibility features you mention), but turned off everyone else because of the bland, ugly and difficult to use UI, not to mention that there are only a very limited set of standard controls. I doubt Reaper would be the success it is now, if it were so.
Having said that, hey, this is Open Source! Like Reaper, I am willing to support accessibility if you, or anyone else is willing to do the extra effort.
> And noone asked me for accessibility, zero people.
It's possible that blind DAW users have just gotten tired of trying to advocate for accessibility in plugins. I thought I had a chance on this thread, since I would potentially be reaching several developers, including future plugin developers who haven't yet chosen a toolkit, instead of having to write to one at a time.
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.
To be fair, knobs as shown in the screenshot are afwul in an usability’s point of view (how do i rotate this, how to fine tune the value), but they convey the information in the context of music plugins really well for the person most likely to use them.
A lot of DAWs use these. With the ones I have used you click the knob and then drag (up to turn the knob left, down for right). It's really horrible actually.
Right. Physically, potentiometers are semicircular sliders.
But another advantage of knobs is the ability to turn them, quickly and yet accurately, with thumb and first finger. Some even have push-pull gear reduction, to go between fast and accurate.
So you'd think that a GUI knob would use some analogous two-finger twisting gesture. With thumb and first finger.
Which is awful and anti-intuitive--far worse than merely non-discoverable. It looks like a familiar control system that a hardware synth would have, but it's actually just a skin on a vertical slider: so it not only forces you to learn a different interaction anyway, but on top of that it lies to you about what it's doing!
Skeuomorphism worshippers have a lot of nerve to complain about abstract GUI philosophies when their own cult hasn't eradicated these design atrocities. Gosh, it sure looks pretty though...
I think you may have forgotten
to add "imho", otherwise the message looks like its telling an indisputable truth. Audio professionals don't complain about skeuomorphism and philosophies and certainly there're no worshippers, as nobody cares about the new fancy names of mainstream visual styles (btw non-skeuomorphic knobs are quite common, e.g. Ableton).
From my own experience, knobs are far superior to sliders in audio applications, as all the adjustments are typically guided by hearing, and sliders' values can jump if you click in a wrong place. This just disturbs the flow. Most of the work with audio software UI is fine tuning parameters, often by a few percent, so relativistic nature of click-drag is perfect for this. Sure, there're relativistic sliders, but they feel rather unintuitive.
If you're willing to share, I'm curious how you came up with the name, especially with it being literally one character (a space) different from such an established project from two decades ago.
And kudos to you being willing to change it now that you know. It probably only really affects old OS and embedded nerds like me, and as an amateur musician I do find your project interesting, but I have to admit I got my hopes up that QNX Photon had finally been open sourced, or at least brought up to modern standards with a new release.
Just a stupid mistake, really. I know QNX, but I haven't used it and I didn't know the QNX Photon name. You guys are right. I should've done a 3 minute Google. My bad.
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.
For me, nothing is as nice looking as Photon (resolution independent) and GPU friendly to allow 60 FPS cross-platform GUI.
It looks like you still need to roll your own.
I am currently working with Dear ImGui and found a pipeline where I put SVG icons in a true type front and can then render them resolution independent with Dear ImGui.
Yes, have been excitedly following Scenic since Boyd Multerer's talk about his experiments a couple of years back. Haven't tried it yet as I somehow kept putting off wrapping my head around Elixir and FP
Doesn't Skia have a very fragile API? I remember reading that they were breaking their API/ABI all the time. If nothing else, Cairo's API is always backwards compatible.
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.
In a good knob it’s not an arc but just clicking and dragging straight up or down that makes it move. A lot of VST audio plugins work like this and they get a lot of controls into a small area like this.
But then the gesture doesn't correspond to the interface at all. You could get the compactness plus a visual that corresponds by having something like a vertical slider that appears when you mousedown on the spot.
> They don't provide knobs because they're a bad idea for input
I like knobs because the distance from the center of that control (radius of your arc movement) can be a “fineness” or “coarseness” control. I think sliders don’t usually offer this.
That's why you don't use circular dragging for a knob, you use vertical/horizontal drags (or a combination of both, JUCE supports those for reference, I forget what it defaults to). I've only seen rotary dragging in a handful of products and it always sucks.
Arrow buttons are pointless when you're trying to dial in a value - which is the whole point of using knobs in audio software. They don't give you adjustable granularity or an easy way to continuously adjust - and if you do give it those functions, you've made a knob without the visual feedback of knob position. Or like you say, put it in the center of a ring of numbers, but again, you've just made a knob!
Yes, if you have to click up, then down, then up again, and down to nail down a "just right" value, those buttons would be more difficult but their operation would be apparent. You might be able to get to a "just right" value if mousedown can be held while the cursor is moved between the buttons but a slider is probably better.
The knob behavior you're describing is essentially an invisible slider. An invisible line is better than an invisible arc but it's still not good. Why not make it visible? A visible slider could appear on mousedown so there's something that corresponds to the gesture.
It's not non-intuitive. The most acclaimed UIs for audio software are littered with knobs, and they have to be. You're talking about dozens to hundreds of continuous parameters that need to be dialed in by hand in conjunction with the user's ears. It's also common practice to have a hotkey like ctrl to swap between coarse/fine tuning of the parameters, so you can dial it in without changing controls or letting go of the mouse - which is often done in real time during playback.
In your first example, you've just made a knob that doesn't look like a knob.
In your second example, you're confusing mouse position and gesture. Linear sliders map mouse position to state changes, rotaries map gesture. Another way of looking at it is that a rotary slider's state is decoupled from the input, and in doing so, is a much more responsive control. Not to mention, you have an infinite 2D area to traverse to change the knob value with respect to the widget itself, not a finite, defined path.
And the huge reason that linear sliders (at least off the shelf ones) are impossible to use for audio UIs is that 99% of your user's time is spent adjusting from the previous position, not resetting it to a new one. That means any behavior where a click resets the position (like clicking just past the current position) is broken. Not just because it's trash UX for the application, but because in audio systems jumping parameter values can cause artifacts, and mitigating them is not without cost in performance and fidelity.
> It's not non-intuitive. The most acclaimed UIs for audio software are littered with knobs
That doesn't make them intuitive, they're merely familiar to people already familiar with such audio software.
> hotkey like ctrl to swap between coarse/fine tuning of the parameters
Image editors and video editors have keys like that too, they're not related to knobs.
> In your first example, you've just made a knob that doesn't look like a knob
That's great! I preserved the functionality while making the action more apparent.
> a rotary slider's state is decoupled from the input
That's what I'm criticizing.
> Not to mention, you have an infinite 2D area to traverse to change the knob value with respect to the widget itself, not a finite, defined path.
The visual feedback of both sliders and knobs are both restricted to finite, defined paths. Whether the control of the input is restricted to that path depends on how it was designed. With some sliders, you can only move the control when the cursor remains without the bounds of the slider the iTunes volume control for example. With other sliders, once you've clicked on the control, the cursor can be outside the slider, I think this is the "infinite 2D area" you're talking about. The macOS menu bar volume and Sound Preferences sliders are examples of this latter behavior, I also found this example (you need to click the play button for the code to run).
> That means any behavior where a click resets the position (like clicking just past the current position) is broken
Yes, for what knobs are used for, you wouldn't want a slider control to jump to whatever point on its line was clicked on. This is another behavior that is found on some sliders (both iTunes and macOS Sound volume controls) but not others (the P5 example above).
On a more meta level, a whole industry decided after 30 years of iterations that knobs that work like invisible sliders are the best controls, and you - who by the looks never had any extensive use of audio software - are claiming that they are all wrong, because of some philosophic argument. You might be true, you might be the rare visionary who sees a better way of doing things where other cannot, but the burden of proof is on you.
> 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.
That’s what I did. Made it slide by default (because I hate trying to twist a virtual knob). I briefly had a translucent rectangle popup when the control was in slider mode but it turned out not to be helpful as linear dragging seemed to make sense to everyone and I only had like eight options in total.
The one nice innovation I had was automatically detecting horizontal or vertical drags - useful for things like pan controls where a horizontal motion makes more sense.
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.
Then you hit the second requirement: complete bitmap theming, many times of a skeuomorphic kind. This is extremely difficult to do in something like Gtk/Qt.
1. Motif came first. Among people who knew what Motif is, the look of Windows 95 was widely recognized as being very similar to Motif to the point of being a knock-off.
2. See the diamond-shaped radio buttons in the second example. :)
Oh, I didn't see the second screenshot. Yeah that one is more like what I remember Motif looking like. The first one though is definitely going for the Windows 95 look.
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.
Are most Windows apps currently designed with WPF or something else?
I have always looked to things like the Calculator and Notepad as a signal of confidence; I know there’s little reason to rewrite them, but the proof of the pudding would be if Microsoft updated something as “simple” as those applets to their championed UI framework.
I know Visual Studio (and their abandoned Expression Studio) is/was built with WPF, but what’s the score in the “wild”?
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.
Hey thank you for your work. Giving the world a permissive Plugin-capable GUI library is a really special thing, so from us plugin developers I hope you know we appreciate your efforts.
I assume they mean "Foreign Function Interface" this is a modern C++ code base, and hence can not be easily wrapped in a C function pointer for consumption by non-C++ languages.
FFI = foreign function interface[0], a way to call functions written in one language (generally C) from another. By "FFI friendly" I think the parent meant that Photon Micro GUI isn't something you can easily use from languages other than C++.
Bummer. Higher level low footprint languages such as Nim and Crystal would benefit a lot from bindings for this GUI.
Probably Lua too, but that's a different context and Lua already has Tekui and others.
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!
Hi I'm Joel, the the author of Photon. Yes, I know NanoGUI. I actually started with NanoVG. I had problems embedding in a plugin, IIRC. GLFW is not embeddable, IIRC.
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.
Probably just a stripped down Tcl. Most of the code was written years ago in a week or two, i've only added minor stuff (like a few new functions), improved performance a bit and fixed bugs since then. And the Free Pascal implementation, of course, but that was also done years ago. I've used it in a bunch of my own projects and i've heard a couple of others using it too.
TBH i do not have much experience with Tcl itself outside of writing a few Tk utilities to automate a few bits on my job some years ago. I followed its approach mainly because it sounded like a good combination for being very simple to implement and very flexible to work with, making it ideal for a hosted scripting language (though it doesn't fit all tasks - far from it, especially in places you want even a hint of performance).
So i can't really judge how exactly it differs from Tcl language-wise. It is not compatible as it provides much fewer functions and those work in a different manner. For example there isn't uplevel, but there is upeval which works in a similar manner (though the depth is always one but they can be nested) and there is also downeval (used through upeval to evaluate code back at the environment from where upeval was called), topeval (like upeval but at the toplevel environment), enveval (eval in a function-like environment with optional variable passing in and out) and jaileval (eval in a new, optionally clean, LIL context). Also there isn't much in terms of state notification outside of watch (which i think it works like Tcl's trace but only for variable writes).
I think the syntax is compatible with Tcl (i haven't done any excessive testing to be sure though, LIL was done mainly by "eyeballing" Tcl) so it could be possible to write shims in LIL to be able to write code that works in both, but TBH i wouldn't rely on that.
So i call it just "Tcl-like" in the same sense that JavaScript is a C-like language.
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.
Totally agree with you. While I've been away from QNX for a long time, I did enjoy this API and system design. When I saw it go EOL, I made an appeal for them to open source it. Never heard a peep.
Those were the days! I had BeOS as my only OS for over a year until it became clear that Palm wasn't going to continue supporting and updating it. It wasn't long after that I got into QNX, initially because of my interest in embedded systems, but after running Photon on a test machine I fell in love with it almost as much as I loved BeOS.
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.
I’ve never seen the phrase “microgui” used besides with QNX and this. With “photon” it’s so unique that there’s a 0% chance they hadn’t heard the name before. I’d like to know their reasoning.
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.
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?