Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added next run and last run time to timers display. #4503

Conversation

harishanand95
Copy link
Contributor

@dperpeet @petervo I need moment.js in this. i did like this selinux/moment to get moment as of now. Can u tell me how to add moment right way?
@andreasn can u look into designs here?
screenshot from 2016-05-30 16-41-55

also what should I do when it shows last run 46 years ago i.e 1970 ?

@petervo
Copy link
Contributor

petervo commented May 30, 2016

You should rebase this on the latest master.

To use moment you should create a link in your directory to the moment.js file in bower_components and then change the makefile to include it in the bundle for this package. You can see an example of this in either the selinux, kubernetes or ostree package.

@harishanand95
Copy link
Contributor Author

@andreasn why does the disabled section has a different style than enabled and static ?

@andreasn
Copy link
Contributor

andreasn commented Jun 2, 2016

What do you mean more specifically?
That they don't have the "Previous Run" and "Next Run"? or that they are kind of centered in the middle of the table?

@harishanand95
Copy link
Contributor Author

harishanand95 commented Jun 2, 2016

@andreasn Previous run and next run is what I added extra. Is it okay? Is the repetition of the words next run and last run for each of entry good?
and yes I was actually talking about the id's being centered in the middle for disable? Why is that? I felt it would have been nice to have it like enabled and static.

@harishanand95 harishanand95 force-pushed the systemd-nextrun-lastrun branch 3 times, most recently from 295b6b9 to f5f9156 Compare June 8, 2016 08:33
@harishanand95
Copy link
Contributor Author

screenshot from 2016-06-06 15-01-31
screenshot from 2016-06-06 15-12-32

@harishanand95 harishanand95 force-pushed the systemd-nextrun-lastrun branch 3 times, most recently from 79791ab to c5059eb Compare June 15, 2016 10:36
@@ -127,4 +131,4 @@ update-lib:: update-bower
$(JSMODULE) -m -d jquery -o $(srcdir)/pkg/systemd/bootstrap-datepicker.js \
$(BOWER)/bootstrap-datepicker/dist/js/bootstrap-datepicker.js
$(JSMODULE) -m -d jquery -o $(srcdir)/pkg/systemd/bootstrap-combobox.js \
$(BOWER)/bootstrap-combobox/js/bootstrap-combobox.js
$(BOWER)/bootstrap-combobox/js/bootstrap-combobox.js
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing newline

@dperpeet
Copy link
Contributor

looks good, but there is still some work to be done

if (name.indexOf("@") != -1) {

if ( name.slice(-5) == "timer")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whitespace, better: if (name

@harishanand95
Copy link
Contributor Author

harishanand95 commented Jun 16, 2016

screenshot from 2016-06-16 23-10-17

@dperpeet I have changed next run time and last trigger time from relative time to calendar time-stamp.
Sorry abt the indentation and spaces

next_run_time = timer_unit.NextElapseUSecRealtime;
}
unit.NextRunTime = moment(next_run_time/1000).calendar();
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found in init.js that variables are written like next_run_time, active_state, systemd_manager etc while properties of unit are like unit.LoadState, unit.UnitFileState, unit.CombinedState et cetera.
so I think having properties as unit.NextRunTime, unit.LastTriggerTime and variables as next_run_time is better than changing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found in init.js that variables are written like next_run_time, active_state, systemd_manager etc while properties of unit are like unit.LoadState, unit.UnitFileState, unit.CombinedState et cetera.
so I think having properties as unit.NextRunTime, unit.LastTriggerTime and variables as next_run_time is better than changing?

Old cockpit code uses the underscore notation. In newer code, we've switched to the way most of the other js code seems to be written: camelCase.

The exposed DBUS properties (e.g. unit.NextRunTime) are actually a special case, since that is a DBUS convention. Cockpit API will automatically expose the properties if they begin with a capital letter.

Looking at your code again, I believe you did this right - you can remain consistent with the current code.

@dperpeet dperpeet added question Further information is requested and removed needswork labels Jun 20, 2016
@harishanand95 harishanand95 force-pushed the systemd-nextrun-lastrun branch 2 times, most recently from 378cf80 to 4ba4abd Compare June 22, 2016 11:37
b.wait_visible('#services')
m.execute("systemctl start test.timer")
b.wait_in_text(svc_sel('test.timer'), "Today")
b.wait_in_text(svc_sel('test.timer'), "unknown")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

testservices-testbasic-timer

@dperpeet The test checks if test.timer shows "Today" as part of next run and "unknown" in last trigger time.

@andreasn andreasn self-assigned this Jun 22, 2016
@andreasn
Copy link
Contributor

the labels "Next Run Time" and "Last Trigger Time" sounds a bit off to me.
Could it be just "Next Run" and "Last Trigger" instead?
That it's times you'll be able to see from the fact that the labels are times and dates.

@harishanand95 harishanand95 force-pushed the systemd-nextrun-lastrun branch 2 times, most recently from 0447b9a to 5b3bd23 Compare June 23, 2016 12:05
@harishanand95
Copy link
Contributor Author

@andreasn removed "Time" from Next Run Time and Last Trigger Time and also added few deleted new lines that was already present in the code.
screenshot from 2016-06-23 17-43-11

@andreasn
Copy link
Contributor

Can current state be just "State"?

@harishanand95
Copy link
Contributor Author

@andreasn Corrected
screenshot from 2016-06-23 18-19-49

@andreasn
Copy link
Contributor

Looks good to me.
Thanks for fixing this!

@dperpeet dperpeet removed the question Further information is requested label Jun 24, 2016
b.click('#services-filter :nth-child(4)')
b.wait_visible('#services')
m.execute("systemctl start test.timer")
b.wait_in_text(svc_sel('test.timer'), "Today")
Copy link
Contributor

@dperpeet dperpeet Jun 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is our most common source for race conditions in our tests: before you can wait for the text to be there, you should first wait for the element o be present.
In this case, add a line before: b.wait_present(svc_sel('test.timer'))

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, make sure that svc_sel('test.timer') is exactly the selector you want to use here

@harishanand95 harishanand95 mentioned this pull request Jun 28, 2016
6 tasks
@harishanand95 harishanand95 force-pushed the systemd-nextrun-lastrun branch 2 times, most recently from 24deff7 to 9575f8d Compare June 29, 2016 09:21
@dperpeet dperpeet assigned dperpeet and unassigned andreasn Jun 29, 2016
@dperpeet
Copy link
Contributor

There's a merge conflict - can you please rebase on master and squash the commits into one? Thanks!

@dperpeet
Copy link
Contributor

@andreasn Right now this code doesn't update the display, it only shows the time differences (e.g. "in 5 seconds") on load. I think this is ok for now. Do you agree?

@andreasn
Copy link
Contributor

@dperpeet yeah, I think it's all right for now, but I would like it to be fixed as a followup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants