Agreed. Math looks great so far, except for the rounding, as you pointed out. What's GMP?

EDIT: Nvm, I lmgtfy'd myself

Nice job, not everyone would use that good netiquette (whoa, Firefox knows that's a word!). AHelper, why GMP instead of a slightly lighter-weight solution such as BCD?

First, thanks for the attention. I agree that the answers should be separated, but realize that this is a simple list widget (generic). I could add in another mode just for gCAS2, but that could be ugly... I must point out that using the list widget without icons should be a small font.

I could make question and answer icons... But I can always use the small font and just add in about 3 spaces in-front of answers.

And with GMP, that's all I could find. Have a better idea, you tell me! I am not experienced with anything like that. If you have a suggestion for a C library that is made to be small/embedded, post post post and I will port port port </ x3>

Perhaps you can add functionality to the list widget that gives you the ability to right align items inside? Or you could display "2+2=4" where the user entered the "2+2" and you appended the "=4".

Right-aligning isn't that easy mainly because I would have to handle many things on scrolling and adjusting the starting position of drawing the text. If the string is longer than the screen, it wouldn't make a difference - it would still start at the left.

I think that adding in special icons will work...

You should have a routine to measure the physical size of a string, and you could just do [X location of widget] +[Width of widget]-[Width of text] to figure out the new starting position.

For big text, no routine is needed. The font is the same size. It's just that a string like x^2-2*y*x+y^2 will not fit. Sure, I can right-align, but it will often be overridden.

I'm a bit concerned that the lack of right-alignment here means that GUI in general cannot be right aligned, or aligned at all with GlassOS. If that is the case, it might be worth looking into adding more to the layout engine.

(If nobody noticed that I am looking at the Qt docs when making this) I will add in a textAlignment (more time to draw, uglier code, etc.). See Qt::AlignmentFlag

I'm a fan of the idea of a single character at the beginning of lines of text that are answers (or questions, I suppose, either one); perhaps something like a filled arrow? Or whatever you think is best, as you're the author and designer.

filled in square, hollow square was the idea, but SirC does have a point... alignment will be useful in a larger scope.

Here are some symbol ideas for you:

Feel free to use them as you like. I still prefer the idea of using the other side of the screen, though. Also, do you have it set up for scroll-back, so you can recall previous questions/answers?

It will. I will need to mod the GUI_TextBox_Do() code to allow pasting of text.

I will try out your icons when I get that part of the renderer made. (Not hard, just takes a bit of time) I will post images for feedback once I do.

Sounds pretty good, but I'm wondering how you'll do copy/paste. The KnightOS model for a global clipboard is that three bytes of RAM are dedicated to clipboard use: a data type ID byte, and a pointer to the data. For text, you'd assign it an ID byte (such as 0x01), and when you copy some text, set the clipboard type to text and point the address to the newly allocated memory for the text. Once a new value is copied to the clipboard, you could free the memory storing the copied text.
I think this method would work pretty well with GlassOS, considering it works globally and can work for several kinds of data, so it can be extended to pictures and rich text and all kinds of other things.
Another suggestion is to add keyboard shortcuts, based on ON-key combinations, so ON+C would be copy, ON+V would be paste, and so on.

I'd say use the 89 style clipboard, and maybe even the same key combo's, it works pretty well there. And SirCmpwns idea for how to store it seems rather sane, maybe a temp file in the FS for storage would do.

The idea of a temporary file scares me - the filesystem is in ROM, so even with the idea of flash chip wear aside, that would drastically reduce the time between garbage collections (defragmentations? Not sure what GlassOS calls it). In addition, the whole process of writing the file to flash would be a lot slower as well. A clipboard most definitely belongs in RAM.

I assumed he would have a ramfs or at least write caching so that the issue of fs wear is limited for temp things that may or may need be needed soon.

From my current understanding of GlassOS, he does not.

In that case I vote it be a virtual file system that maps to system things, for instance /sys/clipboard would be the current string in the clipboard and /sys/apps may list all the apps running etc. Either way having it be a file a program can just read or write two would make things much easier than using a clipboard specific api. Not to mention a sysfs like interface would be useful for quite a few other things.

A quick note...

I haven't put any work into a clipboard other than "It Shall Be Done". I see where SirC is going. I think that dedicating a 3-byte struct...

Code:


Now, please remember that GlassOS always has 2 heaps, one local, and one global. The global RAM isn't big, but it can surely hold clipboard data. malloc_shared() will do that.

And yes, the entire FS is ROM-based simply because I don't have the same needs as TIOS. It uses a large part of it to store variables, lists, matrices, small programs, etc. GlassOS isn't a calculating OS - It leaves that to programs, which is partially why the heap for each process is huge. I know, a RAM fs might help, but think first that some calc's don't have the extra RAM. That's wouldn't help too much. Now, I wouldn't have an issue with making a ramdisk feature that will let you mark extra RAM as temporary FS space. It would simply go under /mount/ramdisk and all fopen, fputs, readdir, etc. will work in the ramdisk as if it were the flash...

But I don't want to get on that simply because there would be calcs without that option... Don't forget about plans for /mount/linky (or /mount/usb)... It would at least be persistent and wouldn't kill the flash chip