LoginLogin
Nintendo shutting down 3DS + Wii U online services, see our post

Alternate Program Editor (DEMO)

Root / Submissions / [.]

MZ952Created:
Version:DemonstrationSize:
Load the PRG "FORMAT2" into slot 2 for this to work, sorry forgot to add this. Also, you must have some code in Slot 1 (you can load boguscode into it) so that it doesnt try to manipulate code that doesnt exist. Program currently undergoing major revision, expect the Beta in a couple weeks. Current date: 4/11/16 As the program is in its early production phases, the amount of usable features is limited. However, there are many planned features i will list and by releasing this demo and getting the feel of my program, i hope that some may contribute some ideas they wish to see in it. The idea behind this is to create a full fledged replacement for the original code editor SmileBASIC uses. This is challenging enough, due to all the features present in the original. I am ultimately coding this for myself to use, so it has got to be better than the original. Here are the features and aspects: Alternate minimalistic keyboard, with features necessary for programming. Viewing code on dual screens Touch screen functionality for purposes such as highlighting code, drag and drop, scoll, on screen utilities other than keyboard, et cetera Onscreen calculator for swift, painless number crunching Onscreen note taking (apart from code), can be typed or hand drawn (schematic purposes). A never before seen form of syntax highlighting which can denote loops and conditional statements. Can type code in all RGB colors and Multiple Text Sizes. A toolbar expandable on the lower screen which you can access all the sub-applications like notes, TXT viewer and so on Smart cursor movement Compacting code into labeled folders which can be expandable and manipulated (organization purposes). A command index similar to the one on the default keyboard for speedy typing Select, Cut, Copy and Paste (a necessity). A terminal for executing some code (will most likely run the code you type in a different slot, then return to the main program) An intuitive way for finding that RGB color you want (like a color wheel), most likely a sub-program on the toolbar. Double viewing screen mode (removes keyboard completely, viewing code on two screens), probably mapped to R button or something. A separate double viewing mode where you see even more code on the bottom screen, but are equipped with a smaller keyboard. Unlimited code slots Viewer for graphical images A copy and paste clipboard, for copying and pasting more than a single element of code. Those are my ideas this far. Now, if you avid coders have any suggestions, i'm completely open to them. I'm sure you have a few things you'd change about the smilebasic code editor if you could. A few of you may be concerned about the program running into errors and you losing the portion of code you've worked on. Another feature i plan is an autosave feature, which will slowly export code to a program slot and being imperceptible to the user (when exporting massive amounts of code from the editor, a tremendous delay is caused as the loop runs). I will also map the total export feature to a button or button combination for ease. My program uses line wrapping, each line may be only 40 characters long. You can easily import a program you're working on by loading it into slot 1 and running my program (which should be in slot 0) My program has a simple (but not for very long) form of metadata it uses for things like colors and text size, it is loaded into slot 2. Because my program uses the print function, trying to avoid printing bugs when printing CHR$(10) can be tricky, so, when you import the code into the editor, all instances of CHR$(10) are removed, as well as the text being wrapped 40 characters long. The ENTER character is replaced with CHR$(294), which, in the code editor, functions the same as the enter key. It basically tells the exporting algorithm where to break to the next line of code when un-wrapping the code. My point: make sure you don't have CHR$(294) in your program (its not a commonly used character). Conventional syntax highlighting, as you know it, is most likely not going to be fully implemented. Possibly to an extent, but nothing like the original. You can type text in different sizes and all RGB colors, though it should be known that overuse of this feature does cause graphical artifacts on the console. It may look weird, but no erroring. As of now, i have not completed the keyboard, it only types the letter A (as a debugging test) EDITS: The top screen and the bottom screen will soon act as totally separate, editable screens. You can toggle the two screens using the R button. It will basically allow you to be at two places inside the code at a time. New graphics engine, eliminating most if not all graphical artifacts. Planning more complicated touch capabilities for editing code. Keyboard completed, missing characters will be added to the accessible tool bar. Sound effects added. X Deletes lines A Enters a line B Backspaces in the current line Y Exports (does not work/will error) Stick for fast movement Many improvements for typing text. I cannot stress enough how this application uses line wrapping, to end a line and begin a new one, you must have the CHR$(294) at the end of it, which is provided on the keyboard. If you, for example, type an entire program without any of these characters, your entire program will be exported as a single line of code. Also note that the cursor edits the characters behind it, not the character it seems to be on. In the beta version, the tool bar will be loaded with its minor applications, and a rough version of syntax highlighting should be usable, as well as functional exporting.

ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
Automatic indentation is a good idea, i can incorporate it when i begin syntax highlighting, though it may be tricky, as a line of code can only be 40 characters long onscreen, until exported. Good idea nevertheless. I'm uncertain what you mean behind configurable highlighting schemes. If lowerdash or C are compilers, they should be able to compile exported code into legal SB code. I think you are saying have my program use a syntax highlighting for other programming languages. If so, that may not be possible, this is centered around the SmileBASIC language. Maybe in the far future i can allow syntax highlighting plugins that users themselves can easily write. thats far though. Can you elaborate on "export minified"?

