| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
| |
Addresses a copy-paste typo introduced in commit 65064ce (Check if the
configuration folder exists, 2018-08-25).
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The number of seconds in a day and daylength in seconds differ when
Daylight Saving Time is in effect on two days of the year. The day when DST
takes effect is 23 hours long, and the day when DST ends is 25 hours long.
In the latter case the date changing thread wóuld enter a loop in the last hour
before midnight (in the former it would set the date an hour too late).
The next midnight is calculated through mktime(), invoked by date2sec().
Wrong daylength prevented appointments from being stored in the day vector and
caused them to be displayed wrongly in the appts panel.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calcurse saves time and date information on disk as local time in readable text
file format. When loaded from disk or when entered by the user, local time is
converted to Unix time (seconds since 00:00:00, 1 January 1970). When
displayed, and later when saved to disk, the Unix time is converted back to
readable local time. Both conversions depend on DST.
Hence, if midnight for a day with DST in effect (i.e. local time) is converted,
increased with an amount and converted back, the amount has changed if DST is
_not_ in effect for the resulting time. In general, calculations on Unix time
variables should be used with caution because of the DST-dependent conversions.
Instead, the calculations should be performed on local time data with the help
of mktime().
The commit fixes start time for pasted appointments (ordinary and recurrent)
and the 'until'-date of recurrent appointments, pasted as well as new and
edited. The latter problem is slightly different in that the adjustment is a
number of days, as it is for exception dates.
Update of the date in parse_datetime() has been corrected to be similar to
update of the time, although no problem has been identified.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
| |
A new apppoint inserted on the day when the clock is adjusted backward by an
hour got a wrong start time (an hour late). Reason: mktime() must not use the
Daylight Saving Time information returned by localtime_r().
Also editorial simplifications.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
| |
Partly addresses GitHub issue #145.
Suggested-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
| |
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
| |
The main thread only reads and removes events from the queue. All other threads
only insert events in the queue. Hence, only insertion and removal need protection.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
| |
After user acknowledgement a system event is deleted from the event queue.
The configuration variable determines whether it is turned into an appointment
(for later inspection) or not.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
| |
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The screen and user interaction is managed by the main thread. Other parts of
calcurse (threads) wishing to use the screen or communicate with the user, must
do it via the main thread.
For this purpose the main input loop is extended with a message queue. A thread
may insert a message in the queue. The main thread tests for messages before
listening for user commands. If a message is present, it is displayed (in a popup
window) for the user to acknowledge. Depending on the message other actions may
be performed, e.g. the message could be turned into a "system appointment/event"
and inserted among the usual appointments.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
| |
Quitting calcurse with auto_save on may lead to an interactive conflict
resolution for the save operation. When the result is a cancellation of the
save, the quit command is also cancelled.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
| |
When loading/saving the configuration file the entry is silently ignored
(which means it is removed by the first save).
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
| |
The return code from new_data() and io_load_data() is explicitly defined as a
bit mask. A file access error is recognised and reported back to the user.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A complete save or reload operation is made up of several cooperating lower
level function calls. In stead of protecting the lower level read or write calls
on the data files, the entire save or load operation is protected in order to
ensure its integrity.
Thus mutex protection has been moved from the level:
io_load_data(), io_merge_data(), new_data(),
to two functions at the higher level:
io_save_cal(), io_reload_data().
The protection includes pre- and post-hooks.
The function io_load_data() needs no protection when calcurse starts up
(threads not yet started) or runs in non-interactive mode (no threads involved).
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
| |
To protect the periodic save from being cancelled during a save operation.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
| |
A new argument to io_save_cal() makes it possible for the periodic save thread
to avoid 1) user interaction and 2) overwriting new data.
At the moment the thread has no way to report on the result of the save.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function io_save_cal() saves apts, todos, configuration data and key
bindings. The configuration and key files do not belong with the two data
files, but the progress bar function assumes that all four files are saved in
a fixed sequence. Since it is used nowhere else and contains unused parts,
the function has been removed.
A return code for file access error is introduced, and the EXIT macro moved to
the command level in calcurse.c.
Save of configuration and key data were already moved to the configuration menu
in commit 0124618, A save refinement: no action if everything is unchanged.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moving user information to calcurse.c makes it easier to perform the actual
save/reload operatons in io.c, e.g. it is possible to load instead of
reload after a merge in conflict resolving.
The save/reload operations are of such importance that the user should always be
informed of the result (it's a bit disquieting when there is no reaction to a
save or reload command). Hence, the save/reload status messages are no longer
conditioned by show_dialogs(). No confirmation is asked for, so a message stays
until the status bar is updated by another action.
Care is taken to inform about save/reload actions that result in no change.
Texts are kept concise because of the limited message area. When conflicts are
present, whether saving or reloading, the "continue/merge/cancel" pattern seems
easier to grasp.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A reload action will do nothing if in-memory data as well as data files are
unchanged. This commit accomplishes the equivalent for a save action.
Because saving of configuration data and key bindings are mixed up with saving
of data files, any changes in those will only be saved if data files also have
changed. Hence, configuration data and key bindings are also saved upon exit
from the configuration menu.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a replacement for commits 57dd3d6 and 912124b.
The idea is to move the check for modified files and the list initialization
into io_load_data(), and let io_load_data() decide what to load. A new
argument is used to force a load.
The return code from new_data() (the renamed version of
io_check_data_files_modified()) tells which files have changed.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After resolving a save conflict with the merge tool, a save operation has,
in effect, occurred, and data files must be reloaded to import the result of
the conflict resolution.
This is a replacement for commit 2fe9c7e. The operations concerned with the user
interface are kept out the io-operations (as in all other cases) and take place
at the command-level in calcurse.c. and not at the io-level (io.c).
Shorter, more concise prompt texts.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
| |
The flag modified (io.c) keeps track of the memory state of data:
modified == 0: unchanged since load or last save
modified == 1: changed since load or last save
It is now unset in io_load_data() and io_save_cal() only.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
| |
The wins_update() call is the responsibility of the caller of
io_resolve_save_conflict().
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The thread is stopped/started in wins_prepare/unprepare_external() when hooks
are run. There is no need to do it in io_reload_data(). In fact, because of the
nested calls
notify_stop_main_thread() <--- io_reload_data()
...
notify_stop_main_thread() <--- hook/wins_prepare_external()
...
notify_start_main_thread() <--- hook/wins_unprepare_external()
...
notify_start_main_thread() <--- io_reload_data()
the thread has been running after the first hook anyway.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The introduction of hooks raised a problem with window updates. The diagnosis
in commit feb059e8 (Fix segmentation fault on reload with pre-load hook) was
right, the cure was wrong.
The problem is wins_update(), not the listbox contents. The wins_update() call
does not belong in wins_unprepare_external() (or in io_reload_data()), but at a
higher level. It should be called _after_ reload, as indeed it is in
key_generic_reload() when the listbox contents have been updated (todo as well
as appointments). The call was introduced in commit 8ae75f3 without comment.
The todo updates in io_reload_data() also belong in key_generic_reload() where
they were before commit 7f06c252.
When saving data, all panels must be updated in case a hook was executed.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
| |
Fixes GitHub issue #139.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
| |
Comments inserted.
Slightly different implementations of parse_time() and parse_datetime().
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
| |
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
| |
Memory pointers must be initialized at the start in case memory is
freed (cleanup) before it is allocated.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
| |
Use one (small) buffer long enough to hold a date.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When setting start time for a new appointment, a date is disallowed
(in all other cases both time and date are still allowed).
Both date and time are displayed for the user to correct when an
appointment is changed or moved.
Built-in help in the status bar for display of input formats.
Several bug fixes that resulted in data inconsistencies (end time
before start time).
The routines use the enhanced parsing funtions to validate input:
ui_day_item_add(void)
parse_datetime()
parse_duration()
parse_datetime()
ui_day_item_repeat(void)
parse_date_duration()
parse_date()
ui_day_item_edit(void)
update_start_time()
day_edit_time()
parse_datetime()
update_duration()
parse_duration()
parse_datetime()
update_rept()
parse_date_duration()
parse_date()
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
| |
All appointment times are checked for validity. Overflow by time
arithmetic is detected. End times are checked when appointments
are moved. Three functions are involved: parse_datetime(),
parse_duration() and parse_date_duration(); they all have a
new argument for validation purposes.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
| |
check_sec(), overflow_add(), overflow_mul()
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
| |
Incorporated day_edit_duraton() into update_duration().
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
| |
When editing the start time, move the item instead of keeping the
previous start time as end time. When editing the end time, start with
an empty end time instead of the previous start time.
Fixes GitHub issue #89.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
| |
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
| |
The changed handling of thread ids implies that they must be initialized
before exit of calcurse where they are used. Hence the function
vars_init() is now called irrespective of command line arguments.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows to specify a configuration directory containing:
* conf
* keys
* hooks
When used in combination with -D $ddir, $ddir contains all the other
files not mentioned above.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
| |
A new save thread was started every time a positive periodic save value
was input in the general options configuration menu. And only one thread
can be stopped by entering 0, also when done repeatedly.
Always stop the old thread before (possibly) starting a new.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calcurse deadlocks when
1) an upcoming appointment is on display in the notification bar,
2) an external command (like help) is started,
3) the time for the upcoming appointment arrives, and
4) the external command is exited.
The notification bar thread is stopped while the external command is
running. Upon exit from the external command, the n-bar thread is
restarted and calcurse locks.
The cause is the way in which the main notification bar thread is
stopped:
static pthread_t notify_t_main;
void notify_stop_main_thread(void)
{
if (notify_t_main) {
pthread_cancel(notify_t_main);
pthread_join(notify_t_main, NULL);
}
}
Objects of type pthread_t are opaque and should not be accessed
directly. Initially notify_t_main is an uninitialised static variable
(0), but later it has a value, which may or may not be the thread id of
the notification main thread.
Note that the thread id after exit of a thread may become the thread id
of a new thread. Thus the variable set when the thread is created, is
invalid after exit of the thread.
Specifically, the first time notify_stop_main_thread() is called (by
notify_start_main_thread() before the thread is created) is harmless
(because notify_t_main is 0). Calling notify_stop_main_thread() later
may be either
OK
because the main thread is running, or
harmless
because no thread with id notify_t_main is running: the two
functions will fail with return value ESRCH (no such process), or
fatal
because an unrelated thread with this thread id is running: it will
be cancelled, and the join may or may not succeed depending on
whether the thread is joinable or detached.
The "unrelated thread" could be the next-appointment thread,
notify_thread_app, launched by notify_check_next_app().
Always calling notify_stop_main_thread() before starting the main thread
becomes fatal when notify_check_next_app() is called shortly before
notify_start_main_thread(). This is the case in the scenario described.
The next-app-thread is then running when notify_stop_main_thread() is
called, and apparently it has the thread id of the old main thread
(confirmed by logging the return values from pthread_cancel() and
pthread_join(); the first succeeds while the second fails with EINVALID
which means that the thread is not joinable). The next-app-thread will
therefore exit without unlocking mutexes.
Ensure that notify_t_main, in case the notify main thread is not
running, has a value that it will never have when it is running. A
possibility is the thread id of the main() calcurse process (returned by
pthread_self()).
Check for this condition in notify_stop_main_thread() and set
notify_t_main when the thread is stopped.
Similar changes have been introduced for the periodic save thread and
the calendar date thread.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to deficient validation, it is possible to get an inconsistent
database with an appointment that ends before it begins. Edit an
existing one and specify an end time by a date that precedes the start
date, or create a new one and give a date as end time that precedes the
start. Then exit calcurse; on restart it will report a data error and
exit.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
You try to enter an appointment, but enter an invalid start time (by
mistake). Calcurse rejects the input. You enter the correct start time
and calcurse asks for the description, not the end time, i.e. you get an
event.
The check for an event must only be performed on valid input.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
| |
Translations (in po-files) of texts that are used for alternative
choices (e.g. [dwmy]), may use UTF-8 encoded Unicode characters (e.g.
[éãüå]).
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Internally characters (keys) have two representations: integers and key
names. Key names are characters strings, usually the name of the
character; e.g., the character A has the representations 65 and "A", and
the tab character the representations 9 and "TAB".
The function keys_int2str() turns the integer representation of a
key/character into the key name.
For display purposes the key names are usually confined to have display
width at most three. Some curses pseudo-keys have longer key names;
e.g., the back-tab character is "KEY_BTAB". A long key name makes a
character difficult to recognize in the status bar menu.
The key name of a multibyte, UTF-8 encoded character is the conventional
Unicode name of the code point; e.g., the character ü has key name
"U+00FC" because ü is the code point 0xFC. Most of these look alike in
the status bar menu.
The patch makes the key name of a multibyte character look like that of
a singlebyte character: the character itself, i.e. the key name of the
character ü is "ü".
The main tool is implementation of a utf8_encode() routine.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
| |
Purely for readability and in preparation for the counterpart utf8_encode().
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
| |
Add a static state variable to indicate whether the notification thread
is already running or not. Only start the thread if the notification
thread is paused. Only stop the thread if the notification thread is
actually running.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
| |
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
| |
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|
|
|
|
|
|
|
|
|
| |
The configuration file (~/.calcurse/conf by default) can now be
specified with -C or --conf.
Workaround for GitHub issue #86.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
|