mirror of https://github.com/KLayout/klayout.git
Updated doc and some images.
This commit is contained in:
Matthias Koefferlein
parent
287deaa574
commit
a8ac6aafe7
Binary file not shown.
|
Before Width: | Height: | Size: 138 KiB After Width: | Height: | Size: 130 KiB |
|
|
@ -14,7 +14,7 @@
|
|||
<p>
|
||||
In some places, the API requires to attach code to an event. An event could be a menu item which is selected
|
||||
or a change of some status which might require some action. The API allows implementation of specific code which is
|
||||
called in that case. This enables us to implement initialisation functionality for example or the functionality
|
||||
called in that case. This enables us to implement the functionality
|
||||
behind a menu item. In this text we will refer to such functionality by the general term "callback". In general
|
||||
a callback is custom code that is called from the API in contrast to API code that is called from the custom code.
|
||||
</p>
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
</p>
|
||||
|
||||
<ul>
|
||||
<li><b>Reimplementation (Strategy Pattern)</b>: some API classes provide "virtual" methods. "virtual" is a C++ term and
|
||||
<li><b>Reimplementation</b>: some API classes provide "virtual" methods. "virtual" is a C++ term and
|
||||
means a method that can be overridden in a derived class. This technique is employed for example in the
|
||||
"Strategy" design pattern. In strictly typed C++ this is quite a common pattern which allows definition of interfaces
|
||||
and concrete implementations based on those interfaces. Ruby as a dynamic language doesn't care much about
|
||||
|
|
@ -43,6 +43,11 @@
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The "Observer" class which was there prior to KLayout 0.25 has been dropped in favour of the more
|
||||
flexible events. It is no longer supported.
|
||||
</p>
|
||||
|
||||
<h2>Reimplementation (Strategy Pattern)</h2>
|
||||
|
||||
<p>
|
||||
|
|
@ -98,65 +103,10 @@ end</pre>
|
|||
|
||||
end</pre>
|
||||
|
||||
<h2>Observer</h2>
|
||||
|
||||
<p>
|
||||
Using the Observer pattern requires an additional object. Again reimplementation
|
||||
allows attaching custom functionality to the callback. In contrast to the Strategy pattern,
|
||||
the interface is very generic and can supply only few parameters, if there are parameters
|
||||
at all.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
An observer is an object of a class derived from the Observer class (<class_doc href="Observer"/>).
|
||||
An example for a use case for the Observer is the LayoutView class (<class_doc href="LayoutView"/>). This class
|
||||
offers multiple events that indicate certain conditions. Here is some code:
|
||||
</p>
|
||||
|
||||
<pre>module MyMacro
|
||||
|
||||
include RBA
|
||||
|
||||
class MyObserver < Observer
|
||||
def signal
|
||||
Application::instance.main_window.message("Selection changed", 1000)
|
||||
end
|
||||
end
|
||||
|
||||
observer = MyObserver::new
|
||||
Application::instance.main_window.current_view.add_selection_changed_observer(observer)
|
||||
|
||||
end</pre>
|
||||
|
||||
<p>
|
||||
In this example, an observer is created and attached to the "selection_changed" event of
|
||||
LayoutView using "add_selection_changed_observer". When the selection changes, the "signal"
|
||||
method of the observer is called. By reimplementing that method we show a short message
|
||||
in the MainWindow's status bar.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Because Ruby is a dynamic language and allows overriding of methods per instance, we can simplify
|
||||
the example further which avoids having to create a new class:
|
||||
</p>
|
||||
|
||||
<pre>module MyMacro
|
||||
|
||||
include RBA
|
||||
|
||||
observer = MyObserver::new
|
||||
def observer.signal
|
||||
Application::instance.main_window.message("Selection changed", 1000)
|
||||
end
|
||||
|
||||
Application::instance.main_window.current_view.add_selection_changed_observer(observer)
|
||||
|
||||
end</pre>
|
||||
|
||||
<h2>Events</h2>
|
||||
|
||||
<p>
|
||||
Events are the callback variant that is the easiest one to use. Using an event it is possible
|
||||
Events are the callback variant which is the easiest one to use. Using an event it is possible
|
||||
to directly attach a block of code to a callback. An event has a specific signature, i.e.
|
||||
the parameters it provides. The block can obtain this parameters by listing them in it's argument list.
|
||||
</p>
|
||||
|
|
@ -211,7 +161,7 @@ end</pre>
|
|||
|
||||
<p>
|
||||
If the Qt binding is available (see <link href="/programming/qt_binding.xml"/>), Qt signals
|
||||
are available as events which simplifies the implementation of a Qt dialog. In this example,
|
||||
are implemented as events. This way it's very simple to create a Qt dialog. In following example,
|
||||
the "textChanged" signal of QLineEdit is attached a code block which copies the text of the
|
||||
input field to the label below:
|
||||
</p>
|
||||
|
|
@ -230,12 +180,34 @@ end</pre>
|
|||
# implement the textChanged signal as event:
|
||||
input.textChanged { |text| label.text = text }
|
||||
|
||||
dialog.exec
|
||||
|
||||
end</pre>
|
||||
|
||||
<p>
|
||||
Please note that unlike Qt signal/slots, this technique does not allow to attach multiple
|
||||
handlers to one event/signal.
|
||||
Using the += operator on the event, multiple handlers can be added to a signal:
|
||||
</p>
|
||||
|
||||
<pre>module MyMacro
|
||||
|
||||
include RBA
|
||||
|
||||
dialog = QDialog::new(Application::instance.main_window)
|
||||
layout = QVBoxLayout::new(dialog)
|
||||
input = QLineEdit::new(dialog)
|
||||
label1 = QLabel::new(dialog)
|
||||
label2 = QLabel::new(dialog)
|
||||
layout.addWidget(input)
|
||||
layout.addWidget(label1)
|
||||
layout.addWidget(label2)
|
||||
|
||||
# two signal consumers:
|
||||
input.textChanged += lambda { |text| label1.text = text }
|
||||
input.textChanged += lambda { |text| label2.text = text.reverse }
|
||||
|
||||
dialog.exec
|
||||
|
||||
end</pre>
|
||||
|
||||
</doc>
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,6 @@
|
|||
<topic href="/programming/ruby_binding.xml"/>
|
||||
<topic href="/programming/ruby_pcells.xml"/>
|
||||
<topic href="/programming/qt_binding.xml"/>
|
||||
<topic href="/programming/traditional.xml"/>
|
||||
<!-- TODO: more -->
|
||||
</topics>
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,6 @@
|
|||
<b>Scripts</b> are simple text files which are prepared externally and KLayout acts as an interpreter for these scripts.
|
||||
A special case of scripts is included code, while is loaded into other scripts or macros using "require" on Ruby
|
||||
or "import" on Python. Scripts have been the only way to code Ruby functionality in version 0.21 and earlier.
|
||||
That way is still supported, but deprecated (See <link href="/programming/traditional.xml"/>).
|
||||
</li>
|
||||
<li>
|
||||
<b>Macros</b> are special XML files which contain Ruby code plus some additional information required to
|
||||
|
|
|
|||
|
|
@ -18,17 +18,21 @@
|
|||
<pre>build.sh -with-qtbinding ...</pre>
|
||||
|
||||
<p>
|
||||
The API provided covers the functionality of Qt 4.6. To build KLayout with Qt binding,
|
||||
at least Qt version 4.6.2 is required. The API covers the following Qt modules:
|
||||
The API provided covers the functionality of a certain Qt version. Currently this is Qt 4.6 and Qt 5.5.
|
||||
The API covers the following Qt 4 and Qt 5 modules:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>QtCore: the basic Qt API</li>
|
||||
<li>QtGui: the user interface widgets and supporting classes</li>
|
||||
<li>QtXml: support for XML</li>
|
||||
<li>QtXmlPatterns (Qt5): XML schema and queries</li>
|
||||
<li>QtSql: database support</li>
|
||||
<li>QtNetwork: various network protocols and supporting classes</li>
|
||||
<li>QtDesigner: dynamically load designer files (.ui)</li>
|
||||
<li>QtMultimedia (Qt5): multimedia support</li>
|
||||
<li>QtPrintSupport (Qt5): print support</li>
|
||||
<li>QtSvg (Qt5): SVG implementation</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -79,8 +79,8 @@
|
|||
|
||||
<p>
|
||||
RBA/GSI follows a simple principle that significantly simplifies the implementation: who created
|
||||
an object is responsible for cleaning it up. In different words: a reference is not transferred between C++ and Ruby space.
|
||||
Thus we have to consider two cases: The
|
||||
an object is responsible for cleaning it up. In other words: a ownership of an object is usually
|
||||
not transferred between C++ and Ruby space. Thus we have to consider two cases: The
|
||||
object is created in Ruby or the object is created in C++ code. Literally the object "lives" in Ruby
|
||||
space or in C++ space. In both cases, there is a pair of objects, but one of them is controlling
|
||||
the other.
|
||||
|
|
@ -121,12 +121,13 @@ cell.shapes(layer).insert(box)</pre>
|
|||
Ruby to C++. RBA handles that case by explicitly transferring control when a QObject or one of the
|
||||
derived objects is created with a parent reference in Ruby code. Qt implements it's own mechanism of controlling
|
||||
the lifetime which includes monitoring of the lifetime of child objects. This feature makes transferring the
|
||||
control feasible for these kind of objects.
|
||||
control feasible for these kind of objects. For some Qt methods which are know to transfer the ownership
|
||||
of an object, the ownership is transferred explicitly.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
An object living in Ruby space can be explicitly deleted to free resources for example. For this, the
|
||||
"destroy" method is provided. This method will only deleted the C++ object and not the Ruby object. However,
|
||||
"_destroy" method is provided. This method will only deleted the C++ object and not the Ruby object. However,
|
||||
the Ruby object will become invalid and calling a method on such an object will result in an error.
|
||||
</p>
|
||||
|
||||
|
|
@ -137,36 +138,12 @@ cell.shapes(layer).insert(box)</pre>
|
|||
Ruby object is still alive but the C++ object is deleted. In that case, the flavor of the link between
|
||||
the Ruby proxy and C++ object is important: if the link is bidirectional, the C++ object will inform the
|
||||
Ruby proxy that the reference will become invalid. The Ruby proxy will mark itself as being invalid and
|
||||
will block further calls to methods. If the link is unidirectional that is not possible and this situation
|
||||
bears the danger of invalid references with fatal consequences if an attempt is made to call a method
|
||||
then.
|
||||
will block further calls to methods. Object supporting this reference binding are the API classes
|
||||
and "bigger" database objects such as Cell or Layout.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Fortunately that case is rare. A situation frequently encountered is that:
|
||||
</p>
|
||||
|
||||
<pre>// C++:
|
||||
const Box &Polygon::bounding_box() const { return m_bounding_box; }
|
||||
|
||||
# Ruby:
|
||||
polygon = RBA::Polygon::new
|
||||
...
|
||||
box = polygon.bounding_box
|
||||
polygon = nil
|
||||
... after some time the polygon is deleted and if box was a reference this would crash:
|
||||
puts box.width</pre>
|
||||
|
||||
<p>
|
||||
From that example we learn that we shall be careful by exposing aggregations
|
||||
through references. The solution is to create a copy from a
|
||||
const reference. The copy then lives in Ruby space and is basically detached from the
|
||||
C++ object.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If copying is not an option because the object is too heavy, a bidirectional link will be used
|
||||
in most cases. For example:
|
||||
For example:
|
||||
</p>
|
||||
|
||||
<pre>main_window = ... # the RBA::MainWindow object
|
||||
|
|
@ -176,10 +153,19 @@ view = main_window.current_view
|
|||
main_window.close_all
|
||||
# this will fail, because the view is a Ruby proxy that knows that the C++ object
|
||||
# has been deleted:
|
||||
view.load_layout(...)</pre>
|
||||
view.load_layout(...)
|
||||
# You can check this by asking "_destroyed?". This will return "true":
|
||||
view._destroyed?</pre>
|
||||
|
||||
<p>
|
||||
Calling "destroy" on an object living in C++ space is not safe in general. In some cases, this can have
|
||||
For "lightweight" objects such as the geometry primitives (Box, Polygon etc.), the link is unidirectional
|
||||
and lifetime monitoring is not possible. This situation
|
||||
bears the danger of invalid references with fatal consequences if an attempt is made to call a method
|
||||
then. Fortunately this case is rare and usually mitigated by providing an object clone.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Calling "_destroy" on an object living in C++ space is not safe in general. In some cases, this can have
|
||||
fatal consequences (i.e. destroying the MainWindow object). An exception from that rule are Qt objects
|
||||
because Qt does lifetime monitoring internally and destroying an object from the outside (Ruby) is
|
||||
a valid operation in most cases (although there are exceptions).
|
||||
|
|
@ -388,8 +374,10 @@ A::new.f(x)
|
|||
<h3>Hash arguments and return values</h3>
|
||||
|
||||
<p>
|
||||
Some functions support hashes for arguments and return types. Unlike Ruby, C++ hashes
|
||||
(maps) are strictly typed, so it's important to provide the right key and value pairs.
|
||||
Associative containers (std::map, QHash etc.) are mapped to Ruby hashes.
|
||||
Unlike Ruby, C++ associative containers are strictly typed, so it's important to provide the right key and value pairs.
|
||||
</p>
|
||||
|
||||
</p>
|
||||
|
||||
<h3>Default arguments</h3>
|
||||
|
|
|
|||
|
|
@ -1,258 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE language SYSTEM "klayout_doc.dtd">
|
||||
|
||||
<doc>
|
||||
|
||||
<title>Traditional Ruby Programming</title>
|
||||
<keyword name="Programming"/>
|
||||
<keyword name="RBA"/>
|
||||
<keyword name="Ruby scripts"/>
|
||||
|
||||
<index/>
|
||||
|
||||
<p>
|
||||
Before version 0.21 and the development IDE, Ruby scripts had to be prepared externally and KLayout had to be
|
||||
restarted to use them. In addition, binding a script to a menu entry required some coding.
|
||||
This method still is supported for version 0.22, hence it is described here. It is provided for backward compatibility
|
||||
and because KLayout can be used as a standalone engine for RBA scripts without a user interface.
|
||||
</p>
|
||||
|
||||
<h2>Using RBA scripts</h2>
|
||||
|
||||
<p>
|
||||
To use RBA, the script location must be passed to KLayout using the "-r" option (in this example "hello_world.rb"):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
klayout -r hello_world.rb</pre>
|
||||
|
||||
<p>
|
||||
If used this way, all RBA functionality must be put into one script. Usually, this script will provide all the
|
||||
classes and definitions required and register new menu items and handlers.
|
||||
</p>
|
||||
|
||||
<h2>Basic RBA</h2>
|
||||
|
||||
<p>
|
||||
The ruby script given with the "-r" option is executed before the actual application is
|
||||
started. In fact, the application execution is initiated by the script, if one is given.
|
||||
In order to make the application start, the ruby script must contain at least this statement:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
RBA::Application.instance.exec</pre>
|
||||
|
||||
<p>
|
||||
"RBA" is the module provided by KLayout. "Application" is the main controller class (a singleton)
|
||||
that refers to the application as a whole. It provides the "exec" method which runs the application
|
||||
and returns if the main window is closed.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In most cases, the script will perform initialization steps before calling "exec" and may do cleanup
|
||||
once the application returned. Initialization may involve loading of layouts, registering menu items,
|
||||
initializing other resources etc. However, the "exec" call can be omitted and then KLayout acts as
|
||||
a pure interpreter for the script.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In larger applications
|
||||
however, source code is usually organised into libraries and a main code part. Libraries and
|
||||
supplementary code can be loaded prior to the loading of the main source with the "-rm" option. Files loaded
|
||||
with this option do not need to (and in fact must not) contain the "RBA::Application.instance.exec" call. This allows
|
||||
providing independent libraries and initialisation code to a RBA script environment:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
klayout -rm setup1.rb -rm setup2.rb -r hello_world.rb</pre>
|
||||
|
||||
<p>
|
||||
RBA code can be installed globally by creating a file with suffix ".rbm" in the same directory than the
|
||||
KLayout binary. If such files are encountered, they will be executed automatically
|
||||
before all files specified with "-rm" and "-r" are read.
|
||||
</p>
|
||||
|
||||
<h2>A simple example</h2>
|
||||
|
||||
<p>
|
||||
This example script registers a new menu item in the toolbar, which displays a message box saying "Hello, world!"
|
||||
when selected, and runs the application:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
class MenuHandler < RBA::Action
|
||||
def triggered
|
||||
RBA::MessageBox::info( "Info", "Hello, world!", RBA::MessageBox::b_ok )
|
||||
end
|
||||
end
|
||||
|
||||
app = RBA::Application.instance
|
||||
|
||||
$menu_handler = MenuHandler.new
|
||||
$menu_handler.title = "RBA test"
|
||||
|
||||
menu = app.main_window.menu
|
||||
menu.insert_item("@toolbar.end", "rba_test", $menu_handler)
|
||||
menu.insert_item("tools_menu.end", "rba_test", $menu_handler)
|
||||
|
||||
app.exec</pre>
|
||||
|
||||
<p>
|
||||
This simple example already demonstrates some important concepts:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><b>Reimplementation</b>: the menu item's functionality is implemented by
|
||||
reimplementing the Action object's "triggered" method. This method is called
|
||||
when the menu item is selected.</li>
|
||||
<li><b>Delegation</b>: the menu item is not implemented directly but
|
||||
the implementation is delegated to an "Action" object. The action provides
|
||||
the "slot" that the menu item refers to. One action may be used for multiple
|
||||
menu items. The action does not only provide the implementation but the
|
||||
title, keyboard shortcut and other properties of the menu item. This way, the
|
||||
action may be used in multiple places (i.e. menu and toolbar) and still appear
|
||||
the same.</li>
|
||||
<li><b>Menu item addressing</b>: The menu item is addressed by a "path" expression.
|
||||
In this case, the path is used for specifying the place where to insert the item.
|
||||
The path "@toolbar.end" instructs the menu controller to insert the item at the
|
||||
end of the toolbar. The path "tools_menu.end" instructs it to insert the item at
|
||||
the end of the "Tools" menu. The second string passed to "insert" is the name
|
||||
of the new item. After inserting, the new item can be addressed with the path "@toolbar.rba_test"
|
||||
and "tools_menu.rba_test".</li>
|
||||
<li><b>Ownership of objects</b>: RBA is not able to guarantee a certain lifetime of an
|
||||
object, because Ruby and C++ implement different lifetime management models. Specifically, for
|
||||
the action object this means, that the menu controller, which is implemented in C++ cannot
|
||||
tell ruby that it keeps a reference to the action object. Without further measures, ruby will
|
||||
ignore this relationship and delete the action object - the menu item will disappear.
|
||||
To overcome this problem, an explicit reference to the action object must be held. In this
|
||||
case, a global variable is used ("$menu_handler"). This could as well be a member of an object
|
||||
or an array member.<br/>
|
||||
It is very important to keep this aspect in mind when designing RBA applications.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Documentation for the various classes involved can be found in <link href="/code/index.xml"/>.
|
||||
</p>
|
||||
|
||||
<h2>Extending the example</h2>
|
||||
|
||||
<p>
|
||||
To give the menu callback a more "ruby style" look, a wrapper can be created what allows
|
||||
to attach code to the menu in the style of a ruby iterator. Now the callback uses "yield" to
|
||||
execute the code attached to the menu. In addition, the menu item now uses a icon and a keyboard
|
||||
shortcut ("Shift+F7"):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
class MenuHandler < RBA::Action
|
||||
def initialize( t, k, i, &action )
|
||||
self.title = t
|
||||
self.shortcut = k
|
||||
self.icon = i
|
||||
@action = action
|
||||
end
|
||||
def triggered
|
||||
@action.call( self )
|
||||
end
|
||||
private
|
||||
@action
|
||||
end
|
||||
|
||||
app = RBA::Application.instance
|
||||
|
||||
$menu_handler = MenuHandler.new( "RBA test", "Shift+F7", "icon.png" ) {
|
||||
RBA::MessageBox::info( "Info", "Hello, world!", RBA::MessageBox::b_ok )
|
||||
}
|
||||
|
||||
menu = app.main_window.menu
|
||||
menu.insert_item("@toolbar.end", "rba_test", $menu_handler)
|
||||
menu.insert_item("tools_menu.end", "rba_test", $menu_handler)
|
||||
|
||||
app.exec</pre>
|
||||
|
||||
<h2>Events</h2>
|
||||
|
||||
<p>
|
||||
Starting with version 0.21, RBA features "events". Events allow to specify a Ruby block which
|
||||
is called when a certain condition takes place. Using events eliminates the need for
|
||||
deriving a from an existing class. In particular, with version 0.21, RBA::Action features one
|
||||
event called "on_triggered". A block associated with this event is called, when the action
|
||||
is triggered.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
With events the example looks like that:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
app = RBA::Application.instance
|
||||
|
||||
$menu_handler = RBA::Action.new
|
||||
$menu_handler.title = "RBA test"
|
||||
$menu_handler.shortcut = "Shift+F7"
|
||||
$menu_handler.icon = "icon.png"
|
||||
|
||||
# install the event
|
||||
$menu_handler.on_triggered {
|
||||
RBA::MessageBox::info( "Info", "Hello, world!", RBA::MessageBox::b_ok )
|
||||
}
|
||||
|
||||
menu = app.main_window.menu
|
||||
menu.insert_item("@toolbar.end", "rba_test", $menu_handler)
|
||||
menu.insert_item("tools_menu.end", "rba_test", $menu_handler)
|
||||
|
||||
app.exec</pre>
|
||||
|
||||
<h2>Using KLayout as a pure interpreter</h2>
|
||||
|
||||
<p>
|
||||
KLayout can be used as a RBA interpreter without user interface. That allows implementation of
|
||||
layout processing scripts using the provided RBA bindings to the layout database objects, namely RBA::Layout.
|
||||
You cannot use user interface objects
|
||||
in that mode and the RBA::MainWindow instance will be nil. You can pass parameters from the command line to
|
||||
the script by defining Ruby variables.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Here is an example which reads a layout and converts it to OASIS with some special settings:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
ly = RBA::Layout.new
|
||||
ly.read($input)
|
||||
|
||||
gzip = false # or true to use gzip on the file
|
||||
|
||||
# special settings for OASIS output
|
||||
opt = RBA::SaveLayoutOptions::new
|
||||
opt.format = "OASIS"
|
||||
opt.dbu = 0.0001
|
||||
opt.oasis_write_cblocks = true
|
||||
opt.oasis_strict_mode = false
|
||||
opt.oasis_compression_level = 10
|
||||
|
||||
ly.write($output, gzip, opt)</pre>
|
||||
|
||||
<p>
|
||||
Assume that script is saved to "write_oas.rb". To run that script, use the following KLayout call:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
klayout -rx -r write_oas.rb -z -rd input=in.gds -rd output=out.oas</pre>
|
||||
|
||||
<p>
|
||||
The two "-rd" options will instruct KLayout to define two Ruby variables for the input and output file name. They can be used
|
||||
as "$input" and "$output" in the script.
|
||||
</p>
|
||||
<p>"-z" will disable the user interface. Therefore, this
|
||||
KLayout call can be used in scripts and on servers without X connection for example.
|
||||
</p>
|
||||
<p>"-rx" will
|
||||
disable all implicitly loaded scripts such as autorun macros which speeds up application start and
|
||||
avoids undesired side effects.
|
||||
</p>
|
||||
|
||||
</doc>
|
||||
|
||||
|
||||
|
|
@ -271,7 +271,6 @@
|
|||
<qresource prefix="/help/programming">
|
||||
<file alias="introduction.xml">doc/programming/introduction.xml</file>
|
||||
<file alias="python.xml">doc/programming/python.xml</file>
|
||||
<file alias="traditional.xml">doc/programming/traditional.xml</file>
|
||||
<file alias="index.xml">doc/programming/index.xml</file>
|
||||
<file alias="application_api.xml">doc/programming/application_api.xml</file>
|
||||
<file alias="database_api.xml">doc/programming/database_api.xml</file>
|
||||
|
|
|
|||
Loading…
Reference in New Issue