.Net Like Gui Builder for Python?

[Chris Angelico]

On Sat, Jul 26, 2014 at 2:13 PM, TP <wingusr at gmail.com> wrote:
> Not that I disagree with the overall point of just using a text editor
> (especially for Python GUIs) but apparently you've never created a C# WPF
> app using Visual Studio? WPF fully supports layout controls, is *not*
> generally pixel based it's more similar to HTML + CSS (although you do pixel
> perfect layout if you try), and still easily does (2). And while I almost
> exclusively use the Visual Studio XAML tab view rather than bothering with
> the Designer view you can drag & drop if you really want to. And Microsoft's
> Expression Blend takes that to a whole 'nother level supposedly making it
> easy for "even" graphic designers to create GUIs without delving too much
> into raw code wrangling.

No, I haven't. (I haven't done anything with C#. There's a limit to
how much I have time to learn, and I'd much rather work with something
like Pike than C#.) In the light of this, I'd best separate out my
concerns a little further:

1) GUI layouts that use pixel positioning
2) Drag and drop GUI layout interfaces

The first has all the problems I mentioned, of being tightly bound to
so many things. A twip-based layout solves one of them (font size),
and it's possible to get simple features like "match sizes on all
these widgets" and "align these widgets' left margins" (both of which
I had in VX-REXX) to help; but none of that deals with run-time layout
requirements, which are much MUCH better served by a rule-based
layout.

The second, though, still does have issues. While it'll give you a
good result at the end, it's not nearly as advantageous as the d'n'd
interface for laying out pixel-precise positions. WYSIWYG HTML editors
aren't exactly sweeping the board (in fact, every serious web
developer I know prefers to work with the markup itself), and even
then, they're not so much "drag and drop positioning of stuff" as they
are "word processor that saves as HTML". You may as well skip the
WYSIWYG editor and just work directly with code; the benefit isn't
enough to justify the risks, the biggest of which is that your lovely
layout will look completely ugly on a different platform, theme, font
size, etc.

There is one special case, though. When it comes to *mocking up* an
interface, it is sometimes helpful to have a drag-and-drop system that
allows a non-programmer to put something together - a sketch, if you
like. Imagine taking a sheet of physical paper and an actual physical
pencil, and drawing out a layout; now imagine making that both easier
and clearer by dragging widgets around. At no point do you ever expect
the paper sketch to be perfect, and certainly you don't expect it to
work on all platforms, font sizes, etc; but it's a lot easier than
manually crafting ASCII art, and it's something that a programmer can
look at to decide how to lay things out. It's far from perfect,
though, as it assumes a fundamentally 2D layout; GUI design, even back
in the 90s when I first started, was always a tree of parent-child
relationships. But if you want that sort of thing for your mock-up,
I'm sure it'd be possible to abuse something to do it; I used the Open
Watcom C++ Dialog Editor for the job, a few times. It doesn't even
have to be backed by the same language or toolkit.

We're broadly in agreement, though. Instead of searching for the ideal
GUI window builder (and, by the way, one person's ideal will differ
hugely from another's), just write the code directly. Life's better.

Plus, it plays more nicely with source control. Ever tried to dig
through a git repo to figure out when a change happened to an Open
Office document? Not so useful. But I can 'git blame' a source file
and know for sure that I'm getting meaningful results. LilyPond files
are source code; NoteWorthy Composer files are binary blobs. (I'm not
sure about other music formats, like Sibelius's save file, as I
haven't used them.) I'd much rather work with a format where the disk
changes mirror the conceptual changes. Readable diffs FTW.

ChrisA