Hacker News new | past | comments | ask | show | jobs | submit login
Photon Micro GUI (cycfi.com)
175 points by ingve 3 months ago | hide | past | web | favorite | 124 comments

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.

> This is puzzling to me. Do sighted DAW users really rely on such a high-bandwidth, continuous flow of visual information?

Yes. Volume meters, equalizers, beat counters, loop counters, etc. I can go on and on.

There is a reason why people use specific DAWs for specific purposes (Hip-hop guys seem to gravitate to Ableton Live, for example).

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).

> Rather than complaining

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.

> How could I know that anyone would adopt it?

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.

I sell plug-ins and I just don't know _any_ of them. And noone asked me for accessibility, zero people.

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.

[1]: https://osara.reaperaccessibility.com/

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.

At least if you're using electron, a11y is pretty much in the box... Electron + React + Material UI is pretty nice all around.

Too many skeuomorphic elements.

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.

The mobile and web people are probably triggered at this ui lol

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.

What are knobs used for anyways outside of daws?

Yes, how does one adjust the setting of a knob?


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.

Ah, so a slider, posing as a knob.

Yes, except taking up much less space.

Which is exactly the purpose of a knob in meatspace too :)

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.

I would hope you can also use the mouse wheel by hovering over the knob

Yes, Photon does that with all continuous UI elements.

Click/touch + drag.

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.

Was confused for a moment because the Photon UI for QNX is also called a "Micro GUI".


Same here. Such a shame I need to go into my car to run QNX...

Hi I'm Joel, the the author of Photon. It seems I have to change the name. Bummer :-) Anyway, I didn't know. Thanks for pointing it out.

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.

All good names are taken

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.

I now changed the name to Elemental C++ GUI library. Again, sorry for the stupid mistake and the confusion it caused.

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.

I knew the original dev of cairo. It’s amazing to see how it is being used in many different projects: a testament to his work all those years ago.

This GUI looks great, too. It’d be interesting to have python bindings to it.

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.

I'm curious if you have come across (and recommend) any framework which lie in between Photon (Cairo) and Dear ImGui.

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.

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.

You might try Scenic. It’s more embedded oriented but does run on desktops using OpenGL. Also it’s new so the component library is pretty small still.

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

Anyone using Skia?

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.

It is at very least a pain to set up, specially on Windows.

I’ve always been curious why Google didn’t spin out Skia. Maybe because it lacks the UI primitives you really need to make it useful?

What do you mean with "spin out"?

(sorry English is not my first language)

Take Skia and promote it as a toolkit independent from Android, Chrome, etc.

It would already help they had binaries available, or not expect externals to replicate their build infrastructure.

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.

> But then the gesture doesn't correspond to the interface at all.

I remember learning soft synths when I was 11 - 12 years old and back then it maybe took me a few minutes to get it. Come on.

> 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.

Some iPhone apps provide this for the time slider (I believe via the native media player control, although I could be wrong). It is very nice.

I’ve seen this too, and yes, it’s nice. I don’t know where in the stack this feature lives.

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).

In the space of that slider you linked to, and audio app would have 5 knobs:


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?

Not a bad idea, actually.

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.

> option somewhere buried

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.

> Probably an indication that a good solution is truly missing.

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.

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.

True, you could write a new Qt control.

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.

Behold, in all its skeuomorphic glory, the Qt styles example:


That looks almost exactly like Motif from 1991, but superimposed with a wood grain pattern.

Looks more like Windows 9x than Motif to me.

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. :)

3. 3D embossed arrows on scroll bars.

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.

Qt has the following style that you can use, where you just have to ship the bitmaps for your controls in a predefined naming scheme : https://doc.qt.io/qt-5/qtquickcontrols2-imagine.html

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”?

Most greenfield enterprise apps are WPF/UWP, some still insist on using Forms though.

No one uses MFC/ATL for greenfield applications on Windows.

When C++ comes into play, it is plugged via DLLs or COM into .NET applications (or even via C++/CX, C++/WinRT or C++/CLI).

As for pure Win32 C style, for greenfield apps, only if are feeling masochist.

Not counting 3rd party alternatives here like Qt, Delphi or C++ Builder.

What's the distinction between WPF/UWP/WinRT/.NET?

What's the Windows' analogue of Swift+SwiftUI? i.e. telling someone new to the platform about what to focus on.

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?

- Does it make use of a GPU if available?

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.

It seems I have a lot of work to do...

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.

Nice screenshots; but doesn't seem "FFI friendly", unfortunately.

what does that mean? a google search proved fruitless

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++.

[0]: https://en.wikipedia.org/wiki/Foreign_function_interface

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.

You can still write Crystal wrappers for it, just not using FFI. This looks like it might be polished enough: https://github.com/Papierkorb/bindgen

The bigger issue is that Crystal really needs first-class Windows support before people will use it for GUIs...

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!

NanoGUI[1] is another GUI framework which uses NanoVG underneath. Interested to know if the author is familiar with that and what's their take on it.

[1]: https://github.com/wjakob/nanogui

This reminds me of the look of Blender's GUI, which is also OpenGL based.

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.

I came across Oui-blendish [1] whose goal is to help make blender-like UI

[1]: https://bitbucket.org/duangle/oui-blendish/src/default/

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.

At first glance, LIL does look very similar to Tcl. Do you consider it a stripped-down Tcl or are there other language features you added?

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.

There is a Java version of Tcl called Jacl. I have no idea if it would work for your purposes.


There is androwish, but it is a native port of tcl/tk iirc, not java. https://www.androwish.org/home/home

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).

Name collision--QNX's gui was/is also named "Photon MicroGUI" and that is what I thought this post was going to be about: http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2F...

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.

QNX is EOL? Really? The last release was only in 2017. I hadn't heard this was happening and I can't seem to find any reference to it.

I recall that QNX/Photon floppy disk in the late 90s. The entire OS and a GUI on a single floppy!!! (And it didn't look like GeOS or Windows 1)

> Rivaled only by BeOS

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.

Was just going to say this. Thanks. QNX was/presumably still is amazing in its simplicity and correctness.

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.

The only difference is the word break: "microgui" versus "micro gui".

Hi I'm Joel, the the author of Photon. Thanks for noting. I honestly did not know. Oh well... It seems I have to change the name.

I expected this http://photonkit.com/ , which is also a GUI project

That brings back fond memories. Both of my BB10 phones and my first experience with C (and vi). I learned C on a PC running QNX.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact