-The text widget is a text viewer/editor that operates on a string -that may contain multiple lines. - -
-PCB_DAD_TEXT(table, user_ctx) -creates a new text widget and installs user context. - -
-The only callback the user may provide is user_free_cb which is called -when the text widget is destroyed. Other than this, DAD caller code can not -react on events happening in the text. - - - Index: trunk/doc/developer/dad/widgets.html =================================================================== --- trunk/doc/developer/dad/widgets.html (revision 34886) +++ trunk/doc/developer/dad/widgets.html (nonexistent) @@ -1,275 +0,0 @@ - -
- --Input widgets are leaf widgets in the widget tree that typically -implement a field where user input takes place. Available -input widgets are: -
| creation call | screenshot (gtk2) | description - |
|---|---|---|
| PCB_DAD_LABEL | | single line or multi line of plain text, from a string - |
| PCB_DAD_LABELF | | single line or multi line of plain text, using printf formatting - |
| PCB_DAD_ENUM | | select one value from a fixed set (typical implementation is a combo box) - |
| PCB_DAD_BOOL | | checkbox - |
| PCB_DAD_INTEGER | | set an integer value - |
| PCB_DAD_REAL | | set a real (floating point) value - |
| PCB_DAD_COORD | | set a coordinate value - |
| PCB_DAD_STRING | | input single line string value (plain text) - |
| PCB_DAD_BUTTON | | clickable push button - |
| PCB_DAD_PROGRESS | | progress bar - |
| PCB_DAD_TREE | | a list, table or tree of text data - |
| PCB_DAD_PREVIEW | | drawing area - |
| PCB_DAD_PICTURE | | static bitmap image - |
| PCB_DAD_PICBUTTON | | static bitmap button - |
| PCB_DAD_COLOR | | color button and selector - |
| PCB_DAD_TEXT | | text box (text editor) - |
-Draw a label, which is not an input field (unmodifiable by the user). -text is copied by the call into a new allocation. The only -control text accepts is '\n', which is line break. - -
-Same as PCB_DAD_LABEL() but the text is rendered using printf. Note: -printf args, including the format string, shall be in parenthesis, e.g. -
-PCB_DAD_LABELF(dlg, ("Cats: %d", num_cats))
-
-
--The user can choose one value out of an ordered list of strings. The list -is passed as a NULL terminalte char * array. The value -of the enum is an integer index into that array, 0 being the first string. -
-Typical GUI implementation is a combo box, without text editing. - -
-Ask the user about a boolean value, typically using a checkbox. The value -of the bool is an integer which is either 0 or 1. - -
-Ask for an integer value, between a minval and a maxval. -The value is an int, which is not guaranteed to be wider than a -16 bit signed value. -
-Typical GUI implementation is a text entry, often upgraded with small buttons -to increase or decrease the value ("spinbox"). - -
-Ask for a REAL (double precision floating point value), between a minval -and a maxval. -
-Typical GUI implementation is a text entry, often upgraded with small buttons -to increase or decrease the value ("spinbox"). - - -
-Ask for a coordinate value, between a minval and a maxval. -The value is pcb_coord_t. -
-Typical GUI implementation is a text entry that understands unit suffix, -often upgraded with small buttons to increase or decrease the value ("spinbox"). - - -
-Ask for a single line of plain text input. -
-The value is a dynamically allocated string. - -
-A push button the user can click on. text is not allocated or copied -(shall be a static const string or allocated/free'd by the user). -
-There is no value, the only interface is the change callback. - - -
-Present a progress bar which is not an user input. value is a -REAL value between 0.0 and 1.0. When the code changes the value, the -GUI makes sure the dialog box is drawn and flushed, because typical use -is in a busy loop calculation. - -
-Present a tree-table with cols columns of text objects. When -first_col_is_tree is 1, the first column works as a tree, with -indentation and/or tree graphics and logics for collapsing/expanding subtrees. -If opt_header is not NULL, it is a NULL terminated static const -array of header strings describing the table header to be displayed, in as -many strings as cols specified. -
-A special cases: -
-
| case | parameters - |
|---|---|
| plain flat list | cols=1, first_col_is_tree=0 - |
| tree-only | cols=1, first_col_is_tree=1 - |
| table-only | cols>1, first_col_is_tree=0 - |
-Manipulating the data and the view are both done using - special tree-table macros. - -
-Present a drawing area with callbacks to the host code to handle drawing: -
| argument | meaning - |
|---|---|
| expose_cb | called when (parts of) the preview needs to be redrawn - |
| mouse_cb | called on mouse events - |
| free_cb | called before the widget is destroyed - |
| initial_view_box | set the initial zoom/pan to match the view box specified in drawing units - |
| min_sizex_px | widget minimum size in x direction (width), in pixels - |
| min_sizey_px | widget minimum size in y direction (height), in pixels - |
| user_ctx | opaque pointer that is passed to every callback - |
-The pointer to a static xpm image is stored in the enumerations field. The image -is displayed in a widget without any other decoration. - -
-The pointer to a static xpm image is stored in the enumerations field. The image -is displayed in a button tat behaves exaclty as a normal BUTTON in all other -regards. - -
-A button that has a solid region of the color specified in value. Unless -read-only (PCB_HATF_CLR_STATIC), when the user clicks the button a -HID-specific color selector dialog is popped up where the user can -specify a new color. - -
-Free form multiline text string, edited using a HID-builtin text editor. Line -terminator is \n. -
-TODO: accessor macros - -
| creation call | screenshot (gtk2) | description - |
|---|---|---|
| PCB_DAD_BEGIN_HBOX |  | arrange children widgets in a horizontal list - |
| PCB_DAD_BEGIN_VBOX |  | arrange children widgets in a vertical list - |
| PCB_DAD_BEGIN_HPANE |  | split the parent box horizontally into two sections; the split ratio is adjustable Note: "left" and "right" are the first and second children (left and right sibling) of the widget tree - |
| PCB_DAD_BEGIN_VPANE |  | split the parent box vertically into two sections; the split ratio is adjustable Note: on the screenshot "left" and "right" are the first and second children (left and right sibling) of the widget tree - |
| PCB_DAD_BEGIN_TABLE |  | arrange children widgets into a n*m matrix, allocate each cell the same size Note: on the screenshot the table is set up to have 3 columns - |
| PCB_DAD_BEGIN_TABBED |  | create a "tabbed notebook" view, each children is a new tab - |
-hbox, vbox and table share a few common compflags, that are defined in -hid_attrib.h, pcb_hatt_compflags_t. The explanation of what each flag does -can be found there. The most commonly used ones are PCB_HATF_FRAME, -PCB_HATF_SCROLL, PCB_HATF_EXPFILL. -
-If PCB_HATF_EXPFILL is set, the given box tries to expannd and fill, using -up all available space in its parent widget. If multiple sibling boxes -have this flag set the behaviour is unspecified; some HIDs may prefer -to grow only one box, others may evenly distribute the avaialble space -among boxes. If this flag is not set, the box uses only as much space -as its children widgets require. - - -
-Arrange children widgets in a horizontal or vertical row. - -
-Expect exactly two child widgets. Arrange them horizontally, with -a widget in between them that allows the user to change the space allocation -between the sides. - -
-Expect exactly two child widgets. Arrange them vertically, with -a widget in between them that allows the user to change the space allocation -between the sides. - -
-Place children widgets in a table with cols columns. Widgets are -placed by filling up rows first. If there are not enough widget to finish -the last row, rightmost columns are left empty. -
-The table is homogenous, which means the cell size is the same for all cells -and is either determined by the size of the smallest cell content or if -the table fills in a larger widget space than its minimal size, then cell -space is evenly distributed. - -
-Creates a "tabbed notebook": each child widget ends up on a new -page, there is only one page shown at a time and there is a GUI way -to switch page (the tab). The list of tab names is passed as tabs, -as a NULL terminalte char * array. The number of tab names must match -the number of children widgets. The value -of is an integer index into that array, 0 being the first tab. -
-If compflag includes PCB_HATF_HIDE_TABLAB, the tab graphics are hidden - -no tab labels printed and the user can not click to switch tab. This is -useful for dialog boxes where the code needs to present different tabs -using the same screen estate. -
-If compflag PCB_HATF_LEFT_TAB is set, tab labels are presented in a vertical -row on the left side of the widget. This is useful if there are a lot of -tabs with short names. - -
-Create a new widget by duplicating an existing one. attr is the -widget ID of the existing widget. If the widget being duplicated is a -BEGIN*, it will need a corresponding PCB_DAD_END. - - -
-The raw macro call is PCB_DAD_SET_VALUE, which can change (overwrite) a named -field of the current (last created) widget. The following table lists high -level macros that usually call PCB_DAD_SET_VALUE on a specific field. -
-
| name | description - |
|---|---|
| PCB_DAD_COMPFLAG(table, val) | set all compflags - |
| PCB_DAD_MINVAL(table, val) | change the minimal value for numeric input - |
| PCB_DAD_MAXVAL(table, val) | change the maximal value for numeric input - |
| PCB_DAD_DEFAULT_NUM(table, val) | set the default (initial) value for numeric fields (integers, coords, bools, floats) - |
| PCB_DAD_DEFAULT_PTR(table, val) | set the default (initial) value for pointer fields (e.g. strings) - |
| PCB_DAD_MINMAX(table, min, max) | hange both the minimal and the maximal value for numeric input - |
| PCB_DAD_CHANGE_CB(table, cb) | cb is a function that shall be called upon any change to the widget value - |
| PCB_DAD_HELP(table, val) | set the help text (typically presented as a tooltip) - |
-There is a dad() action in the dialogd plugin that exposes all the above macros. -The dialog table ID is am arbitrary unique string and commands are the macro -names without PCB_DAD, written in lowercase. -
-Please refer to scripting rosetta -project for examples. An example of a typical small dialog box is the -unit conveter -script. - Index: trunk/doc/developer/dad/run.html =================================================================== --- trunk/doc/developer/dad/run.html (revision 34886) +++ trunk/doc/developer/dad/run.html (nonexistent) @@ -1,75 +0,0 @@ - -
- --Dialog box data is created in memory using either PCB_DAD_DECL(table) or -PCB_DAD_DECL_NOINIT(table). The first call declares and initializes all -variables and is suitable for when the dialog box is hosted directly in -(static) global variables or as local variables of a function. The _NOINIT -version omits the initialization and is suitable for declaring the dialog box -as part of a struct. In the latter case the caller needs to make sure all -dialog box fields are initialized to zero. -
-How user attached data and memory allocation is managed is described in -the DAD closing sequence document. - -
-The typical sequence of running a non-modal dialog is: -
-(declaration) -(filling in with widgets) -PCB_DAD_NEW(); --
-The modal argument of PCB_DAD_NEW() is pcb_false. The dialog box -is created in the PCB_DAD_NEW() call, which returns immediately, leaving -the dialog box running in the background. -
-The typical sequence of running a modal dialog is: -
-(declaration) -(filling in with widgets) -PCB_DAD_NEW(); -PCB_DAD_RUN(); -(process the return value of PCB_DAD_RUN()) -PCB_DAD_FREE(); --
-The modal argument of PCB_DAD_NEW() is pcb_true. PCB_DAD_RUN() -will not return until the user gets the modal dialog box closed (either -by the VM or by the code). -
-There is an alternative sequence using PCB_DAD_AUTORUN() but it saves -only one line compared to the above code and makes handling the return -value somewhat more complicated. Thus the above sequence should be -preferred. - - -
-After creating the dialog box widgets in memory, the actual GUI can be -started up by a call to action dad(dialog_name, run, title) or -dad(dlgname, run_modal, title). -
-The difference between run and run_modal is when the -call returns: -
-There are two ways a DAD can be closed: -
-There are four sets of structures/allocations associated with a DAD: -
- -There is only one allocation sequence: -
-In other words, one PCB_DAD_NEW() needs to have exactly one PCB_DAD_FREE() -pair. If PCB_DAD_FREE() is called while the dialog is on (code close), -the dialog is closed and the callback function is called (unless it is -already running). The [caller] can access DAD widget states and values -only between PCB_DAD_NEW() and PCB_DAD_FREE(). - Index: trunk/doc/developer/dad/wreal.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wreal.png =================================================================== --- trunk/doc/developer/dad/wreal.png (revision 34886) +++ trunk/doc/developer/dad/wreal.png (nonexistent) Property changes on: trunk/doc/developer/dad/wreal.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/wtree.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wtree.png =================================================================== --- trunk/doc/developer/dad/wtree.png (revision 34886) +++ trunk/doc/developer/dad/wtree.png (nonexistent) Property changes on: trunk/doc/developer/dad/wtree.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/wlabel.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wlabel.png =================================================================== --- trunk/doc/developer/dad/wlabel.png (revision 34886) +++ trunk/doc/developer/dad/wlabel.png (nonexistent) Property changes on: trunk/doc/developer/dad/wlabel.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/wbool.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wbool.png =================================================================== --- trunk/doc/developer/dad/wbool.png (revision 34886) +++ trunk/doc/developer/dad/wbool.png (nonexistent) Property changes on: trunk/doc/developer/dad/wbool.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/wenum.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wenum.png =================================================================== --- trunk/doc/developer/dad/wenum.png (revision 34886) +++ trunk/doc/developer/dad/wenum.png (nonexistent) Property changes on: trunk/doc/developer/dad/wenum.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/tree.html =================================================================== --- trunk/doc/developer/dad/tree.html (revision 34886) +++ trunk/doc/developer/dad/tree.html (nonexistent) @@ -1,32 +0,0 @@ - -
- --The table tree widget is a table containint cells arranged in a -fixed number of columns. Each cell is a dynamically allocated -char * string. - -
-These macros, defined in hid_dad.h, are used to fill up the last -created (tree) widget with initial data. They return a row pointer. If the -row pointer is NULL, root is used - in this case insert means inserting at -the beginning of the row list, append means append at the end of the row list. -
-When the tree widget is already created, typically when the dialog box -is already running, the code can use hid_dad_tree.h for reading or -changing cells or rows of the tree. Any change is immediately reflected -on the GUI. Please refer to the comments in hid_dad_tree.h for details -on the functions and arguments. - - - Index: trunk/doc/developer/dad/wprogress.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wprogress.png =================================================================== --- trunk/doc/developer/dad/wprogress.png (revision 34886) +++ trunk/doc/developer/dad/wprogress.png (nonexistent) Property changes on: trunk/doc/developer/dad/wprogress.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/wpicture.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wpicture.png =================================================================== --- trunk/doc/developer/dad/wpicture.png (revision 34886) +++ trunk/doc/developer/dad/wpicture.png (nonexistent) Property changes on: trunk/doc/developer/dad/wpicture.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/whbox.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/whbox.png =================================================================== --- trunk/doc/developer/dad/whbox.png (revision 34886) +++ trunk/doc/developer/dad/whbox.png (nonexistent) Property changes on: trunk/doc/developer/dad/whbox.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/intro.html =================================================================== --- trunk/doc/developer/dad/intro.html (revision 34886) +++ trunk/doc/developer/dad/intro.html (nonexistent) @@ -1,56 +0,0 @@ - -
- --Attribute Dialogs were originally invented around the early/mid 2000s for export -HIDs to store a static, flat list of options that are then presented both -as command line options and as the GUI dialog box for export parameters. - -
-DAD is the dyamically allocated version, extended with new widget types for -providing tools for building more complex dialog boxes. It is not connected -with command line options in any way at the moment. -
-The list of widgets is still a flat, growing C array, often called the -table. But inside the table, widgets build as a logical tree -structure. Widgets with name that includes "BEGIN" will open a new -logical layout level that has to be closed with a PCB_DAD_END(). - -
-A table is always built incrementally and sequentially. In this sense -the dialog box is static: once build and created, the number and -type of widgets can not be modified. The dynamic aspect is that the code -may create (and destroy) arbitrary DAD boxes, even with loops and -runtime conditions on what widgets end up in the box. -
-There are two kind of widget calls: widget creation and property set. -Property set calls always change the last created widget. This, by -convention, is often indicated by code indentation as well. For example: -
- PCB_DAD_INTEGER(dlg, "foo"); - PCB_DAD_MINVAL(dlg, 1); - PCB_DAD_MAXVAL(dlg, 10); - PCB_DAD_DEFAULT_NUM(dlg, 3); - widget_id_foo = PCB_DAD_CURRENT(dlg); - PCB_DAD_BUTTON(dlg, "update!"); - PCB_DAD_CHANGE_CB(dlg, pcb_act_attr_chg); --
-PCB_DAD_INTEGER() and PCB_DAD_BUTTON() are (macro) calls to create -new widgets (an integer entry and a button), the rest of the calls -change the last created widget's properties. -
-The main widget of the box, the root widget of the widget tree is -any widget. It is practical to make it a container widget (e.g. a HBOX, VBOX, -TABLE, PANE, or TABBED) so that it can host children widgets. -
-After each creation, the caller can query and store the integer widget -identifier using the PCB_DAD_CURRENT() macro. The widget identifier can -be used, together with the table, to query or change widget properties -and current value any time the dialog box is active. - Index: trunk/doc/developer/dad/wtable.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wtable.png =================================================================== --- trunk/doc/developer/dad/wtable.png (revision 34886) +++ trunk/doc/developer/dad/wtable.png (nonexistent) Property changes on: trunk/doc/developer/dad/wtable.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/wvbox.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/dad/wvbox.png =================================================================== --- trunk/doc/developer/dad/wvbox.png (revision 34886) +++ trunk/doc/developer/dad/wvbox.png (nonexistent) Property changes on: trunk/doc/developer/dad/wvbox.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc/developer/dad/index.html =================================================================== --- trunk/doc/developer/dad/index.html (revision 34886) +++ trunk/doc/developer/dad/index.html (revision 34887) @@ -1,14 +1,5 @@
- --All rendering is driven by the core. The core understands the PCB stackup, -layers, layer groups, compositions within the layer groups, extra labels, -layer visibility, etc. The HID is a slave device that takes drawing -instructions and blindly executes them. -
-However, the HID has a chance to alter which layer groups are drawn, using -the set_layer_group hooks return value. - -
-The rendering is done in bursts. A burst may redraw only a small window -of the screen. Each bursts draws multiple layer groups, in Z-order, from -bottom (furthest from the eye of the user) to up (closest to the eye of -the user). Each layer group is drawn on a transparent sketch canvas. In positive mode, -objects are drawn with multiple colors on each sketch canvas. In negative mode -pixels are erased from the sketch canvas, making the affected pixels transparent again. Drawing -on a layer group (either positively or negatively) should -overwrite pixels on the same layer group. In other words, there's -no translucency between two overlapping objects drawn on the same layer -group. - -
-There is a so called output canvas, which shall be cleared to -the background color upon render_burst / start. The background -color shall be fetched from the config tree (appearance/color/background). -
-The following steps are taken by the core in a burst: -
-When set_drawing_mode / reset is called, the HID needs to -create a new sketch canvas, all pixels initialized to transparent. The -core may switch between positive and negative draw any time. When -set_drawing_mode / flush is called, the current sketch -canvas needs to be blitted onto the output (in a HID-specific way) and -the sketch canvas can be destroyed. The output canvas shall be flushed to -the screen upon render_burst / end. -
-Optional optimization: the most common case is when only positively drawn -layers are used to draw the final output. Drawing on separate sketch canvases and -blitting them onto an output buffer is a waste in this setup. To give HIDs a -chance to avoid the extra copies, set_drawing_mode calls have an -argument called direct. When the direct is set, it is safe -to directly draw on the output canvas, without allocating a sketch canvas. The -core guarantees the followings: -
-It is possible that the core would draw the whole board in direct -mode. It is safe to ignore the direct argument and always use the -more expensive, sketch-canvas+blitting method. - -
-The API contains Graphic Context, or GC for short. A GC is a pen with -properties like color and tip shape. The core will initialize multiple -GCs for the drawing and will pass a GC pointer with each drawing command. -
-Note: this concept is orthogonal to the above canvas based drawing. -Regardless of which GC is used, the object being drawn always ends up -making modifications to the currently active (sketch) canvas. -
-A GC can be initialized only after render_burst / start -and all GCs will be uninitialized before render_burst / end. - -
-In negative drawing mode, drawing an object always clear on the current canvas, -regardless of the GC color. -
-In positive drawing mode, objects are drawn with whatever color the -current GC has. The special color "drill" is used to draw holes that go thru -all layers of the board. It is possible that a drill is drawn over existing -objects and new objects are drawn on top of a drilled hole. To get the -proper order, the HID shall set the .holes_after to 1. -
-(Note: there's no "erase" color anymore.) - - -
-When switching over an existing HID from the old use_mask() API to the new -composite API: -
-XOR draw is used as a mean to make an object always visible, no matter -over what background it is drawns. It is not used as a cheap draw/erase -mechanism, so HIDs are free to implement it with a different algorithm - as -long as it is guaranteed that objects drawn on the same colored background -will stick out. -
-There are two places XOR draw takes place: -
-In both cases the drawing mode is set to PCB_HID_COMP_POSITIVE_XOR, which does -not clear the direct flag. The GC that is used for drawing the actual -objects also has its xor mode set. - +Moved to librnd Index: trunk/doc/developer/hidlib/TODO =================================================================== --- trunk/doc/developer/hidlib/TODO (revision 34886) +++ trunk/doc/developer/hidlib/TODO (nonexistent) @@ -1,22 +0,0 @@ -What the user code needs to implement - -1. actions (optional) - StatusSetText() - DescribeLocation() - -2. docked DAD subwindows (optional) - bottom status line - top right coord readout - top left toolbar - -3. conventions - all calls have access to the current (pcb_hidlib_t *) - there's a design (pcb_board_t) - recommendation: the design struct's first field should be pcb_hildib_t so they can be casted forth and back - -4. icon colors: - - None - transparent - #000000 - black - #7A8584 - light grey - #6EA5D7 - cyan/blue Index: trunk/doc/developer/hidlib/init_seq.txt =================================================================== --- trunk/doc/developer/hidlib/init_seq.txt (revision 34886) +++ trunk/doc/developer/hidlib/init_seq.txt (nonexistent) @@ -1,117 +0,0 @@ -1. simplified (custom) init sequence - -This method is useful for the simplest, gui-only applications that -potentially do not have plugins. - -int main(int argc, char *argv[]) -{ - pcb_fix_locale_and_env(); - - /* set up non-hidlib related app states */ - ... - - pcb_hidlib_init1(conf_core_init); - - /* process command line args */ - ... - - pcb_hidlib_init2(pup_buildins); - - /* set up hidlib related app states - all main infrastructure is up by now */ - ... - - /* initialize the gui and run the main loop */ - pcb_gui = pcb_hid_find_gui(gui_name); - if (pcb_gui == NULL) { - pcb_message(PCB_MSG_ERROR, "can't find HID '%s'\n", gui_name); - pcbhl_log_print_uninit_errs(""); - exit(1); - } - if (pcb_gui->parse_arguments(&argc, &argv) != 0) { - pcb_message(PCB_MSG_ERROR, "can't init HID '%s'\n", gui_name); - pcbhl_log_print_uninit_errs(""); - exit(1); - } - pcb_gui->do_export(&camv.hidlib, 0); - - /* application state uninit */ - ... -} - - -2. standard init sequence - -Hidlib calls help to initialize the plugin system, parse the command line -argument, choose command line action, exporter or GUI in a standard way. -Full featured hidlib applications with feature and export plugins should -use this sequence. - -static const char *camv_action_args[] = { -/*short, -long, action, help, hint-on-error */ - "V", "-version", "PrintVersion()", "Print version info and exit", NULL, - "V", "-dump-version", "DumpVersion()", "Print version info in script readable format and exit", NULL, - NULL, "-copyright", "PrintCopyright()", "Print copyright and exit", NULL, - NULL, NULL, NULL, NULL, NULL /* terminator */ -}; - -int main(int argc, char *argv[]) -{ - pcbhl_main_args_t ga; - - pcb_fix_locale_and_env(); - - pcbhl_main_args_init(&ga, argc, camv_action_args); - - pcb_hidlib_init1(conf_core_init); - for(n = 1; n < argc; n++) { - /* process application-specific arguments here and skip the next line for those */ - n += pcbhl_main_args_add(&ga, argv[n], argv[n+1]); - } - pcb_hidlib_init2(pup_buildins); - - /* direct exporting via -x */ - if (pcbhl_main_args_setup1(&ga) != 0) { - camv_main_uninit(); - pcbhl_main_args_uninit(&ga); - exit(1); - } - -/* Initialize actions only when the gui is already known so only the right - one is registered (there can be only one GUI). */ -#include "generated_lists.h" - - if (pcbhl_main_args_setup2(&ga, &n) != 0) { - camv_main_uninit(); - pcbhl_main_args_uninit(&ga); - exit(n); - } - - if (ga.hid_argc > 0) { - /* command line leftover: typically file name(s) to load, in - ga.hid_argv[0 .. ga.hid_argc-1]; */ - } - - /* do the export if -x was specified */ - if (pcbhl_main_exported(&ga, ...)) { - camv_main_uninit(); - pcbhl_main_args_uninit(&ga); - exit(0); - } - - /* main loop */ - do { - /* optional: if a plugin is required for basic GUI operation, load it here */ - if (PCB_HAVE_GUI_ATTR_DLG) - gui_support_plugins(1); - pcbhl_mainloop_interactive(&ga, ...); - } while(pcb_gui != NULL); - - /* application specific uninit */ - ... - - pcbhl_main_args_uninit(&ga); - return 0; -} - - - Index: trunk/doc/developer/hidlib/index.html =================================================================== --- trunk/doc/developer/hidlib/index.html (nonexistent) +++ trunk/doc/developer/hidlib/index.html (revision 34887) @@ -0,0 +1,5 @@ + +
+Moved to librnd + + Index: trunk/doc/developer/indent.html =================================================================== --- trunk/doc/developer/indent.html (revision 34886) +++ trunk/doc/developer/indent.html (revision 34887) @@ -1,36 +1,5 @@ --indent --line-length256 -brs -br -nce --tab-size2 -ut -npsl -npcs -hnl -cli2 -nsaf -sai -nsaw -ncs -c0 -cd0 -cp0 --
-Contributors are kindly asked to follow this style or run the above -commandline on their new code before sending a patch or committing -to svn. The style of existing code lines should not be changed, -not even the "surrounding" lines to a largish patch, especially not in the -same patch/commit with actual code changes. -
-We do not put space between the pointer-asterisk and name; indent(1) -unfortunately does this in function declaration: -
| right | wrong - |
|---|---|
int foo(char *bar);
- | int foo(char * bar);
- |
-We have a patch against indent 2.2.11 to -fix this. -
-We do not use tabs for aligning code in columns; we use tabs exclusively -to indicate levels logical alignment. indent(1) attempts to align the -right-side comments using tabs. We have a patch -against indent 2.2.11 to change this when column is set to 0. - +Moved to librnd