31–40 of 59 posts
I find it amusing that the paper doesn't include any screenshots. Those were the days!
It's a neat project. Write cross platform desktop apps in C. Presumably it would not have been very usable in practice in the late 1980s, because of all the OTHER system interfaces that still weren't portable, even if the windowing system was available in a portable way. I can remember the subsequent period in which Java desktop apps were relatively common. They had cross platform UI by default. But the problem was:…
... was said reading it in a browser on who knows what OS/DWM.
I mean that 90% (if not more) of all UI interactions happen now in a browser or in multi-platform applications (e.g. messengers, SublimeText, VSCode, etc).
It's a neat project. Write cross platform desktop apps in C. Presumably it would not have been very usable in practice in the late 1980s, because of all the OTHER system interfaces that still weren't portable, even if the windowing system was available in a portable way. I can remember the subsequent period in which Java desktop apps were relatively common. They had cross platform UI by default. But the problem was:…
Honestly, "native UI" gets so much worse with every passing year that I don't even want native UI. I want old windows UI. I saw a screenshot of GTK 1 and the first thing I thought is that I'd rather make something using GTK 1 than GTK 3. Unfortunately I asked an AI chatbot about it and they advised against it because of "security" :(
So if I run Dune2 in dosbox, is that a security issue? Of course not, but if you were to load a bitmap from the network and feed it to GTK1 for displaying, there could well be an overlooked issue lurking around. But you need to look at the greater picture, not just "old==insecure"
Windows has keyboard shortcuts on buttons, but you can set per-user whether they appear underlined always or only when you hold Alt. Mac always has exactly one, immovable menu bar; and Enter doesn't close a dialog box. GNOME can rollup or pin windows from the title bar if you add the buttons for it. Whether the native dialog layout has the ok button to the left of the cancel button depends on the OS and the writing direction (p206 of [1]). Not every platform has a native calendar widget. And so on ...
Worse still, you're building an abstraction layer on top of several genuinely different systems, that users of different platforms will expect to work differently in the first place. Go down this rabbit hole and you end up with "show a help button on modal dialogs only on platforms where this is usual, and where you can open the help window without closing the modal first". "Portable native-GUI" is almost an oxymoron; wxWidgets is perhaps the closest we can get where at least you can ask for a wxFindReplaceDialog abstraction (p229 of [1]) and get the cancel button in the platform-default place, even if "Find-Replace Dialog" is not a feature included in the OS' component library itself.
[1] https://wxwidgets.org/docs/book/Cross-Platform%20GUI%20Progr...
How old is this? 1989 or something like that? Guido was probably quite young when he wrote it. Looks like LaTeX? Edit: Someone else wrote 1988 which I suppose makes sense, as the latest reference at the end is from 1988 too. So then Guido was 32 years old.
I would say roff, not LaTeX
A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components. Windows has keyboard shortcuts on buttons, but you can set per-user whether they appear underlined always or only when you hold Alt. Mac always has exactly one, immovable menu bar; and Enter doesn't close a dialog box. GNOME can rollup or pin windows from the title bar if you ad…
Sometimes though you're throwing together a quick and dirty UI for a specific use case that you just want to run on a bunch of different platforms and this sort of toolkit is great for that. It can be the difference between the application existing at all and it being available on a range of operating systems.
A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components. Windows has keyboard shortcuts on buttons, but you can set per-user whether they appear underlined always or only when you hold Alt. Mac always has exactly one, immovable menu bar; and Enter doesn't close a dialog box. GNOME can rollup or pin windows from the title bar if you ad…
Win32 + Proton/Wine? No idea.
How old is this? 1989 or something like that? Guido was probably quite young when he wrote it. Looks like LaTeX? Edit: Someone else wrote 1988 which I suppose makes sense, as the latest reference at the end is from 1988 too. So then Guido was 32 years old.
> quite young > 32 years old As a ~20 year old this feels so weird to read. I'm still considered young in ~10 years?
Earlier quoted context omitted.
Which had the ugliness problem then, although it is a lot better now.
AFAIK Tk simply wrapped native widgets though? E.g. when the result was ugly, then that was because the platform's native UI framework was ugly.
It didn't look ugly by early 90s standards (basically Motif look&feel) but didn't evolve.
It also always felt like a foreign body inside Python because Tcl was always still there along with it.
A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components. Windows has keyboard shortcuts on buttons, but you can set per-user whether they appear underlined always or only when you hold Alt. Mac always has exactly one, immovable menu bar; and Enter doesn't close a dialog box. GNOME can rollup or pin windows from the title bar if you ad…