Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!lll-lcc!pyramid!oliveb!sun!cmcmanis From: cmcmanis@sun.UUCP Newsgroups: comp.sys.amiga Subject: Re: Intuition Extensions & other languages Message-ID: <17456@sun.uucp> Date: Mon, 27-Apr-87 16:06:49 EDT Article-I.D.: sun.17456 Posted: Mon Apr 27 16:06:49 1987 Date-Received: Wed, 29-Apr-87 00:59:49 EDT References: <3604@garfield.UUCP> Organization: Sun Microsystems, Inc. - Mtn View, CA Lines: 142 Summary: Design them differently Some comments to John's posting, but here is the executive summary : o Don't touch the UserData fields! I use 'em and so do others. o Write code that uses home grown 'resource' files but don't force everyone too. Possible levels of Commodore support : 1) "Oh that's nice" 2) Document "What to include in a 'resource' file" 3) Here's a resident 'resource.library' as part of release x.y type 'n' now to skip the gruesome details... In article <3604@garfield.UUCP>, john13@garfield.UUCP writes: > 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. Congratulations you have just reinvented the resource paradigm of window design. The Mac and the Atari have variations of the resource concept which adds yet another filetype to worry about, specifically the .rsc file. This file contains descriptions of the menu and gadget text and is loaded when the file is loaded. Editing it to contain french or german text is fairly easy and the program automatically changes too. Writing code that does this is good for the developer because it saves one edit/recompile. > 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). John there are *lots* of problems with changing programs that aren't expecting to have their menus diddled with. Look at microGNUmacs with its 'browser' menus, or InfoMinder with its chapter menus. Also many programs use static arrays to allocate menus (and thus hard code menu addresses into the program) so when you change them for Intuition they don't change for the code. Then things like menu 'Checkmarks' don't appear anymore. Then there are the programs that dynamically allocate menu items but cache the pointers etc etc So no, it isn't easy and isn't really even possible to do this reliably. Conclusion, "Don't bother." I am all in favor of 'resources' but don't kill yourself looking for a way to add them to programs you don't have the source to. > 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. First, I have edited out the next 'n' lines because I personally feel that modifying intuition.h, adding flags etc is not the solution, and wish to propose my own :-). Second, *DO NOT* usurp the UserData fields from the Users because we use them all the time for our own crufty purposes and we are glad to have them so there :-). As John mentions the simple and _doable_ solution is to build the gadgets, windows, menus, and text on the fly. That is, create these structures at run time rather than at compile time. You could even define your own 'resource' type file that would describe the tool layout to your program. This file would consist of lines of the form : Boolean Gadget at (100,20) "Start Copy" COPYCMD ^^^^^^^^^^^^^^ ^^^^^^^ ^^^^^^^^^^^^ ^^^^^^^ \ \ \ \_____ GadgetID \ \ \_______________ GadgetText \ \_________________________ Window Position \________________________________________ Type MenuItem "Project" SubItem "Load" SubItem "Save" SubItem "Quit" Or something similar (possibly easier to parse) then you could edit them with a text editor and customize your gadgets/menus. This actually buys you two benefits, first if only you have such a capability, you will be whipping together Intuition Tools in nothing flat since this 'ToolBuilder' would do the userinterface stuff for you, second you could adapt your tools to foreign markets quickly and thus win lots of sales. (Of course most people just adapt their code by editing the source, it is a simple string replacement.) But if your tools have this capability they might be more desireable in the market, especially if you let users customize the tools. The disadvantage is that the code to create menus, gadgets, requesters, and such on the fly is usually bigger than just statically allocating structures and filling them in with initializing statements. So one possible answer would be to create a resident library that does too building. Then your code could open it, build all of the structures it needs and then close it (thus freeing up some memory). Probably the best of both worlds. > 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 Exactly so why change the O/S (or add all of these requirements) to Intuition programs for everyone? > ... (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. Yes, an excellent idea :-). > 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 extensions.h>, 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". Although technically changing intuition.h isn't rewriting the O/S it is overkill. Just write your code to do this. Also, don't worry about programs that can't support this sort of stuff, it is their own tough luck! > 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. I like the idea, see my comments. What is infeasible it to try to stomp older programs into compliance. Like I said before, leave the UserData fields alone! So do this for your future programs, maybe even convince Commodore to write their code that way. But don't bother writing a hack to add this to older programs. > John Russell john13@garfield.mun.cdn As always I've gone on to long. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These views are my own and no one elses. They could be yours too, just call MrgCop() and then ReThinkDisplay()!