Hacker Newsnew | past | comments | ask | show | jobs | submit | whartung's commentslogin

JavaFX is a hidden gem. I really like the programming model with its binding and scene graph and CSS.

It's not as portable as Swing, as it has some platform specific binary components to it. But it works fine on mainstream platforms. For me Swing portability is not worth giving up the FX model.

Just be aware that if you happen to bundle in the Web view component, you're basically adding WebKit to your distribution. I did this with a small project because I wanted to have a "help" screen with Markdown -> HTML. Easy, but "expensive". It simply adds a big chunk (10-20Mb) to your distribution.

(Now I have a very crude Markdown renderer for this task, which is a 100 lines code, and I'm working on a better one -- but I have yet to pull the trigger on the latest FX with its new Rich Text component, which could change everything.)

One hot tip with cross platform FX, however. Embed your fonts. The font suite is not common across the distributions, and the CSS does not honor the font fall back (i.e. if not XXX font, then YYY font), so if the runtime doesn't have your specific font, it collapses to the System font. So, embedding the fonts you use helps a lot with cross platform stability. Plenty of free fonts, I have not had a real problem with this. But it can be one of those O.o moments when you test on other platforms and encounter it the first time.


There was a time when I sold my computer and bought a motorcycle.

Can honestly say that was one of the best trades I’ve ever done. I didn’t buy another computer for 3 more years.


Sold my computer + DLSR camera back in the day to afford moving countries. Can't imagine what life would have been if I didn't, very happy I did. Lived with a netbook for 2-3 years, but was before I was a professional programmer.

Ive always wondered if I sat down with a sketch artist and was asked to describe my wife, how close we would get.

Note that in a drawing like this, accuracy is not always required.

https://www.independent.co.uk/news/world/americas/worst-poli...


Its talked about here: https://www.c64-wiki.com/wiki/Garbage_Collection

The process they used was simple, but brutal.


A bigger question.

How do you all GIFT music these days?

My brother recently sent me a new album for my birthday. Very kind. But, it's on vinyl. And I don't have a player.

But it just reinforces thoughts I had before. I had wanted to gift him some music too, but, how? He has a phone. He has a computer. He's not particularly tech savvy. I know I can't ship him a CD, he has nothing that can rip it.

I know you buy an album on Amazon, they let you download the MP3s right away. But, how do I even gift that? Can you even download MP3 to an iPhone? From someplace not Apple? I honestly have no idea.

And it just highlights, to me, the entire (seemingly) difficulty of gifting music today.

Me, I still buy CDs and rip them.


I'm hoping to see progress in this space.

Folks talking about how 32G is not enough for local use, but then there's been work like this to empower it.

My hope is that the new 32G M6 will be "useful" locally, possibly because of work like this.


Yes, but also 12 tok/s versus Claude is so far from comparable. I know that it’s not exactly 1:1, but it’s a long way from an easy trade-off, especially considering hardware prices for high levels of RAM.


32GB is simply too tight; you need 8 minimum for the OS and you need about 4-8 more for the LLM you’re visiting and kv cache.


yes! I'm bullish on this. there is a lot of work to do. I've been experimenting with pruning, distillation, and retraining too. I'm sure your 32gb m6 will run a badass local model!


I'm sure I'm not the only person to have built a wall unit in a bedroom only to learn, later, getting it out the door, and through the hall, and down the stairs turns out to be job for Dirk Gently.

That said, moving some of this flat pack furniture has been a mixed bag. Some move well, some don't.

I did have a wall unit, a $99 hardware store particle board piece assembled with big screws and those interesting, round cam fasteners. It survived three separate moves, including one where it flew out the back of my pickup truck onto asphalt (thankfully in a gas station, vs the freeway I was about to get on). Corner got dinged, door flew off, but it survived!

But I've had other pieces that assemble and are rigid, when torqued around through the moving process start to come undone. The particle board and fasteners are designed for loads only in specific directions and tend to not do well, and fail, outside of those.


I would submit that the point of the GUI was necessarily "anti-keyboard" as more "pro-discovery", plus adding gestures that would be difficult on a keyboard.

Keyboard interfaces can be, but not necessarily, quite opaque. There's a reason in the old days companies shipped keyboard overlays and function key templates to help users (or went all in with custom keyboards built for the application).

In contrast consider something like Wordstar where you pretty much just needed to memorize the three prefix keys, and if you pressed one and waiting, you'd get a menu describing all of the options.

Obviously, things like early Smalltalk and, probably, Xerox (having never used any of the early Xerox systems), relied heavily on the mouse, but even it had command accelerators.

The CUA standard was that crossover that Windows, and MOTIF, adopted. Much of that work is still with us today, and it worked well both on GUIs and TUIs (witness the old Turbo Pascal/C++ IDEs, and other applications). Those character based applications had to assume there was no mouse, but offer the flexibility of being good citizens should a mouse be present.


It says I'm terrible. But I've known that for a long time.


I've mentioned this before, but the rise of the TUI is the simply the systemic failure of remote GUIs.

The primary value statement of TUIs is that they work over SSH with remote systems.

But now, we're hearing rumbles about the limitations of the "modern" terminals with regards to working well with a "rich" TUI. How a raw tty doesn't really cut it since it, at a minimum, can't detect key presses, only actual character/byte patterns. How there needs to be a new protocol, a "better" terminal client.

Of course when you go that route, then the current terminal emulators will need to be updated, or you'll be required to install a different terminal emulator that supports the new protocol. But that kind of defeats the theoretical, historical ubiquity of a TUI. It would not surprise me that many modern TUIs only work with an ANSI terminal.

Back in the day, we had systems like Visual Basic, Power Builder, SQLWindows. GUI/language systems particularly well suited for Client/Server DB development.

For a time, Firefox actually presented itself as a modern incarnation of these tools. Using XUL and JS for UI development, built in utilities to talk back to servers over HTTP. It was a platform for "Rich Internet Applications(tm)".

It didn't really take off, it wasn't documented very well, kind of buggy. It also required Firefox as a client. The potential was there, but not quite realized. Ajax hit the web browser in full force and that pretty much was the last nail. Now, you could use "any" browser for more interactive applications.

Of course, we advance to today, where many sites work in any browser as long as its Chrome. We have advanced applications that are no more than a Canvas element, with everything else being reinvented from scratch. "Have bitblt, will travel."

The browser is the closest thing we have to a universal remote GUI, but we all know the issues with it for many contexts. As an application platform, it may be ubiquitous, but that doesn't mean it's at all lightweight.

We used to have lightweight, remote GUI applications. Rootless X Window applications. Folk don't necessarily want the entire desktop, they just want an app, with some fields and buttons. You could slap them together with TCL/TK. Remember dtksh? We're not talking about trying to write Adobe Premiere or AutoCAD in these things. We just want some simple utilities, fields, icons, maybe a chart. Scrolling tables and a menu.

But we can't do that today, not readily, not easily.

So, we're kicked back to 1978 and the rise of the Smart Terminal, instead of 1984 and the rise of the X Terminal.

If folks are going to write out a custom client for a TUI, then may as well go the extra 10 feet and make it a remote GUI client. Reinvent all of the wheels as they go round, and round again.


one step deeper - it's a failure of WIMP[1]. Imagine if instead of having a border around the parts of an app that make it an app and instead we applied the unix way but to the gui? What if we had lightweight widgets that had a lifetime of their own and could be nested and combined.

[1]: https://en.wikipedia.org/wiki/WIMP_(computing)


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

Search: