Live data from Hacker News

Show HN: Don't code your UI, draw it

github.com

141–148 of 148 posts

Re: Show HN: Don't code your UI, draw it

#141

Earlier quoted context omitted.

> How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide? For simpler forms you'd just set anchoring properties of the widgets in question (akRight/akBottom in Borland's VCL or whatever its counterpart is called in WinForms or what was its predecessor). Nowadays it's even easier with things like, say, GTK's HBox/VBox. > Computers operated within a lot more…

In WinForms, it's still called Anchor (it really did take a lot from VCL), but since enums are scoped in .NET, you have Anchor.Left, Anchor.Top etc. WinForms also had Dock (Left, Right, Top, Bottom, or Fill) which basically forced the control against that edge of its parent, taking up full length and/or height accordingly in one dimension, and using the explicitly specified size in the other. With multiple controls w…

Using anchors and docking was extremely intuitive and easy in WinForms, I miss these heavily. I'm trying to build an UI with Qt Designer right now and using layouts instead is quite a pain when building something sophisticated. Perhaps everything can be done with them but becoming fluent in their behavior and tweaking is going to take time.

Re: Show HN: Don't code your UI, draw it

#142

Earlier quoted context omitted.

I agree with your main point about empower people. It seems that people are coming to you to help estimate how long an idea takes to implement. If that's the case, I agree with everything you've said. But if they're proposing an idea, say a new sign up form to increase conversions, phone number validation is an irrelevant detail to worry about at this point (unless that was a significant problem with the old sign up…

In your scenario, I agree, number validation is irrelevant. So I'd ask that you pick something that is relevant for your environment. Whatever it may be, would a tool that educates and puts some of the cost back on the "idea person" or stakeholder be a good thing? I think it would.

> would a tool that educates and puts some of the cost back on the "idea person" or stakeholder be a good thing? I think it would.

So would I, as I mentioned in my reply to you. It's easy to propose ideas without regard to cost like a "minor enhancement" that takes 6 person-months.

Re: Show HN: Don't code your UI, draw it

#143

Earlier quoted context omitted.

Just a note, C++ Builder, Delphi and it's open source counterpart - Lazarus (cross-platform) are still here and involving.

But they feel really obsolete. I don't feel like coding C++ or Pascal when there are modern languages like Python, Clojure, C#, Rust etc and intelligent code editors like Idea/PyCharm that are a lot less boring and more relevant. Sure, old-style visual RAD is still here but it has been forgotten behind as the programming languages progress skyrocketed.

Do you think they are exciting, and Pascal and C++ are not?

Python: slow, useless for threaded programming, full of obvious mistakes (anybody likes one-line lambdas?)

Clojure: a flaccid, viagra-less Lisp.

C#: basically same as Java, the yardstick on "boring" languages

How can they be exciting?!

However, I agree that Rust is exciting, very exciting, because it has fearless concurrency, zero-cost abstractions, move semantics, trait-based generics and efficient C bindings.

Re: Show HN: Don't code your UI, draw it

#145

Earlier quoted context omitted.

It's funny how web development still doesn't offer the ease and productivity of early 2000s RAD environments. Even this software is actually not simpler, on the contrary: It is far more complex, because you don't know how to create a given widget [assuming you already learned what widgets there are, because the software doesn't tell you]. You have to learn what the software recognizes and how you need to draw it in m…

Early 2000s RAD environments had a much simpler model to work with, that didn't accommodate things like changing the size of widget's contents well. If all you needed was a button of a fixed size, that would always stay in e.g. the bottom right corner of the window, they could do that. If you wanted a button that would automatically resize as its label grew longer, some of them could do that too (pretty much every fr…

None of the issues you're describing really still exist now in the majority of those kinds of tools, though.

Keep in mind it was usually always the case you could set widget sizes (or do anything else you wanted) "in code", also.

It's not as though you were ever forced to always use the visual designer for absolutely everything.

In general, there are no significant differences whatsoever between the way something like React actually works and the way something like WinForms works.

Re: Show HN: Don't code your UI, draw it

#146

Earlier quoted context omitted.

Just a note, C++ Builder, Delphi and it's open source counterpart - Lazarus (cross-platform) are still here and involving.

But they feel really obsolete. I don't feel like coding C++ or Pascal when there are modern languages like Python, Clojure, C#, Rust etc and intelligent code editors like Idea/PyCharm that are a lot less boring and more relevant. Sure, old-style visual RAD is still here but it has been forgotten behind as the programming languages progress skyrocketed.

C++ is the industry standard for the game industry. How is it obsolete?
Post reply on HN