Syntax highlighting it relatively simple compared to some of the other things you're doing just remember that things like BGMPLAY 1ACLS are valid (I would recommend making a list of characters that ARE allowed before and after each type of command) for example, before functions (purple by default), there can be numbers, parenthesis, etc, and after can be -, and some others; you'll need to do some testing.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
that means removing extra spaces and line breaks, and shortening variable names, I think. You might want to look at my automatic indenter. it's not PERFECT, but it's very good at detecting commands (could also be reused for syntax highlighting)

Replying to:12Me21
Syntax highlighting it relatively simple compared to some of the other things you're doing just remember that things like BGMPLAY 1ACLS are valid (I would recommend making a list of characters that ARE allowed before and after each type of command) for example, before functions (purple by default), there can be numbers, parenthesis, etc, and after can be -, and some others; you'll need to do some testing.
i experimented with highlighting before. ive found that scanning all the text it displays on the screen and matching everything to its corresponding highlight causes runtime delays. lag. I've further tested an idea where i have a rendering algorithm find all the syntax highlighted stuff in the chunk of imported code, and keep tabs on them (their Y coordinates) as the code gets altered, though it is prone to its bugs. The upside to it is that it only has to track if new at the cursor position syntax has been typed or old syntax has been erased.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
Removing extra spaces and linebreaks. My code originally did this and i removed the feature.. Haha. well, i can do this, yeah. Might create some kind of settings page for all this crap, to toggle on/off.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
removal of spacing characters and comments, variable shortening. Anything to make the program as small as possible without really changing the actual instructions. Also, while Lowerdash can compile into SB code, the point is that you want to write it in non-SB. The trouble is that the NORMAL editor doesn't recognize languages other than SmileBASIC, so when writing for those others you don't get syntax highlighting. Since you have this editor, it makes sense to make up for that. I think it was LEX that was of particular interest for language syntax work.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
Ah, i see. Should these different syntax highlightings be similar in manner to SB's (Highlighting particular commands or phrases), i think it can be accomplished. Since i see the demand for Syntax Highlighting, i guess i should consider implementing it fully. Maybe, the user can write DATA at a specific label to define which commands to highlight and what colors to highlight them in. What i'm really focusing on is my idea of syntax highlighting, which would help the user better see the flow of their code on the graphic interface. (edit): As my program isn't quite built around changing individual character's colors, how would you feel if the syntax highlighting took place on the graphic screen by drawing a filled box behind the command with whatever color it does? Otherwise, i would need to revise GREATLY my text drawing system, and i could not guarantee an artifact-less presentation while using it. SB doesn't seem to handle loads of graphics being erased and redrawn frequently well.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
I'll do you one better: Do the back-highlighting, but then make an inverted font so it just shows through. That'd be fast.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
Has someone already made an inverted font? That seems like a lot of work.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
Wouldn't an inverted font be just f(x)=~x ? Doesn't seem to be any trouble.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
uh no, unfortunately its not a concern of an inverted equation. It's a concern of literally designing an inverted font. (Your normal font has solid pixels making up the character, while this inverted font has solid pixels filling the space around the character, leaving a 'hollow' version of the character inside). Get it?

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
I'm not sure I see the problem Even though the default font isn't great, it's still readable doing this. You could do the same to any font, it doesn't have to be "designed" for this.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
What is that? I'm afraid i do not know much of anything about fonts. the only way i know how to create a font is to use FONTDEF and manually type in the font code.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
I changed the transparency to white and the white characters to transparent, then put color beneath it. I think the problem is that you're forgetting that the font sheet is a GRP just like everything else. http://smilebasic.com/en/reference/#file Go through and filter it like you would any other image, then load it into GRPF.

Replying to:Yolkai
ooooo OOOOOOOO Looks like you've got a pretty big list of plans already, but here are some thoughts:
  • -Configurable highlighting schemes -- Such that if I want to write Lowerdash or, heck, even C in this, I can and still be able to see.
  • -Automatic indentation
  • -Do um. Do something about those fonts, please.
  • -Consider making it a Smiletool. Then you can both access all the files they might want and also not waste slots.
  • -An "export minified" feature, to save a few bytes for upload.
Or you could just COLOR 0,#TWHITE

Whenever I tap the touch screen it types "A". Edit: Oops, should have read the description.

Replying to:blizord
Whenever I tap the touch screen it types "A". Edit: Oops, should have read the description.
Haha yeah, ive got a functioning keyboard and i'm updating the demo shortly.

I like the concept.

I like it!