Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Libmui is a macOS Classic widget lib for Linux (github.com/buserror)
300 points by buserror 8 months ago | hide | past | favorite | 82 comments
Not sure if I would post this for the last day of #marchintosh OR wait for tomorrow the 1st of April. Both apply equally.

Anyway, here's a pet project of mine, I made it as a glued on for another pet project of mine, but it developed a life of it's own now and can soar skyward toward success, fame, and glory.




Related, there's a public domain truetype font that's a pretty great copy of the original Chicago system font: https://fontlibrary.org/en/font/chicagoflf


I was pondering using Chicago as default font, but it is pretty 'typecast' (no pun intended, this time ;-)) -- Charcoal (that was used in System 8.x onward) is a lot less 'known' and also, I think, a significant improvement...

But it is actually pretty easy to switch to Chicago in the library -- apart from the clone you mention, there is also a 'plain' TTF version of the original Chicago floating around...


Split the difference with Espy Sans as seen in Newton, eWorld, iPod Mini, and often predicted to be the default system font in “Copland” Mac OS 8 had it shipped: https://lowendmac.com/2000/using-the-espy-font/

t. satisfied Nu Sans shareware buyer http://www.scootergraphics.com/nusans/ :)


Bitmap fonts are beautiful. I think the original iPod(s) also used Apple's bitmap fonts including Chicago and Espy Sans.


I love Espy as my system font.

One benefit to having the Newton Connection Utilities and Toolkit installed is that beautiful font.


Charcoal fits the spirit of the hiDPI remake better to my eyes too. But as we're on 'spirit' and pedantry, the unaligned popup selectors in the demo look off to me, compare with

https://www.oreilly.com/api/v2/epubs/0201700042/files/020170...

or similar.


Maybe I'm weird, but I feel like that style of GUI design with OS 8 and 9 were the pinnacle of GUI styling. Well, maybe BeOS deserves mention as well. But you could put young children in front of a Mac at school, and they'd figure out how to do everything they needed to do without much help and with no distraction.


Yes there are a few tweaks to make -- I worked in 'passes' in the code, and my last 'pass' at the menus was a little while ago, normally I go and fix the little nags as I go along.

Last (big) pass was the text editor, which isn't totally finished and polished but I had to release something for the deadline ;-)


I found it fascinating that my brain readily accepts this as macOS Classic UI, even though, as you say, it's a kind of System 7++ - a neat trick to have pulled off. Then after a bit it starts nitpicking on alignment and spacing unasked, like some weird Apple Cult Manchurian Candidate.


The unaligned popup selectors scared me too... hope it won't be added to "get off my lawn"-faq ;)


> …there's a public domain truetype font that's a pretty great copy of the original Chicago system font…

You can also get the "real" TrueType Chicago font (designed by Bigelow & Holmes) via a System 7.6.1 download, then convert the TTF to OTF with FontForge's command line tool. https://www.macintoshrepository.org/1682-mac-os-7-6-x

  fontforge -script -c 'Open($1); Generate($2);' input_font.ttf output_font.otf


Why even go through that trouble? In what circumstance would you need an `otf` when a `ttf` won't suffice? (Genuinely curious, I've wondered this for a while because I've never seen something that supports `otf` but not `ttf`).


TrueType fonts of that era typically came in separate Windows and Macintosh versions due to implementation differences. One difference was how Windows relied on an additional `OS/2` (lol) table in the TrueType font data, unused by Mac OS: https://typedrawers.com/discussion/501/can-someone-explain-t...

The arguably bigger reason is that Mac OS didn't support "data fork TrueType fonts" (what most people probably think of when they think "TTF file") until Mac OS 8.5 (1998). Before then, TrueType and other fonts on the Macintosh were resource-fork-only, because "installing" a font prior to 1992 meant using a special Font Mover utility which actually grafted the font's resource data into the Macintosh System suitcase itself at an unused Resource ID#. Attempting to even copy such a font to a Windows system would yield a 0-byte file on the receiving end unless one knew what they were doing. System 7.1 (1992) added a dynamic "Fonts" folder in the System Folder but still expected to see them as Macintosh resources.

An Apple-commissioned font like Chicago probably never had an official data-fork-plus-OS/2-table "Windows Version" made of them at all. Since the actual Bézier curve data (`glyf` table) was the same on either platform, it was possible to homebrew a Windows version of a Macintosh font or Macintosh version of a Windows font.


Upvoted for implausibly specific domain knowledge.


At one point I recall TTF hinting being patent-encumbered, but you bring up a great point — any patents surely have expired by now.


Modern versions of macOS also include the "Silom" Thai-language font, which uses Chicago for its Latin glyphs.


This is really cool, Michel wrote this for his Apple II emulator, and I've been using it (as a slight troll) to replace the front-end for an Archimedes emulator. It's early days, but if _I_ can understand the API, it must be OK :)


Even using it for an Apple II emulator is a bit of a troll because back in the day Apple II users resented the Mac as they wanted Apple to continue the Apple II line and were upset that Apple dumped it in favor of focusing on the Mac. That said, I do have a fondness for the classic Mac interface


The Apple IIgs had a simplified Mac-style GUI, so it kinda fits.


The IIgs UI is not simplified at all, it had pretty much all the toolkits the Mac had in terms of user interface. It had all the graphics bits, the IPC bits, even networking, layered filesystem etc etc; it is often overlooked how far they had gone in term of featureset at the time of GS/OS 6.03 which was the last (official) release.


Is any part of GS/OS based on original MacOS code ported from 68000 to 65C816? Or is it a clean-sheet reimplementation?

If one in 1988 wanted to port a MacOS application to GS/OS, how difficult would it have been? What would have been the IIgs equivalent to, say, MPW?


I think the main problem was that the chunkier graphics necessitated by the lower resolution always made the IIgs graphics look like a primitive copy, so everyone assumed the rest of the stack underlying it was similarly primitive.


I liked the dual header 2D graphics rasterizer that this uses: https://github.com/xboot/libcg. I'm always amazed by how we can build powerful software with minimal dependencies like that.

Would it be that hard to build nice, clean and powerful UI libraries as alternatives to Electron?


No. But then what would we do with all of the extra memory and performance?


Extra memory and performance is invariably passed down to people who will come up with lovely bloat to fill the void :-)

I find it quite horrifying in many ways to see how much resources are used for so very little in terms of user benefits. Not just 'UI' per se, but just general functionality.

And the 'reasons' are always the same too, 'it is more maintainable' (read: it is not, in 2 weeks time the new version of your stack will break your 'code'.), 'it is easier to read for a newcomer' (read: no, not at all, it is just this week's fancypants trend), 'it is more secure' (read: just because we don't actually KNOW what it's doing, and rely on hopefully someone else for it) etc etc.


The real reason is always the same: it's cheaper. That's just the way it goes.


This is incredible. It's MIT licensed AND written in C! If you added shims for the AppKit APIs this might give GNUstep a run for its money.


Or just theme GNUStep, it supports themes like this.


Sure. But the problem with GNUstep is the GPL.


This looks great. I wish I could switch my entire MacOS ui to that.


Activate high contrast mode from the accessibility settings and you're almost there.


Nice project, I really liked the old classic Mac UI. All your examples look great and it seems easy to use from looking at the widget demo code.


That’s very cool. I wonder how much effort would be needed to read resources from a resource fork (.rsrc) to create UI.

If it could be done, ResEdit could be used :-)


Loved the FAQ.


Not a Mac fanboy even if I now use a Macbook Pro for most of my work (and like it).

But this is good.

I mean: anything that brings back some sanity. Clear unambiguous controls. Menus instead of gear icons, hamburger menus and fly droppings.

Great work!


Modern UI is confusing and disgusting. They're more magazines than useful software.


Great Job !


I know that this is picky but the old Apple Human Interface Guidelines specify things like how much distance you put between different elements! Try it out. Go for the 1992 edition of the HIG, for this System 7 look.

Like, when you have a dialog box, you have a certain number of pixels on the left, right, top, and bottom. The buttons are a certain number of pixels apart. If you look at old software from the very early days of the Mac, you’ll see that it’s kind of the wild west of user interfaces—either the HIG wasn’t out yet, or people weren’t reading it.

The HIG also has a bunch of good practices for thins like how to name buttons and menu items. Buttons should ideally be single words, and should be verbs. Menu items get a “…” ellipsis if there’s a dialog box that appears before you perform the action. The book shows how common interfaces look in non-English languages, like Arabic, Hebrew, and Japanese.


Good thing we innovated away all of that. Now we have hamburger menus and magically disappearing UI elements.


Yeah. No.1 PIA is a thin scrollbar on Serious Sam Mental difficulty.


Thin overhead super low contrast scrollbars that keep disappearing and have a hitbox even smaller than the visual part. I hate how this thing seems to have infected every single software. I've been using computers since I was 10 years old and these things give me some trouble, imagine someone who is not as comfortable with tech or has some disability, even a minor one. It's a trainwreck.


> Like, when you have a dialog box, you have a certain number of pixels on the left, right, top, and bottom. The buttons are a certain number of pixels apart.

IIRC, if you were using DITL resources for layout (standard practice for dialog boxes), ResEdit would help you out by snapping controls to these spacings. If you were doing programmatic layouts, though, you were on your own.


Here are some screenshots and links for the 1992 edition of Apple's Human Interface Guidelines.

https://safereddit.com/r/MacOS/comments/me2r7j/macintosh_hum...


I wish Apple had a modern version of this that 1) was as well thought out and 2) they actually paid attention to.


