
Show HN: Xel, widget toolkit for native-like Electron apps - jarek-foksa
https://xel-toolkit.org/
======
deedubaya
I'm sure this will be useful for someone, but from a UX perspective I have one
comment about the macOS theme.

HTML representations of macOS native UI elements have been attempted many
times. I still haven't seen anyone get them just right. I think you're better
off using a design which doesn't try to replicate native elements as they
won't match a user's selected appearance, nor will they automatically update
when macOS makes a styling change. This will probably give the user a bad
impression of your app.

~~~
kitsunesoba
Indeed. I applaud the effort, but the UI of macOS has many, many subtle
details that at first glance don't have much value and end up getting
discarded in imitations. Once those details are missing it becomes evident why
they the original possessed them.

If you're going to imitate a native style, you've gotta go whole hog and nail
it down to the last idiosyncrasy or it's going to be vaguely weird/awkward.

~~~
citrusui
Funny you mention that: I've always had the idea of replicating the Mac's
Cocoa interface. Once you extract the System UI assets[0], you have a good
reference to use. Actually using that reference to make a (web) framework is
something more complicated, but I wouldn't say it's impossible. I haven't
tried, mainly because I don't have enough patience, but also because I'm
uncertain if it violates any copyright laws, (which it probably does.)

[0]:
[https://github.com/alexzielenski/ThemeEngine](https://github.com/alexzielenski/ThemeEngine)

~~~
jarek-foksa
I was also concerned about the possible copyright claims, therefore I have
encapsulated the macOS theme in a single CSS file [1] and I added a more
restrictive license to it. I might remove it completely in case I receive any
complains from Apple. I'm not using any assets from macOS though, everything
is done with plain CSS.

I'm planning to implement ElementaryOS themes [2] as a safer alternative that
looks good on both macOS and Linux.

[1] [https://github.com/jarek-
foksa/xel/blob/master/stylesheets/m...](https://github.com/jarek-
foksa/xel/blob/master/stylesheets/macos.theme.css)

[2] [https://elementary.io/docs/human-interface-
guidelines](https://elementary.io/docs/human-interface-guidelines)

------
comex
One macOS behavior this gets wrong that a lot of other clones do too: press-
and-hold on menus and select boxes.

With the native widgets, you can invoke a menu item either by clicking the
menu, releasing, and then clicking the item - or by pressing down on the menu,
dragging to the item, and releasing.

Xel doesn't support the latter at all. Other toolkits do but get some details
wrong, like

\- if you release on an item that opens a submenu, it dismisses the menu (but
the same doesn't happen if you click such an item after clicking the menu);

\- macOS assumes you're using the press style if _either_ the mouse moves a
significant amount between pressing down on the menu and releasing, or it
stays pressed for a certain interval. So if you press a menu, wait a second,
and release, it dismisses the menu.

------
stupidcar
IMO, trying to clone native UI widgets in a 3rd party toolkit is a bad idea,
and Swing proved it in the early 2000s. No matter how hard you try, you end up
in an uncanny valley where it looks and feels _almost_ like a native macOS (or
whatever) app, but there are bugs and inconsistencies that make it feel
slightly off.

Far better and easier to just use a custom widget toolkit that works
consistently across all your target OSes. So many actually-native apps use
custom widgets anyway nowadays that your app will hardly look foreign for
doing so.

~~~
jarek-foksa
AFAIK Swing did not have the advanced theming capabilities that are now
possible with modern CSS.

Making the HTML widgets look and behave exactly like native Cocoa components
is probably not going to happen, but definitely I can do better than Swing or
GTK.

~~~
stupidcar
Swing is an extremely powerful toolkit with very rich capabilities. And since
it's backed by Java2D, you can control the painting of a widget at the pixel
level, if you want to - which is something CSS won't have until the CSS
Painting API arrives[1]. For proof, look at what JetBrains achieves in
IntelliJ, which uses Swing.

Technical capabilities are not the obstacle. The problem is that you're trying
to reverse engineer and build a faithful emulation of a complex set of
software components in a completely different language and runtime. And unlike
emulating a legacy system, OS toolkits are a moving target. They get tweaked
constantly, and often overhauled completely with each new release.

[1] [https://www.w3.org/TR/css-paint-api-1/](https://www.w3.org/TR/css-paint-
api-1/)

~~~
evilduck
IntelliJ still feels like a Java app imitating a macOS app to me. They do
better job than most, but if you open up the settings of it and compare it to
XCode's setting, it jumps out at you.

------
hartator
> To view this site, you must use Chrome, Opera or other Chromium-based
> browser.

I think that's a good summup of the downsides of relying in web technologies
to build desktop apps. Can't produce a true website.

~~~
jarek-foksa
It's not a website, it's a single-page app built with Xel, which in turn is an
experimental project built with bleeding edge Web Platform technologies such
as Custom Elements v1, Shadow DOM v1 or ES2017.

I will implement a proper project website for all browsers when the project
matures.

~~~
Sir_Cmpwn
Don't do a UA check. Just let it be broken. At the absolute worst put up a
page warning users it might not work, then let them try anyway.

~~~
jarek-foksa
This approach works with mostly static or server-side generated websites, but
with JS-heavy SPA unsupported browsers would be just showing a blank page.

Currently I'm checking whether the browser supports Custom Elements v1, Shadow
DOM v1 and HTML imports. If it does not, I'm showing the fallback page.

------
zerr
A question: Why bundling Electron/chromium is better than bundling JVM?

~~~
tomjakubowski
Support tooling for web UI development is superb. I don't know the state of
the art in Java/JVM GUI, but the rapid prototyping you can achieve with live
code reloading, browser DOM inspectors, etc. is unmatched in my (admittedly
limited) experience with UI toolkits. QtQuick is the only other that's come
close for me, and it's heavily inspired by the front-end web "toolkit".

It's probably more about the developer experience than anything else. Bundling
Electron in every application is pretty bloaty.

~~~
pjmlp
RAD tooling for native UIs was already a thing in the mid-90's.

Web tools are still catching up with 4GLs and RAD environments.

------
scandox
> To view this site, you must use Chrome, Opera or other Chromium-based
> browser.

Well frankly F off

~~~
kbenson
Actually, given the subject, that's an entirely acceptable requirement.

If all the components are only meant to function inside a blink based engine,
then making versions that might function without chrome specific extensions
just for the demo site is silly and a waste of resources.

It's simple enough to install chrome just to view this if you didn't have it
installed already, and if you are interested in deploying an electron app, you
probably already do.

Requiring a chrome based browser to view is the equivalent of requiring your
browser support java applets when viewing a site showing off a toolkit for
java applets (assuming it's a decade in the past). The simplest way to show
the actual usage it to actually use them, and the best way to make that
function _correctly_ is to deploy examples that actually use the engine.

~~~
detaro
I'd argue presenting the documentation for your java toolkit as a java applet
would be bad form.

Not getting the full demo without a matching browser (although I'd ask the
question if there isn't a polyfill for the webcomponent APIs), but there is no
reason why a basic info page with at least a screenshot doesn't work
everywhere, and would already be a lot friendlier. There is the "fork on
github" banner, but the readme just sends you back: "Visit xel-toolkit.org for
demos, documentation and code samples."

~~~
jarek-foksa
Unfortunately it is not technically possible to polyfill all Web Components
APIs. Shadow DOM is especially hard to polyfill in any sensible way (Google
did try it, but failed to deliver a solution that would cover all use cases).

I'm sorry for the missing documentation on Github, I will write a proper
project description with some examples later next week.

