DonationCoder.com Software > N.A.N.Y. 2010

NANY 2010 Idea: A 'polite' reminder/diary system

<< < (15/24) > >>

tomos:
frog_1.wav rocks.  =]
-skwire (November 11, 2009, 03:45 PM)
--- End quote ---

lol - have to agree there ;D

thanks for new version Skwire, will check it out tomorrow

[edit] like pong & droplet sounds too :up: [/edit]

doctorfrog:
I'm partial to earwax.wav myself. ;)

I'll heap my notes upon the thread tonight/tomorrow.

doctorfrog:
anuran notes, 1.0.6

anuvu:
1. Request: add option to toggle wordwrap in log viewer pane

2. Request: add option to add 0,1, or 2 carriage returns between individual log entries. (readability) Option text: "Spaces between log entries: none, 1, 2"

3. Request: add option to add 0 or 1 carriage returns between timestamp and entry text. (readability) Option text: "Insert space between timestamp and log entry: Yes, No"

4. Request (maybe): If implementing 3, and user choice is "Yes," then indent log entry relative to timestamp (which is already indented). 2-3 spaces in should be sufficient. (readability)

5. Request (maybe): right click on logviewer pane = drop-down menu option: "Export to text." Result: saves everything currently in logviewer pane to a text file. (for really lazy users, or as a "discoverable" feature).

6. Concern: My one discomfort now is that, before we had text files being generated that could be human-read with ease. Now, because of the "SS" symbols in the logfile markup, using the viewer is every so slightly forced upon the user, since this is the prime location for a clean view of logs.
It's not too bad now, and may be unavoidable, but I suggest we remain cognizant of this, as one of my goals was to keep the logfiles human-readable through the ages, if the user forgets or loses Anuran, or the program itself becomes incompatible with future OS's. Thoughts?

7. Request (maybe maybe): With 6 in mind, offer an easy way to select all text files in the logfile pane and export as "pretty" text, as it would be displayed in the logviewer pane. Result: each individual logfile is translated into a pretty text file. (This is a fairly big maybe.)

8. Bug (keepin' this alive): Anuran only archives a logfile if the user-specified time increment passes while Anuran is running. Solution: base the archive increment on the creation time of current.anu.

Other:
- I like how the entries are indented slightly. This is a Good Thing.
- I like how AnuVu presents log files. We're moving in a very good direction. With Anuran, we have a means of generating scads of user data. A searchable viewer gives that data a lot more meaning and use. It's a more crucial element than I thought it would be at first, and I'm glad you're working on it.
- Your thoughts on my 'generic timestamp' suggestion above? (https://www.donationcoder.com/forum/index.php?topic=20516.msg184295#msg184295)

skwire:
1-4. All good suggestions and added to my ToDo.  I also plan to add user-configurable font choice.

5. The edit control has a standard menu of its own.  How about if I add the Export entry to the File menu?  That's where it typically is for most apps.

6. It's a liberty that I almost had no choice but to take; it makes thing much easier for me.  I tried to keep it very simple though with only the section (§) marker to denote entries.  If it ever came down to it through the ages, a simple search & replace would fix that in no time.

7. To clarify, you want each logfile exported to a separate text file, right?

8. It's on my buglist and should be squashed soon.  Here's my logic flow:
    * Keep track of the last archived time in the config.ini.
    * On Anuran startup, compare that timestamp with the current time.
    * If the interval exceeds the configured interval, archive immediately and update config.ini.
    * From this point, archive on the configured interval timer.

Other:
- I like how the entries are indented slightly. This is a Good Thing.
- I like how AnuVu presents log files. We're moving in a very good direction. With Anuran, we have a means of generating scads of user data. A searchable viewer gives that data a lot more meaning and use. It's a more crucial element than I thought it would be at first, and I'm glad you're working on it.
- Your thoughts on my 'generic timestamp' suggestion above? (https://www.donationcoder.com/forum/index.php?topic=20516.msg184295#msg184295)
-doctorfrog (November 12, 2009, 11:43 AM)
--- End quote ---

Yes...I try not to lose sight of KISS (Keep It Simple Stupid) when writing an application.  Keep it tightly focused but still elegant and useful.  I think I address the 'generic timestamp' issue when explaining point #8 above.

doctorfrog:
My reply:

1-4. Awesome.

5. This would be fine. Possible wording: "Export current view"

6. Totally acceptable. I just had to pipe up about it.

7. Good question. The option I had in mind was something like "Export all selected logfiles to individual text files." Kinda wordy. Might need an intermediary dialog... ok, menu option: "Export all..." This leads to a dialog asking for an export location. We can have the full wording there, and a file/directory select widget.
People who only want to export the current view can do so via another menu option: "Export current view...", or simply copy and paste the contents of the view pane.

8. That works. Though I still think storing a creation date in each logfile has its uses, particularly for more accurate file sorting (that isn't based on filename or file properties, both of which can vary). Actually, why not pair that with an "archived on" datestamp that appears at the end of the logfile as well?

Other thoughts for myself:
- at some point, we'll need to document that .anu files are just text files. The .anu extension and the need for a viewer might lead to the impression that there's some wonky proprietary format at work here.
- I might want to write up a basic readme.txt. No need for a full-blown helpfile, though.

Navigation

[0] Message Index

[#] Next page

[*] Previous page