Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!unido!laura!exunido!markhof
From: markhof@exunido.uucp (Ingolf Markhof)
Newsgroups: comp.sys.atari.st
Subject: Re: GEM programming
Keywords: GEM
Message-ID: <647@laura.UUCP>
Date: 6 Oct 88 15:25:42 GMT
References: <586@sdcc15.UUCP>
Sender: root@laura.UUCP
Reply-To: markhof@exunido.UUCP (Ingolf Markhof)
Organization: University of Dortmund, W-Germany
Lines: 61

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)