Show HN: Xel, widget toolkit for native-like Electron apps
xel-toolkit.org
xel-toolkit.org
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.
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.
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...
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.
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.
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.
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.
Anyway, cloning macOS UI is not my primary goal. I just want to build a widget toolkit that could be themed however I want.
Anyone that has spend a few hours of their life reading either the "Rich Filthy Clients" Sun blog posts or the book that came out of it, should be able to write quite good Java Swing applications.
With CSS even getting something basic like hardware acceleration, is a matter of playing with Z transforms and hopping that the user is running the right browser, with the right version on the right operating system and it will pick up those CSS hints and accelerate them.
Even then, the amount of CSS tricks is limited, because each browser and GPU makes it different and it cannot be queried for.
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.
I will implement a proper project website for all browsers when the project matures.
Although I do question why his website would use the same framework since it's chromium only. It's fine to make it only for chromium, as he is targeting Electron which is chromium, but his website shouldn't depend on it too.
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.
It's probably more about the developer experience than anything else. Bundling Electron in every application is pretty bloaty.
Web tools are still catching up with 4GLs and RAD environments.
Funny enough, for anyone able to do proper Swing/JavaFX coding, the JVM applications take less space, are better integrated into the OSes and perform better than Electron ones, but it requires skill to do so.
I really can't understand why use HTML technologies for the Desktop...
Well frankly F off
Blocking other browsers is a bit extreme, but would reduce the pointless bug reports and bad publicity.
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.
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."
The equivalent would be if Java had a documentation viewer application which was built in Java and was the standard way to view the documentation. At that point, saying and enforcing "You need to read our documentation using the standard documentation program but utilizing this special Java version which is what you would be deploying the toolkit in, because that's the only way the examples will work right." matches the current situation.
I'm sorry for the missing documentation on Github, I will write a proper project description with some examples later next week.
Suffice, yes. And yet they are clearly inferior to actually using the widget as it would be used, so why sacrifice that? In the name of possible users that refuse to use Chrome?
I think the number of people that are actually interested in this that do not have a version of Chrome handy already install that they can use and are unwilling to install it to see the functionality of a tool that relies on the functionality of a core component of Chrome is very small. So small, in fact I would be interested to hear from someone that was actually put off from viewing this that was actually in the market to make an Electron app.
If I hadn't seen this comment thread, I would've went about my business to never give Xel a shot, because I'm on a low-end machine currently that takes forever to boot up Chrome, or any modern browser for that matter.
Though, I'm also a proponent of writing accessible sites/apps that don't break when javascript's disabled, so this sort of "you need x to view y" grinds my gears.
TL;DR: I'm definitely in the minority but it'd still be nice to have screenies
Sidenote: To those who use angular/react/vue: add a prerender to your buildscript to fallback to a static site for js-disabled folk. It can even wait for database calls, so dynamic content can still be shown. I personally use this one for Vue: https://www.npmjs.com/package/prerender-spa-plugin
> I'm definitely in the minority but it'd still be nice to have screenies
Which is fine, and I'm not arguing it's better to not have them, just that when it comes to the set of cases where it's okay to require a specific browser version, this pretty much fits the bill for me. Anything else is more work than using the actual widgets in examples, so that's what appears to have been done (and (one of?) the authors is on record here as saying they are planning to a add more later).
I just think "Well frankly F off" is a bit extreme given the actual specifics of the situation. People have a tendency to shift outrage from one item to another using false equivalencies (a website targeting general users doing this would be a different story), and I think that's worth calling out when I notice it.
In the longer run I'm planning to replace HTML Imports with ES.next modules, so it's temporary dependency.