315 lines
11 KiB
Org Mode
Raw Permalink Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

#+STARTUP: indent
* TODO [#A] Refine UI :version_1.0:
The UI is a bit messy right now, especially the aspect/antiscia
changer buttons and the display theme changer combo box on the chart
** TODO Redesign display theme and house system chooser
For these, a menu button with a popover may be the best option. That
would need a nice icon, though (possibly with some planet and aspect
** TODO Redesign view switcher
The current view switcher (a menubutton) doesnt show its accels
(maybe because of the radio menu items?). Maybe it should be put back
to a GtkStackSwitcher. The original place for that is now used up by
the window title and the chart name, so a new place must be found for
** DONE Preview images
There is no preview image right now in the list view. AgChart may have
an ag_chart_get_pixbuf() function that generates the preview image. It
should use a very limited display theme (maybe with Sun as its only
planet and no aspects nor antiscia). Generating this pixbuf on the fly
would be very resource intensive, so caching should also be
introduced. This way ag_chart_get_pixbuf() should check the cache dir
first. The cached file's name should be generated from the chart
related data, location and timestamp. Changing the name or city name
would not change the chart itself. If this seems to be slow for bigger
amount of charts, a worker idle function may be introduced, as
suggested in ag_window_load_chart_list().
** DONE Update help
After the chart editing part of the UI is done, the help screenshots
must be taken again.
** DONE Add a progress bar for the list screen
When there are many charts, loading the previews may take long. A
progress bar should show the state of loading.
Another (slightly better) idea is to load charts to the list withou
previews, and load/generate the images afterwards. The same idle
functionality could do this, either.
* Ease navigation
Since the migration to GtkIconView the chart list became very hard to
** Chart search :version_1.0:
The chart list should be searchable either by starting typing or with
a key combination, like Ctrl+F.
** Configurable preview size :version_2.0:
Chart preview size should be configurable. However, below a certain
value (I'd guess around 150px) it would become unreadable. The lower
boundary should be around 3 times the checkbox size (right now that is
set to 40px). Under a certain value (e.g. when a degree's size gets
below 2px) a warning should be issued.
* Issue an error message for missing resources :version_1.0:
If a gres:// link cannot be loaded by the XML loaders, Astrognome
should issue an error message, stating that this is either a bug in
the current chart theme (in 2.0+) or in Astrognome itself.
* [#C] Port to other Linux distros :version_1.0:
It is possible that other distros wont handle the current
installation well. To be tested, especially on target platforms.
* Package for different distros [0/5] :version_1.0:
- [ ] Fedora
- [ ] Debian
- [ ] Ubuntu
- [ ] Arch
- [ ] Gentoo
* DONE Preview images :version_1.0:
The database (or more likely the cache directory) should contain a
preview image of each chart. The chart list screen should show a
small box with the name and the preview image. Upon mouseover the
image should blur/darken and some chart data (maybe customizable?)
may get drawn over it.
* Customizable accels :version_2.0:
Accels should be customizable, and they may also get some more sane
defaults. Right now they are imitating Placidus, which, in turn, is
not very intuitive.
The accel customization may get its place on the Preferences dialog.
* Chart cleanup :version_1.0:
The chart is still messy under some circumstances, especially with the
"Everything" display theme. Multiple conjuctions, or conjuctions with
the Vertex and the descending Moon node (these latter two are not
subject to the dist calculation) cause serious overlaps.
Vertex and the descending node can be added to the body list, thus
they would get their own dist value. However, if a new theoretical
point gets added to Astrognome (like the East point soon), it will
make another exemption, which is pretty unlucky.
The icon size is currently a parameter of the XSLT. It may become
dependent on the chart's size (currently, for the big chart it's
* DONE Chart manipulation :version_1.0:
* Different chart types [/] :version_2.0:
- [ ] Synastries
- [ ] Transits
- [ ] Progressions
* Time stepping :version_1.0:
Stepping through time without actually modifying the saved chart
data. The result would be a moving chart while it won't complain
about saving upon close.
* Application settings :version_2.0:
- [-] Default display properties [1/10]
- [X] Traditional view
Personal (inner) planets, Ptolemaic aspects only, nothing else
- [ ] Show/hide major aspects
- [ ] Show/hide minor aspects
- [ ] Show/hide astiscia/contrantiscia
- [ ] Show/hide personal planets
- [ ] Show/hide outer planets
- [ ] Show/hide dwarf planets and asteroids
- [ ] Show/hide fixed stars
- [ ] Show/hide hidden ascendant
- [ ] Show/hide vertex/anti-vertex
- [ ] Different symbols for some planets [0/3]
- [ ] Uranus
- [ ] Pluto
- [ ] Pholus
* Regiomontanus import :version_2.0:
* Chart export as different image types [3/3] :version_1.0:
- [X] SVG
- [X] JPEG
- [X] PNG
Other formats supported by GDK-PixBuf are considered useless, and
most people should be able to open these types.
* Chart printing :version_2.0:
* [#C] Port to Windows :version_2.0:
* Future aspect table ideas
The aspect table may be redesigned a bit. Currently its just a
GtkGrid with images or characters.
** How about extending GtkGrid itself?
** Column/row highlighting
If possible, the row and column where the mouse points to, should
be highlighted. This, of course, should have a setting to disable
this behaviour. Another option is to create divisor lines between
the rows and columns.
** Aspect/antiscion changer
The aspects table should utilise the same changer as the chart to
show different relations between the planets.
** Apply display themes
The aspect and antiscion table should use the same display theme as
the chart. If a planet, aspect or antiscion axis is not in the
display theme, it should not be visible on the table.
* Display themes
Currently, display themes can display/hide chart parts based on CSS
rules. Maybe actually removing planets from the chart would make
more sense. This, however, is not possible with aspects and
antiscion axes. SWE-GLib should provide a solution to this.
Planet visibility checklist:
- planets are visible by default
- is the planet excluded from the theme? If so, add rule
.planet-<planetname> { visibility: hidden; }
Aspect visibility checklist:
- aspects are visible by default
- is this type of aspect has to be visible? If no, add rule
.aspect-<aspecttype> {visibility: hidden; }
- is planet1 visible? If no, .aspect-p-<planet1> {visibility: hidden; }
- repeat for planet2
Antiscion visibility checklist:
- same as for aspects
** Implement the original Astrognome theme
The software created by Jean-André Santoni has its own list of
planets, which is more than Classic, but obviously less than
** Arabic parts and fixed stars :version_2.0:
As soon as SWE-GLib supports them, of course
* Chart themes
This can get hard. What if Astrognome 1.0 supports 10 planets, 2.0
supports 15, and I use a chart theme for 1.0 in 2.0 (or vice verse)?
In such cases a warning should be presented to the user.
I may use fallback icons (yeah… how?), but they may look really ugly
on the custom theme.
* Add the East point :version_2.0:
SWE-GLib doesnt support it yet. It is the equatorial ascendant, and
is calculated by Swiss Ephemeris, which presents it in ascmcs\[4\].
* Support for Julian calendar :version_2.0:
It may be usable for only in the backends, like when importing a
Placidus file with Julian date. SWE-GLib doesnt support it yet.
* Cloud export (and maybe import) :version_2.0:
GNOME Online Accounts supports some popular cloud services. It may
be a good idea to implement saving, and possibly loading to/from
* DONE Dynamic chart size :version_1.0:
Right now some planets may disappear from the chart because they get
too far from the chart ring (due to @dist).
The maximum @dist value can be get with the following XPath
/chartinfo/bodies/body/@dist[not(. < ../../body/@dist)][1]
* Default location :version_2.0:
This is needed for the Now cart. A default location should be set in
the preferences window, which can be used by either Now charts and as
a default for new charts, although Im not sure about the latter.
* Create nice icons :version_1.0:
Most icons, especially for planets, are ugly. @droid242 is already on
it to create some nice ones.
* Create an antiscia table :version_1.0:
There is only an aspects table present. We need an antiscia table,
* Apply dislay theme to aspects/antiscia tables :version_1.0:
* Create a nice help file :version_1.0:
* Add printing support :version_2.0:
That sounds nice, but what should a printed chart contain? Chart and
aspects, for sure, and some chart data, too. Maybe an antiscia table,
if they are displayed at all.
* Add a chart information to the chart tab :version_1.0:
In the chart tab, only the name of the chart can be seen. A chart info
display, like Placidus status bar, would be nice.
One idea is to use an info button on the header bar that displays the
chart info in a PopOver. This should be bound to an intuitive key
binding (Alt-Enter, Ctrl-I, I dont know). A status bar is the other
option, but that doesnt seem to GNOMEish…
* Tables of planet, house cusp, fixed star and arabic lot positions
This should be on a new, separate stack child (maybe one child for
each table).
* Create a DBUS interface for the Now chart
It would be nice to have an interface that could start Astrognome and
immediately go to the Now chart.
* Copy chart to clipboard
Saving charts as images is one thing, having them on the clipboard is
another. I can't tell a valid usecase, though…
* Create a desktop notification after save/export
This would make the user able to display the new file in a file
manager, so it can be shared, copied over, whatever.