HACKING: improve documentation
This commit is contained in:
parent
b02d2c0d5c
commit
69e417cf19
@ -28,4 +28,4 @@ cabal install
|
||||
Contributing
|
||||
------------
|
||||
|
||||
See [HACKING.md](HACKING.md).
|
||||
See [HACKING.md](hacking/HACKING.md).
|
||||
|
@ -1,6 +1,9 @@
|
||||
HACKING
|
||||
=======
|
||||
|
||||
Check out the [issue tracker](https://github.com/hasufell/hsfm/issues)
|
||||
if you don't know yet what you want to hack on.
|
||||
|
||||
Coding style
|
||||
------------
|
||||
|
||||
@ -8,6 +11,7 @@ Coding style
|
||||
- no overcomplicated pointfree style
|
||||
- normal indenting 2 whitespaces
|
||||
- just make things pretty and readable
|
||||
- use the provided [hsimport.hs](hacking/hsimport.hs)
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
@ -17,13 +21,33 @@ __Everything__ must be documented. :)
|
||||
Hacking Guide
|
||||
-------------
|
||||
|
||||
The main data structure is in [DirTree.hs](src/Data/DirTree.hs), which
|
||||
should be seen as a library. This is then mapped into the Gtk+ GUI at
|
||||
[Gtk.hs](src/GUI/Gtk.hs) and [Utils.hs](src/GUI/Gtk/Utils.hs).
|
||||
The main data structure for the IO related File type is in
|
||||
[HSFM.FileSystem.FileType](src/HSFM/FileSystem/FileType.hs), which
|
||||
should be seen as a library. This is the entry point where
|
||||
directory contents are read and the File type in general is constructed.
|
||||
The File type uses a safe Path type under the hood instead of Strings,
|
||||
utilizing the [hpath](https://github.com/hasufell/hpath) library.
|
||||
|
||||
File operations (like copy, delete etc) are defined at
|
||||
[File.hs](src/IO/File.hs).
|
||||
[HSFM.FileSystem.FileOperation](src/HSFM/FileSystem/FileOperations.hs)
|
||||
which use this File type.
|
||||
|
||||
Only a GTK GUI is currently implemented, the entry point being
|
||||
[HSFM.GUI.Gtk](src/HSFM/GUI/Gtk.hs). From there it flows down
|
||||
to creating a [MyGUI object](src/HSFM/GUI/Gtk/Data.hs#L51) in
|
||||
[HSFM.GUI.Gtk.MyGUI](src/HSFM/GUI/Gtk/MyGUI.hs), which is sort of
|
||||
a global object for the whole window. Inside this object are
|
||||
theoretically multiple [MyView objects](src/HSFM/GUI/Gtk/Data.hs#L101)
|
||||
allowed which represent the actual view on the filesystem and related
|
||||
widgets, which are constructed in
|
||||
[HSFM.GUI.Gtk.MyView](src/HSFM/GUI/Gtk/MyView.hs). Both MyGUI and MyView
|
||||
are more or less accessible throughout the whole GTK callstack, expclicitly
|
||||
passed as parameters.
|
||||
|
||||
For adding new GTK widgets with functionality you mostly have to touch the
|
||||
following files:
|
||||
* [builder.xml](data/Gtk/builder.xml): this defines the main GUI widgets which are static, use the [glade editor](http://glade.gnome.org) to add stuff
|
||||
* [HSFM.GUI.Gtk.Data](src/HSFM/GUI/Gtk/Data.hs): add the widget to e.g. the MyGUI type so we can access it throughout the GTK call stack
|
||||
* [HSFM.GUI.Gtk.MyGUI](src/HSFM/GUI/Gtk/MyGUI.hs): add initializers for the GUI buttons to be fetched from the GTK builder.xml file
|
||||
* [HSFM.GUI.Gtk.Callbacks](src/HSFM/GUI/Gtk/Callbacks.hs): define the callbacks and the actual functionality here
|
||||
|
||||
Note that the main data structures are still a bit in flux. Join
|
||||
[the discussion](https://github.com/hasufell/hsfm/issues/12) on how to
|
||||
improve them.
|
||||
|
Loading…
Reference in New Issue
Block a user