[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 : 119 points
Date : 2024-03-31 19:33 UTC (3 hours 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 :)
| 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 ;)
| 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
| 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...
| 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
| 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.
| proneb1rd wrote:
| This looks great. I wish I could switch my entire MacOS ui to
| that.
| 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.
___________________________________________________________________
(page generated 2024-03-31 23:00 UTC)