[HN Gopher] Show HN: Libmui is a macOS Classic widget lib for Linux
___________________________________________________________________
Show HN: Libmui is a macOS Classic widget lib for Linux
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.
Author : buserror
Score : 283 points
Date : 2024-03-31 19:33 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mattbee wrote:
| 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 :)
| jhbadger wrote:
| 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
| zozbot234 wrote:
| The Apple IIgs had a simplified Mac-style GUI, so it _kinda_
| fits.
| buserror wrote:
| 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.
| mrkstu wrote:
| 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.
| tpmoney wrote:
| 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
| buserror wrote:
| 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...
| pvg wrote:
| 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.
| dingdingdang wrote:
| The unaligned popup selectors scared me too... hope it
| won't be added to "get off my lawn"-faq ;)
| buserror wrote:
| 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 ;-)
| pvg wrote:
| 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.
| queuebert wrote:
| 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.
| Lammy wrote:
| 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/ :)
| musicale wrote:
| Bitmap fonts are beautiful. I think the original iPod(s)
| also used Apple's bitmap fonts including Chicago and Espy
| Sans.
| itomato wrote:
| I love Espy as my system font.
|
| One benefit to having the Newton Connection Utilities and
| Toolkit installed is that beautiful font.
| CharlesW wrote:
| > _...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
| brirec wrote:
| 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`).
| CharlesW wrote:
| At one point I recall TTF hinting being patent-encumbered,
| but you bring up a great point -- any patents surely have
| expired by now.
| Lammy wrote:
| 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 Bezier 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.
| pram wrote:
| Upvoted for implausibly specific domain knowledge.
| AshamedCaptain wrote:
| > 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.
| exe34 wrote:
| This is why we can't have nice things.
| buserror wrote:
| 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.
| Kwpolska wrote:
| 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.
| lelanthran wrote:
| > 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.
| Kwpolska wrote:
| The start menu width does not change with the screen
| width, here's a smaller screenshot of Vista in English: h
| ttps://betawiki.net/images/3/35/WindowsVista-6.0.6002.180
| 05...
| lelanthran wrote:
| > 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.
| Kwpolska wrote:
| 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
| lelanthran wrote:
| 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.
| ben_w wrote:
| 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).
| jwells89 wrote:
| 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.
| AshamedCaptain wrote:
| 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".
| sirwhinesalot wrote:
| Already better than GTK4
| zozbot234 wrote:
| 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.
| desiderantes wrote:
| Very apt username
| e40 wrote:
| 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.
| pmarreck wrote:
| You're the fun one at parties, I see
| jeffhuys wrote:
| My mind visualizes you as a grumpy old man
| proneb1rd wrote:
| This looks great. I wish I could switch my entire MacOS ui to
| that.
| carlosjobim wrote:
| Activate high contrast mode from the accessibility settings and
| you're almost there.
| yjftsjthsd-h wrote:
| > 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:)
| eitland wrote:
| 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!
| tomthehero wrote:
| Modern UI is confusing and disgusting. They're more magazines
| than useful software.
| ndiddy wrote:
| 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.
| kstrauser wrote:
| 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.
| Findecanor wrote:
| _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/
| rcarmo wrote:
| Amazing. Now all we need is for this to replace all the Electron
| stuff out there, and sanity will be restored on the desktop.
| klodolph wrote:
| 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.
| actionfromafar wrote:
| Good thing we innovated away all of that. Now we have hamburger
| menus and magically disappearing UI elements.
| hnthrowaway0328 wrote:
| Yeah. No.1 PIA is a thin scrollbar on Serious Sam Mental
| difficulty.
| amlib wrote:
| 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.
| raybb wrote:
| 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...
| musicale wrote:
| I wish Apple had a modern version of this that 1) was as well
| thought out and 2) they actually paid attention to.
| UncleSlacky wrote:
| helloSystem are doing something similar:
|
| https://hellosystem.github.io/docs/developer/ux-
| guidelines.h...
| duskwuff wrote:
| > 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.
| jimbokun wrote:
| Loved the FAQ.
| felipefar wrote:
| 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?
| musicale wrote:
| No. But then what would we do with all of the extra memory and
| performance?
| buserror wrote:
| 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.
| jfb wrote:
| The real reason is always the same: it's cheaper. That's
| just the way it goes.
| jhatemyjob wrote:
| 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.
| anthk wrote:
| Or just theme GNUStep, it supports themes like this.
| jhatemyjob wrote:
| Sure. But the problem with GNUstep is the GPL.
| OnlyMortal wrote:
| 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 :-)
| wiz21c wrote:
| Great Job !
___________________________________________________________________
(page generated 2024-04-01 23:02 UTC)