OK, then with a minimal core, here's the minimum I'd want, I think:
- The Doors CS desktop in some form, useable by at least arrow keys and maybe a mouse cursor too.
- All the header stuff we've been talking about here and in the 84CC, including description, icon, and other things
- The HomeRun hook
- Ability to run BASIC and ASM programs (I guess "standard" and nostub ASM programs)
- Some hybrid libraries for BASIC programmers
- Some libraries for ASM programmers
- CALCnet
- A form of the DCS GUI

I don't think it's worthwhile to completely depart from our previous set of libraries, personally.
Tari wrote:
I'd agree that a minimal core is one of the best things you could do, though that's not to say you shouldn't include a set of libraries as standard.

If we're in a position to discard many existing conventions, I think it makes sense to effectively specify a way in which shells act like dynamic linkers, allowing the programmer to specify a set of shared libraries to link against.

The biggest problem here is that there may be a non-negligible amount of library call overhead, since library code is not feasibly relocatable in most cases (and disallowing relocation automatically makes some sets of libraries mutually exclusive). Thus we need to place trampolines somewhere in memory, or have a single entry point that takes a parameter identifying the function to call (just like bcalls do).

I basically came in to say this.
KermMartian wrote:
OK, then with a minimal core, here's the minimum I'd want, I think:
- The Doors CS desktop in some form, useable by at least arrow keys and maybe a mouse cursor too.
- All the header stuff we've been talking about here and in the 84CC, including description, icon, and other things
- The HomeRun hook
- Ability to run BASIC and ASM programs (I guess "standard" and nostub ASM programs)
- Some hybrid libraries for BASIC programmers
- Some libraries for ASM programmers
- CALCnet
- A form of the DCS GUI

I don't think it's worthwhile to completely depart from our previous set of libraries, personally.


I personally say to worry about making DCS work without any library support, beyond the whole windowing and such that DCS will need for itself. Then once it can run programs, we could start up 2 topics that we can compile lists for BASIC and ASM programmers so they can suggest library like things.

And at that point, based on what's said, you can further determine if SE's are the way to go with that system or not.

I don't mean to keep poking in that direction, it's just.. I've seen how many people that have complained about the size, just keep offering the suggestion so people can't say that anymore, and it gives programmers the ability to say 'This game requires DCS8 to run, due to libraries included in this game' and it will be libraries not found anywhere else. That's all I'm getting at.

Wish I were knowledgeable about z80 asm to assist even starting on this massive project.
ya know, ive been wondering. those complaints about DCS being too big...with the expanded Flash in the 84C, wouldnt this be taken care of? personally, I wouldnt care if DCS took 6 pages in the color.
I wouldn't care if DCS took 6 pages on my Ti84+. Really. I think that you need to wait and take a look at the new/revised libraries for this thing before making a decision.
A nice USB MSD driver is still always a nice thing to add to a calculator! Wink
Well, that's the thing: we have the coders like IkariTari, Elfprince, DrDnar, tr1p1ea, comicIDIOT, tifreak8x, Compynerd, and others in one camp with their insistence on a minimal, expandable shell, with more of the target users (Luxen and Dapiano) in the other camp clamoring for features over sleekness. I'm torn.

By the way, as requested by Adriweb, some mockups of a 3x4 and 4x4 Doors CS 8 desktop:

in case you didnt know, i would rather an expandable shell. expansions sounded like a great idea to me, but i dont see why a small shell would be feasable with so much bloody flash availible to us to exploit. but dont get torn up about it, kern. expandable is better than solid. look at the history of windows, for an example.

and, i think that those are nice, even if they are mocks. i actually think that the bar is nice here, if you make DCS able to modify the bar---

any chance that TI made the bar modifyable? like through a hook? just an idea i had...
How about upgradable and configurable applications. This way, you can write your sleek little shell, that has the ability to basically hook up some interchangeable parts in case somebody wants some extra features, but make Doors CS the main core. Utility apps, games, useless novelties.. If you start with a main core like MirageOS, and set up the community to write applications that work with and are based off of Doors CS as the foundation, you'll get your popularity, and we'll all be happy with people of all kinds writing all the amazing apps and porting the old ones to the new calc.
KermMartian wrote:
Well, that's the thing: we have the coders like IkariTari, Elfprince, DrDnar, tr1p1ea, comicIDIOT, tifreak8x, Compynerd, and others in one camp with their insistence on a minimal, expandable shell, with more of the target users (Luxen and Dapiano) in the other camp clamoring for features over sleekness. I'm torn.


Ultimately, you will go with what makes the majority happy overall, once more people get to offer their opinions. I'm just thinking with our way, you'll get both, because people can more easily just tack on functionability and features, and actually use the SEs like you had intended for programmers to do ages ago. Smile

But, we shall see what other people have to say on the subject. Maybe it's time to make a poll thread, see about getting people's input?
exactly like how tifreak8x put it. i was giving ideas, but I never meant for you to think i was saying use all of them!
Oh yeah, also digging those screenshots, by the way. Do we know if we can remove that upper tool bar, yet?
LuxenD wrote:
exactly like how tifreak8x put it. i was giving ideas, but I never meant for you to think i was saying use all of them!
Don't worry, I'll hold my own council in the end, but it's important to me to please as many of the users in the target audience as possible. I need to balance what users will want with what programmers writing DCS8-compatible programs will want.

