slavin@acf4.UUCP (Scott Slavin) (01/10/88)
>I have a GEM programming question. >How do I prevent text that I'm writing to a window from >overwriting a dropdown menu or a dialog box? >Should I use "clipping rectangles", and if so, >how do I get the size of the clipping rectangle? >Thanks, >Jonathan Nagy I didn't think it was possible to have an event waiting (ie. the window coming down) and have output to the screen at the same time. If your talking about the menu overwriting the window text, that is also impossible because the AES saves all the screen under the menu that is coming down. As for dialog boxes, your best bet to to open a window underneath it, and when the dialog box is gone do a window redraw from the message event that will be waiting. Scott Slavin slavin@acf4.nyu.edu slavin@miswnet
pa1132@sdcc15.UUCP (pa1132) (10/03/88)
Here is some questions about GEM: 1. Why is the number of windows limited to 8? Why did DRI design this way? With a miminum of 512k memory for the ST, memory shouldn't be a problem. Even on the earliest 128k Mac, there is no limit on number of windows you can have on the screen. Is there any way to modify the AES so we can get rid of the memory limitation? 2. How to get the menus to appear on other parts of the screen instead of the top line of the screen? I have seen some desk accs to have menu bar under their window title bar. How is that done? 3. How to get bottons, editable (spelling?) text fields and other objects, that used to appear in dialog boxes, to appear in a window? 4. How to modify the appearance of windows? For example, in PageMaker for the Mac, icons are added to the border of windows to show the current page. Is that kind of trick possible under GEM? PageMaker is a trademark.
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (10/04/88)
In article <586@sdcc15.UUCP> pa1132@sdcc15.UUCP () writes: > >Here is some questions about GEM: I suspect that someone more experienced will answer, but here's what I know on the topic (not much!) > > [ stuff deleted ] > Is there any way to modify the AES so we can get rid of the memory > limitation? > Atari might be able to do that, but who knows. Haven't heard them say the limit was raised in TOS 1.4. If you have too many windows things get very cluttered anyway. This isn't a Sun with space for 4 or 5 big windows on the screen at once. > 2. How to get the menus to appear on other parts of the screen > instead of the top line of the screen? I have seen some desk accs > to have menu bar under their window title bar. How is that done? > You'd have to write your own menu handling routines. The standard ones are easy to use, but limited. > 3. How to get bottons, editable (spelling?) text fields and other > objects, that used to appear in dialog boxes, to appear in a window? You can write your own dialog handler and integrate it with code to handle it being in a window (redrawing it, moving, sizing, etc.) Tim Oren's ProGEM columns provide an alternate dialog handler which would make a good start. This is also the only way to provide non-modal dialogs, which are nice in a lot of situations. > 4. How to modify the appearance of windows? For example, in > PageMaker for the Mac, icons are added to the border of windows to > show the current page. Is that kind of trick possible under GEM? Laser C does this but I'm not sure how. I assume that they simply open a window and draw the border elements themselves. When the mouse is in the window, they essentially operate the window and border elements like a big dialogue and internally generate messages for arrows being clicked on, etc. You could try to trick GEM by, for example, drawing the page number inside of the vertical slider box each time you reposition it. However, you'd have to be very careful to make sure that GEM never erases it without it being redrawn. > > PageMaker is a trademark. yawn. -------------- Greg Lindahl internet: gl8f@virginia.edu U Va Dept. of Astronomy bitnet: gl8f@virginia.bitnet
wolf@pyr.gatech.EDU ( Thomas Wolf) (10/04/88)
I'm not going to venture a guess on DRI's motives for the window-limitations, but I suspect that it was probably easier to code :-) Does anybody know whether the REAL GEM (the one that is still supported by DRI -- not Atari's version) has this limitation? About putting buttons, editable strings, etc. in Windows (instead of Dialog boxes): When I wrote a calculator program, I created a Dialog box with all these objects. In my program, I created a window with dimensions set to the width and height of that dialog box. Then I displayed the dialog box inside the window (and redrew it whenever a redraw-event happened.) The toughtest part was getting the dialog box to appear in places OTHER than the center, since that is where these boxes appear by default. This was done by accessing the dialog-boxes data-structure (and I think that was a kludge.) Hope this helps a bit.....BTW, I think this method (of accessing the object's data-structure directly) might also work for menus -- but I could (and probably am) wrong.
pa1132@sdcc15.UUCP (pa1132) (10/05/88)
Just a question about Laser C: Do they use standard windows, or they also create some pusedo-GEM windows? If so, are those pusedo-GEM windows also used by the programs created in Laser C? From the review I see on magazines for Laser C, their windows indeed look different. Also, does Laser C's labrary contain routines to support scrolling within windows? Just aN after-thought: Since GEM is so slow, so dumb, anything which replaceS GEM's component is desirable.
apratt@atari.UUCP (Allan Pratt) (10/06/88)
What you are forgetting about GEM is that the window stuff is provided for your convenience: you don't HAVE to call or enable them; you can just write your own. For example, create a window with no title bar, no close box, no full box, no size box, no sliders and no arrows. Wow! A rectangle! But this is a rectangle which gets redraw messages and other window handling. Now, you put your OWN stuff into the window: your own scroll bars (with page numbers if you like), your own title bar (with extra gadgets if you like), etc. All these things can be objects, and AES will help you manage them and tell when the mouse is clicked on them. AES provides the primitives for doing these things, IN ADDITION TO the high-level management routines, which you can use if you're satisfied with them. If you aren't, go out and make some of your own. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
rjung@sal4.usc.edu (Robert allen Jung) (10/06/88)
In article <596@sdcc15.UUCP> pa1132@sdcc15.UUCP () writes: >Just a question about Laser C: Do they use standard windows, or >they also create some pusedo-GEM windows? If so, are those >pusedo-GEM windows also used by the programs created in Laser C? >From the review I see on magazines for Laser C, their windows indeed >look different. Also, does Laser C's labrary contain routines to >support scrolling within windows? Laser C's GEM-based shell does, indeed, use their own windowing routes (at least it looks that way to me). Similarly, they use their own file selector, and other custom dialogues. HOWEVER, this applies to the shell only. The programs YOU create will use standard GEM windows and GEM dialogues -- Unless you expend the extra energy to write your own window handler routes. As for scrolling, that's another thing for the programmer to sweat over (What do you want, it's _only_ a compiler B-) --R.J. B-) P.S. I've no affiliations with Megamax (or anybody else) except as a satisfied customer (bring on LaserDB!). ----------------------------------------------------------------------------- Disclaimer: These are my views, and mine alone. # ## # Mailing address: Beats me, just reply to this message # ## # (rjung@nunki.usc.edu?) ## ## ## #### ## ####
markhof@exunido.uucp (Ingolf Markhof) (10/06/88)
In article <586@sdcc15.UUCP> you write: > >Here is some questions about GEM: > > 1. Why is the number of windows limited to 8? Why did DRI design > this way? With a miminum of 512k memory for the ST, memory > shouldn't be a problem. Even on the earliest 128k Mac, there is > no limit on number of windows you can have on the screen. Is > there any way to modify the AES so we can get rid of the memory > limitation? My information is, that the Microsoft Company who developed GEM got some trouble with Apple because of the violation of copyrights. As you know, GEM is very similar to the Mac's user interface and Apple did not want to see such a plagiate. I don't know the details, but the result was that Microsoft was not allowed to produce an own user interface that is to much Mac-like. Therefore, GEM got the eight-window restriction. I don't know if there is an easy way - such as just to change a constant value somewhere in the GEM-System - to modify GEM so you can get more windows. But because of the fact, that I've never seen such a modifyed GEM, I don't think that this is possible. Of course, it's not a must to use GEM windows. Basicly, a window is just some rectangular area on the screen. GEM provides only a little bit of support for manipulating windows. The main think it does is to remark existing windows and to send messages to your application if you click somewhere in a window. So, the main parts of window actions are to be solved by you application. Of course you can ignore the little bit of help GEM gives for windows an write window routines by your own. This can be done without the 8-window-restriction, of course... > 2. How to get the menus to appear on other parts of the screen > instead of the top line of the screen? I have seen some desk accs > to have menu bar under their window title bar. How is that done? GEM menus are just as they are. If you want something else, you have to write your own procedures. You know the location of the active window, and you know the mouse coursor postion on the screen.By comparing this informations, you can detect if the mouse is in a position where you want to have a menue. So, just paint one onto the screen. Highligt the selected items when the mouse is pointing to them by redrawing the proper part of the menue. Finally, dicard the menu by replacing it with the thinks you saw in its position before the menue was created... > 3. How to get bottons, editable (spelling?) text fields and other > objects, that used to appear in dialog boxes, to appear in a window? I guess this is possible. But have to know the GEM's Object Library very good. Menus, Boxes, Icons are stored in certain data structures which are described in the GEM's AES Guide. Every object has an position on the screen. This can be manipulated... > 4. How to modify the appearance of windows? For example, in > PageMaker for the Mac, icons are added to the border of windows to > show the current page. Is that kind of trick possible under GEM? Yes, it is. Some GEM Programms also use such icons. For examle look, look at GEM-Draw. But again, there are no standard procedures for this task and it has to be handeled by your own procedures. Ingolf Markhof (markhof@exunido.UUCP)
to_stdnet@stag.UUCP (10/06/88)
From: emh@omni.UUCP (Eric Hopper)
I don't think that you need to access a dialog's data structure
directly to get it to appear someplace else other than the center of the
screen.
Ah, yes. Here it is in the Laser C manual. To make a dialog box at
a given position you would have to use this function, or something simlar:
int make_dialog(dialog, your_x, your_y)
OBJECT *dialog;
{
int x, y, w, h, itemhit;
form_center(dialog, &x, &y, &w, &h);
x = your_x;
y = your_y;
form_dial(FMD_START, 0, 0, 0, 0, x, y, w, h);
objc_draw(dialog, 0, 10, x, y, w, h);
itemhit = form_do(dialog, 0);
form_dial(FMD_FINISH, 0, 0, 0, 0, x, y, w, h);
return(itemhit);
}
Of course this doesn't deal with the problem of drawing it within a
window, and handling the box yourself. That would involve all sorts of
complicated calls to objc, and graf routines that I don't have time to
research right now.
Eric Hopper (Omnifarious)
emh@stag!omni.UUCPc91a-ra@franny.Berkeley.EDU (reader.john.kawakami) (10/09/88)
In article <647@laura.UUCP> markhof@exunido.UUCP (Ingolf Markhof) writes: >In article <586@sdcc15.UUCP> you write: >>Here is some questions about GEM: >> >> 1. Why is the number of windows limited to 8? Why did DRI design >> this way? With a miminum of 512k memory for the ST, memory > > My information is, that the Microsoft Company who developed GEM got some >trouble with Apple because of the violation of copyrights. As you know, >GEM is very similar to the Mac's user interface and Apple did not want >to see such a plagiate. I don't know the details, but the result was that >Microsoft was not allowed to produce an own user interface that is to >much Mac-like. Therefore, GEM got the eight-window restriction. Major corrections: First, GEM was developed by Digital Research Inc. (DRI) not Microsoft (which makes Windows for the PCs). Apple tried to sue DRI, but they settled out of court. As a result, the desktop icons changed, close-full-shrink window icons changed, and pull-down menus became drop-down menus. Later, the desktop for PC-GEM was changed again--to the point of being unusable. Apple is going through litigation with Microsoft and HP over similar so- called copyright infringements (I may be wrong here, maybe it has been settled already). The 8-window bug should not be related to this. I suspect that window space, like folder space, is constant. This bug could be avoided by using dynamic memory allocation. But, this might be hampered by the non-standard (read: sh*tty) Malloc. I don't think this would be hard to fix--but the fixes to Malloc may render some programs un-runnable. TTL EXE MUX PRG A3I MTX TTP FOE TUS APP JTK MMU CRT VDI TOS DRI GEM CPM ACC OMV JOH NKA WAK AMI c91 a-r a@f ran ny. Ber kel ey. Edu kaw aka mi@ zen .Be kel ey.