codythegreat / dss Goto Github PK

Enhancement

The following enhancements are planned for DSS:

• gg - jump to first slide
• G - jump to last slide
• ngg / nG - jump to n slide

Description

Currently, if a user has/wants fewer or greater than 15 slides, they have to supply a number with the -s option. This should be automatic: the program should auto-detect how many slides there are in a presentation and adjust accordingly.

Proposed Solution

A function that quickly scans the presentation file, in a memory efficient manner, and returns the number of slides would do nicely.

0.2 is nearing release. I'm going to start testing the features to make sure their implementation is bug-free and stable:

• j k movement
• q quitting
• b B bookmarking

Bookmarking can cause a segfault if you bookmark a slide on one file, open another file with less slides and then call the bookmark. Solution is to clear bookmarks on opening new file.

fixed with 312f183

• t theme selection
• g G movement
• numerical slide jumping

Needs error message for if numerical input is outside of min/max slide number.

fixed with c0a7cec

• : command mode

When user is inputting a command, the ESC key will exit the mode, but display an error. Instead the ESC should exit without an error being displayed

fixed with f231255

• blist / bmark / bclear commands
  see above
• open command

commit 312f183 added error handling for empty filename argument. added call to clearBookmarks()

• / search mode

see command mode

• n N searching

error should be displayed if lastSearchTerm doesn't contain a string

fixed with 7c30ffc

I propose we use one buffer for the numerical input instead of two (this buffer can grow with the number, so we will not be limited to just two digits with the current solution.)

Since several functions use numerical inputs (command case 6, G and our soon to be implemented link accessing feature) I believe that the logic for this should be its own function that can be called whenever numerical input is introduced.

I believe that this one change should make the code much shorter and more readable for these instances.

As suggested in the comments of issue #25, I took a look at the Roadmap.

The grammar and verbiage looked good to me, but I think there should be more consistency in terms of capitalization (every point under 0.1 begins with a capitalized word, whereas none of the ones under 0.4 do).

The current implementation of single and double slide printing (lines 82-122 of display.c) is not the cleanest, and the code has a few repetitions. I believe that we could create a function that will take in some inputs (such as x, y, slide) and print the given slide's lines at that position. This would allow us to shorten this code while cleaning it up, and allow for more functionality with slide printing in the future.

I think that this would be a pretty easy feature to add in. we can use mvprintw to print to a specific row of the screen. I think the best way to do this would be to print the file name on the left side and slide number to the right.

When I first compile the program (from either v0.3.0 or master), I always get the help screen if I try entering an argument (unless I give it -v). I was able to add some code to break the loop causing it, but I am confused about why this affects me and not anyone else.

I am using Termux on Android 5.1.

Original code:

while ((ch=getopt(argc, argv, "hv"))!=EOF) {
        switch (ch)
        {
        case 'v':
            version();
            return EXIT_SUCCESS;
        case 'h':
            usage(), 
            return EXIT_SUCCESS;
        default:
            usage();
            return EXIT_FAILURE;
        }
    }

Basically every time the program has a valid argument, like ./dss sample.txt, the program runs 'usage()' and returns 1.

Working code:

while ((ch=getopt(argc, argv, "hv"))!=EOF) {
    if (strcmp(argv[1], "-h") && strcmp(argv[1], "-v")) {
        break;
    } ...

While a user can use B to jump to a bookmark, I believe that there is a benefit to having multiple options for jumping to bookmarks

You can already jump to a slide in command mode numerically, so it makes sense that something like :r would take you to the slide at register r.

This could be easily implemented by having the logic for case 'B' in handleKeyPress separated into its own function (something like slide* slideAtRegister(char reg, slide *curSlide)), and then case 'B' and this new feature could just use this one function.

This issue is to record any sort of bugs that need to be fixed for the new features prior to release of 0.3.0.

To be tested:

• Double slide mode keybinding d Tested - functions as intended
• Double slide mode command double Tested - functions as intended
• Double slide mode compatibility with existing keybindings/commands Tested - functions as intended
• COLOR tag error handling Tested - functions as intended
• URL error handling added commit 5befcf6 to fix urls being detected without ending ) character
• URL printing and selection in double slide mode (should the user pick a slide to select from, or should all possible links on both slides be available for selection?) This feature is currently disabled (
  ce11273). A soft error will be printed to the screen if the user tries to open a link while in double display mode.

Changes to be made:

