eoo@let.rug.nl (Eize Oosting) (06/10/91)
In article <829@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: > >On the other hand, it would be very useful to have an Amiga >programmer's utility with which you could design menus, gadgets, >requestors, and other Intuition objects, play with them on the screen, >and write the definitions out to an object file. Then you simply link >your code to the "intuition resources" you have created, and away you >go. It might even be possible to write it so that the editor could >recognise its "resources" in a program, and allow you to edit them >without re-linking the program. > There is a program called PowerWindows II, with which you can create almost any layout, and then generates Manx or Lattice C code, or even Assembler. It's very handy. /\__________/\ /\___________________________________________________/\ / \ / \ | Letteren- | Marvin Minsky once defined Artificial Intelligence as: | | Faculteit | '... the science of making machines do things that | | R.U. Groningen | would require intelligence if done by men'. | | The Netherlands| | | | Does this include adding a device to the Mountlist? | | eoo@let.rug.nl | Eize Oosting | \ __________ / \ ___________________________________________________ / \/ \/ \/ \/
mattel@auto-trol.com (Matt Telles) (06/10/91)
In article <1739@gufalet.let.rug.nl> eoo@let.rug.nl (Eize Oosting) writes: > >There is a program called PowerWindows II, with which you can create almost >any layout, and then generates Manx or Lattice C code, or even Assembler. >It's very handy. > Um.. could we have a little more info on this? Is it PD/Shareware/Commercial? Who makes it? (Or if PD -- where is it available..) This sounds like a WONDERFUL program..... Matt the net.lurker -- ============================================================================== Matt Telles mattel@auto-trol.COM {...}ncar!ico!auto-trol!mattel Auto-trol Technology 12500 N Washington Denver, CO 80241-2404 (303)252-2874
m0154@tnc.UUCP (GUY GARNETT) (06/13/91)
In article <1739@gufalet.let.rug.nl> eoo@let.rug.nl (Eize Oosting) writes: >In article <829@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: >>On the other hand, it would be very useful to have an Amiga >>programmer's utility with which you could design menus, gadgets, >>requestors, and other Intuition objects, play with them on the screen, >>and write the definitions out to an object file. Then you simply link >>your code to the "intuition resources" you have created, and away you >>go. It might even be possible to write it so that the editor could >>recognise its "resources" in a program, and allow you to edit them >>without re-linking the program. > >There is a program called PowerWindows II, with which you can create almost >any layout, and then generates Manx or Lattice C code, or even Assembler. >It's very handy. > Well, PowerWindows II is very good at what it does (creating user interface source code), but it falls short of what I described above. First of all, PowerWindows requires you to have one of its supported compilers (SAS, Manx, or a compatible assembler) to generate object modules. So you have to recompile your code to incorporate changes (the "resource editor" concept tries to avoid re-compiling the program, and would hopefully make changes in-place, with no re-linking required either). PowerWindows does not help programmers working in Modula-2, or Draco, or other languages; a "resource editor" which generated loadable (by LoadSeg) object definitions would be usable from any programming language which supported library calls. The procedure would be to LoadSeg() the "resource file", and look in the front of the loaded resource file for an array of "resource headers": each resource header would contain the name of a resource, and its address (all of the addresses, and the pointers in the structures contained in the resource file would be valid, thanks to relocation by LoadSeg). Place the addresses in pointer variables in the host program, and away you go. A properly done resource editor would let you edit the resource file (to change the colors or appearance of various objects, for example) without affecting the program (as long as all the "resource headers" were defined, and pointed to appropriate structures, everything would be fine). For the most popular languages, a utility could be provided to append the resource file to the executable, and a function provided to locate the resource header table. How about it? Wildstar "... I'll see you on the dark side of the Moon!" -- Pink Floyd
eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) (06/14/91)
In article <834@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: [lotsa stuff left out...] >A properly done resource editor would let you edit the resource file >(to change the colors or appearance of various objects, for example) >without affecting the program (as long as all the "resource headers" >were defined, and pointEd to appropriate structures, everything would >be fine).... Which brings us to another point: the current version of Intuition (1.3, the only one I have seen the Docs for) does not support static definition for a number of important layout features, specifically colors (you can specify which pen to use for rendering, but you can't muck around with the cmap) and filled shapes. Both of these rather important features of a user interface must be handled in code. If you want a filled red background in your window, you must set up a cmap entry with LoadRGB4() or something equivalent, then you must do a SetRaster() to that window with the appropriate pen. If that window is ever resized, or if you have Intuition objects within that window and have it set to SIMPLE_REFRESH, you must do another SetRaster() to refresh the background. These two features could, and should be handled by intuition. There is current support for statically defining poly-lines (borders) and bitmaps (images). Although a filled polygon could be defined through an image, a great deal of space is being used compared to the few bytes needed for a couple of coordinates. The colormap should also be handled in the Intuition NewScreen() call. Colors belong to a screen (O.K., Viewport, but Intuition doesn't deal with Viewports, and the Intuition equivalent of a Viewport is a screen) so the screen should be able to handle its own colormap. If these two things were added, I believe it would be enough to completely define the appearence of most Intuition-based applications. Such an application could store the entire user interface (the bits you see) as static data that could then be munged by a resource editor. Loading this UI would be zero overhead, after all it is linked in to the application. The resource file could be generated separately by a resource editor during testing, and eventually linked, permanently, to the application. Proper placement or tags would also allow post-linkage resource modification by a well designed resource editor. This would allow users to totally trash your application all by themselves! (8^) Next weeks topic: BOOPSI, How To Statically Define Your Application's UI, or Look Ma, I Lost My Gadgets!! -- ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid