Touché. Before the iPhone came along, Apple developers (which in spirit I still am) used "app" as short for "application". That's how I meant it. Here's your formal definition: http://www.webopedia.com/TERM/A/application.html Nowadays "app" has come to mean exclusively an iPhone application - or what passes for it on all the various knock-off copies.
> I believe instead that they are something which can be used in either case. Yes, I agree totally with that, but only in a cynical sense. Menus can be abused as well as used, and the ways of doing that are infinitely flexible. A properly designed menu system is a huge help for a novice user. This was established by a series of research reports coming out of Xerox PARC during the 70s based on solid human factors research. The WIMP interface (window - menu - mouse - pointer) interface deserves its good reputation. Properly used. But a haphazard menu design is worse than useless, and you're provably better off (as a novice user) sticking to UNIX, which has evolved better ways of presenting random bunches of mnemonics for user selection. Which I put it to you is all that a typical MSWin program does. But myth has replaced reality in the public eye. Modern app[lications] have gotta have menus, like gas-guzzlers had to have tail fins, because it made them go faster. Your use of "user-defined menus" is revealing. I first heard it being used by a cross-platform IDE vendor who wanted to say to its customers "me-too" - and here's a kludge to do it. The customers neither knew nor cared that they were falling between two stools. They didn't even want a usable UI – what price your job if any fool can do it? They simply didn't want to look like dinosaurs. The price people pay for fashion! On Tue, Sep 15, 2015 at 6:57 PM, Raul Miller <[email protected]> wrote: > Do you have formal definitions of these concepts? > > If not, I'd be tempted to say; neither. It seems to me that menus by > themselves do not make an application, nor do they make an extension. > I believe instead that they are something which can be used in either > case. > > Thanks, > > -- > Raul > > On Tue, Sep 15, 2015 at 1:36 PM, Ian Clark <[email protected]> wrote: >> @Raul - answer me this first: is a (collection of) "user-defined menus" >> >> (a) an app in its own right? or- >> >> (b) an extension of the J app? >> >> On Tue, Sep 15, 2015 at 1:46 PM, Raul Miller <[email protected]> wrote: >>> I'm still not seeing how what you indicate as "the OSX design" makes >>> sense for any interpreted programming environment which allows user >>> defined menus. >>> >>> -- >>> Raul >>> >>> On Mon, Sep 14, 2015 at 8:02 PM, Ian Clark <[email protected]> wrote: >>>> No, @Raul, I was answering Bill's question re OS X features. >>>> >>>> The "proper" design for OS X isn't fit for Windows -- and vice-versa. >>>> You don't need to be a conspiracy theorist to know this is (-was) >>>> intentional on the part of M$. Remember the "look and feel" lawsuit? >>>> >>>> On Mon, Sep 14, 2015 at 3:55 AM, Raul Miller <[email protected]> wrote: >>>>> 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 >>>> ---------------------------------------------------------------------- >>>> 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
