70

This post is here to save your time during GUI development in Mathematica. And one way to do this is to know where limits are and to be aware of features that are awaiting.

Background

Usually I don't have to care (it hurts my brain though) about misaligned details, additional/missing pixels. But currently I'm participating in a project where the design matters and I have to follow examples made by a graphics designer. I have to workaround 10 "features" per hour, and I'm not talking about fancy stuff.

This is intended to be a cheat-sheet for GUI development, based on our experience.

What is on topic here

  • Links to guidelines making GUI creation process more stable, predictive.

  • Links to guidelines on how to achieve robust dynamic performance of GUI-s.

  • Links to known bugs and workarounds for GUI-related issues, preferably posted as separate Q&A threads.

  • Tips about communication with designer/manager about requirements.

    People are used to the fact that you can create very nice layout with css in no time. How to explain that it is impossible, or not worth the time spent, in Mathematica? How to explain why getting rid of "white line" in some secondary menu took me half a day, and I've failed?

Community
  • 1
Kuba
  • 136,707
  • 13
  • 279
  • 740
  • Feel free to include additional bullet points. The more "possible issues" are stated here, the more time one may save in future. – Kuba Mar 09 '16 at 12:11
  • 1
    Broad question. Unless you're expecting a "big-list" type of answer (e.g. "Common pitfalls", "good practices", etc), I'm not sure, where to begin. Doing stuff with graphics' primitives helps, instead of using functionality such as Framed, etc. I rolled my own GraphicsGrid precisely because of these "issues". Is doing everything in raster a must? I'd personally feel more confident working in vector. (removed silly question about Rasterize/Image. – LLlAMnYP Mar 09 '16 at 13:29
  • 4
    @LLlAMnYP One can do here as with other such questions with sub-topics: one answer per "feature". Since all these things are the aspects of one big problem, I think it makes total sense to ask this just as Kuba did, in one question. As the answers start to accumulate, it might become appropriate to split them into separate Q / As, and link those from here. – Leonid Shifrin Mar 09 '16 at 13:33
  • 1
    @LeonidShifrin Oh, I'm not opposed to that, I love those long threads. The hardest part is getting them started :-) – LLlAMnYP Mar 09 '16 at 13:38
  • 1
    I'm not seeing the problem with the background spilling out of the frame, as in the first attached image. When I select the output of the command with the cursor, I see 1px margins above and below the frame (which seem to be counted into the vertical image size) and a 1px margin to the right, which is not. – LLlAMnYP Mar 09 '16 at 13:40
  • It may not be easy to make MMA work as expected, but it is possible to understand, what's going on. Graphics[{Red, EdgeForm[Directive[Blue, AbsoluteThickness[1]]], Rectangle[{0, 1}, {99, 100}]}, ImageSize -> {100, 100}, PlotRange -> {{0, 100}, {0, 100}}, AspectRatio -> Full, PlotRangePadding -> 0, ImagePadding -> 0, Background -> Green] for example. Note the coordinates of the rectangle, that are needed to get its edge in the right place. – LLlAMnYP Mar 09 '16 at 13:49
  • 15
    For me the most disappointed thing is that most, if not all, of these problems have been documented for several years and several versions but WRI have made no attempt to fix them. Giving us feature bloat seems a higher priority than fixing bugs that could actually lead to useful uses of Mathematica. Speculating, I wonder if it doesn't get back to the WRI 100% focus on Manipulate and the demonstrations project and the "cool" stuff that can be done in the classroom at the expense of applications for commercial (internal) deployment – Mike Honeychurch Mar 09 '16 at 23:16
  • 13
    ...which in turn gets back to WRI having a negligible commercial footprint (lets face it SAS, R, SPSS, Python, Matlab, Tableau etc etc are kicking its ass in corporate environments) and sales % dominated by universities. – Mike Honeychurch Mar 09 '16 at 23:19
  • 4
    @MikeHoneychurch I agree with you that WRI seems to be focusing on quantity rather than quality. By the way, do you have a source/reference about WRI's negligible commercial footprint? – QuantumDot Mar 10 '16 at 12:19
  • 5
    @QuantumDot source: me. If you have the time it is reasonably easy to put this together in a semi-quantitative way. Public companies have public accounts so you can readily find how much business they are doing. Private companies are more difficult. You need to rely on whatever revenue information they release and accept it as real. Revenue information is important not the number of users they claim they have. Everyone plays games. If a university has a site license then all students will be deemed to be users etc. Additionally you can correlate that info with job adds ... – Mike Honeychurch Mar 12 '16 at 00:37
  • 7
    @QuantumDot over the years I have found reasonable correlation between revenues and proportion of job ads requiring a certain software as a skill. For example when I worked at WRI Mathworks from memory had about 15-18 times WRI revenue and Mathcad had twice WRI revenue. Job ads were in reasonable agreement with those ratios. Since then I am in Australia so this market is my only concern. A former reseller here also sold Mathcad so I know that Mathcad sales exceed Mathematica. Job ads here Mathematica is very rarely mentioned. SPSS, SAS, python (numpy, pandas), R etc are desired skills ... – Mike Honeychurch Mar 12 '16 at 00:42
  • 4
    @QuantumDot ...for tasks that Mathematica could very easily do and probably do better. To digress note how python is very Mathematica like nowadays with jupyter. Tableau and to a lessor extent Qlikviews seems to have the the visualisation market cornered ...although I'd be surprised if D3.js and similar based javascript frameworks don't take over eventually (the difference is that Tableau clearly has a very good sales force). I've also spoken to a number of recruiters about obtaining additional pipeline of contract work and they are blunt that Mathematica is a non-starter. And so on ... – Mike Honeychurch Mar 12 '16 at 00:47
  • 5
    @QuantumDot as a final observation I use MongoDB more and more these days and in an ideal world Mathematica seems like a perfect program to accompany it because associations can be very Mongo like but Mongo is currently mostly used in web development I think which excludes Mathematica. Also Tableau have already got in there and established a relationship with Mongo for their BI connector ... – Mike Honeychurch Mar 12 '16 at 00:52
  • @LeonidShifrin Maybe I should move all examples and links to the wiki answer below so it will look similar to pitfalls and other guidelines? – Kuba Mar 13 '16 at 10:31
  • @Kuba I would do that once there are actually answers to some of the questions asked. – Leonid Shifrin Mar 13 '16 at 11:07
  • 4
    I agree that there is much that needs to be done. Pessimistically (some optimism comes later), my sense is that this is not merely a case of fixing some bugs here and there - there is something about the whole process of interface building in Mathematica that IMO needs a re-think. The biggest challenge seems to be to achieve a certain"interface composability" while simultaneously communicating to the user an "internal programming model". What I've found frustrating (and perhaps this is alluded to in the first two points) is that it can be difficult to predict ... – Ronald Monson Mar 17 '16 at 22:48
  • ... how settings for ItemSize, ImageSize etc (Full, All, Automatic etc) change a layout especially for composed interfaces. Also CSS has been designed for managing resized interfaces but IME this is a lost cause for sufficiently complex interfaces in Mathematica (fixed pixels only used now). It reminds me of a post on managing the complexity of big code except here it is for "big interfaces"; while I think the strategies presented there offer hope for taming the ... – Ronald Monson Mar 17 '16 at 22:48
  • 1
    .. resulting complexity, I'm not sure the same can be said for dynamic interfaces using the current layout protocols (the kernal evaluation issues seem much more resolvable). My kind-of-defeated workaround is a bit hit and miss but it has had an interesting side-affect: I've long given up trying to cajole elements into place or force designs - instead everything is parameterized with external/internal dynamic sliders. This seems kind of ridiculous - being reduced to stochastically trying designs out until you hit a non-buggy one - and maybe it is, but it has meant sampling ... – Ronald Monson Mar 17 '16 at 22:53
  • ... a much wider space of possible designs that my own limited imagination could have ever conceived ( perhaps then I'm overrating an internal programming model (?) while still arguing the case for options that generating "continuous visual refinements" while also allowing an interface composability). Obviously subject to actual contractual/technical/personel constraints, one possibility might therefore be to instead of taking the plans of a designer/manager and implementing them while fighting Mathematica's contraints; from a much rougher initial design, start with mma constraints before ... – Ronald Monson Mar 17 '16 at 22:54
  • 2
    .. allowing the designer/manager to explore a space of allowable, non-buggy interfaces? Dynamic Interfaces started with a bang through Manipulate and Dynamic but development seems to have tailed off in recent years as focus has shifted towards Data Science and Cloud offerings. There is however a natural synergy between all three so perhaps a couple of hard-won successful examples might start to indicate this potential (how such interfaces are distributed/monetized to provide resources for such development - well that is another story altogether ...) – Ronald Monson Mar 17 '16 at 22:55
  • 3
    Certainly WRI will fix all of those problems very very soon. Otherwise even the last few professionals actually using Mathematica for GUI development will have to move to JavaScript, Python and so on for GUI's to be used by actual customers. Maybe the Mathematica kernel will still be useful, by virtue of APIFunction and EmbedCode. – Rolf Mertig Jul 13 '16 at 20:00
  • @RonaldMonson I only partially agree with you. Mathematica is primarily a computer algebra system, and anything else it is capable of is "extra". On the other hand, remember that before v6, no one knew or expected that any dynamic functionality can be integrated so nicely with Mathematica. They did it, and I was very pleased with the intuitive extension of the "everything is symbolic" paradigm. Mathematica, by default, was not meant either for GUI-development, interface programming or standalone code to be distributed, nevertheless, they have improved these features considerably. – István Zachar Jul 14 '16 at 08:11
  • @IstvánZachar Perhaps you are right in that original design choices for one purpose forever preclude optimal implementations for others. The unity of the WL was deliberate though and I would have thought designed to enable exactly this sort of "extra" (i.e. not primarily be a computer-algebra system). It's not immediately obvious to me that fully-fledged GUI-development is impossible - it seems that what is needed is to directly address certain composability issues that arise once a certain complexity threshold is surpassed. – Ronald Monson Oct 18 '16 at 18:45

2 Answers2

12

Things to keep in mind when developing complex GUI in Mathematica:

Wolfram System general issues:

FrontEnd / GUI construction specific issues

Major:

Minor

  • Misaligned frames, additional pixels, imprecise dimensions

    Extra pixels are introduced in many cases, leading to improper dimensions and misalignments.

    test = Framed["TEST", Background -> Red, FrameStyle -> Blue, ImageSize -> {100, 100}]

    Mathematica graphics

    test = Framed[   "TEST",   Background -> Red,   FrameStyle -> #  ] &;

Column[{#, #, Column[{#, #}, Spacings -> 0]}, Spacings -> 0] & /@ {test[Blue], test[None]}

    enter image description here

    ImageDimensions@Rasterize@test

         {100, 102} (* I could live with {102, 102}... *)

    Grid cuts my images

    enter image description here

    TabView Alignment problem for content larger than a view area:

    enter image description here

  • Transparency and background issues

    Transparent bitmaps in controllers bug.

    Dynamic graphics appears first with wrong background

    DensityPlot and GeoGraphics put a white frame around an inset Button.

     {DensityPlot[Sin[x] Sin[y], {x, -4, 4}, {y, -3, 3}, ImageSize -> 100, 
  Epilog -> {Inset[Button["Test"], Background -> None]}],
  GeoGraphics["London", ImageSize -> 100, 
  Epilog -> {Inset[Button["Test"], Background -> None]}]}

    Mathematica graphics

Further problems

Notebook's WindowSize interference with contents' Dynamic ImageSizes

Problem with CurrentValue["MouseOver"] and Deploy

Kernel / coding style issues

OS dependent features

From my experience it is impossible to create precise GUI for Win and Mac. Not all features are OS dependent, and often workaround for one will give you headache in the other.

Grid layout problems: different sizes when rendering on Mac and Windows

Not needed Stylesheet locked by the FrontEnd

Community
  • 1
Kuba
  • 136,707
  • 13
  • 279
  • 740
4

Regarding the lack of control of the output size, at least with a sufficiently high ImageResolution setting it can be tuned:

  test = Framed["TEST", Background -> Red, FrameStyle -> Blue, 
  ImageSize -> {100, 100}, ContentPadding -> False]
ImageDimensions[Rasterize[test, ImageResolution -> 354]]

enter image description here

Rolf Mertig
  • 17,172
  • 1
  • 45
  • 76