#16 some feedback

open
nobody
None
5
2007-01-29
2006-12-08
Anonymous
No

- consider adding buttons to output areas to clear areas & copy contents to clipboard
- consider allowing debugger to step back
- consider providing history buffer for undo/redo functionality in editor
- consider allowing output buffers to be saved to a file (i.e. txt & bmp), consider a "recording" mode where this may be done automatically when a program is run
- consider using XML for the docs & reference, so that it can be easily localized by volunteers (who would simply have to copy/translate existing XML files)
- consider allowing users to define new output regions with custom dimensions
- consider providing an optional execution log window which may contain annotated debug messages, i.e. along the lines of "line 21: incrementing variable x by 1", "line 22: jumping back to start of loop in line 5" etc - something like this would preferably be scrollable
- consider allowing to set conditional breakpoints
- consider providing support to draw text at certain coordinates in the graphical view
just my 2c, I think these things would be useful to allow new programmers to actually understand what's happening behind the scenes

Discussion

  • drblast

    drblast - 2006-12-09

    Logged In: YES
    user_id=989631
    Originator: NO

    - consider adding buttons to output areas to clear areas & copy contents to clipboard

    These exist. If you go to the View->Toolbars menu you can activate them.

    - consider allowing debugger to step back
    This is next to impossible to do correctly for an imperative language like Basic256, or would require a ridiculous amount of memory. Basically the state of the interpreter and all variables would have to be saved after each step.

    - consider allowing output buffers to be saved to a file (i.e. txt & bmp), consider a "recording" mode where this may be done automatically when a program is run

    This is also available via the toolbars in View->Toolbars. (minus recording mode)

    - consider using XML for the docs & reference, so that it can be easily localized by volunteers (who would simply have to copy/translate existing XML files)

    Is there some sort of standard XML format for this? I'm not too familiar with translation other than what occurs in the BASIC256 program itself. Any link would be helpful.

    - consider allowing users to define new output regions with custom dimensions

    I'll check into this.

    - consider allowing to set conditional breakpoints

    I'll be adding this to the to-do list. There will be a BREAK command which will put you in debugging mode.

    - consider providing support to draw text at certain coordinates in the graphical view

    This will be added to the to-do list too.

    Thanks for the suggestions!

     
  • Nobody/Anonymous

    Logged In: NO

    >> consider providing support to draw text at certain coordinates in the graphical view
    > This will be added to the to-do list too.

    then some basic support for a "locate" statement for the text view to determine where output from the print statement should be displayed, might also be a good idea?

     
  • drblast

    drblast - 2006-12-10

    Logged In: YES
    user_id=989631
    Originator: NO

    The BASIC-256 documentation is generated by a custom Lisp program which outputs to HTML. It wouldn't be difficult to change that program to output to a qt-linguist compatible XML file, if that's what you're asking.

    I'll look into it. However, it might just be easier to just translate the HTML documentation directly, without having to go through the intermediate conversion steps.

     
  • Nobody/Anonymous

    Logged In: NO

    I think, in the long run, XML-based help/documentation files are probably preferable because they would easily lend themselves to be used together with a more integrated- help/documentation system, where you may for example want to provide features such as syntax completion, context-sensitive tooltips or possibly even a simple dialog-driven wizard GUI where programmers may select kidbasic instructions from a pull-down menu (combo box) and parametrize it then using a corresponding dialog.
    It's this sort of stuff, that may would normally result in unnecessary duplicates and version inconsistencies, because of the challenges involved in maintaining multiple different versions (for different purposes) of basically the same stuff.
    Given that kidbasic is already using QT, and because of QT's excellent XML support, using XML for the integrated docs & help would seem like a natural fit.

    Also, while features such as the aforementioned wizard-gui would seem like overkill for most of us more experienced programmers, there's surely an added benefit for newbies who may not yet be familiar enough with syntax, structure and expected parameters for certain statements.
    Thus, having something like this, would enable new users to immediatley benefit from using kidbasic because they may conveniently interact with the code editor using an interactive wizard that would allow them to parametrize pre-configured templates for basic language-constructs (such as for example print, gosub, return, cos)

     
  • Nobody/Anonymous

    Logged In: NO

    I think, in the long run, XML-based help/documentation files are probably preferable because they would easily lend themselves to be used together with a more integrated- help/documentation system, where you may for example want to provide features such as syntax completion, context-sensitive tooltips or possibly even a simple dialog-driven wizard GUI where programmers may select kidbasic instructions from a pull-down menu (combo box) and parametrize it then using a corresponding dialog.
    It's this sort of stuff, that may would normally result in unnecessary duplicates and version inconsistencies, because of the challenges involved in maintaining multiple different versions (for different purposes) of basically the same stuff.
    Given that kidbasic is already using QT, and because of QT's excellent XML support, using XML for the integrated docs & help would seem like a natural fit.

    Also, while features such as the aforementioned wizard-gui would seem like overkill for most of us more experienced programmers, there's surely an added benefit for newbies who may not yet be familiar enough with syntax, structure and expected parameters for certain statements.
    Thus, having something like this, would enable new users to immediatley benefit from using kidbasic because they may conveniently interact with the code editor using an interactive wizard that would allow them to parametrize pre-configured templates for basic language-constructs (such as for example print, gosub, return, cos)

     
  • drblast

    drblast - 2007-01-29
    • status: open --> open
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks