Notepad

[Brett_val]

Originally Posted by nikc4

Maybe the player itself can read it, but the lua interpreter can't.

Good point. That could explain it. But if that's the case, we'll never see every character displayed in a LUA notetaking app...

I heard there is a nosy journalist going through our apps, so I thought I'd hurry a bit with my updates.
No, seriously, I really love your initiative 3vil7ree! I think it's great what you are doing for the X-Fi2 community, and it also stimulates me a bit to get the work done

So, I have a new update!

First thing you will notice is that the images have changed. Thanks to Habhome´s knowledge and advice I spend some time Gimp'in and I've finally created my own images . (okay there are three images left.. I´ll create them myself later. It´s just that I´ve been working all day on this update and I wanted to upload what I have thusfar.)

I've revised almost the whole code, especially the main loop got a total makeover. Besides some possible improvents I think it's now also better readable for others, since this time I didn't care about the amount of lines the main.lua would get . Which is also because I learned that the size of the main.lua file only influences the startup speed of the app, and not the speed while it's running.. (which I also have to thank Habhome for)

The sms keyboard is still not really looking how I want it to be, but at least it's more functional now. I added the shift functionality, and you can now also do enters with it.
It's now also possible to place the cursor somewhere in smsmode by tapping (I think the code revising/cleanup did wonders, because before I got weird errors with this (like I posted before)).

I have to apologize for the bad wordwrapping I did before.. there were some really unnecessary bugs in it. The wordwrapping is much better now, and if anyone still finds some bugs, please discribe them carefully and I´ll look into it.

I added an option: "new file" in main menu. While using the app I found that this was necessary.

New feature: Copy-paste can be accessed when you hold the screen above the keyboard, and also only when the keyboard is shown.
After the keys have disappeared, you can select text by moving your finger from RIGHT to LEFT. The selected text will be highlighted, and then you can click on "copy" or "cut". To paste the text, place the cursor somewhere and hold the screen at the same place, and then tap "paste".
For now, it´s only possible to select text from right to left, and also one line at a time.. I want to make it possible to select multiple lines, but I have to think about that some more.. again, it's just that I wanted to upload what I have thusfar, and I'm hoping to make this copy paste functionality a lot more user friendly later on.

[CrowdAds]

[Habhome]

I have to say that this is amazing. I perceive the app as much smoother now, and the menu is looking much better.
I agree that the SMS keyboard need some graphical improvements, it doesn't really fit into the X-Fi2 design which the other keys do.
Unfortunately it's too late right now for me to do any extensive testing to try and catch those pesky bugs, but I'll play around with it tomorrow if I get time.
One thing which I've seen in all your versions so far is that when you change the settings of colors it isn't really changed until you exit the entire menu structure. It's a minor thing, but it'd provide a greater preview of at least the key colors.

And I'm glad to see you appreciate my advice, I just try to share what little I do know, I am still in training myself. So don't take my word for precisely everything I say, but I'm usually right =P

[RobertsAccount]

I too agree with Habhome about how the SMS style keyboard doesn't fit into the X-Fi2 design, but this app just keeps getting better and better! Keep up the fantastic work!

[Habhome]

Bugtesting time!

I did some bug testing on this by simply writing the bug report with the application itself, and adding some gibberish writing to actually find something to comment about ofc =P. Unfortunately it's not very well formatted in the saved .txt, though I'll test and see how it looks if I paste it into here:

(The many empty lines are left as is due to it being a bug I mention)

New line and automatic capital letters seems
to be working, and so does the word wrapping.
I could write a story with this application, not that
I really care much for writing my own stories.
Though it could begin with the usual "once upon
a time", and then continue with the usual knight
who's supposed to rescue a kidnapped princess.

Notes of bugs:
1; Line 7(from the top, even if you've scrolled
down), if you type on it you can't move the cursor


<--Bug #4, inserted the (text) and it did this after view switch






inside it by tapping until you've saved the file. If
you then add a character you can't tap once
again.

2; With automatic formatting activated if you
delete the period for example it still keeps the
keys as capital. suggestion is to let the game <--Bug #3, should've been empty line between
draw the letters also on the SMS keyboard so
they change with capitalization

3; wordwrapping done while typing in portrait
view is not recalculated for horisontal mode
automatically, and neither does it rememer the
new lines you've added so everything is on the
same line after switching to horisontal. If you
switch to portrait <--Bug #3, was unwrapped and then got wrapped
again then it wraps the words but the new lines
are gone. Also after going from portrait to
horisontal and you continue writing it won't wrap
words on that line until you press enter and make
a new line. but after hiding the keyboard it
rewraps, but still seems to skip the line.

4; after making an insert in some existing text as
such that it wrapped the text and happened to
make a blank line and deleting the line it adds
several lines to that place after switching to sms
mode and write and then switch back.

/bug report written in the application by
Habhome

[Brett_val]

Glad you like it! Thanks for the compliments

Originally Posted by Habhome

One thing which I've seen in all your versions so far is that when you change the settings of colors it isn't really changed until you exit the entire menu structure. It's a minor thing, but it'd provide a greater preview of at least the key colors.

Yeah you're right, I kinda forgot about that every time. It's an easy fix though. I'm also working on the smskeyboard, so I'll update that alltogether when it's done.

I already found some "known issues" myself:
The cursor is not always at the place you're actually typing.
And also tapping the screen to write the letter in smsmode interferes with the placing of the cursor..
I'm working on those

EDIT:

Originally Posted by Habhome

Bugtesting time!

Thank you very much for such an extensive testing! Although I couldn't fix everything (I've been working on it for a few hours today) I'll keep the unfixed issues in a "todo-list"

1; I wrote the exact same text you wrote (cool story by the way, you should write fairytales ) and I noticed it too.
Thing is, when special keyboard is shown, the area where you can cursortap is smaller, so I thought of doing just if y<spd then cursortap, and have the value of "spd" change when you toggle special/normal keys. So after pondering a while it came to me that this spd is not changed when special keyboard is automatically turned back to normal keyboard by type assistance. So that's it! Fixed (at least, if

If you then add a character you can't tap once again.

by "character", you mean a special one that causes the automatic normal keys.. ) But I'm pretty sure this was the cause.

2;I added something to the backspace function to take the temporary caps down when you have deleted a period, question mark or exclamation mark, and if that was the last one; so in case you have typed multiple periods or question marks and you want to delete one, the autocaps is still there.

Now I'm wondering, is it allowed to start with a capital after a number of periods? Like this... This "T" shouldn't be a capital, or should it? Right now the app writes a capital in this situation, but I suspect that it's better if it doesn't do that. Because... this "t" looks better to me. I'm not sure, what do you think?

Letters are now drawn on the smskeyboard by the app, which is also easier for me and it displays caps when needed.

3;I don't think you would want the wordwrapping done while in portrait view to also appear in normal view, because then you would still have the shorter sentences from the portraitview? But I see the point with the new lines not being remembered. That's something I have to think about some more..

I don't really understand this one:

Also after going from portrait to horisontal and you continue writing it won't wrap words on that line until you press enter and make a new line. but after hiding the keyboard it rewraps, but still seems to skip the line.

It fails to wrap, so the text goes out of the screen? I'll keep this note in the todo list, and try to recreate it.
And hiding the keyboard shouldn't activate any wrapping, so am I understanding you correctly here?

4;Hmm.. hard one. I think it's an error in the way the lines are "recovered" when switching from portraitmode to normal view. You see, I need a way to have the app remember where the enters were when you switch to portraitmode and have everything wrapped, in order to restore those lines when switching back to normal view. (I tried it without restoring, just rewrapping, but then all enters are gone after switching normal-portrait-normal).
The way the app does this now, is by adding "\n" after each line, keeping it there while in portraitmode, and when you switch back it goes searching for the "\n's" and cuts lines there.
That's also the reason why new lines added in portraitmode aren't remembered.. and also the reason why new characters appear a little further than the cursor when you type at the end of an orginal line. (because the \n is there I think.) So I have to think of another way to have the app remember where the enters were, but with the possibility to add new enters while in portraitmode... oh man I'm making this app really hard for myself

Note: fixes/updates described above are not uploaded yet... version 2.71 will be uploaded later. I'm in the process of fixing these bugs and some of them are not ready yet.

[Habhome]

Originally Posted by Brett_val

Thank you very much for such an extensive testing! Although I couldn't fix everything (I've been working on it for a few hours today) I'll keep the unfixed issues in a "todo-list"

You're very welcome. And I apologize for the short descriptions of the bugs. It's not easy bugtesting an application while trying to listen to at least some of what your physics teacher is rambling about. And I wrote down about the bugs as I encountered them, so the details may be fuzzy.

Originally Posted by Brett_val

1; I wrote the exact same text you wrote (cool story by the way, you should write fairytales ) and I noticed it too.
Thing is, when special keyboard is shown, the area where you can cursortap is smaller, so I thought of doing just if y<spd then cursortap, and have the value of "spd" change when you toggle special/normal keys. So after pondering a while it came to me that this spd is not changed when special keyboard is automatically turned back to normal keyboard by type assistance. So that's it! Fixed (at least, if by "character", you mean a special one that causes the automatic normal keys.. ) But I'm pretty sure this was the cause.

Haha, I just needed something to fill it out with to test so just jotted something down xD Fun thing is it became exactly 7 lines which is where you first encounter the bug, and as I encountered it I started the bug list since I now had a bug found =P

I don't remember what character I added after saving, it can have been a dot/comma or a letter, I don't remember at all.

Originally Posted by Brett_val

2;I added something to the backspace function to take the temporary caps down when you have deleted a period, question mark or exclamation mark, and if that was the last one; so in case you have typed multiple periods or question marks and you want to delete one, the autocaps is still there.

Okay

Originally Posted by Brett_val

Now I'm wondering, is it allowed to start with a capital after a number of periods? Like this... This "T" shouldn't be a capital, or should it? Right now the app writes a capital in this situation, but I suspect that it's better if it doesn't do that. Because... this "t" looks better to me. I'm not sure, what do you think?

Hm, This all depends on your reason for using multiple periods I'd say. If it is as a sign of interrupting your sentence only to resume it again, then it shouldn't be capital. If you on the other hand means it as such that you abort the sentence and start a new one, then it should be capital. As it takes 1 shift click to make the first letter capital, but 2 to change from a shift to lower case I think that it after multiple periods should not make the next letter capital, since it is easier to make it capital manually than not.

Originally Posted by Brett_val

Letters are now drawn on the smskeyboard by the app, which is also easier for me and it displays caps when needed.

Nice!

Originally Posted by Brett_val

3;I don't think you would want the wordwrapping done while in portrait view to also appear in normal view, because then you would still have the shorter sentences from the portraitview? But I see the point with the new lines not being remembered. That's something I have to think about some more..

That is true, but if I remember correctly it was so that if I wrote two paragraphs of text in portrait mode (which would need wrapping in normal mode), and then switched it to normal mode it all ended up on the same line. And it didn't care for my blank line I had added.

Originally Posted by Brett_val

I don't really understand this one:

It fails to wrap, so the text goes out of the screen? I'll keep this note in the todo list, and try to recreate it.
And hiding the keyboard shouldn't activate any wrapping, so am I understanding you correctly here?

It's like this: I write in portrait mode, turn the player around and continues the line in normal mode. When it reaches the end of screen it continues to write outside of it. And yes, I hid the keyboard and then it wrapped the lines as it should. That is at least how I remembered the bug. (Keep in mind I didn't really recreate any of the bugs I encountered and just wrote down all fact I could gather while multitasking during a lesson =P)

Originally Posted by Brett_val

4;Hmm.. hard one. I think it's an error in the way the lines are "recovered" when switching from portraitmode to normal view. You see, I need a way to have the app remember where the enters were when you switch to portraitmode and have everything wrapped, in order to restore those lines when switching back to normal view. (I tried it without restoring, just rewrapping, but then all enters are gone after switching normal-portrait-normal).
The way the app does this now, is by adding "\n" after each line, keeping it there while in portraitmode, and when you switch back it goes searching for the "\n's" and cuts lines there.
That's also the reason why new lines added in portraitmode aren't remembered.. and also the reason why new characters appear a little further than the cursor when you type at the end of an orginal line. (because the \n is there I think.) So I have to think of another way to have the app remember where the enters were, but with the possibility to add new enters while in portraitmode... oh man I'm making this app really hard for myself

This one was hard to explain in quick and short words which was necessary during the circumstances of testing. Besides, I am not sure exactly when the empty lines got added since the area was outside of the screen when I had reached that point, but I noticed it after saving (Which takes you up to the first line again) and scrolled down to where I were and that's when I saw the blank lines.

- - - - - - - - -

After thinking back I now remember another thing I pondered about, and that is the scrollbar. It is too big and to scroll all the way down you have to take the bar outside of the screen. You can scroll all the way down, but it's not aesthetic and I think it's hindering the functionality slightly =P

[Brett_val]

Originally Posted by Habhome

You're very welcome. And I apologize for the short descriptions of the bugs. It's not easy bugtesting an application while trying to listen to at least some of what your physics teacher is rambling about. And I wrote down about the bugs as I encountered them, so the details may be fuzzy.

No need to apologize, I'm happy that you took the time to test it. Even when it's during class haha . Even short descriptions will point me in a direction, and give me an idea what could not be working right.

I tried searching for spelling rules on periods but I couldn't really find it.. for now I'll assume that when the user types multiple periods, he/she doesn't want to abort the sentence, and take the caps down.

Originally Posted by Habhome

if I remember correctly it was so that if I wrote two paragraphs of text in portrait mode (which would need wrapping in normal mode), and then switched it to normal mode it all ended up on the same line. And it didn't care for my blank line I had added.

I know why it ignores the new lines, and I have to change the whole way it handles the rewrap. I hvae some new ideas and I'm working on it.

Originally Posted by Habhome

It's like this: I write in portrait mode, turn the player around and continues the line in normal mode. When it reaches the end of screen it continues to write outside of it. And yes, I hid the keyboard and then it wrapped the lines as it should. That is at least how I remembered the bug. (Keep in mind I didn't really recreate any of the bugs I encountered and just wrote down all fact I could gather while multitasking during a lesson =P)