tifreak8x wrote:
Oh yeah, also digging those screenshots, by the way. Do we know if we can remove that upper tool bar, yet?
Since we can talk directly to the screen, we can put whatever we want on the screen, it turns out. Check out my PCSEBall demo that I released today, which is as far as I know the first community program to display directly to the LCD.
well, wasnt the purpose of SEs to be that if someone needed something from DCS8, that they could easily make/get an SE? to EXPAND on the SHELL?
LuxenD wrote:
well, wasnt the purpose of SEs to be that if someone needed something from DCS8, that they could easily make/get an SE? to EXPAND on the SHELL?
The original purpose of an SE was very limited, to add things like USB mouse support, locking, or a clock inside Doors CS. I'm thinking that DCS8 might need something that is a cross between SEs and what I used to call "Appended Library Extensions" (ALEs). Modern C programmers would call them Shared Libraries.
ooh, thanks for reminding me about the clock! since all calcs 84C will have a clock in it, do you think it may be feasible to refresh the clock on a ram clear? like, anytime you use DCS8 with a date that isnt default, that it is saved in the archived appvar, and pulled out when the calc resets and DCS is run again? this is more a personal thing i wished for, but i dont know how many people actually use the clock, too...
LuxenD wrote:
ooh, thanks for reminding me about the clock! since all calcs 84C will have a clock in it, do you think it may be feasible to refresh the clock on a ram clear? like, anytime you use DCS8 with a date that isnt default, that it is saved in the archived appvar, and pulled out when the calc resets and DCS is run again? this is more a personal thing i wished for, but i dont know how many people actually use the clock, too...
You could save the clock, but you have no way of knowing how long it has been since you saved it. I would think that a feature like that would be more frustrating than helpful.
[quote="KermMartian"]
comicIDIOT wrote:
Quote:
If someone wants a lightweight shell, they have it. If they don't then they can download Shell Expansions for DCS.
Doors CS has always been aimed at users who want a lot of features and worry less about weight, but that's not to say it's not a change of attitude that I'm willing to reconsider.


I think it'd be a positive change. DCS is the only "heavyweight" contender in the WWE of Calculator Shells.


Code:
February 20th, 2013 (Pacific, UTC -8)
1:44 PM +KermM I suspect Axe and the TI-84+CSE aren't going to play that well together.
1:44 PM @saxjax (C) [SuperMonkey] z
1:44 PM +KermM Well, let me qualify that.
1:44 PM +KermM Axe in its current form won't play well with the 84+CSE
1:44 PM +KermM I don't doubt that Runer112 will be able to adapt it to the new LCD paradigm
1:44 PM +KermM SuperMonkey, z to you too
1:44 PM @saxjax (C) [Art_of_camelot] I'd probably play with Lua, and I'd be learning C.
1:44 PM DrDnar_ Axe will need to be forked, or have a crapload of #ifdefs.
1:45 PM DrDnar_ An entirely new graphics API will be needed.
1:45 PM DrDnar_ Which is strangely a lot like assembly and BASIC.
1:45 PM @saxjax (C) [Art_of_camelot] Yea, I'm not sure if Axe will even be ported tbh.


It'd be awesome that if Axe is ported, that DCS8 could offer support by updating a respective SE - or even adding an SE with the library commands and header info.

I realise that letting other developers add support for future libraries or languages to DCS8 may be a bit hard but people tend to move away from things that are slow to adopt new (popular) features; with all the time you don't have, it might be in the shells best interest to support a wide range of SEs or at least code libraries.

If there happens to be a TI-83+C with significantly less App Pages than the 84+CSE, users may once again be clamoring for the shell with the smallest foot print.

I'm starting to reiterate the points I've already made though with different words and examples. I will come off as a bit hypocritical here but I really love modular designs (and an active plugin, add-on community) in software. I'll try my best to advocate less for these features now Razz

Quote:
Quote:
The amount of things that can be altered and amended through an SE is up to you, of course.
You == me or you == programmers?


You == Me (Kerm).

Do you want to open up the GUI to be modded by an SE or leave the GUI untouchable. Etc.
KermMartian wrote:
Well, that's the thing: we have the coders like IkariTari, Elfprince, DrDnar, tr1p1ea, comicIDIOT, tifreak8x, Compynerd, and others in one camp with their insistence on a minimal, expandable shell, with more of the target users (Luxen and Dapiano) in the other camp clamoring for features over sleekness. I'm torn.

I'm not against providing a large set of features, but the core specification should be designed such that alternative pieces of software with fewer features could be used in lieu of DCS, provided client programs didn't depend on any DCS-specific features.
Basically I want to ensure the sort of backwards compatibility we already have in shells can be replicated in reverse order, since many programs don't require the rich set of libraries that DCS provides.
Oh, heartily agreed, which is why I like the idea of a more descriptive header that talks more about the features that the particular program does and does not need to function.
The one thing I've been wishing for years that 83+ shells had done in the first place: start programs at userMem+2, not userMem-2!

Do Venus-style relocation (forget about trying to keep compatibility with crazy programs like Ion), and make it safe for programs to use GetKey, and APD, and look themselves up in the VAT, and resize themselves, and use any other system routines they like. Smile

Relatedly, it would also be nice for the shell to provide an easy way for programs to register their own putaway handlers (MirageOS does this, sort of, but it should be properly integrated with the OS's putaway system so that 2nd+Off and silent link DTRT.)

Also, provide a way for programs to declare explicitly, at run-time, whether they should be written back to archive upon exiting.
  
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 ... 16, 17, 18  Next
» View previous topic :: View next topic  
Page 3 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