If you ever tried TomTom HOME, you probably noticed that its user interface is “unusual”. It tries to mimic the user interface of a navigation device meaning among others that all messages (“dialogs”) replace the entire window content and require you to dismiss them before you can continue doing whatever you have been doing. There are some advantages to that kind of user interface but it was also a constant source of irritation among our testers (and, no doubt, users). In particular, you could still use the menu despite the dialog, with strange results.
After this has been going on for a year, a decision was made to switch to a more conventional user interface concept and use real modal dialogs. Modality was an important point because often these dialogs are a reaction to an USB event where we really want to stop the user from doing anything until he is done with the dialog. Now you can probably imagine that such a radical paradigm shift wasn’t easy to implement and replacing the function that opened dialogs was only the beginning. Still, after some time we got something that was stable and made sense — even though we now have way too many modal dialogs, something that we will continue working on.
That means, we got it stable on Windows. Mac OS X however was a different story, issues still kept popping up. I doubt anybody anticipated how hard it would be to get everything working there. I had to spend quite some time digging into Mac issues and you could really see how hard Mozilla developers tried to shoehorn Mac’s user interface into a cross-platform framework — and still failed.
Now I know fairly little about Macs so forgive me if I get some details wrong. But it seems that Mac had two concept that correspond with the concept of modal dialogs that you have on Windows or Linux. One is so called “sheets” that appear from the title bar of a window. They aren’t independent windows, have no title bar and block only the window they belong to. Another concept are app-modal dialogs that look like regular windows and block the entire application. XULRunner usually opens dialogs that have a parent window as sheets and those that don’t as app-modal dialogs.
Our dialogs belong to a window so they should be displayed as sheets. Which works mostly fine as long as you only have one of them. But in our case a new dialog can pop up at any point, even if another dialog is already open. And that’s where it gets weird because only one sheet can be visible at a time. If both dialogs have the same parent window, the new dialog will not open until the old one is dismissed. That is something we couldn’t accept because the new dialog is usually more important. Also, we cannot have an entirely different user interface on Windows and Mac — but on Windows new dialogs always show up on top. Fortunately, there is a solution, you simply have to use the dialog that is already open as parent window for the new dialog. The new dialog is displayed and the old dialog is hidden until it is dismissed. Only that you cannot find out which dialog is currently visible. And that there is a way to bring up the hidden sheet via dock icon menu, and if you use this feature it messes things up. And judging from the discussion in the second bug opening multiple sheets isn’t supposed to work that way anyway, so at some point a XULRunner update will likely break the fragile solution that we built up.
Some other issues that have been investigated:
- Clicking a window while a sheet is open doesn’t bring it up unlike for native Mac applications — resolved by updating XULRunner
- A hang after certain sequences of opening and closing dialogs — couldn’t get it reproduced outside our application, and it went away when we sorted out parent window issues
- It is possible to access main window’s menu despite a modal dialog — had to be tolerated, we cannot fix it at this point
To sum up, my impression is that as far as inconsistencies between Windows and Mac in XULRunner go, modal dialogs are pretty much the worst case scenario. Only the inconsistencies in the way menus work are worse.
Comments
Though the window model is essentially the same as Windows, on Linux dialogs specified as model are not actually modal, i.e. you can focus the opener window. This is in my experience anyway.
Would it be possible to have an option to request the ads but not display them? Some sites (imeem.cxxxm) will refuse to display content until an ad is requested.
Short answer – yes. For the long answer please ask in the forum (no registration required) and give a more detailed description (link to a page that gives you trouble at the very least), getting a solution usually doesn’t take long.
Step back and take a deep breath. Then read the last lines about Adblock Plus. As nearly as I can make out, the convoluted jargon is an attempt to say problems could result using the blocker. The few who have given their lives to this (!) now have something more to discuss (among the three or four poor souls who choose to do so).
To find that a presentation didn’t go well also amazes me. The whole point of technology for non-research communication is not to specialize to the nth degree, but to provide widely available secure use and speed in a world of several billion others who do not care terribly about ads online. We do care about compromising privacy, since that has become a real problem, not simply an annoyance.
Hi,
As Tomtoms are working under linux, how can you explain that the application tomtomhome works only under windows and Mac OSX, and does not exist for linux ???
Is it a trade agreement between tomtom and MS, or is there an other reason ?
Is it so complicated to do ?
Yes, it is complicated. No, the operating system of the devices itself doesn’t matter. No, there is no other reason. Work on a Linux version was underway but never got finished.