synfig / synfig-docs-dev Goto Github PK
View Code? Open in Web Editor NEWDeveloper's documentation of Synfig
Home Page: https://synfig-docs-dev.readthedocs.io/
Developer's documentation of Synfig
Home Page: https://synfig-docs-dev.readthedocs.io/
By following the building instructions for CMake on Linux, I got nothing in the proposed "cmake-build" folder after run cmake ..
.
I want to write more detailed docs for the rendering process and cobra engine. Where should I put it? The Code Structure
section doesn't seem appropriate, because I will be explaining both the algorithm and the code, and the page will become really long.
Toolbox shortcuts improvement was implemented & merged back in 2020 in this PR synfig/synfig#1823
The proposal outlined in this page has already been resolved and I believe that it can safely be deleted from the dev docs.
@ice0 Index page isn't updated with a link to this page. Do I have to update index.rst
like this?
common/Setting up QtCreator IDE.rst
Originally posted by @Keyikedalube in #60 (comment)
Repos are opt-in now
Otherwise just labelling issues won't count toward Hacktoberfest
I'm new to RST so I didn't bother to get into that fancy doc page structuring instead heavily focusing on writing the content PR #60
I just checked out the Blender doc and I noticed it's actually possible to break a major topic into sub-topics.
A good reason why breaking current synfig IDE page into:
Index
> IDE
> NetBeans
> QtCreator
> Building Synfig
is to let the target user choose a subtopic based on their preference. Blender also did a nice trick of adding next->next page link directly after the sub-topic page conclusion. In our case, we can add Building Synfig
page link on NetBeans
conclusion page because there's no point for the NetBeans user to read QtCreator page using the default (?) Next link. Whereas, QtCreator
can just follow through to Building Synfig
page naturally :)
https://docs.blender.org/manual/en/latest/index.html
After the user sets up his IDE, he should be guided directly to Code structure
Building Synfig and Dependencies are redundant because his IDE already takes care of that
Shouldn't Contributing guidelines be on top?
Because this topic doesn't really have a chronological connection with previous and next. It's standalone just like Code of Conduct
Group Building Synfig (<- rename it to Autotools) and Synfig Using CMake together
Just like NetBeans and QtCreator are grouped together under a single IDE topic
Merge Preparing Environment sub-topic from Autotools and CMake together in one single section under Building Synfig category
Move Package using CMake sub-topic from Synfig Using CMake to Packaging Synfig for distribution
So here's an outline of how I think the new ordering should be:
- Contributing guidelines
- Setting up your preferred IDE
- Code structure
- Building synfig
> Preparing environment
> Autotools
> CMake
- Packaging synfig
> Autotools
> CMake
- Tutorials
...
@morevnaproject It seems like the ending word in building doc line 213 is incomplete
Let's suppose you made changes in synfig-studio and want to rebuild it without re
There should be a code of conduct as I saw on any other open source org. So it will be easy for newcomers to know what they should follow and what they should not ๐
I suggest to remove "Table of Mappings" headers from child pages of this section - https://synfig-docs-dev.readthedocs.io/en/latest/projects/lottie/layers.html
Otherwise, those headings are cluttering index:
I have found some notes about structure of "synfig-studio" - https://pastebin.com/LrdkJc4q
It would be nice to add them to "Code structure" section - https://synfig-docs-dev.readthedocs.io/en/latest/common/structure.html
Duplicating text below just in case if the pastebin link become unavailable:
[Core model]
../synfigapp/main - stores information for the entire application (fg/bg colors, width, settings, input devices)
../synfigapp/instance - information unique for each instance (root canvas, canvas interface list, selection manager, save/save_as)
../synfigapp/canvas_interface - information unique to each exported canvas (I believe opening a canvas in the canvas browser loads a new interface, but not a new instance)
;* current time (at playhead), editing mode (normal/animated)
;* wrappers for various actions, such as adding layers or adding/setting/converting valuenodes
../synfigapp/value_desc - link to a value node (eg. layer.param_name parent_value_node.param_index; animated.waypoint; canvas.param)
valuelink - (?) Valuebase link. Inherits from synfig-core, why is this in studio/gtkmm?
../synfigapp/inputdevice - input devices
../synfigapp/settings - settings
../synfigapp/selectionmanager (look-into) - selection manager interface, null selection manager
../synfigapp/editmode - edit mode (normal, animated)
../synfigapp/uimanager - interface class for a UI interface (Dialogs such as yes_no, yes_no_cancel, etc) The actual UI interface used is defined elsewhere
[Action system]
../synfigapp/action - defines types of actions: action, undoable, canvasspecific, super, group
../synfigapp/action_param - defines parameters for action
../synfigapp/action_system - action system and passive grouper
../synfigapp/actions/* - individual actions
[======================= MISC =======================]
../synfigapp/general.h, general.h - gettext macros
../synfigapp/cvs - cvs system
../synfigapp/timegather - (?)
[======================== UI ========================]
[Core UI]
main - entry point, creates an instance of App
app - initializes the application (loads all UI components)
;* manages instances (which one is selected), canvas views, preferences
autorecover - automatic recovery (references app, uses instance)
devicetracker: save/load preferences and init extended input devices
instance - (?) inherits from synfigapp::Instance
[Misc UI]
splash - splash screen window
about - about dialog
adjust_window - (?) Adjustment Window, uses scale factor
onemoment - window saying "one moment, please"
dialog_setup
widget_filename
iconcontroller - pairs icon files with gtk names. Can get an icon for a valuenode or layer
[Canvas view]
canvasview - makes the menus; receives on_duck_changed events; creates a workarea
framedial - a table with play/forward/backward buttons
keyframedial - buttons for seek next, previous, lock
resolutiondial - Increase/decrease/ use low res
toggleducksdial - Show/hide various types of ducks
zoomdial - zoom in/out/etc
[================== Ducks and Tools =================]
[Workarea]
workarea - [inherits from duckmatic and Gtk::Table] the workarea
event_layerclick - event for layer clicked
event_mouse - stores the mouse button pressed and any modifier keys
eventkey - key of events (e.g. refresh, stop, undo, workarea clicked...)
[Ducks]
duckmatic - manages ducks, ducks_dragger, strokes, and Beziers
;* (Also defines duckdrag_base and translate)
;* When a duck drag is done, passes the new locations of the duck to canvasview (reverse manipulation function)
duck - a duck (stores either a point or an angle of rotation)
ducktransform_* - define duck transformations. These are used to transform the ducks so they line up with a transformed object on-screen
[Toolbox]
toolbox.h - the toolbox
widget_defaults - the fill/outline/etc selection widget in the toolbox
widget_tooloptions
[State system]
smach.h - typedef etl::smach<CanvasView,EventKey> Smach; // [state machine]
statemanager -keep track of states
state_* - all of the states
;* states such as normal and rotate define their own duck draggers
../synfigapp/blineconvert - used by draw tool to convert list of points to a bline
[================ Docks and Dialogs =================]
[Docks System]
dockmanager - gets size, position, or contents of a dockable, registers/unregisters dockables, find dockable or DockDialog, present a given dockable (takes a name)
dockable - generic class for dockables. "dnd" is "drag-and-drop"
dockbook - a notebook (tabbed group) of docks
dockdialog - a window, presumably containing various dockbooks (tabbed groups) of dockables
dock_canvasspecific - base class for canvas-specific dockables
[Docks]
dock_info - (shows mouse position and the color under it)
dock_navigator
dock_history
dock_curves - uses curves widget + some time sliders
widget_curves
[Tree docks]
canvastreestore- (?)
dock_canvases - canvas browser
dock_timetrack
widget_timeslider - the time track, labeled at regular intervals
dialog_keyframe
dialog_waypoint
widget_keyframe_list
widget_waypoint
widget_waypointmodel
keyframeactionmanager - "Add new keyframe" and "keyframe properties" buttons, keeps track of keyframe tree
keyframetree - TreeView of keyframes
keyframetreestore - stores keyframes (is there any point to keyframe_tree_store_class_?)
dock_metadata
metadatatreestore - model for metadata tree
dock_layergroups
layergrouptree - TreeView of layer groups
layergrouptreestore - model for layer group tree
dock_children
childrentree - TreeView of canvas' children
childrentreestore - model for children tree
dock_layers
dock_params
layerparamtreestore - model for layer params tree
layertreestore - model for layers tree
layertree - returns TreeViews of layers and params
layeractionmanager - keeps track of layer tree; creates actions relating to layers
[Widgets for valuenodes]
widget_value - picks the right widget for a valuenode
widget_canvaschooser - Canvas valuenode (select canvas)
widget_color
widget_coloredit
widget_gradient - gradient valuenode
widget_compselect - select the composition (file) being edited
widget_distance - spinbutton (for type real when it's a distance)
widget_enum - enum type values
widget_time - time valuenode
widget_vector - (aka point)
[Dialogs]
dialog_color - select a color
dialog_gradient -set a gradient
canvasoptions -toggles grid snapping, visibility, and size
canvasproperties - name, id, info, and metadata
[======================= Other ======================]
[Renderer system] - I have not looked into this much
asyncrenderer
preview - Preview class and the preview widget
renddesc - RendDesc widget (Render menu - why is it called desc?)
renderer_* - rendering system
workarearenderer
dialog_preview
dialog_targetparam - parameters for rendering target
[Audio system] - Did not look at, as it is disabled
audiocontainer
dialog_soundselect
widget_sound
[Modules]
./mod_mirror/ - Mirror tool
./mod_palette/ - Palette
module - interface class for models: has methods start() stop()
[======================= MISC =======================]
ipc - (?)
keymapsettings - (Defines the structures for managing key map settings) affects accelerators
groupactionmanager - (look-into) references LayerGroupTree
compview - Does not appear to be used anywhere
Currently the order of the topics doesn't really follow a chronological path.
For example "Setting up your preferred IDE" relies on prerequisites from "Building Synfig using command line"
This could lead to wrong installation (as seen on Windows) and discourage new contributors.
Also, mix of Tutorials, Release Procedures, etc...
The general order should be:
Also "List of Hotkeys" should be removed from dev's documentation and present only in user's manual ๐
I propose to reorder the topics as follow:
Current | Proposed |
---|---|
Contributing guidelines Setting up your preferred IDE Code structure Building Synfig using command line Packaging Synfig for distribution Tutorials Release procedure Roadmap Synfig File Format (.sif) Google Summer of Code Projects List of hotkeys Random notes Code of Conduct |
Contributing guidelines Building Synfig using command line Setting up your preferred IDE Code structure Synfig File Format (.sif) Tutorials Packaging Synfig for distribution Release procedure Roadmap Projects Google Summer of Code Random notes Code of Conduct |
It would be nice to use simple icons instead of "Supported" / "Not Supported" words here - https://synfig-docs-dev.readthedocs.io/en/latest/projects/lottie/supported.html
This will increase readability a lot. ^__^
Well I know why I am getting the following warning
Warning: Your Pipfile requires python_version 3.5, but you are using 3.6.7 (/home/a/.local/share/v/s/bin/python).
$ pipenv --rm and rebuilding the virtual environment may resolve the issue.
$ pipenv check will surely fail.
I think as we are using $ pipenv install --three
this will by default make virtual environment with python3.x
and pipfile.lock can take care of everything else
I realized QtCreator by default uses spaces for indentation. Users would have to manually duplicate Qt default C++ Code Style settings and change it to tab character for synfig project. A manual guide could be written about this in a new section under QtCreator topic :)
These things need to be done:
I came across this: https://docs.readthedocs.io/en/stable/guides/autobuild-docs-for-pull-requests.html
Can this be integrated to the documentation?
Qt Creator supports CMake out of the box. It'd be nice if a new page about it is maintained on the doc page.
Maybe break the IDE page into two parts
One could create their own custom kit for Synfig in case they want to modify the CMake generator from the default one provided by Qt Creator (on Linux it's Unix Makefiles).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.