• llist command displays nothing when there are no links on the current slide. This could seem like an error to the user. we should display a bottom bar message similar to "no links found on this slide" bottom bar message added in commit ce11273
• There should be a way to disable the COLOR tags if a user desires. Perhaps a command like nocolor? added linecolor command that toggles line coloring via colortags (commits dbb18c9 and e23c03a)
• URLs are limited to one per line. Should we allow for more, and if so how should they be handled? I'm not going to add this feature at the moment. Perhaps in a future update
• COLOR tag can cause junk text if not implemented properly (user adds COLOR="b without bg and ", for example) fixed in commit 8b66188 by checking fg/bg values after loop
• when COLOR tag error prints, the next error to print will be slightly to the right of the first moving initDisplay below parseTXT in main.c fixed this issue (commit 601c368)

This issue is currently only occurring on my work computer through an SSH terminal to a remote server. Underline characters are either not fully being concatenated to each slide, or they're not being printed properly on the call to printw during the program loop.

I'm not sure if this an environment issue for my ssh server but i have yet to reproduce this issue on my home Linux machine.

Feature addition: simple slide fade in/out "animation"

I think this could be achieved using a rgb value "ramp" for each value.

Example:

static short ramp_r[6] = { ... };
static short ramp_g[6] = { ... };
static short ramp_b[6] = { ... };

and then we'd have a loop that assigned the global color value with each index of the three ramps.

Edit: we'd also need an argv to disable this. Maybe -f?

I tested the program by opening the sample.txt presentation and monitoring dss with valgrind.

==15543== Memcheck, a memory error detector
==15543== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==15543== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==15543== Command: ./dss sample.txt
==15543==
==15543==
==15543== HEAP SUMMARY:
==15543==     in use at exit: 1,045,969 bytes in 206 blocks
==15543==   total heap usage: 400 allocs, 194 frees, 1,075,302 bytes allocated
==15543==
==15543== LEAK SUMMARY:
==15543==    definitely lost: 2,562 bytes in 1 blocks
==15543==    indirectly lost: 0 bytes in 0 blocks
==15543==      possibly lost: 0 bytes in 0 blocks
==15543==    still reachable: 1,043,407 bytes in 205 blocks
==15543==         suppressed: 0 bytes in 0 blocks
==15543== Rerun with --leak-check=full to see details of leaked memory
==15543==
==15543== For counts of detected and suppressed errors, rerun with: -v
==15543== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

It appears that the program leaks memory in some places. I will look into this further, but thought you should keep this in mind.

File Error Handling

Currently if the file is not read properly in main the program will print a message stating that the file name could not be read, and a seg fault will follow. This should be handled more gracefully.

1. A file read error should state and error as it does now, but there should also be a call to return EXIT_FAILURE;
2. We should stop the program from continuing to the point that a seg fault happens

I propose that we add a return statement in before the seg fault in the code.

This should be a pretty simple issue. I wouldn't really call it a bug or enhancement, but rather "good house keeping" programming wise.

The goal of this issue is to have a single call to displayLoop instead of it currently witting in a while loop. displayLoop should house the looping logic (while loop), displayLoop should also handle switching of slides on each iteration.

Switching of slides can still be handed via pointer *slideNumber and we'll give the display loop a pointer to the array of Slide struct so that it can simply call the exact slide that *slideNumber points to (something like slides[*slideNumber]

Once we are finished with the logic in displayLoop we'll simply return to the main function, make a call to free(slides) and make a call to exit() to close the program.

Currently there are a few functions that were left in slides.c from the previous methodology that was used to build out the slides. Since transitioning to our new/better way of handling the slides we no longer need to hang on to these old functions. They should be removed.

I've noticed that on a few of the slides that are sometimes some strange characters such as "A^P". These characters are not present in the .txt file (or atleast not visibly present.)

I believe that the following commands should be added:

• llist - lists the available links on the current slide
• link n - opens the links at index n (n can be >10)

Double Slide Display Mode

One of the planned features for version v0.3.0 is for enabling the user to view two slides at once. Here is the premise of feature:

• The user either presses a key or a command (maybe d) and double slide mode will be enabled
• When the screen refreshes, two slides will appear, one on the left, and the other on the right.
• When the user advances a slide forward, the right slide will shift to the left and a new slide will take the right slide's place.

This feature will be useful during the slide editing phase where a use can see previous and next slides juxtaposed next to each other. Errors in formatting and design will be more apparent from one slide to another.

The current implementation for line printing was fine prior to the addition of line coloring, but with this new feature it becomes very apparent where lines stop and start. I propose a solution to this where each line has spaces appended until it reaches the length of the longest line. I think that the printSlideAtPosition function should handle this at time of print, so that the program will not have to keep the extra spaces in memory.

This feature will make it much easier for our users to make clean looking slides.

Perhaps if a user doesn't want this feature enabled we could add a flag to disable it?

More/Better Themes

This one should be pretty easy. Currently DSS has a few themes added in that can be switched using the t key. I'd like to see not only a refinement of the current themes, but also more themes for the user to choose from. ncurses also supports 256 color mode, so on capable computers that should allow for much more freedom. We could take advantage of this.

