> this would mean that Term would get two top level menu items, Script and > Window, that would be completely disabled.
@Chris - yes, that's exactly what the Apple UI guidelines recommend. But do *I* recommend it? See my reply to Raul. To suit myself, I guess I would. But JQt is cross-platform, so I can't really blame you for designing for Windows. What's best for the novice user? Well, we're into GUI-wars now. Maybe on the chat-list, if anyone has the stomach for it. Personally, I've given up bothering (where J is concerned). On Mon, Sep 14, 2015 at 4:43 AM, chris burke <[email protected]> wrote: >> Qt, being cross-platform, is a law unto itself, it seems. > > No, this is our design, nothing to do with Qt. > > Term and Edit windows have different menu requirements, so we made separate > menus for them. It never occurred to me to have the same menus, but with > unwanted items disabled. For example, this would mean that Term would get > two top level menu items, Script and Window, that would be completely > disabled. > > > > On 13 September 2015 at 18:28, Ian Clark <[email protected]> wrote: > >> @Bill >> >> > Is this behavior (sharing menu) a feature of osx in general? >> >> Yes, definitely. >> >> In OS X the menubar belongs to the app. Not to the window, as in >> MSWin. At least it did when I was programming the Mac in C in the 80s >> / 90s. >> >> Most commercial apps for the Mac, e.g. Firefox, TextEdit, Microsoft >> Word, let you create a new window with ⌘N. E.g to edit a second >> document. All such windows share the same menubar but window-specific >> menu items (⌘C, ⌘V …) work only on the topmost (=active) window. >> There's generally a "Window" menu, listing all open windows – the >> active window is shown checked: (√). Of course there are apps which >> only ever show one window. What the menubar applies-to is never in >> doubt. >> >> J602 doesn't obey the rules. Thus: if you launch the Plot package, it >> makes a separate window, but when you click on that window – the >> menubar vanishes, leaving only the Apple-supplied menus ("Apple" and >> "J"). I guess Plot is pretending to be an independent app? >> >> By contrast, JQt does obey the rules - up to a point. All windows >> owned by JQt, even user-created ones, share the same menubar. However >> the Edit and Term windows chop-and-change menus between them (a big >> no-no - you should gray them out, not make them vanish.) That totally >> bamboozled me, until I worked out what it was playing at. I was >> discovering menu items one day and not finding them the next. >> >> The basic model is that when an app (e.g. DreamWeaver) lets you work >> on either a picture or text, say, these aren't 2 different sorts of >> window. They're one-and-the-same sort of window, adapted to picture or >> text, inapplicable menu items like "Rotate" or "Spelling" being >> grayed-out. The menubar is owned by the app, as I said, and is >> therefore common to all windows. Apart from J, all Mac apps I've seen >> follow this basic model. >> >> Qt, being cross-platform, is a law unto itself, it seems. >> >> On Mon, Sep 14, 2015 at 12:51 AM, bill lam <[email protected]> wrote: >> > Is this behavior (sharing menu) a feature of osx in general? >> > On Sep 14, 2015 5:17 AM, "Ian Clark" <[email protected]> wrote: >> > >> >> @Chris >> >> >> >> > Does your repaint include some computation that could have been done >> up >> >> front? >> >> >> >> It's TABULA. Judged superficially, yes. The toolbar is painted >> >> laboriously pixel by pixel, also it's animated. A speedup would be to >> >> take a snapshot of the isidraw and use that instead. But it is >> >> (planned to be) reconfigurable by the user, so I don't want to get >> >> into speedups just yet. Particularly as I'm now badly equipped for >> >> cross-platform testing. >> >> >> >> > How did you do that? >> >> >> >> Currently a t-table carries free-form info that's displayed in the >> >> "Info" tab. It's good in practice to have that optionally in a >> >> separate window, so it can be left visible while interacting with the >> >> main form, and I've done just that. >> >> >> >> But when the "Info" window has the focus, instead of the menubar >> >> disappearing and being replaced by something vestigial, I can still >> >> see the main form's menus. And they all work. >> >> >> >> TABULA also optionally creates a "plot" window – and the same remarks >> >> apply. Bill thinks it's a bug not a feature. But jwplot wouldn't be so >> >> useful within an app if it hid the app's menus. >> >> >> >> > I suppose we should allow redefining the menubar on the fly. >> >> >> >> I guess most J coders won't need the facility to reconfigure a menu >> >> after every user interaction. Only people like me, trying to write >> >> professional-looking cross-platform software. Perhaps I simply >> >> shouldn't be using Jwd, but working directly with Qt widgets? I can't >> >> be far short of my 100th GUI. >> >> >> >> wd 'set menuitem text "New Caption" ' -would be nice. But destroying >> >> and rewriting the whole menubar ought to be fast enough. It is >> >> intuitive (using rplc) and totally flexible. >> >> >> >> Ian >> >> >> >> On Sun, Sep 13, 2015 at 3:25 PM, chris burke <[email protected]> >> wrote: >> >> >> My form takes a noticeable time to repaint. I don't want to do that. >> >> > >> >> > I am a little surprised by this. Does your repaint include some >> >> computation >> >> > that could have been done up front? >> >> > >> >> >> But I see with JQt it's possible to define two separate forms for the >> >> same >> >> > app. If one of them specifies no menus, it lets you see the menus of >> the >> >> > other form – even when it's got focus! >> >> > >> >> > How did you do that? >> >> > >> >> > I suppose we should allow redefining the menubar on the fly. >> >> > >> >> > >> >> > >> >> > On 13 September 2015 at 05:32, Ian Clark <[email protected]> >> wrote: >> >> > >> >> >> My form takes a noticeable time to repaint. I don't want to do that. >> >> >> >> >> >> But I see with JQt it's possible to define two separate forms for the >> >> >> same app. If one of them specifies no menus, it lets you see the >> menus >> >> >> of the other form – even when it's got focus! At least, it does on >> the >> >> >> Mac (…under Snow Leopard). >> >> >> >> >> >> I conjecture it's possible to split my form into a menu-less and a >> >> >> menus-only form. The latter will be a lot less pain to recreate – and >> >> >> easily reconfigured like this: >> >> >> >> >> >> wd MYMENUSONLY rplc 'Repeat Last Action' ; 'Repeat "Delete Line"' >> >> >> >> >> >> The same trick will let me offer an up-to-the-minute MRU list >> attached >> >> >> to the File menu. >> >> >> >> >> >> Maybe there are gotchers. Maybe it won't work on all platforms. But >> >> >> it's worth me doing some experiments. Anyone care to try it with >> >> >> MSWin? (I can see a sticky "fellow traveller" being needed for the >> >> >> main window, consisting only of a menubar.) >> >> >> >> >> >> On Sat, Sep 12, 2015 at 2:49 AM, chris burke <[email protected]> >> >> wrote: >> >> >> > You can create a new form to replace the old, positioning exactly >> over >> >> >> the >> >> >> > old. This should happen fast enough to be unnoticeable. >> >> >> > >> >> >> > I cannot think of examples in J8, but this was done in J6, for >> example >> >> >> with >> >> >> > the Find and Replace dialogs. >> >> >> > >> >> >> > On 11 September 2015 at 15:56, bill lam <[email protected]> >> wrote: >> >> >> > >> >> >> >> I think these functions are not implemented. >> >> >> >> On Sep 12, 2015 4:50 AM, "Ian Clark" <[email protected]> >> wrote: >> >> >> >> >> >> >> >> > With jwd in JQt, how do I change the text of a given item in an >> >> >> >> > existing set of menus? >> >> >> >> > >> >> >> >> > E.g. to state precisely what action I'm offering to Undo / >> Repeat / >> >> >> etc? >> >> >> >> > >> >> >> >> > An allied problem is to add items to an existing menu, e.g. to >> >> provide >> >> >> >> > a MRU facility. >> >> >> >> > >> >> ---------------------------------------------------------------------- >> >> >> >> > For information about J forums see >> >> >> http://www.jsoftware.com/forums.htm >> >> >> >> > >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> >> >> For information about J forums see >> >> http://www.jsoftware.com/forums.htm >> >> >> >> >> >> >> > >> ---------------------------------------------------------------------- >> >> >> > For information about J forums see >> >> http://www.jsoftware.com/forums.htm >> >> >> >> ---------------------------------------------------------------------- >> >> >> For information about J forums see >> http://www.jsoftware.com/forums.htm >> >> >> >> >> > ---------------------------------------------------------------------- >> >> > For information about J forums see >> http://www.jsoftware.com/forums.htm >> >> ---------------------------------------------------------------------- >> >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- >> > For information about J forums see http://www.jsoftware.com/forums.htm >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
