This feature is present in zStart, among other things.

Also, I don't know if this was discussed before but could there be a mode where DCS would run a program as if the calc was a regular 84+ ? I mean like a backwards-compatibility mode where DCS would interpret the commands in a way that old programs still run in monochrome and on a virtual "96x64" screen ? The mode the program should be runned with could be specified in the program's header

Instead of implementing all the menus, why not make a text->tokenizer with code-completion suggestions? It seems like the most irritating part would be the regex state machine and the radix tree for all tokens, but I bet that could be generated automatically.

Using the OS menus is... not easy, but not *that* hard either. That's what Mon is for. Figuring out how to make all the system edit buffer routines work correctly is a bit more difficult, but if you wanted to write your own program editor, you wouldn't necessarily need to do that.

Actually, as far as OS menus for token selection go, do we know where they store the data for them and if it that data is structured in some fashion that would allow them to be reproduced programmatically inside a DCS gui?

I haven't looked into it in any detail; I don't think there's any API that would let you retrieve the menu data, but it probably wouldn't be too hard to extract it from the OS manually. JMan's documentation of the menu hook would be a good place to start.

I don't think anybody has mentioned this yet, but it would be a very good idea for the program header to indicate a minimum shell version (or rather, perhaps standard API version) in case we want to add more standard routines in the future.

I think that's definitely accurate. The burden of avoiding programs that won't have the proper libraries available should fall to the shell (by detecting the requirements from the header), not the program (from an iVersion-like call).

So, I didn't read everything now, I'll just give my thoughts on it:
I like the idea of 32*32 program images, it would be even cooler if they could be in color.
With the TI basic libs: I definitely think there should be new drawing options for the new calculator, maybe stuff like rectangles, filled and borders in different colors, triangles and maybe a pixl test that also returns the color the pixel is in.
Then also a more broad omnicalc support like the sound command.
Last, it would be awesome if DCS could be made capatible with apps like zStart (as in not clearing other hooks)
And for space, as the 84pcse has so much more new space maybe DCS could get a new app page if space is too much of a limitation.

While I'm no longer in favor of making DCS as few pages as possible, I still deeply insist on using SEs to include ASM & BASIC Libraries. They'd be easier to maintain on such a new calculator as they migt rapidly change the first year or more and DCS8 would have to have a release cycle to match. The TI-84+/83+ was already well established from a programming stand-point that the libraries were not going to be changing at all, let alone often, when DCS6 included them in-app.

I think DCS8 should be flexible and allow users to create and use Libraries as they see fit. And perhaps around DCS9 or 10, we can consolidate the popular libraries into the app itself.

Letting other programmers create libraries would take work away from Kerm and his multitude of projects. But if he wants to create/port libraries then I can't stop him, I just think it'd be time better spent if he did not do so and perhaps implemented a robust SE system or had more time outside of his personal/academic projects.

Even if that would enlarge ASM programs by 512 bytes for 4-bit indexed color or 128 bytes for monochrome? I suppose we need to make the common shell header support a variety of color depths and sizes.
Absolutely, especially since a lot of those features are missing. I'm planning to delegate that to tr1p1ea (and other external library authors) if possible.

Quite possibly. I'm planning to restart a lot of stuff from scratch, so I won't need to pull in the whole old codebase. For example, I'm temporarily tossing out the GUI API.

I very heartily agree with this. I want Doors CS to have a way to "absorb" libraries into itself, though, manage external libraries in such a way that only a single App must be shared among friends. What do you guys think of that? Maybe have a library manager tool that can absorb, eject, and delete external shared libraries?

What's this you say? Real package management with dependency resolution?

No, I would expect all libraries to be self-contained singletons with no external dependencies, even if that means a small amount of replicated code. I don't think there are going to be SO many different libraries created for this to be a problem. I for one don't feel like implementing dependency resolution in all its (NP complete?) glory in z80 ASM.

Oh well. I can dream.

Indeed you can, and I can continue to weigh the value of my coding time against how used and useful a particular feature will be. I think I need to start congealing all of the ideas discussed so far into some sort of bulleted list to spur further refinement, and perhaps frontpage-news it as well.

I just got another good idea:
Add the other features of Omnicalc to DCS, so Parentheses Assistant, Memory protection, Entries Menu, Ram recovery (i think possible with extra RAM), Virtual calc (i think possible with extra RAM), Base Conversion, Thousands Separatores, Quick apps, hiding the finance app, and a custom menu (hitting vars twice)
Another nice idea I have is when hiding the finance app still being able to access it by hitting apps twice.

EDIT: Maybe that stuff could be made into an SE......

I feel like RAM recovery and Virtual Calc are no longer options (and the latter was always buggy anyway), now that the OS uses large portions of extra RAM for graph and image buffers, and I expect a good number of ASM games will also be using the extra RAM to support all these fancy graphics.

I totally remember Omnicalc now. Virtual Calc was insanely cool. Parentheses Assistant & Thousands Seperators were nifty, though I'm sure the assistant will be an optimizers nightmare.


Code:


I think it'd be a great "introduction" to the mouse if the arrow keys on the calc shunted the cursor to each clickable point/section. This would introduce the user to the mouse and they could eventually turn off the mouse and they'd be able to move it around freely. This way they'd at least get familiar with the concept of the mouse; whether they enable free motion or not is on them.


Code:


I think libraries should remain independent. That way they are just drag and drop; On and off the calculator. Including a way for DCS to send files over USB would be amazing, you'd be able to send SEs and lay the groundwork for gCn!

Wow, for a while there this whole discussion turned into why Ion works the way it does and had to do with RAM structure during execution, which is mostly speculative at this point because we don’t know as much as we need to to write a practical shell yet.
Kerm, basic core with the ability to add (hopefully done by you and anybody else who helps write the app) SE’s. I think the simplest (and most friendly to new and old programmers alike) to deal with program making and especially game creation (which takes a lot of libraries or some incredible programming) is to just let people do their own thing, and NOT have to have DCS8 oncalc just to run a program. Maybe in DCS9 you can make it so games can be DCS9 prerequisite compatible. The world needs to start simple, and we need to just explore the thing first. If everything has to be DCS oriented, then it’s not going to be easy for everybody to get their own creative work done their way. PLus, they have to follow YOUR rules and regulations. TI set the standard. Making it more picky and difficult to write programs isn’t helpful. I’m waiting for the official SDK to come out.

No offense from anything I wrote! I imagine it can be taken to be offensive, I’m not against you or DoorsCS, which is my favorite shell

I think building off the concepts of 7 is important. Besides, you can run your programs from the homescreen without running DCS and not 'need' DCS in that instance. The whole point of a shell is to have it add things. If a person doesn't need DCS to run a program, that's called a no-stub asm program.

I'm not sure at all what you were trying to get at, I'm really rather confused at this point.

I’m just saying not to make everything dependent on Doors, but write the darn app because it does add good features and functionality.