helloSystem are doing something similar:

https://hellosystem.github.io/docs/developer/ux-guidelines.h...


Interesting, I hope they continue the interface guideline effort and are successful putting them into practice in their system.

One thing that Apple did well, as far as I can tell, was getting application developers to abide by the human interface guidelines, which made for a more consistent and seamless experience across apps.

In the modern hellscape of web apps, every app has its own appearance, interface, behavior, data formats, cloud storage system, etc. Moreover, control is strongly with the app developer/service provider rather than the user. Web apps routinely disable or alter standard features like cut and paste, or going back after clicking on a link. Upgrades are often forced and full of bewildering changes....

Which means that even if Apple (or HelloSystem) could force every desktop (or mobile) app developer to obey its interface guidelines, it would have no effect on the many web apps which people will still have to use.


> I miss the days were UIs were /crafted/ not just decided for you bad a bad 'layouting' engine with huge rectangular flat buttons and no sense whatsoever of 'design' or usability.

I couldn't disagree more regarding 'layouting' engines. I absolutely detest pixel-perfect English-only UIs that basically look like a mess the moment anything (including font DPI) changes. You CANNOT imagine how much pain the work of the translator is and it just doesn't matter because it will look horrible anyway, specially the more "smarts" the original English form designer applied.

I want to enlarge the fonts, reduce the size of the useless icons, and set black backgrounds, and no amount of "creativity" from the original designer is going to convince me to lose that flexibility. I'll also translate to my native tongue thank you very much.

Flat buttons and no usability testing is another story, of course.


It is not terribly difficult to make 'crafted' UI localizable, there are a few rules to follow that's all. I worked for apple back in the day and shipped software translated in countless languages, and the same 'crafted' UI worked pretty well in all cases. Of course there are always exceptions, and 'modern' HiDPI present issues if all you do is use hard coded pixels as a unit, but it is still manageable.


Would it work if the other language increased the text length twofold? How about right-to-left languages? What if the language is sensitive to numbers and putting a numeric textbox in the middle of a sentence would require the sentence to change phrasing significantly depending on the value?

Here’s a screenshot of the Windows Vista start menu in English: https://cdn.arstechnica.net/wp-content/uploads/2015/07/Scree...

As you can see, it’s a nicely crafted layout, with the power buttons at the bottom taking up all the available space, and the thin separator lines below "E-mail", below "Games", and above "All Programs" are taking up the entire widths of the boxes they’re in (minus reasonable margins).

Here’s the Polish version: https://ia902303.us.archive.org/24/items/WinVistaSP2AIOPLMay...

The awful translation made both columns of the menu much wider, making the separators look too short, and adding blank space next to the power buttons.


> The awful translation made both columns of the menu much wider, making the separators look too short, and adding blank space next to the power buttons.

They aren't much wider.

The one English one is a 1373px wide screen shot. The Polish one is 800px wide.

Even if both menus were in exactly the same language, the second one would look wider anyway.


The start menu width does not change with the screen width, here’s a smaller screenshot of Vista in English: https://betawiki.net/images/3/35/WindowsVista-6.0.6002.18005...


> The start menu width does not change with the screen width,

With respect, you're missing the point - the start menu width does not change with screen width, so on a smaller screen the start menu takes up more space.

You're comparing a ~800px-wide screen with a ~1400px wide screen - obviously the narrower screen is going to lose more to the start menu than the wider screen, even when the menu itself is exactly the same pixel size in both screens.

> here’s a smaller screenshot of Vista in English: https://betawiki.net/images/3/35/WindowsVista-6.0.6002.18005...

That's still much, much larger than the polish version you supplied. Why not show images of the polish version and the english version with the same resolution?

TBH, I get very skeptical when doctored evidence is produced in support of an argument. Your argument might have been better received had you produced no evidence at all rather than misleading evidence.


How is this doctored? It’s hard to find screenshots at an exact size. But if you really can’t see the difference, here are screenshots from clean installs in both languages at two resolutions:

https://i.ibb.co/CByXH82/Vista-Start800.png

https://i.ibb.co/CWLvgn5/Vista-Start1024.png


