john13@garfield.UUCP (04/21/87)
[] 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 <intuition/ 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". 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
cmcmanis@sun.UUCP (04/27/87)
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 <intuition/ > 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()!
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) (04/28/87)
In article <3604@garfield.UUCP> john13@garfield.UUCP writes: >[] > >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? There's one important program that uses the UserData field: WorkBench From looking at the source, it appears to use the UserData field as a pointer to a Damage list that it maintains. And anything you put there will probably be wiped out and may cause other unknown things to get trashed. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
john13@garfield.UUCP (04/29/87)
In article <1776@cbmvax.cbmvax.cbm.UUCP>, carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) writes: > > There's one important program that uses the UserData field: WorkBench > > From looking at the source, it appears to use the UserData field as > a pointer to a Damage list that it maintains. Thanks for the response. I found this out shortly after, and will modify my menu-changer so that it will only add new items if the UserData is NULL or points to a list of valid menuitem nodes. However, I realize this won't stop the list from being trashed if a program decides halfway through to change UserData. Oh well. No interesting Workbench menus. Unless...what's this one, ExtData, not documented? Maybe I could...argh! No! Please, don't hit me! :-) John
gary@eddie.MIT.EDU (Gary Samad) (04/30/87)
In article <3604@garfield.UUCP> john13@garfield.UUCP writes: >[] > >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). Well, this may not work for several reasons. Looking for CloseWindow messages wouldn't always work because programs may exit for other reasons (via a keystroke command, for instance) and what about programs that are not actually done after you hit CloseWindow (maybe a requester comes up about saving your data or something). Also, my new program, in fact, uses a single menu which multiple windows share. >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, I use the UserData fields, so please don't muck with them. I like your basic idea but I think there are probably too many problems to overcome (such as, what about menus that are built and changed dynamically). > >John Russell john13@garfield.mun.cdn Gary