proj-oot-ootGuiNotes1

" For example, in Tcl/Tk (which combines the Tcl language with a tool kit for building graphical interfaces), you can create a working application with only two lines of code:

button .myButton -text "Hello" -command exit pack .myButton "

-- http://archive.wired.com/wired/archive/3.09/geek.html

---

https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b

not saying we should just use this, b/c it re-renders at 60fps or whatever, consuming a lot of CPU time, and also it doesn't use native widgets. But this article goes into detail about properties that the GUI editor should have, and some properties that affect the language, such as being able to livecode the GUI, sorta.

---

 tabtab 4 days ago [–]

Why is state management a problem? Could you give a sample scenario? Have all screens be tied to an application session instead of managing page per page. A given screen stays put the entire session (although may be hidden or removed as needed). Its state would be hierarchically addressable & examinable, such as requesting "scopeA:screenB.panelC.widgetD.value". (Scoping clause optional.) I have some further suggestions for state and scope management that would take up too much space here.

[1]

note: i should ask tabtab for GUI library ideas sometime when i am making a GUI library. Should ask Lion too (he was working on a GUI library, i believe).

---

gjvnq 4 days ago [–]

Business automation.

There seems to be so much that can be easily automated by simple scripts. We just need a better UI and a better way to teach people how to use it.

reply

texasbigdata 4 days ago [–]

Isn’t that Microsoft’s entire “hey use active directory, and write this no code flow app” premise?

reply

tabtab 3 days ago [–]

There's been a lot of products that try, including MS's current "Power Apps" and "Power Automate" utilities. But the problem is that lots of intricate business rules need to be understood and maintained longer term. RAD has had a problem with long-term maintainability of business rules. Instead, I'd like to see a focus on a stateful GUI markup standard so that it's easier to do regular code-based CRUD apps without dealing with screwy web (un) standards, such as bloated JavaScript? libraries and CSS wankiness. The UI is a bottleneck to CRUD dev productivity.

reply

---

layer8 4 days ago [–]

WIMP is fine. The problem at present is that “modern” UIs don’t adhere to WIMP conventions (tooltips, context menus, regular menus, keyboard accelerators/shortcuts and navigation, using native look & feel and controls including windows chrome, unambiguous visual distinction between actionable controls and mere labels/text/images, power-user features like configurable toolbars that were a common feature 20 years ago, ...).

---

tabtab 24 days ago

Re: "too bad there are no good alternatives to this"

What about the Tk/Gtk family of products?

tabtab 24 days ago

What does the Tk family lack to make "thrivable"? It doesn't have built-in resizable editable data grids, but that gap alone is not a show-stopper.

arp242 24 days ago [–]

Qt is an application framework – it's much more than just a "GUI toolkit".

Tk is nice, but also small and very limited in scope, which is great for some use cases, but less so for others. It's like the difference between a desktop environment like GNOME or KDE, which do much more than just "manage windows", and a more basic window manager like i3 or the countless others that are out there.

spacechild1 24 days ago [–]

Tk is a nice little GUI toolkit, but feature-wise it isn't even comparable to Qt in any way. Personally I started with Tk but it turned out to be too limited, so I switched to Qt.

---

tabtab 45 days ago

RE: "The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology taught to people in school."

It's worked fairly well for "isolated" groups of services, such as API's to file systems, network services, etc. Where it fails is domain modelling and any system or sub-system having more than a few entities. OOP doesn't scale when there is a large number of domain nouns and/or attributes involved.

For example, OOP worked quite well for early and fairly simple GUI's. But when GUI systems and applications grew larger and more complicated, OOP GUI's turned into spaghetti. I believe something more like an RDBMS is necessary to manage large quantities of nouns and attributes so that one can slice and dice their particular view and grouping as needed for different tasks: query the parts instead of navigate a parts graph. You can navigate graphs like a cave explorer, but you can't easily say "show me all nodes (caves) with such and such...". Perhaps this is the "data orientation" you speak of.

(I'm puzzled why in Java Swing the event handling code for a button click has to be fed into a "listener" instead of attached to the button object itself. The second is more logical in terms of thinking in the domain of UI's. Listener is an implementation detail that should be hidden away most of the time.)

On a really small scale, trees and nesting work fine. On a medium scale graphs work fine. But on the larger scale, relational or something similar is a better tool. The hard part has been getting RDBMS to manage "blocks of behavior" well (events, snippets, functions, etc.).