The only reason I can think of why it was drawing outside of the screen (and ignoring the "line length is too long already"-code), is because the length of the line was not properly saved, which must have happened while changing from portrait- to normal mode. I'll make sure the new code does this right.

Originally Posted by Habhome

This one was hard to explain in quick and short words which was necessary during the circumstances of testing. Besides, I am not sure exactly when the empty lines got added since the area was outside of the screen when I had reached that point, but I noticed it after saving (Which takes you up to the first line again) and scrolled down to where I were and that's when I saw the blank lines.

I did not encounter this appearing of empty lines myself, but I have some ideas why it could happen, so I'll take them into account while I'm making a new code .

Originally Posted by Habhome

After thinking back I now remember another thing I pondered about, and that is the scrollbar. It is too big and to scroll all the way down you have to take the bar outside of the screen. You can scroll all the way down, but it's not aesthetic and I think it's hindering the functionality slightly =P

I totally agree that it's weird that you have to scroll the bar outside of the screen to scroll down to the last line. I'll change that, and I'll also make it smaller so it doesn't cover any visible keys.

[Brett_val]

New update: v2.71

I think I almost fixed all the bugs while changing normal-to-portrait-and-back. I didn't test it to the full extent yet, but I was so excited that I wanted to show the new version to you guys.

Also, version 2.71 has the new sms-keyboard, but it doesn't support the custom buttoncolors yet..

[Esai]

You know, what you should add?
Volume control and an option to turn off SMS-keyboard(That mode...portrait one..)
And an idea... Change placing of the menu key...remove it from the keyboard and put it to home button...(Hold home button for menu.)
These should be 10 min of work...(Time it took me to do it...)

[Brett_val]

Originally Posted by Esai

You know, what you should add?
Volume control and an option to turn off SMS-keyboard(That mode...portrait one..)
And an idea... Change placing of the menu key...remove it from the keyboard and put it to home button...(Hold home button for menu.)
These should be 10 min of work...(Time it took me to do it...)

Volume control shall be added, I think it should be added to every app on here.

What do you mean with "turn off"? You can hide the sms keyboard with the down arrow shown above the keys.

Why remove the menu button? It will just leave an empty spot.
Besides, hold-homenbutton should be used to access volume control.

[Brett_val]

Originally Posted by Gruffler

i think it could be possible to integrate pics but it's a question wether it's useful

pics for what? Or, you mean a bin file?

[RobertsAccount]

Originally Posted by Brett_val

What do you mean with "turn off"? You can hide the sms keyboard with the down arrow shown above the keys.

Why remove the menu button? It will just leave an empty spot.
Besides, hold-homenbutton should be used to access volume control.

I think what he means is you shoud be able to disable the portrait mode, so that if you turn the player portrait, the screen won't change orientation. I fail to see the point of this though, as everything will be sideways... I like the idea of holding the menu button for volume control though! Keep up the good work..

[Android18]

Hey brett val
every things fine but the buttons the problem
just increase the button size
it will help make it type fast


and if we save in portrait view is shows error in save file

[Brett_val]

Not sure what you mean by error in save file, did it get corrupted? It should save the current file the same way in both viewing modes (when autosave is enabled).

As for the size of the buttons, they could be bigger but then you'd have very little space for the actual text, so this was the compromise I made. For faster typing there's the sms-style keyboard, maybe that helps?

[jameswalker101]

When I have my player the normal landscape orientation, the keys are the correct way up. If I rotate the player, the 'phone' keyboard is displayed.
But, if I hold the x-fi upside down, the KEYBOARD IS THE WRONG WAY!!!

[Brett_val]

Originally Posted by jameswalker101

When I have my player the normal landscape orientation, the keys are the correct way up. If I rotate the player, the 'phone' keyboard is displayed.
But, if I hold the x-fi upside down, the KEYBOARD IS THE WRONG WAY!!!

Well, then you're just holding it upside down and you need to turn it around. You are the first person to complain that you cannot use it upside down.

On a more serious note; the Zen can only do landscape (0 degrees) and portrait (90 degrees). 180 and 270 degrees don't work.

[Android18]

For the layout use the ipod's layout

Its easy to type

[jameswalker101]

Can there be a menu on startup?

[Habhome]

Originally Posted by Android18

For the layout use the ipod's layout

Its easy to type

Pictures? Any more arguments WHY it is easier? The more thought through feedback you provide the more people will listen.

Originally Posted by jameswalker101

Can there be a menu on startup?

AS above, more thought through feedback. What would be in said menu? Why is it necessary? There's no menu when you open Notepad in Windows, or most other text-editors for that matter, why would this one need it?

[carjoyaa]

did anyone else get an error in opening the app in the zen xfi2? it starts to show then it says "an error occurred". is there anything i can do to make it work?