In practice, this is when it's most useful though. Mathematica will already tell you the file has been changed in memory, so you just want to know which tabs only live in the cache at that moment.
But since it appears to work, I don't question this transformation. However, I remembered that I wrote a prefix-tree (Trie) transformation recently for the IntelliJ Plugin lexer. There, the pure check of all possibilities is turned into a more clever regex of the form:
@b3m2a1 If I had to write few rules of thumb for gui programming in mma then somewhere on top there would be 'forget about that pixel (row/column/misalignment/flickering) - you won't fix it or it will take you two days and won't work on another OS anyway'
@b3m2a1 maybe you could add * like in edited notebooks
@b3m2a1 probably lots of scope for adding GUI support to an IDE (profiling, unit tests, design patterns etc ...) One rule of thumb I'd add is that (as unsatisfactory as this currently is) beyond a certain level of complexity in dynamic interfaces just be resigned to having to perform trial and error in designing layouts but aim to streamline the process (e.g. by using dynamic vars for layout parameters etc)
@RonaldMonson IMO, anyone who already worked with e.g. the scene builder in JavaFX, or the UI Designer in IDEA or Android studio, will instantly see that Mathematica is not made for UIs beyond a certain level of complexity.
It's not that this is not possible, but it is just not the right tool for it.
I have thought for a long time to use something like the Scene Builder to create the XML layouts and convert them to Mathematica, but there are too many holes in the implementation of Mathematica.
@RonaldMonson If you are not picky about details like exact aligning or spacing and you follow a careful design-pattern with your dynamic stuff, you can get pretty far. But it is not really fun anymore then.
@RonaldMonson Especially with JavaFX and Android (for me at least) it become obvious that a clear separation of UI and functionality is so much more fun. This is hard in Mathematica and cannot be done entirely. However, the other thing is that any other person will look at your code and ask what the heck you did there.
Agreed, exactly my experience (although I haven't ventured beyond with other tools). For me it is still fun with all dynamic updating seeming to scale by having a single association carrying the interface's data structure and tightly controlling any dynamic updating - but managing the layout becomes painful fairly quickly (with one reduced to trial and error only marginally ameliorated by setting layout variables in a separate dynamic interface.)
It seems to me though, that putting everything into a single "interface association" (with suitable organization internally) and then dynamically updating this by passing to Mma's various controls essentially separates the UI from functionality ... ?
I have a function that specifies the function of the button. I send the interface association (IA) to this function and this then gets implemented as a button if that control is deemed fit for purpose.
This of course means the the function must have HoldAll attribute and one has to pervasively use With injections but it seems to scale
@RonaldMonson Right, I have something similar that follows a model-view-controller pattern. I pass the controller to the UI and e.g. buttons can call controller["ButtonXPressed"].
This is similar to specifying a handler for an action in other frameworks.
However, sometimes you need to do other stuff like telling a dynamic element to update only under certain situations. This is harder to do and your code looks then very unusual to the untrained eye.
@halirutan @RonaldMonson I do this: mathematica.stackexchange.com/a/197559/5478, view* elements won't update unless they are told to && if they really changed. At the end there aren't very many Dynamic[view*] parts of the layout.
Many can be solved with PaneSelector etc.
There are rules to follow yes but at the end it does not feel foreign to mma style.
Most of my updating is done explicitly but sometimes I end up doing odd things like creating dummy updating variables (but I get the sense that this could be avoided with better design). Still for me and at least the dynamic updating seems less of an issue that the laying out which makes me wonder that if, as you suggest, the layout problem has been "solved" then maybe its framework can be added to WL to produce scalable dynamic interfaces?
@Kuba Yes that is what I essentially do as well except a single dynamic variable appears as the loca l dynamic module variable and this is passed through and placed in the interface as IA[["part-of-datastructure","meaningful description"]] for dynamic updating. This seems to allow clean and scalable modularization.
Looks like a simple question, but I stuck for some reason. I have a positive rational interval and I need to find in that interval a rational number with smallest denominator that is a power of 2. How do I do that?
@halirutan I'd agree with this, but I still like to design stuff for Mathematica because it's what I (and the people here) actually use. I'd never try to use Mathematica for designing an actual distributable application, but for giving people stuff to work with here I think it's worth it.
I think it'd also be possible to write a package to handle some GUI an app layout stuff.
@Feeds @halirutan Of course WRI should do this. But I doubt they will. I argued with SW more than 25 years ago that a public bug tracker would be beneficial and he said it would cost money and software companies don't do that (contrary to hardware companies). If you want to convince him, you might also mention Mathworks (de.mathworks.com/support/bug_reports/faq.html#Q01).
