LuxenD wrote:
if we do that, any chance we can also add some kind of clipboard? i get tired of typing some code into one program, and then simply using a program RCL when i need it. saves about 2 seconds of time. or at least make said app expandable, like how DCS is?
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 Smile
KermMartian wrote:
DJ_O wrote:
Aw too bad. I guess in such case that maybe a custom program editor (preferably one that works exactly like the current one, except with some improvements) that can be installed as standalone app might be in order then?
While typing out and viewing tokenized text is doable from ASM programs with the bcalls that we know (at least on the older calculators), one of the sticky wickets I'm aware of is getting into the menus. I'm not sure how an independent editor would handle the many menus and pasting of tokens into such an editor. Then again, the OS doesn't offer many options to hook into text entry, so I don't think we'll be able to modify the behavior of the existing BASIC editor to do what we want either.


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.
KermMartian wrote:
While typing out and viewing tokenized text is doable from ASM programs with the bcalls that we know (at least on the older calculators), one of the sticky wickets I'm aware of is getting into the menus. I'm not sure how an independent editor would handle the many menus and pasting of tokens into such an editor. Then again, the OS doesn't offer many options to hook into text entry, so I don't think we'll be able to modify the behavior of the existing BASIC editor to do what we want either.


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.
calc84maniac wrote:
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.
Sorunome wrote:
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.
Sorunome wrote:
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.
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.
Quote:
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.
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.

Quote:
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.
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.

comicIDIOT wrote:
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.
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?
elfprince13 wrote:
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.
elfprince13 wrote:
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. Smile 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......
Sorunome wrote:
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:
1:46 PM +KermOffc | comic: which is why DCS8 is going to at least offer a built-in non-mouse mode
1:46 PM +KermOffc | And at most make it the default


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:
1:16 PM +KermOffc | Out of curiosity, though, do you fall on the "minimal" or "complete" side of the argument?
1:16 PM benryves  | The CSE is going to break everything so I wouldn't be too hung up on compatibility layers, though.
1:16 PM +KermOffc | Agreed.
1:17 PM Runer112  | I'm on the minimal side
1:17 PM +KermOffc | Runer112: I'm starting to understand the minimal arguments too
1:18 PM benryves  | KermM: Difficult to say, really. Both have very compelling arguments.
1:18 PM +KermOffc | Runer112: did you see my idea about the self-modification to absorb shared libraries?
1:18 PM Runer112  | I did not
1:18 PM +KermOffc | That would save me having to be the one to maintain Hybrid BASIC and Non-Nostub ASM programs
1:18 PM Runer112  | actually I did
1:18 PM +KermOffc | s/programs/libraries/
1:19 PM Runer112  | not sure how I feel about it though
1:20 PM Runer112  | what's wrong with the library existing outside
1:20 PM You have been marked as being away (Be back Later)
1:20 PM +KermOffc | Students get frustrated easily
1:20 PM +KermOffc | They won't realize they need to send external libraries.
1:20 PM benryves  | KermOffc: Would you use the same 3rd party library mechanism for the "standard" library?
1:21 PM +KermOffc | Not to mention concerns about whether they could be wiped out by a RAM Clear.
1:21 PM Runer112  | don't you need to send the library anyways
1:21 PM +KermOffc | benryves: I'm not sure
1:21 PM Runer112  | if you want to absorb it
1:21 PM +KermOffc | Runer112: only the first student would.
1:21 PM +KermOffc | Who presumably was a non-idiot
1:21 PM +KermOffc | I would even consider distributing versions with the latest libraries "pre-absorbed"
1:21 PM Runer112  | hrm
1:22 PM Runer112  | I like it and I don't like it
1:22 PM benryves  | KermOffc: It would certainly encourage you to make the library system robust and flexible, though I understand your concern about sharing programs.
1:22 PM Runer112  | obviously having everything in one variable is nice
1:22 PM Runer112  | on the other hand, it would sort of make it so using anything other than DCS if you have DCS be a waste of space to have two copies of the library
1:23 PM +KermOffc | Isn't that the case anyway?
1:23 PM +KermOffc | I know very few people who actively use multiple shells
1:23 PM Runer112  | well
1:23 PM Runer112  | what if one person uses DCS and the other person uses some other shell
1:24 PM +Jonimus  | I don't think the libraries should be absorbed, unless you do it PC side ala crunchyos
1:24 PM Runer112  | eh I dunno
1:24 PM You are no longer marked as being away
1:25 PM Runer112  | something just bothers me about an app automatically eating my libraries
1:25 PM +KermOffc | Not automatically


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 Smile
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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6 ... 16, 17, 18  Next
» View previous topic :: View next topic  
Page 5 of 18
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement