While I can agree that user interface consistency can be a good thing, I think that that user interface concepts themselves are at least as much "fashion" issue as anything else in computing.
If there were a really such a thing as an adequate "consistent" (non-kludge) menu system there would be no need for different apps to have different menus. And that this kind of consistency exists only as a [commercially useful] myth is also quite telling... That said, we should probably think about moving this discussion to chat forum soon, if we're not going to be including any code... Thanks, -- Raul On Tue, Sep 15, 2015 at 2:42 PM, Ian Clark <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
