Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!utcsri!utegc!utai!garfield!john13 From: john13@garfield.UUCP Newsgroups: comp.sys.amiga Subject: Intuition Extensions & other languages Message-ID: <3604@garfield.UUCP> Date: Tue, 21-Apr-87 16:50:41 EST Article-I.D.: garfield.3604 Posted: Tue Apr 21 16:50:41 1987 Date-Received: Thu, 23-Apr-87 00:40:08 EST Organization: CS Dept., Memorial U. of Newfoundland, St. John's Lines: 74 [] I've been hacking at Intuition a lot lately, and the next thing I'd like to do is allow someone to change the menu text in programs, so for instance you could translate a program into French just by running it then "installing" the French versions of all the menutitles/items. This in itself is easy. What is not so easy is making it as transparent as it should be. For example, I can overwrite the original text with the new - but that is messy, and means that new menu item text must be of the same length or shorter than the original. Or, I can allocate some space for the text, and simply change pointers in the menu structure so that it's displayed. This is better, but how can the new text be de-allocated when the program finishes? I can think of two ways - monitor that window's IDCMP for closewindow messages or check periodically the list of windows until it is no longer there. But that introduces some new difficulties, you have to provide a background monitor task, and multiple windows sharing menus would not work (guru maybe). The solution is not hard, but would require a new standard on the part of C-A: an "Intuition extension" standard that allows someone to tell what someone else may be doing to their windows. The logical place to add such an extension already exists - the UserData fields of screens and windows. I propose that a range of items be created that could be added on to this field. Some ideas: - FREE_ALSO : if one of these is present, when the window is closed the program should also de-allocate a specified block of memory, which could contain things like user-supplied menu text, user-supplied gadget images, user-supplied pointer definition, etc. - REQ_NODE, GADG_NODE: because gadgets and requesters are not always linked to the window, it would be difficult to supply new text for them in another language. However, if the person who opened the window would be so nice as to also give me a list of pointers to *his* gadgets and requesters, even when they are inactive, it would be a simple matter for me to determine what they are, and substitute new text, and maybe change their size. The FREE_ALSO nodes could be broken down into several sub-categories; maybe an "iconify" gadget could be added to windows without their knowledge, and its definition go here. Replacement menu items, with different positioning, methods of highlighting, etc could be used, not just new text. "Message" nodes might signal to the program that such changes had taken place if a response was desired from the program (eg "You're running on a 1 bit-plane Workbench screen now.") Of course, many programs would have no need of this. But for those with an eye to foreign markets the task of translation would be simplified - no need to recompile, you could supply a program to redefine all the menus after loading (maybe even read these definitions from a user-editable data file). So it would be just an afternoon's work for someone in another country, even without the sources, to custom-tailor the program to that market. I can think of a lot of uses for this sort of a scheme; and, unlike "re-write the DOS" and a lot of other suggestions, it would be easy to implement: just a letter to developers saying "here is the include file , please check before closing a window to determine if you need to do X, Y, or Z, and if you like you may check during program execution to determine if someone's utility is doing A, B, or C to your screen/window". I don't know if there are programs now which use the UserData fields. I suspect I'll soon be checking out a lot of commercial software to see if it actually does. Even in a worst-case situation for a window not using the UserData area, all you would end up with would be some memory not de-allocated properly, and as I said earlier a patch program could take care of that for older software. Well, what does everyone think? John Russell john13@garfield.mun.cdn 5 Alderdice Place john13@garfield.UUCP St. John's, NF (Canada) A1B 2P8 (709) 726-7847