GadTools

Submitted by JosDuchIt on

  • up
    33%
  • down
    67%
This is an article in the making. I am dumping here my questions and hopefull progressing understanding of gui creation on the Amiga from its first appearance on the Amiga till now. I would be very thankfull for hints or code showing how this is done, for pointing me in the right direction when i am misunderstanding a given subject, giving wrong information, or using poor english Why this article? Gui4Cli (also its present OS4 version) is entirely built upon GadTools. It is probably the most sophisticated GadTools based product around. Some people think that because GadTools is 'old'(introduced with OS2.04 just as datatypes.library) it would be better to continu development based on Reaction. I wonder if i should and if i could. What will it cover in the end - How were gui's created in the beginning, where does Gadtools come into play, what came after that? I intend to investigate this through examination of the library functions used for a simple gui: a window containing a listview. 1 in pre-BOOPSI days 2 when BOOPSI first appeared 3 with GadTools 4 with tools such as GadToolsBox (generating C-code making direct use of gatools-calls ) 5 with Reaction - What improvements did each step gave us? Obviously coding is made more easy) - Did we lose something? Obviously versatility if we never look back at the more basic libraries. Probably all steps forwards were based on libraries that can be seen as predecessors or competitors which did not succeeded in being integrated in the OS. There may be improvements that were not included yet, or were forgotten about. For Gadtools we'll look more closely to these. What work made Gui4Cli possible? Early Gadtools gui's were still ugly, were not resisable and were fixed-font. Font-sensitive gui's were not the rule. - what are the possibilities of evolution of GadTools - What are the wishes for evolution of Gui4Cli, how well can they be covered with different approaches eg 1 treat variable length records (CVS files) in database listviews 2 declare a number of gadgets as a group and position them relative to a group anchor 3 have a xONRESIZE xONZOOM events

Tags: 

Blog post type: 

Comments

Belxjander's picture

Submitted by Belxjander on

DataTypes debuted with OS release 3 (Kickstart and Workbench 39), and would not function on Kickstart 37 (Release 2.0) or Kickstart 38 (release 2.1), Along with the initial development of GadTools itself being on release 1.3 systems however, to my knowledge it was first shown with Kickstart 2.0 and later having been put into the Kickstart ROM Image with other "core" OS libraries. BOOPSI was also Introduced in Kickstart 37 and later OS releases... ReAction is from the ClassAct BOOPSI gadget suite having been integrated. The above may not be relevant in the release 4 (NG) editions, I don7t know for sure yet. I will have to investigate further... however I suspect later versions of the GadTools library in Release 3 Kickstarts actually started using BOOPSI classes internally. However that is only my own speculation on the matter. MUI was an alternative to "BOOPSI" Class presentation, and includes a mechanism for use of Intuition BOOPSI compliant classes, so use of ReAction is possible within an MUI context... And again to what I can remember there is reference on the Fishmarket disc to MUI having been available around the time of Release 2 Kickstart becoming available on the Fishmarket CD. I do hope I am remembering all this correctly. From the above... there is also the possibly mixed usage of GadTools +BOOPSI using ClassAct/ReAction classes in a mixed UI context... or MUI with embedded BOOPSI, use of the "colorwheel" or "tapedeck" gadgets in MUI as examples for this. I would more offer the theory that each toolkit has a particular style... and it is up to the programmer to find the style and Toolkit which matches what feels right Anyway... would Gui4Cli be able to be changed from GadTools only to adding ReAction class use? how major would those modifications be? for CVS Database storage can you separate this into a module on its own? Have the option of replacing this module with different database options? but definitely grouping gadgets together with a handler as an anchor... along with additional events I see as a good thing. Just be sure that there is no duplication and keep it simple :)