! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
1: Feature request: easy list of all entries
Status:
RESOLVED: FIXED

Comments

Description Ted Merrill 2012-08-31 01:00:32 CEST
I REALLY need to be able to bring up a window showing all event entries...
each one exactly once, even if it is a recurring event.
Having such a window allows me to quickly review them all to make sure they
are all there, etc.
I'd also like that the list show the NEXT time that the event occurs,
as versus the first time it occurred that is already past... it is too
hard to figure out otherwise.
Events that have expired and don't recur should be shown at the top,
perhaps in a different color or something.
Basically it should be almost like the current event list window except for the obvious differences....

I'm a refugee from KDE who is now no longer able to use kalarm.
I've looked at almost everything else free, and Orage i like the best... thanks!!!
But i've had to hack the source code to get this feature i need (which 
kalarm had).
What i did was to modify event-list.c function app_rows() to always use
the "else" case (which is otherwise just used for only todo and journal).
Perhaps this could just be a checkbox or configuration item as to whether
to show all reps of the event or just the first one?
I also had to modify build_event_tab() in same file to allow a higher
"additional days count" (i changed it to 99999).
With additional days set to 99999 and looking at today's date, i can see
almost what i want, with the exception of showing today's date for something
that fired earlier in the day.

Thanks in advance for considering this,
-Ted Merrill
Comment 1 Liv 2012-09-11 12:28:24 CEST
This seems like a useful feature. Would you consider posting a patch and some screenshots of the functionality?
Comment 2 juha editbugs 2012-09-14 09:14:06 CEST
Orage is basically based on Kalarm. When I moved from KDE to Xfce, I needed Kalarm..so I created Orage.
Your idea seems fine. Will check if new window is needed or if current list can be improved.
Thanks for the idea.
Comment 3 Ted Merrill 2012-09-17 21:36:40 CEST
(In reply to comment #1)
> This seems like a useful feature. Would you consider posting a patch and
> some screenshots of the functionality?

I just did a hack (which i think i well described) so i won't glorify it by posting a patch.... thanks for asking.
Re. what it looks like, it looks exactly like the event list does already except that repetitions are suppressed out of the list.
-Ted
Comment 4 juha editbugs 2013-11-21 14:53:50 CET
Added to 4.9.10.0.
Comment 5 Liv 2013-11-21 17:33:07 CET
Nice!

I'm wondering if maybe the checkbox labels could be better named. I would suggest "Include past" or "Include past events" instead of "also old". And maybe "Only first repeating" instead of "only first". I'm just saying that UI-wise the two checkboxes seem a bit strange, and maybe there's a nicer way to rethink the layout (but I'm not sure how!).
Comment 6 Ted Merrill 2013-11-21 20:48:40 CET
Thanks so much for your good work! I've tested it out...

I really need "only first" to be default true... or better, to be a config parameter.
Modify event-list.c: build_event_tab()
added:
gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(el->event_only_first_checkbutton), TRUE); 
... after the checkbutton is created... that makes it default true... 
but again, better would be to be a config parameter.

The orage preferences "number of extra days to show in event list" is limited to 999 ... this is not nearly enough to show some events that i have scheduled far in the future.
This is easily changed in parameters.c: create_parameter_dialog_extra_setup_tab():
from:
dialog->el_extra_days_spin = gtk_spin_button_new_with_range(0, 999, 1);
to:
dialog->el_extra_days_spin = gtk_spin_button_new_with_range(0, 99999, 1);
... which should cover me until long after i'm dead.

But now my problem is that i get a dangerously long list if i disable "only first".
What probably makes more sense is to show ALL events when in "only first" mode and to use the "number of extra days" only when repeated events are shown.
In event-list.c: event_data() 
i added near the end just before the call to app_data():
if (el->only_first) el->days = 999999;
... a hack that works for me...

This now is pretty servicable, but not entirely friendly if it was used by someone else, since it isn't all that clear that the number of days is only used if "first only" is not set.

In the long run, it probably makes more sense to forget about how many days are shown and instead have a user-settable limit on how many events are shown, and a warning if not all events can be shown...

Thanks again!
-Ted Merrill
Comment 7 juha editbugs 2013-11-22 08:41:13 CET
Thanks for the feedback!

Did the following changes to 4.9.10.1:
1) "only first repeating" instead of "only first".
2) "only first" is now settable parameter
3) "number of extra days to show in event list" is now limited to 99999 also in paramter screen.

I am still thinking about the combination of the old setting. It kind of makes sense, but indeed there is risk of confusion since it goes complex. Maybe it actually waould be clearer to change the "only first" to include all events and just list them all (would be easier to code at least).
(There is also a new bug with excluded days, which I need to fix, so 4.9.10.2 will appear soonish.)
Comment 8 juha editbugs 2013-11-22 09:57:03 CET
ok. I think I will change "also old" to be "list all". 
Andonly enable it after "only first repeating" has been selected.
Why would anybody want to see very old repeating appointments?
Comment 9 juha editbugs 2013-11-22 11:35:11 CET
4.9.10.2:

"also old" is now enabled only after "only first repeating" is set. And it defaults to the same value (can be disabled if needed).

"number of extra days to show in event list" is still valid always and it defines how many days forward is shown. using big values is basically the same than show all.

It is not perfect, but should work better. The biggest missing feature is that it shows really the first repeating event occurrency instead teh next active. But you can see that pretty fast by disabling the "only" first" setting.
(seems like I forgot to git push 4.9.10.1)
Comment 10 Liv 2013-11-23 09:14:22 CET
(In reply to juha from comment #8)
> Why would anybody want to see very old repeating appointments?

(In reply to juha from comment #9)
> 4.9.10.2:
> 
> The biggest missing feature is
> that it shows really the first repeating event occurrency instead teh next
> active. But you can see that pretty fast by disabling the "only" first"
> setting.
> (seems like I forgot to git push 4.9.10.1)

Sorry, but I'm a bit lost. What is the reason for not not allowing to show _all_ events when "also old" is enabled (i.e. not allowing to uncheck "only first repeating" and keep "also old" checked)? I think this is can be useful functionality. It can help you check from which start date until which end date a given activity was happening, for example. I don't think it's crucial functionality, but it's still consistent with displaying "all scheduled events" and "all scheduled events (only first repeating)". Otherwise it's confusing. Say, it's confusing to see "first repeating event" but not the "next active repeating event" in the same list (even if it's easy to get either info). 

Maybe, if people really want 4.9.12 behaviour, put in a hidden option that is disabled by default (so that the default is the 4.9.10 behaviour). What do you think? 


(In reply to juha from comment #9)
> "number of extra days to show in event list" is still valid always and it
> defines how many days forward is shown. using big values is basically the
> same than show all.
> 
I think it is worth adding a tooltip documenting this behaviour.
Comment 11 juha editbugs 2013-11-24 15:15:46 CET
I wil check this again after fixing two related bugs.
Comment 12 juha editbugs 2013-11-29 10:03:35 CET
I have to leave this as it is now.
bug 9507 is not properly fixed and if I enable all old events, they appear wrong in this window.

I will rewrite the whole recurring event code and then this will work. But that is major task and I can not do it to this release or Orage.

Bug #9250

Reported by:
Ted Merrill
Reported on: 2012-08-31
Last modified on: 2013-11-29

People

CC List:
1 user

Version

Attachments

Additional information