Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

121–130 of 148 posts

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

#121

Post by pjmlp »

qwerty456127 wrote: post #94
AnaniasAnanas wrote: post #70

Earlier quoted context omitted.

If you are a C++ user you might want to check out QtCreator. It makes it as easy to create GUIs as Visual Basic did back in the day, and it's free (both as in price and freedom).

Thanks. I used to be a C++ user when there were no better languages for rapid GUI application development around (C++Builder/Delphi were the best). I've switched to C# with WinForms many years ago. Now I'm going to try Qt5 with Python (just because there is no WinForms designer for Linux, nevertheless Qt Creator doesn't feel as intuitive as C++Builder, VisualBasic and WinForms designer did though I believe it can do…

Yeah, sadly Kylix never worked out.

Borland really screwed up that attempt, it was anyway shortly before that whole Inprise stuff. :\

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

#122

Post by pjmlp »

int_19h wrote: post #118
blattimwind wrote: post #46

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…

Motif might be a pain to use versus Win32, from my point of view, but layout managers were a central piece to it.

Likewise, Windows Forms table layout managers and Swing layouts, while not as powerful, did the job.

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

#123

Post by Mikhail_Edoshin »

madeofpalk wrote: post #83
Animats wrote: post #65

Earlier quoted context omitted.

It really is disappointing how modern web GUI environments are harder to use than what was around 20+ years ago. Yes. We had drag and drop UIs decades ago. Now you can't even get a decent GUI program for laying out a web page. CSS/Javascript got so messy that even Dreamweaver became useless. Part of the problem is that ad code requires a messy environment, so that ad blockers and click generators have a hard time. Go…

> Yes. We had drag and drop UIs decades ago. We had _simple_ drag and drop UIs decades ago. Computers operated within a lot more limited constructs back then. UI windows didn't resize, or it was reasonable to expect that they're fixed. How did those drag and drop tools back then handle creating a UI for screens ranging from 400pt wide to 2560pt wide?

An early desktop publishing program, Ventura Publisher (v3 of 1990) could easily reflow complex document layouts and allowed alternate stylesheets to be applied to the same text. This is not exactly UI, but the layout was more sophisticated than what HTML can do. The idea of same content and different rendering is certainly not new.

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

#124

Post by madeofpalk »

qwerty456127 wrote: post #111
vthriller wrote: post #99

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…

> 400pt wide to 2560pt wide There are 2 major strategies for responding to such a difference: 1. Vector scaling. It will make the difference irrelevant and the resulting UI will look approximately the same on whatever a resolution. 2. Capacity scaling. I.e. keep the same font letting more information to fit in the control without scrolling. It may be a little bit hard to formalize but these two can be combined intell…

Note I mentioned display _points_ rather than display _pixels_ - how do you create a UI that scales from a phone to a 27" monitor. This is more than just scaling up assets and turning on word wrap.

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

#125

Post by steve1977 »

sien wrote: post #59
qwerty456127 wrote: post #58

For my whole life I've been "drawing" real GUIs and writing the logic code, not GUI code then. It started with VisualBasic 1.0 for DOS, then there were different versions of VisualBasic for Windows, then Borland C++ Builder and Delphi (I was using the former), then NetBeans Swing designer and WinForms designer in VisualStudio. And now building a GUI is such a problem that a huge number of almost-useless (I really pre…

It really is disappointing how modern web GUI environments are harder to use than what was around 20+ years ago. There are still Visual Basic Apps from the 1990s floating around in large corporations and in government. Users who were expert in the process but not expert developers could easily code up tools to their exact specifications. https://en.wikipedia.org/wiki/Visual_Basic#1990s Admittedly the deployment of we…

> Admittedly the deployment of web applications is much better and they can run on different devices.

But is it really, if you take into account all the incompatibilities between browsers and the different UX paradigms between classes of devices?

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

#126

Post by int_19h »

pjmlp wrote: post #122
int_19h wrote: post #118

Earlier quoted context omitted.

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…

Motif might be a pain to use versus Win32, from my point of view, but layout managers were a central piece to it. Likewise, Windows Forms table layout managers and Swing layouts, while not as powerful, did the job.

Yes, but those layout managers were also incompatible with UI designers, generally speaking.

(WinForms designer technically supports them. But it's less "drag and drop", and more like "drag and ... um, what the hell is this thing doing there now?").

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

#127

Post by int_19h »

pjmlp wrote: post #119
int_19h wrote: post #116

Earlier quoted context omitted.

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…

> Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc. WPF and UWP can deal with it perfectly fine.

Last time I checked the WPF designer, it used canvas by default - which allows you to put elements exactly where you want by simple drag and drop, like the old times in VB6 or Delphi; but then nothing actually reflows or resizes etc at runtime.

If you choose to use layouts, it can display them, but editing it with a mouse is no longer convenient. It's easier to just drop into XAML and hack on it there. On every project I worked on that used WPF (which is quite a few by now), nobody on the team actually used the UI designer, and everybody would switch the default mode for .xaml files in VS to open the markup directly, rather than the usual split view.

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

#128

Post by pjmlp »

int_19h wrote: post #126
pjmlp wrote: post #122

Earlier quoted context omitted.

Motif might be a pain to use versus Win32, from my point of view, but layout managers were a central piece to it. Likewise, Windows Forms table layout managers and Swing layouts, while not as powerful, did the job.

Yes, but those layout managers were also incompatible with UI designers, generally speaking. (WinForms designer technically supports them. But it's less "drag and drop", and more like "drag and ... um, what the hell is this thing doing there now?").

For me it was always "drag and drop" + setting the respective properties, not sure what the problem is, other than not bothering to learn how to use them.

The only problem is how buggy VS designer in some releases tends to be, forcing to restart VS from time to time.

But that affects all kind of stuff, including apps not using layout managers.

And regarding Motif, I surely recall the GUI designers being relatively good.

Likewise with Java Swing and designers like Netbeans Matisse.

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

#129

Post by pjmlp »

int_19h wrote: post #127
pjmlp wrote: post #119

Earlier quoted context omitted.

> Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc. WPF and UWP can deal with it perfectly fine.

Last time I checked the WPF designer, it used canvas by default - which allows you to put elements exactly where you want by simple drag and drop, like the old times in VB6 or Delphi; but then nothing actually reflows or resizes etc at runtime. If you choose to use layouts, it can display them, but editing it with a mouse is no longer convenient. It's easier to just drop into XAML and hack on it there. On every proje…

WPF designer default template is a Grid layout, so it must been a very long time ago.

As for devs preferring to type by hand, well their loss I guess.

Post reply on HN