[ ] Correct battery meter for the 84 series (--/--/--)
[=] Deleting programs sometimes causes system instability (07/28/06)
[=] Deleting folders - subfolders not moved to parent (07/28/06)
[=] If you click on a folder to go into it, then rightclick to rename, you can rename the folder (07/27/06)
[=] Unable to lock or archive folders (07/27/06) this is intentional. see above for rename fix.
[=] Execution of BASIC programs causes homescreen lockup (07/27/06)

Umm...thats not a bug, thats the expected behavior (if you delete a folder on any computer OS it will also delete the subfolders)

But it doesn't delete the subfolders - you just have no way of getting to the files still in the subfolders. I should either make it delete everything below or nothing, not put them in some kind of limbo.

Delete recursively would be the expected behavior....

Yeah, but I'd rather not have a bunch of n00bs telling me "Zomg your shell borked my prgms, lol bbq. j00 are teh ghey". I'll make it move everything to the parents as I intended.

right, but you could get complaints the other way. But you do have a point Kerm, think of MOS folders.

Definitely. I think I'll go with the method I intended but which apparently has gotten broken in between.

Just have a box pop up saying "Warning: All files and subfolders in <folder name here> will be deleted! Are you sure?". Then if the n00bs complaign, call em dumbasses

Moving folders to the parent is incredibly counter-intuitive. Or, you could go with the linux rm type and not delete the folder if it has subfolders UNLESS -r (recursive) is specified....

[=] Execution of BASIC programs causes homescreen lockup (07/27/06)

Or it could simply not delete folders if there are any files in those folders...


So you managed to get the basic bug fixed??

Indeed.
Meh, lemme see if I can get it to work the way I originally intended. I see that the deletion routine is indeed buggy and crqashy.

*bump*
[=] If you click on a folder to go into it, then rightclick to rename, you can rename the folder (07/27/06)
[=] Unable to lock or archive folders (07/27/06) this is intentional. see above for rename fix.

*bump*
[=] Deleting programs sometimes causes system instability (07/28/06)
[=] Deleting folders - subfolders not moved to parent (07/28/06)

No active bugs at this time!

Hurrah!

New bug to add:

[ ] Correct battery meter for the 84 series (--/--/--)

1) with a message box, confirm the delete
2) have an option panel. one of the options should allow the user to choose whether they want recursive deletion. on a related note, make sure you can cut and paste folders. you probably dont want to be able to copy folders or programs.
3)only show basic programs that are mos/dcs compatible, and have an option to convert unknown program types into dcs basic (just insert a header. you could even add in an icon editor).

1. Good idea, I'll do that when I finish the GUIStack
2. Already in the works. It's going to be a DCSMenu item
3. Meh, I think I'll continue to show all for now. I like the idea of a "convert to DCS" rightclick option for TI-OS basic progs though.

[quote="KermMartian[=] Unable to lock or archive folders (07/27/06) this is intentional. see above for rename fix.
[/quote]
I can still do this. Also, the name of the folder screws up.
IE: A folder named Libraries unarchived is named to what looks like a heart then an i when archived.

Edit:Also when I go to copy a file to a folder I can't get out of the folder and if I go down in the folder, the names get currupted. IF i quit and reopen, it works though.

You can still lock and archive folders? Are you using the latest beta?

Well, playing around with the private update, I set the contrast to max, and went to play around with the other options, when it crashed. I got back on there, played around with more options, tried to use the shutdown function (Yeah, I know, it doesnt work) and it crashed again.

I was wondering if it isn't keeping track of memory too good or is losing track of the stack when moving around in the opitions?? That is the only thing I could think of...