---

"Some reference the X-Window system, but it's pixel-based, not vector, and has no input buffering feature, meaning every key-stroke has to make a round trip from client to server before it shows up on the screen. This was okay on LAN's, but questionable over HTTP. " [2]

---

" As far as font consistency, PDF's seem to mostly get it right such that text is in the same position and wrap in the same spot regardless of the viewing platform. We can swipe some ideas from them. A bounding box is one approach: you fully fit the given text into the box on both sides no matter what by adjusting the aspect ratio. Adjustments of a few percent are not going to stand out as odd.

The GUI browser would probably have to be vector coordinate-based, at least as an option. The "layout engine" could be on the server, which gives you more choices of layout engines, including the choice of "none". This would also simplify the GUI browser by pushing the layout to the server.

I'm not against the idea of including at least one layout engine on the client, but it opens a Pandora's box of complexity. Complexity is why web-based UI's suck rotting eggs to manage on multiple devices. It's easier to test when the server computes layout because it's then the same on a billion difference devices, unlike @&#% web browsers. " [3]

---

maxharris 11 months ago [–]

I'm working on a project to provide exactly this! It's a layout engine that takes a tree of components, emits boxes. Currently it's written in JavaScript? and renders to canvas, but it also runs on node + node canvas, so you can do things like generating PDFs and other images server-side.

https://github.com/maxharris9/layout/tree/master/test/compon... https://github.com/maxharris9/jsx-layout https://github.com/maxharris9/layout/tree/master/test/components https://github.com/maxharris9/jsx-layout

My friend is working on a native client that will run programs written for layout without a browser.

If you're interested in this, I'm open to DMs on twitter (@maxharris9)

---

Re: Hopefully, they (MS) will manage to keep their WinUI? promise, and make it quite easy to develop (Windows) desktop apps.

Even if they did, one is pretty much stuck using MS's languages. Rather than write language-specific adopters, create a state-friendly GUI markup standard so any language that can read and write text and talk to the Internet can serve up GUI's.

Re: it's hard to tackle such an insanely complicated issue.

Base it off the Tk or QT kits rather than reinvent the GUI wheel.

photawe 11 months ago [–]

