Further development of GDL

Home Forums Problems and solutions in GDL Others Further development of GDL

This topic contains 5 replies, has 2 voices, and was last updated by  Heimo Mooslechner 3 years, 7 months ago.

  • Author
    Posts
  • #2021

    Heimo Mooslechner
    Participant

    GDL is one of the most powerfull tool within Archcad. Even now, when Archcad is evolving with the normal tools in very good directions, GDL still is indispensable!!

    For me as user and programmer of GDL – the work of scripting has not changed really much since my first experiences in Arhciad 5.5. The evolvings of GDL are marginal – maybe You see this from an complete diffrent viewpoint…

    What was in my mind since the first tryouts was – to make GDL in a way, that is much more friendly to the programmer than it is now.

    GDL is very complex – and to look for information – it always was tricky – even in this new GDL-Platform here – some things ar hard to find.

    GDL should help the scripter in his work. Now – i as scripter have the impression – GDL hinders me to solve problems – out of many reasons…

    (In other CAD-languages the language helps You as scripter. For example it was possible in Autolisp – 25 Years ago – to find the intersectionpoint of two lines without mathematical knowledge – it just was an command within the language. It was possible to follow other existing drawing-elements in scripting to use their coordinates in the script.)

    It should be no problem to find intersectionpoints of two lines (4 coordintaes) without mathematics in GDL.. You schould be able to find it without the usage of external addons! These and similar things should be implemented direct in the gdl-language.

    An other point for my positiv criticism is, that existing drawing Elements in GDL should be mucheasier to use!

    For example – the “Wallniche” – command – to simply understand is a horror for a GDL learning person. (Most of the Polygon -dependend commands are!)
    Yes – You can do a lot with it – if You understood it but still then, its often a matter of trial an error to get the wanted results. This schould be made much easier.

    Why so difficult? Why not making a Wallhole out of existing 3D-Elements like Prism or Tube or Block – simply declaird as wallhole? Everybody knows how to handle a Block-command. Tell the Block (or other 3D-Elments to be a wallhole, to be SOE-Cutform)! It would be much easier for the scripter. Maybe a Group could be the cutform for wallhole!

    The scripting enviroment is stoneage!

    Where ar the line numbers to be turned off and on?
    Where is script highlighting?
    Where is auto-scripting (typing variablenames automatical)?
    where is bracket-closing-displaying?
    where is implementing additional Images for the User-Interface (Just possible by external editors with converting the GDL to other formats ??? Really ???)

    The tries of some experienced Users to solve this like Jochen Süloh with external Editors just “ships around” this Archicad-omission.

    We really schould thing GDL new!

    Teacher in HTL-Salzburg
    AC5-19, Win and Mac
    GDL hobby developer

  • #2022

    James Murray
    Participant

    Strongly seconded on all points. I would add:

    GDL does not even support everything that is possible in Archicad input. For example, no three point arc. I never dreamed my job would involve so much circle geometry.

    The environment does not even allow you to see large parts of GDL functionality: Cutting, group operations, graphical editing, 3D hotspots, and I’m sure there are others.

    My hope is that this forum is the beginning of a serious recognition of GDL’s importance. The next step is to make the tools and environment less miserable.

  • #2024

    Heimo Mooslechner
    Participant

    GDL definetly should be a mirror to the existing Drawing-enviroment. But besides that – it should give the same amount of editing-possibilitys to the end-userasit does for normal Archicad-Tools as Wall, Slabs ect.

    If i declare a Prism – its basicly a set of coordinates with a functionname. If a User activates this thing – it should be possible to alter the shape of it with the normal drawing enviroment without the usage of editable hotspots. The shape schould react as any other normal shape in Archicad like a slab- with the normal pet-Pal-commands. Such a functionality should be implemented without special commands needet. All the calculation needet for it schould be made by Archicad direct – not with complex GDL-Commands. Such a shape would nott have to be static- it schould be able to grow with new points- all the same as evers other shape in Archicad.

    The User wouldnt have to lern new, how to operate the thing. All used commands should work without GDL-Scripting. It should be implemented in the Shape-commands direct on the maximal simplest way for the scripter.

    You cant imagine the possibilities and the success for Archicad with such a tool.

    Lets think it NEW!

    Teacher in HTL-Salzburg
    AC5-19, Win and Mac
    GDL hobby developer

  • #2061

    Heimo Mooslechner
    Participant

    I wish some additional functions direct in GDL – like a function for finding intersectionpoints without having to calculate them by selfmade graphical calculations and without the need to give it to a much too complex addon like polygonoperations.

    This functions should not need more than one line of coding.

    I want to remind Graphisoft – GDL means “Graphical Dialog Language” and should support graphical questions and calculations with builtin functions like this – most easy for the scripter. Other languages can do similar Things since decades (eg. Auto-Lisp)!

    Teacher in HTL-Salzburg
    AC5-19, Win and Mac
    GDL hobby developer

  • #2073

    Heimo Mooslechner
    Participant

    Editable hotspots:

    It is now possible to assign “names” for the editable value. Thanks for that!
    I suggest to make this names readable for the User just hovering the mouscurser above it.

    Now You have to klick on the hotspot to read what he does.

    I would like to have it readable just hovering above it before klicking. It now displays the name of the Element. If a name for a hotspot is assigned, this should appear by hovering above it additional to the name of the element.

    An other option for this could be a simple hotkey that displays ALL THE NAMES of the Hotspots of the Element by pressing the hotkey. After releasing the hotkey – normal behaviour should occur again.

    Teacher in HTL-Salzburg
    AC5-19, Win and Mac
    GDL hobby developer

  • #2074

    Heimo Mooslechner
    Participant

    In “the general scripting assignments” You write:

    GLOB_VIEW_TYPE = 2 – 2D, floor plan

    The model is displayed in the standard 2D floor plan.
    In a 3D script this means that the model is projected to 2D
    via the project2D command.
    This is the main use of an object – this 2D model must be always correct and efficient.

    If GLOB_FEEDBACK_MODE = 1 then
    the model is displayed via feedback lines on the 2D floor plan during the hotspot editing of the object.
    This model is drawn many times in a single second throughout the user interaction.
    This implies that the model should represent the essential parts of the object only.
    Note, that texts (generated by text2 command)
    are not refreshed in feedback mode – since it would slow down the output.

    So it seems to be possible to make display-refresching faster and simpler by using this.
    Thanks for that!

    What i am missing is the following:

    If the users zooms out – so that the displayd symbol of my GDL gets really small on the screen – it often is not useful any more to be visible and editable. I think it would be a good idea to connect the visibility of these hotspots to a precentage – of its extents compared to the screen. – Automaticly made by Archicad itself or controllable by the Scripter?

    Also an criteria for this could be the nearess of the mousecurser similar to the behaviour of the new blue guidelines in AC19..

    To make this as clear as i can: You should be zooemd in enough and the Mousecurser schould be near enough to display the Hotspot and if the Mouscurser is moved even nearer – it displays the Name of the hotspot..

    Teacher in HTL-Salzburg
    AC5-19, Win and Mac
    GDL hobby developer

You must be logged in to reply to this topic.