On Sat, Jul 26, 2014 at 2:13 PM, TP <wing...@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 -- https://mail.python.org/mailman/listinfo/python-list
