stevef@dasys1.UUCP (Steve A. Feinstein) (09/17/87)
Does anyone know if there is a way to modify the GEM desktop's
resource structure. Is there a pointer anywhere that I would be able
to steal. Or am I all out of luck because it's all locked in ROM.
I would guess that there is something akin to what I want to do
possible. As evidenced by programs like EASEL/ST and the ICON munger.
--
Steve Feinstein {allegra,philabs,cmcl2}!phri\
{bellcore,cmcl2}!cucard!dasys1!stevef
New York, NY, USA {philabs}!tg/SCHOMAKE@HNYKUN53.BITNET.UUCP (09/28/87)
[] >From: phri!dasys1!stevef@nyu.arpa (Steve A. Feinstein) >Does anyone know if there is a way to modify the GEM desktop's >resource structure. Is there a pointer anywhere that I would be able >to steal. Or am I all out of luck because it's all locked in ROM. >I would guess that there is something akin to what I want to do >possible. As evidenced by programs like EASEL/ST and the ICON munger. >Steve Feinstein, New York, NY, USA (A few months ago I asked a similar question. No response...) {neurons: fire!} This is an important point. GEM is not really a desktop metaphor! It is a menu oriented user interface mainly. Gadgets like the [Show][Print][Cancel] box, the Fileselector box etc. are irritating me daily. They are disrupting the "stream of thought and action". We want to drag File icons to a Printer icon, to a Kermit icon, to an Application icon, or (much less frequently) ... to a Trash Can icon. Also, consider the following imaginary three-click scenario: click text file once, click MORE.TTP once. MORE appears to need a stdout. Click on a CRT-shaped icon, and off we go. The CRT-icon should stand for a fast text window (sizeable and everything) instead of the eye-blinding TOS screen we are punished with today. These natural extensions to rudimentary GEM can only be implemented if we know more about the vanilla desktop. Personally, I don't like disassembling ROM code etc. The following pieces of information would be very useful, however: -At what address does the "left-mouse-button-clicked" handler in the vanilla desktop start? Can we insert a hook or trap here? Can we make this hook release-independent (address in file)? -Is the standard method for scanning a GEM object-tree used to determine what icon (e.g. a file) is being clicked? -At what times do the necessary GEM data structures reside in RAM (probably only as long as the desktop is visible...)? -Is it possible to change application file icons like on the MAC? I wonder about the amount of work involved in adding these features. It may well be that DRI themselves stopped further improvements because of reaching the spaghetti code stage. In that case, starting from scratch would be advisable (don't look at me). How about calling this child JAM :-) ? {neurons: relax!} * ~~~~~ KKKKKUUUUNNNNN KKK UUUU NNNN Lambert Schomaker K UUUU NNN SCHOMAKE@HNYKUN53.BITNET KKK UUUU NN Nijmegen, The Netherlands. KKKKK UU N