Currently the colors are initialized in the initDisplay() function in display.c. there you'll see the calls to init_pair() for initializing color pairs (foreground and background.) This is where you can change or create new themes.

I tried out the link command to get the links off of the last slide on the sample.txt file. I got the No links detected on this slide message. perhaps there is a difference in code between the l hotkey and the link command (both of these should have the exact same functionality)

Feature Addition: UTF-8 Support

It'd be nice of DSS could support a wider range of characters for people who are wanting to do ascii style artwork. This seems to be possible, but there are a few caveats:

• We may need to switch to -lncursesw instead of -lncurses
• Function call to enable this should be setlocale(LC_ALL, "") NOTE: this must precede the call to initscr()

Since not all environments support -lncursesw I'm curious as to how this will impact stability.

Better Handling of Slide Data

Edit: So I've thought about this some more and I think that if we want the code to be readable and expandable in the future then a doubly linked listed for the slides would be better. I propose the following structure:

typedef struct slide {
    int number;
    int x, y;
    int color;
    line *first;
    slide *next;
    slide *prev;
} slide;

This is very simplified, and variables are subject to change, but this give us a much easier way to pass around the struct as we'd only need one instance to access the rest of the slides. We can use the number variable for our current movement system.

Bug: Slides break with excessive zooming

If a user zoomes in far enough on their screen the lines of the slide will eventually "wrap" down to the next line. This causes what looks likes gaps between each lines, and poor readability.

I think that the best solution to handle this is a warning. If DSS detects that max_x < Slide->x instead of making a call to printw for Slide->content we'll make a call like this:
printw("Terminal zoom/size error: You terminal window is too small to display the slide. Try zooming out or resizing the window");

Upon zooming out the loop would refresh, and if the max_x < Slide->x logic returns false the user will then see the properly displayed slide.

Version Feature Roadmap

Currently DSS has version numbers built in, but there isn't any documentation to determine what a version change would mean in terms of features and functionality. I believe that a roadmap of features to achieve with each version should be created.

This should be an easy one: Since there isn't any text input from the user we really don't need the cursor being displayed after everything is printed to the screen. It should be disabled (preferably globally unless we have a need for it later on.)

The cursors current position is at the bottom right of the screen (after making a call to mvprintw for the slide numbers)

URLs

URL handling will be done with markdown style formatting [title](www.webpage.com)

When dss detects the above format, it'll store the website url to the slide struct, and format the slide to print [n]title whereas n is the link number (in the case of a single link, this would be 0.

If a user presses l followed by the link number the webpage will be opened in the default browser.

For some reason the t key is assigning a bookmark even though B is never pressed. This can be confirmed by changing the theme with t and then running the blist command.

The current tag format used for colors is COLOR="n" where n is a value between 1-56. I don't like this format as if a user wants to define a green/blue color pair they'd have no idea what number that would be without experimentation.

I propose the following change:

COLOR="rg"

first letter represents the foreground color and the second letter represents the background color.

The following letters could be used to correspond to a color:

r = red
g = green
b = blue
B = black
w = white
y = yellow
m = magenta
c = cyan

This will make it much easier for our users to specify the correct line color

Markdown Style Formatting

• bolding with two asterisk * characters
• italic text (is this possible in ncurses?) with a single asterisk character
• code highlighting with backtick ` characters
• links with [] for the link display text and () holding the actual link

I think, starting out, these could be the easiest features to add. More formatting options can be implemented later on.

Edit (7/21/20): These features should be toggle able (off by default) so as to not mess up slides that are meant to be viewed in raw format.

Command and Search use very similar logic for parsing user input. The logic functions like this:

• Command/Search mode is entered
• Go to bottom line, clear and add mode character : / /
• With each character typed, print the char to the screen and to a buffer
• When the user pressed enter, either hand off the input to another function or var

I believe that this logic should be it's own function like so:

int parseUserInput(char *bufferToWriteTo) {
    // parse input
    // write to supplied buffer (if needed)
    // return 0 (fail) 1 (success)
}

This will allow code reuse, and any function that uses user input in the future will benefit from this function.

I think that it would be more aesthetically pleasing if the title and slides are vertically and horizontally aligned. I believe that the window x/y lengths can be acquired with void getmaxyx(WINDOW *win, int y, int x);

Feature Addition: Bookmarking

Bookmarking will be handled in the following manner:

• b be is pressed while in a specific slide, a character is pressed after to set the bookmark
• B can be pressed followed by the key of the bookmark to jump straight to that slide
• if a user is on slide 7 they'd press b and . to bookmark slide 7 to .. The user can then press B. to go to slide 7 from any slide.

This is especially useful for larger presentations where the user may not remember the numbers corresponding to important slides, but would like to set some bookmarks to quickly jump around to notable content.

Feature Addition: Coloring and Themes

I've done some research and the following functions could be useful in coloring/themes:

• has_color() returns a bool value of true or false if terminal emulator support color
• start_color() allows changing colors/use of color related functions (usually called right after initscr()
• init_pair() allows for changing of background/foreground colors

From what I've studies so far it looks like there is support for 16/256 colors. Perhaps we could assign a key such as F2 that would allow cycling through various themes (color pairs)

I believe that we should have an argument that allows a presenter to hide the file name / slide bottom bar. The bar is great during slide editing and presentation practice but it may not be needed/wanted when in actual use.

I think -b would be a good argv to assign this feature to.

I've been doing some testing to see how far DSS can be pushed before it crashes, and currently it can reach 99 slides, but at slide 100 the program will crash with the message:

*** buffer overflow detected ***: ./dss terminated

I find it strange that this happens reliably on presentations with 100 slides, but anything under that is okay. Perhaps there is some kind of hard limit in for struct linked lists?

I've been pondering a solution, and so far my best idea is to have the slides loaded into a "buffer" instead of all at once, and then as the user advances in the presentation the buffer will remove previous slides and add upcoming slides.

Currently Slide.content is setup as a fixed length character array of 5000 characters. We'd prefer for this to be dynamic so that even if a slide exceeds 5000 characters we won't encounter a seg fault. We'd also like to small slides utilize less memory.

I believe that this can be accomplished by setting the Slide.content variable in parser.h as a character pointer char *content and then in parser.c we'd build the content with a character array of x*y size, then we'd simply point the Slide.content variable to the character array. We may also need to allocate the character array to heap memory instead of the stack.

Color

This is one of the core features that will be introduced in v0.3. My current idea for this feature is as follows:

1. User adds a tag on the line that they want colored (for example {COLOR_BLUE})
2. Dss will detect the color code and assign it to a value in the struct. the line will be stored without the tag.
3. when printing lines to the screen, if dss encounters a different color, it'll print that line in that color, then the next line will be in the original color.

This is a very basic overview but hopefully it gets the idea across.

Command mode

One of the features listed on the roadmap for version 0.2 is a vim style command mode. Some early work has already been put into this; Here is a short list of what is currently functional:

• unknown or bad input displays an error
• quitting with :q
• displaying bookmarks with :blist
• clearing bookmarks with :bclear
• jumping to slides by number. 12th slide would be :12

The biggest issue that I'm having so far with this feature is the :open filename command. I've currently commented out that functionality until I can look into it further. I suspect that the main issue with this command is the calls to free() for the slides in main.

I'm also looking for feedback on other commands that would be useful.

Better Bookmarking

Currently DSS supports bookmarking using an array to store slide - register pairs. This array is 5x2 in length.

I think that there could be a better solution for storing bookmarks. If anyone wants to theorize on this that would be great.

Hint: check out this ascii table http://www.asciitable.com/ notice that there are 128 potential values. Can this somehow be useful in our solution?

Opening a new file (calling :open filename) will read the file and display it, but the text is partially garbled by junk characters.

I'm pretty sure that this is an issue with the call to freeLine() in the main.c file. I commented out that line, and the slides rendered fine for the most part (this isn't good though as the old lines are still sitting in memory taking up space.)

Currently I'm trying to port over the code that handles reading the text file in main.c over to another file parser.c to make it easier to maintain. I'm having a few issues implementing this:

My main issue is conceptualizing and implementing how the array of slides (currently of type char[][]) can be efficiently passed to and from parser.h.

I'd like to do this efficiently without having to copy and reassign the array to new memory addresses.

There is really no need to have three different sample text files. We only need two files (for demoing opening different files.) I also believe that these files should serve a purpose. Maybe sample1 could show some more generalized use cases for the app, and sample2 could provide a high-level look at what the code is doing (for contributors or those interested in knowing.)

Feature Addition: Search Slides

I believe that DSS could benefit greatly from having a search feature similar to vim's / searching functionality. I propose the following:

• Use the / to initiate search mode
• input from the user will be added to the screen after the / symbol
• upon pressing enter, the text is parsed (we'll probably have to start out with raw text parsing as using regular expressions would take a lot of time and effort to implement.)
• search starts from current slide, and works down until a match is discovered
• when a match is discovered, user will jump to that slide.
• if end of slides is reached, prints "End of slides was reached with no matches found" or something similar
• a key could be reserved to tell DSS to search backwards instead of forwards.
• n/N could be user to repeat a search and move to next/last item
• bonus: highlight that text in the returned slide that was searched.