I see what you mean with your original post - I have to sadly admit that I read your post wrong (you weren't unclear, I was just not reading properly).

In my initial reading, I looked at the images and assumed you were talking about the reduced real-estate in the rest of the screen due to the expanded menu. Reading more carefully, you were talking about the extra added space on the right margins.

Now that I see what you are talking about, I admit, yes, there is significant extra space on the right margin, but I disagree that it deserves the description of "awful". It's not ideal, but it's not really awful either - readable, understandable and easy on the eyes.


Bad localisation is possible even going from English (US) to English (UK).

I remember a mac magazine from my youth complaining that Apple was wasting unnecessary space by localising the deleted items folder as "Wastebasket" when the Americans had "Trash" and in both countries "Bin" would be valid and even more compact.

(It is now called "Bin" on my machine, I don't think I even noticed the change — we're no longer stuck with 640x480 displays where every letter counts so the change didn't matter when it happened).


Yep, the designer taking into account the strengths and limitations of the UI toolkit being used and remembering to design for more than just the happy path (e.g. accounting for long strings and variable fonts) will get you 90% of the way. UIs localizing badly in my experience is often caused by rigid designs that make loads of assumptions and were only ever concerned with looking good in a mockup.


Decades of fixing dialog templates in resource files disagree with any definition of the word "manageable".

Just for comparison, nowadays a shitton of desktop software doesn't look all too bad with just changing a gettext()-style list of strings, and not even touching the dialog definitions. You may argue that this is because the dialogs nowadays just look equally bad in all languages, but I'd disagree and anyway it definitely is an order of magnitude in "manageability".


This is why we can't have nice things.


> In the 'example' folder, the playground demo copies it to an X11 window via a XCB 'shared' pixmap, so works great even via remote X11. The library is 'smart', like the old OSes, it keeps track of 'invalid' regions, and only redraws what is needed, so theres very very little overdraw.

So it actually is technically superior to most (all?) "modern toolkits. Nice:)


This is gorgeous. Well done!

My only nitpick is that MUI is already the name of an Amiga GUI toolkit. A widget lib named libmui is not what I’d think it was.


Magic User Interface (MUI) is still the primary toolkit on MorphOS, in addition to being the go-to toolkit for many newer Amiga programs as well.

When it was released in 1993, it was very modern. Object-oriented, scalable layout, simple to program, themeable and very customiseable. I wouldn't be surprised if the developers of Qt, Gtk and SwiftUI would reveal that they would have taken inspiration from it.

https://en.wikipedia.org/wiki/Magic_User_Interface

http://www.sasg.com/mui/


gtk+/gnome folks were apparently at least vaguely aware of Amiga MUI e.g. discussing it in a context of implementing theming/styling in Feb 1998 -

https://lists.gnome.org/archives/gnome-themes-list/1998-Febr...


Already better than GTK4


https://github.com/B00merang-Project/Mac-OS-9 includes a GTK+4 theme. If you like the "High Contrast" look, check out https://github.com/B00merang-Project/System-4 too.


Very apt username


Amazing. Now all we need is for this to replace all the Electron stuff out there, and sanity will be restored on the desktop.


[flagged]


SerenityOS takes a lot from the win9x era of GUI design (with a little bit of classic Mac sprinkled in here and there).


Yep, that's pretty much it.

Reminds me that one of the single biggest regressions in GUIs over the last couple of decades is: The knowledge of how to make a proper tabbed dialog has been lost to many.


I prefer win 95 over the modern sh¡tfest, but what I really miss is the shiny aqua stuff that make you want to lick the screen. I couldn't even afford a Mac at the time, so I had the aqua-like themes on gnome (back when you could configure stuff and have it not break early the following week).


Aqua was something else when it came out wasn't it? BUT -- fun fact, that pulsing "OK" button was using 30%+ CPU on my iMac DV back then...

The price you had to pay for lickable UIs :-)


Wasn't Quartz GPU accelerated?


No, not until quite a few versions later.


We used a swing look and feel of aqua and clients loved it… until iOS7 came in


Shitfest indeed.

"back when you could configure stuff and have it not break early the following week"

Exactly, but this was true on every GUI EXCEPT the vaunted Mac. For what, two decades, you could set up your own system-wide color scheme under Windows, which would be inherited by all competent apps. I set up a nice, non-inverse (today's trendy "dark") scheme in 1991 and used it into the 2000s. Then, just before everyone finally realized that staring at black text on a glaring white screen all day sucks... Microsoft removed the scheme editor from Windows entirely.

The Windows shitshow has only gotten more rank from there. Not knowledgable enough to weigh in on Linux and Unix GUIs.


Gnome is basically "we made it, and we really want to feel like we've been creative, and you can't say anything against it."

Granted, I get it for free, but my attention and effort to fight it isn't free, so I only use it when I'm being paid to do so, just like windows.

In my own systems, I've just removed the desktop, I use xmonad, xterm, Emacs and chrome. That covers 95% of what I need.


on the gnome attitude


KDE Plasma is extremely configurable on that end, and lets you define color schemes, window decorations, everything.


You could pick a color scheme on Mac too, as long as it was blue or gray


Ha, true.

They actually did have a way to invert the whole UI... but it also inverted photo images on the screen. poundAppleAttentionToDetail


Glad you didn’t post tomorrow. The one day of the year I don’t look at any HN or Reddit or any social media sites. I hate April Fools pranks.


My mind visualizes you as a grumpy old man


You're the fun one at parties, I see




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

Search: