Co-ordinate-free dialog layout

[Daniel Beardsmore]

I decided against necroposting in the v2 GUI thread, and decided to post here instead.

Judging by what's been said so far, it appears that the new API will still involve physical control positioning.

Does anyone besides me see any value in having some sort of more intelligent layout? For example, if you want a dialog box with control captions on the left, and controls on the right, aligned by their text baselines, assembled dynamically according to font, size/DPI and language, the v1 API makes this impossible. The most you seem to able to do is fudge around a lot.

The API I always have in mind here is Psion OPL32. Psion EPOC32 (EIKON) dialog boxes have all the controls stacked vertically, and each one is defined in a single step that covers the control type, its caption, parameters, and associated variable. When the dialog is shown, all the co-ordinates are determined automatically. (Programs written in C++ can use tabs to fit more controls in, while OPL32 programs inexplicably cannot.)

I think this is a matter for considerable compromise: a way to achieve a lot of basic dialog box and even window layouts, without trying to be all things to all people, since more advanced projects will make demands that would overcomplicate what should be a simple way to get a simple window without fuss, one that means that someone can pick up AutoHotkey and knock up some dialog boxes without a lot of hassle.

As such, I'm thinking, at the most basic level, a window might involve (in a manner very similar to per OPL32):

Initialise dialog, title = "Log in"
Add text box, "&Username", width 30
Add text box, "&Password", width 30, password
Add dropdown, "&Server", items *serverList
Add buttons { "Log in", "Cancel" }, bottom, centre, order { default, cancel }
Show dialog

Something more involved might involve lines thus:

Start tab, "User details"
(controls here)
Start tab, "Server details"
(controls here)

Add buttons would apply to the dialog as a whole, not to tabs.

As you can see, nowhere is the size of anything written, except where absolutely necessary (since the computer can't guess how large your text fields should be).

For cases where columns are actually needed (e.g. to get an image on the left), just write:

Start column

This new column would group controls and captions together just as before. Other possible options include: separator, separator with caption, begin/end control group, and other control types. You could also sub-finalise the layout by writing:

Break

This signs off on all the columns and starts off afresh on a new line.

I was quite shocked to find how awkward it is to just create such a dialog box. From my perspective, AHK as a hotkey/macro/scripting type system should focus foremost on building the sort of basic UI that you'd use such a program for. Something where you might want to prompt the user for some details.

I'm very wary that localisation, wording/spelling changes, system font, DPI etc have substantial repercussions for layout, and it seems strange that AHK's GUI approach expects you to mess around trying to pair up distant controls (if you want auto-layout, you can't put a caption and control together in the code), or hard-code co-ordinates, just to get even the simplest UI. The result of all the wp and XM and lots of random numbers in the code makes it unreadable, confusing, and hard to maintain. None of that should be necessary or exist for basic window layouts.

I don't have a Psion to hand to run through examples with. There are some example screenshots here, taken from my Revo way back when: http://www.guidebookgallery.org/screenshots/epocr5

[lexikos]

Sounds good, but who's going to develop it? v2 has already been in progress for several years more than I imagined at the beginning. The longer it stretches out, the less likely it will ever reach a stable release (with only me driving it).

fincs' API "tries to emulate as closely as possible the simplicity of the old v1.x Gui commands". I don't know about his reasoning, but a side-effect of that is it's not so much work to implement. Even so, my initial plan (years ago) was to barely touch the GUI commands because of the amount of work involved. From my perspective, the fact that fincs has already developed it gives it a major advantage.

[Daniel Beardsmore]

Emulating the v1 GUI was, IMO, a huge mistake. My Windows software is all developed on an antique copy of REALbasic on a PPC Mac. REALbasic was advertised as "cross-platform that really works". While the interface builder does have fairly useful snapping (including text baseline, spacing etc), Mac OS X (as it was then) and Windows have dramatically different typography and widget sets, and since I lay out windows to suit Windows, I end up with lots of truncated captions in Mac OS X (which isn't relevant any more as I can't build OS X Intel binaries). There's nothing in REALbasic (even to this day, under its new Xojo moniker) to account for differences between systems, which completely defeats the cross-platform concept.

The simple dialog building in Psion's OPL32 was amazingly simple and effective — and something I've not yet seen replicated.

I've never been able to place AutoHotkey in terms of where I see it going. As a keyboard remap/macro implementation, it's very good — I use it for macro bindings (e.g. paste as plain text with Win+V), Windows UI control (F10 minimise, F8 always-on-top etc), per-program shortcut management (e.g. adding Ctrl+W to JujuEdit, while blocking Ctrl+Q in Thunderbird, as unlike in Outlook it does not mean "mark as read"), Unicode text entry (I can type "→" straight from my little 60% keyboard), and I've started to migrate in dead key composition to free myself from an ageing and unsupported United Kingdom International layout from some annoying bloke who has never responded to a single e-mail ever.

So at that level, I don't have to worry about things like = vs := and the hours of near-suicide I've reached from completely insane bugs arising from it. Since I run a text editor whose syntax highlighting is controlled by a regular expression based state machine (seriously) I've now instructed it to flag "=" visually to stop me using it, as I carry across that usage from PHP/Perl/JavaScript/BASIC. (Seriously, every time I check out some new text editor, it has the same tired, feeble highlighting as every other one where you just set some colours. Mark Pursey's state machine idea in JujuEdit even lets me nest whole languages by using trigger terms to switch between sets of machine states, each with wholly separate regular expression sets and colour sets, albeit with limited effect as there are only ten states. The program died in 2006 though, but I've kept it alive with a new Windows 10-era toolbar icon set :-)

The irony is that, while AutoHotkey is so awkward, clumsy and painful at writing anything beyond some macros, people strive to use it for things that belong in the realms of Xojo, .NET (in Microsoft's GUI approach of the day), Delphi and the like. This devoted userbase means that plenty of people are likely to want, expect or need as much as possible to remain as-is, especially if they've devoted time to figuring it all out.

From this, it becomes really hard for me to visualise what I think AutoHotkey should actually be, but mentally I place it at the ultra-RAD level. The problem with the v1 GUI is that it makes the sort of GUI building I'd see AutoHotkey as being ideal for—the sort of visual system scripting that was never achievable in WSH—really cumbersome.

At this point, AutoHotkey's userbase seems to be so huge, that I have no idea how any AHK developer could back out of where AHK has gone, and try to refocus on the ultra-RAD system scripting/control/hotkey aspect.

I'm afraid that I have no answers, only my typical unpopular and nonconformist viewpoint :-)