I'm not quite following your argument, Ian. It seems to me that if all windows owned by the JQt app must all have the same menu that this forbids user-defined menus.
Is that really what you are saying J should be doing? Thanks, -- Raul On Sun, Sep 13, 2015 at 9:28 PM, 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