I'm not familiar with Tk, and how well that works, but there are a lot of things a good GUI should do -- just think of databinding and such - it's very far from trivial to develop something that looks really good on all platforms, is easy to use, uses modern concepts (MVVM), and has decent language bindings (c#, c++, java)

tabtab 10 months ago [–]

A lot of those issues would be "back end framework" issues if we had a decent GUI markup standard. Tk would just be a kit to build a GUI browser with, not the domain application itself. It would be roughly analogous to "WebKit?" in HTML-land. When building a domain application, you don't normally set out to build a domain application "in" WebKit?, you use HTML/HTTP/CSS/JS, which are then rendered via WebKit? (at least partially). A web browser doesn't have to use WebKit?.

unlinked_dll 11 months ago [–]

I just think markup is a bad way to write UIs, or anything but documents imo/e. For anything above a toy you'll need to generate markup programatically, and congrats, you've invented the web browser.

tabtab 11 months ago [–]

I'm not suggesting that one always write the UI in direct markup alone. Program-generated markup and/or an IDE (drag and drop) is perfectly possible. It's just the standard interface to a GUI browser. Once the standard catches on, "helper" tools will appear.

Re: congrats, you've invented the web browser.

Web browsers suck for GUI's. Positioning is a royal inconsistent pain (especially fonts); and they lack native widgets such as editable data grids, drop-down menus, tabs, combo-boxes, menu bars, dialog boxes, MDI, and more.

-- [4]

---

	Hierarchies are Limiting Development
	1 point by tabtab on Jan 6, 2018 | hide | past | favorite
	Programming code is repeating a lesson from history. Early databases such as IBM's IMS were hierarchical. But hierarchies proved to not be flexible, and "network" and "navigational" databases supplemented them. But they proved too unwieldy ("pointer-happy") and the relational model eventually superseded them. Our code models are having similar growing pains.

I was in a debate about whether a Java "on-click" GUI button method belonged with a "button" object or a "listener" object. Being with the listener object made implementation easier, but is less "natural" than being associated with a button itself. Why can't it be easily associated with BOTH? Similarly in an MVC application sometimes you want to group or search code by entity and sometimes by the MVC parts, such as the "model" folder. Why can't that also be both?

In relational you have many-to-many tables for such and adjust your query to dynamically associate, filter, and sort how you want. Object (type) hierarchies and folder hierarchies are stifling us. Ditch the trees: R&D time.

---

	GUI's still the pinnacle of productivity, let's help them out
	5 points by tabtab 4 months ago | hide | past | favorite | 4 comments
	Ignore specific technologies, standards, and programming languages for a thought experiment. What's the most productive UI design for regular office productivity? The answer is still GUI's, a technique that's several decades old. All the focus on finger-based mobile and social networks hasn't changed this fact.

While it may be possible to build a highly-productive mobile-style UI, it's difficult to get right and/or requires more user training. The mobile UI world is a sub-set of GUI idioms, for the most part. This means you are more constrained; working with a smaller pallet.

Desktop-style GUI's can fit more on a given screen because the pointer is smaller compared to finger aiming, can have roll-over text for cryptic icons, right-click options, nested pop-ups for drilling down into progressively further detail, and others.

Emulating full GUI's in web browsers has proven tricky. The emulation libraries are huge and often break when new browser versions or brands come along.

If the industry faced the fact GUI's are not going away any time soon, perhaps it would form a good GUI-over-HTTP standard. It could roughly resemble Microsoft's GUI XAML, but be cross-platform, "stateful", and interactive. The Tk or Qt engines maybe can serve as the base for a "GUI browser" or browser plug-in.

ktpsns 4 months ago [–]

XUL (Mozillas XML-based widgets) or JWS (Java WebStart?) seem dead, but I don't know why. They could provide exactly what you ask for -- zero install rich interfaces with better performance then HTML-based ones.

---

	Desktop-flavored GUI's still king of the office, let's standardize it
	4 points by tabtab 18 days ago | hide | past | favorite | 3 comments
	The prediction that mobile would kill off the office desktop was pretty much wrong. Sure, there are ancillary mobile services, but the brunt of office work is done on desktops.

Desktop-like GUI's are still the pinnacle of productivity for typical office use. They also created an established standard that mobile-influenced UI's kicked in the gonads with screwy deviations.

Mice are simply superior to the average finger: right-clicking, roll-over pop-up text, precision, less need for borders around widgets, etc. And GUI's take better advantage of medium and large screens.

What's needed is a state-ful GUI markup standard so that Microsoft has real GUI competition. It would be kind of like dynamic XAML. JavaScript? emulation of GUI's has proven problematic such that the standard should encourage directly supported GUI idioms.

desktopninja 18 days ago [–]

I'd welcome back that windows 2000 GUI any day. clear, concise and consistent

tabtab 17 days ago [–]

Do you mean the operating system's tools, or application design style? I'm mostly focusing on CRUD application development, and perhaps design tools (graphics, CAD, documents, image processing, etc.). Web "standards" (cough) stymied CRUD and design tools.

desktopninja 16 days ago [–]

Many of the programs at that time used the OS's default window styling and controls. So this made the desktop experience feel uniform throughout.

---

	Past GUI/CRUD Productivity Lessons Lost?
	2 points by tabtab on July 10, 2017 | hide | past | favorite
	Back in the 1990's we had GUI CRUD-building tools like PowerBuilder, Paradox, Clarion, Delphi, etc. that made building in-house and biz-to-biz applications easy to learn, use, and intuitive. They had glitches, but got better over time. The "web stacks" ruined all that, and now we have Dagwood sandwiches with lots of components and layers. I felt more productive focusing on business logic (customer needs) than dealing with dodgy scroll-bars, ORM's that produce bad SQL, or JS libraries that don't work with the latest browser version, etc. It seems we de-evolved. I miss being productive.

The new stacks often come with code generators, sometimes called "scaffolding", which can take care of a lot of the grunt-work for you; BUT if something goes wrong, you have meandering dark-grey boxes to debug. As time goes on, each part starts to rot (become obsolete) and the people who built these layers move on, leaving somebody with a mess.

Is there no way to get back to the simplicity of the 90's? What Laws of Nature/Math/Physics exist that force it to be overly complicated? I'd like to see logical proof we are stuck with the current mess; don't just claim I'm a geezer who won't move on.

Do we need more state-full network-GUI standards that sideline JS/DOM? I realize we have mobile devices, but I'm not sure if that's the bottleneck. If we sacrifice chasing the latest aesthetic fad and focus on utility, maybe we can simplify the CRUD/GUI stack. The X Window System with more network latency support, such as client-side input boxes, is an idea. If we move most of the rendering complexity to the server, we don't have to worry as much about myriads of client (browser) versions and brands. Yes, it's the Thin Client dream again. Don't kill it just because it's not sexy. Think of it like an accountant: not attractive, but you need one.

---

" Front end

Our product provides a UI to let users see what they have running on a cluster, the current status of operations like scaling, and telemetry showing what’s going on in their applications.

The front end is a web-based single page app coded in ClojureScript?. The ClojureScript? ecosystem has many mature, well-designed libraries that make development efficient and fun.

Reviewing the libraries and their advantages could be a blog post in itself, but briefly: we use re-frame because its data-oriented state management and event handling models are easy to reason about and inspect. We use reitit for frontend routing; we like how its data-oriented design allows us to associate arbitrary data with each route, which in turn lets us do neat things like dispatch re-frame events on route changes. We use shadow-cljs to compile the project, in part because it dramatically simplifies the process of using JavaScript? libraries and dealing with externs.

We use uPlot for displaying time-series data. Our API backend is served using a Jetty server, and we use Compojure to define backend routes.

Defining our front end in the same language as the rest of our codebase is a huge win, especially the ease of shuttling data back and forth between Clojure and ClojureScript?. The immutable style emphasized by Clojure is just as beneficial in front-end code as back-end code, so being able to leverage that consistently benefits our productivity and the robustness of our product greatly. " [5] (the orig has some hyperlinks)

---

i don't agree with this guy about Labview but:

"Have a look at Labview, Delphi or Palantir’s offerings for examples of highly productive user interfaces." -- [6]

---

delphi is loved

https://insights.stackoverflow.com/survey/2018 (see 'wanted' technologies page)

eg https://news.ycombinator.com/item?id=22573598 ---

some ppl also say VB6 was good at this: https://news.ycombinator.com/item?id=22572156

---

marcus_holmes on March 13, 2020 [–]

I loved VB. I don't think I've ever been as productive as I was in VB - I could literally knock together a complete desktop application in an afternoon.

It wasn't perfect. There were lots of problems with it. It would never win prizes in CS competitions. But man you could build shit with it fast.

docandrew on March 14, 2020 [–]

VB the _language_ obviously has its limitations and frustrations, but VB the _tool_ will be missed. It seems like every alternative mentioned here adds a lot of additional friction for writing simple, one-off utilities.

I don't always want to dink around with the Visual Studio installer to make sure the right version of the MSVC or .NET libraries are installed, or fiddle with code to get a GUI layout to look nice, etc.

Having the IDE, compiler and GUI designer in one big coherent monolith had its advantages.

wazanator on March 14, 2020 [–]

That's kinda what a C# .NET winforms project is. The WYSIWYG editor is pretty easy and the basics are pretty well documented for all the premade widgets that I feel like anyone who just needs to make a one off util program won't have much trouble.

Joeri on March 14, 2020 [–]

Delphi is still around and just as fast to knock something together in. I switched from VB4 to delphi when that was released and never used VB again.

mikewarot on March 14, 2020 [–]

And if you can't afford Delphi, Lazarus is okay, not as well documented, but works well, and the price is right. ($0.00)

---

signaru on March 14, 2020 [–]

VB classic was my first programming language since it was so easy to spit out GUI programs that looked like any other program you use.

I'm afraid current popular languages like python and javascript do not offer that "instant gratification" and is scaring beginners. With only terminal or webpage output, they might get the feeling that what they're coding is far from what "pros" use to write desktop software that is all around them.

Csharp is great, I use it everyday, but is not a real successor. First, it is a massive install which can be an issue with others just starting out. The few things I dislike with Csharp are that executables are dependent on the dot net (or mono) framework and are not native, i.e. far easier to reverse engineer.

Lazarus/Delphi might be the next best things to a classic VB experience. There are efforts to make something similar for Freebasic what Lazarus is for Free Pascal. But they are nowhere close, and the next best alternatives are not free.

I have no right to complain, and I fully understand, but I could be happier if Gambas had native Windows support.

--- benchmark well-rounded gui lib

https://eugenkiss.github.io/7guis/tasks https://hackernoon.com/towards-a-better-gui-programming-benchmark-397aca3542b8

---

https://github.com/v1cont/yad https://lobste.rs/s/xcnisi/yad_create_ad_hoc_gtk_guis_from_shell