Show HN: Libmui is a macOS Classic widget lib for Linux (github.com)
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.
97 comments
[ 2.6 ms ] story [ 146 ms ] threadIf 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?
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...
https://www.oreilly.com/api/v2/epubs/0201700042/files/020170...
or similar.
Last (big) pass was the text editor, which isn't totally finished and polished but I had to release something for the deadline ;-)
t. satisfied Nu Sans shareware buyer http://www.scootergraphics.com/nusans/ :)
One benefit to having the Newton Connection Utilities and Toolkit installed is that beautiful 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
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.
The price you had to pay for lickable UIs :-)
"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.
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.
They actually did have a way to invert the whole UI... but it also inverted photo images on the screen. poundAppleAttentionToDetail
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 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.
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.
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.
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.
https://i.ibb.co/CByXH82/Vista-Start800.png
https://i.ibb.co/CWLvgn5/Vista-Start1024.png
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.
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).
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".
So it actually is technically superior to most (all?) "modern toolkits. Nice:)
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!
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.
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/
https://lists.gnome.org/archives/gnome-themes-list/1998-Febr...
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.
https://safereddit.com/r/MacOS/comments/me2r7j/macintosh_hum...
https://hellosystem.github.io/docs/developer/ux-guidelines.h...
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.
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.
Would it be that hard to build nice, clean and powerful UI libraries as alternatives to Electron?
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.
If it could be done, ResEdit could be used :-)