shadowkyogre / chronoslnx Goto Github PK

Bug is in current version of application and in wip branch. Steps to prove this:

1. Open chronoslnxlib/csscalendar.py
2. Comment out the highlighted lines in the link https://github.com/ShadowKyogre/ChronosLNX/blob/wip/chronoslnxlib/csscalendar.py#L14-L20
3. Run ChronosLNX (via the wrapper *.py)
4. Try resizing the window in any direction

Expected result: Window resizes without delay
Actual result: Window lags while resizing

Proposed solution: Store whether a date is "today" so the today checks aren't done on every redraw.

While I was in the process of refactoring my code, I noticed that there was a drastic slowdown in the calendar widget when lunar return display was enabled. This probably has to do with how the program checks for lunar returns, which is by doing a linear search of the list.

I'm thinking this could be solved by either doing a binary search of the list or just doing direct calculations.

Exactly what the title says, and it probably has to do with how Qt handles window closing. I could do either one of two things:

• Just update the main dialog with the info for the date, but that would make right-clicking the calendar hopeless.
• Make the info dialog block input to all other windows, which I think would prevent the app from closing.
• Aaaand...there's probably some other solutions I'm not aware of.

It should always be from the sunrise for that given day. Related to this bug is the fact that revjul_to_datetime assumes that it should always be given in localtime, which is not the case if the app is used to test against locations that don't actually represent the user's location. This'll be fixed tomorrow.

In KDE, Shutdown and Reboot fail because of it grabbing...um...something. Not sure exactly how or why.

This issue doesn't appear in non-KDE setups with pm-utils, as far as I'm aware.

For those types of alarms for a feature in the future (not to mention, it'd be handy for new moon/full moon cleanups since we're using swisseph).

Relevant links:

• https://groups.yahoo.com/neo/groups/swisseph/conversations/topics/3823
• http://bazaar.launchpad.net/~keturn/py-moon-phase/trunk/annotate/head:/moon.py
• http://stackoverflow.com/questions/2526815/moon-lunar-phase-algorithm

The retrieval of the data should not be dependent on the GUI. So instead, it should be something like this:

(config object)
(core object)
/ |
qt cli some other UI

So that way the data can be retrieved across multiple UIs.

Not to mention it seems quite unclean to have it dependent on the GUI anyway. Also, the config object should probably be less qt dependent so it can be used across different UIs.

https://bbs.archlinux.org/viewtopic.php?id=122317

This is a similar issue. Not sure how to fix it so far.

Actually write up some decent documentation and make that Help button actually useful...

Currently, the events are stored in a csv file in the following format
Enabled,Date,Hour,Event Type,Text

And the available values for date and hour are as follows:
Date:

• Sun
• Moon
• Mars
• Mercury
• Jupiter
• Venus
• Saturn
• Everyday
• Weekends
• Weekdays
• Custom (date)

Hour:

• Sun
• Moon
• Mars
• Mercury
• Jupiter
• Venus
• Saturn
• Every planetary hour
• Every normal hour
• When the sun rises
• When the sun sets
• Custom (time)

This is a gross oversimplification and should also have more triggers that would be also needed, such as:

• Planetary datetime (already kind of implemented)
  • date (probably as an rrule)
  • time (might be an rrule, not absolutely sure)
• Aspect
  • Aspecting planet
  • Aspect
  • Aspected planet
  • second planet is natal
• Moon phase
  • phase (note: this would be the most 'perfect' for each phase. EG: waxing crescent would be 25% illuminated)
  • days before return
• Planetary returns (for now, just sun and moon)
  • planet
  • days before return

The best way for this to be reworked would be to have the csv file sectioned as:
Enabled,Trigger Type,Trigger Opts,Event type,Event Opts
or
Enabled,Trigger,Event type,Event Opts

Either method would involve probably cramming in the options using json or something. Another option would be to just...pickle it. But pickling is ugly too

Some users might not need it and it maybe seen as visual clutter.

In addition, the update interval for redrawing the chart should be at least one minute instead of one second. This is because the houses don't "move" that fast. Neither do the planets.

Steps to reproduce

1. Launch the program sometime before the sun rises for the day
2. Wait until it becomes sunrise

Expected:
The hours are updated for the day now that sunrise has passed.

Actual Result:
The hours aren't updated.